Your Tools Don't Last Because It's Nobody's Job
If you have internal tools, you know how this ends
Meet Nate.
He’s a senior structural engineer. The kind of person that’s always looking for ways to make delivery less painful.
He was working on a high-rise project which has concrete columns. It was a 23 floor building with about 20 or so columns per level. What engineers then typically do to assess the columns, is a technique called a “column load rundown”.
You take results from the analysis model, put them into a design program, and check that every column works. The problem though, is you have to do this for each column on every floor. On this project, that’s more than 400 columns. And every time there’s a design change, you do it again.
It is as tedious as it actually sounds.
Which is why it’s known as a “rite of passage” for graduate engineers. Because it’s labour intensive and considered as “engineering grunt work”, most companies make graduates do them. That solves the cost issue but it still takes a long time to do them.
So, most companies have some sort of workflow to speed this up. Not fully automated but not entirely manual either. Generally, enough for new graduates produce results in a decent amount of time but still too tedious for senior engineers to use.
In this company, Nate built that workflow. It was an Excel spreadsheet that would take the results from an analysis model and through some inputs, it would design all the columns per floor. That meant, the graduates on this project only had to do this 23 times instead of 400+ times. What used to take three days now took about four hours.
But the spreadsheet wasn’t perfect. It only supported one analysis program and it only handled single-storey columns. And since Nate is busy with other projects all the time, the spreadsheet fell behind with each new requirement it couldn’t handle.
Not to mention, fixing a spreadsheet he built for other teams isn’t in his KPIs. It won’t get him promoted. Upper management only cares about how billable he is, not what tools he’s made. It’s not something he can justify spending a Tuesday on when there are deadlines to hit.
And so, the spreadsheet remains out of date. People still use it because it’s still better than doing the rundowns manually. But they start working around it, adding band-aids to cover for the things it can’t do.
In fact, there’s a new graduate working on this project, her name is Rey, and she’s using AI to build a new column rundown spreadsheet because she can’t get Nate’s to work.
But we all know how that goes...
Hi, I’m Braden
I help teams be more efficient in the AEC Industry, then share stories about it here. I also have courses, guides and scripts as part of CodedShapes Pro
Check it out if that sounds like you.
If you’re new to CodedShapes, welcome! You might enjoy these:
The tension of being billable vs internally useful
Nate’s story, unfortunately, represents most internal tools ever built in the AEC (Architecture, Engineering, Construction) industry. Unless it’s a company’s core business offering, tools like these always follow a similar story.
Nate wasn’t trying to build a product. He was just trying to get through a painful process faster. He saw a problem, and he built something that fixed it. Which is most people in this industry. No one is thinking about “internal tooling” or “automation strategy.” Everyone just wants something that makes their lives easier.
Not to mention, building something that solves your exact problem is fun and creative. Chatting to AI or even building a new spreadsheet is more fun than doing a column rundown for 400+ columns over and over again.
But the minute you build something useful that everyone else wants, there’s a tension on your time that didn’t exist before. You now have to teeter between being billable and being internally useful because you now accidentally own what you’ve built
Doing a column rundown one by one is slow, but you’re making progress. And you can charge that time to the project because that’s just what it takes to get it done. But if you work on Nate’s tool, how do you charge your time to something that helps on all projects?
It becomes a battle of solving today’s problem vs solving it in a way that lasts.
And companies usually only rewards the first because anytime that isn’t charge to projects is considered overhead. And when the company looks to promote Nate, it’ll be because of his projects, not because of the spreadsheets he made. Nobody gets promoted for maintaining an Excel sheet.
If we look at pure software development, there’s a reason why “product management” exists as a completely separate role. It’s the work of tracking what’s broken, deciding what to improve, and checking its alignment with the current business.
It’s maintenance, and it’s treated as real work.
AEC has nothing like this. The person who builds the tool is the product manager, the support team, the developer, and they’re also a full-time engineer with billable targets. Which is why most of these tools die.
The Rebuild Reflex
With AI in the mix now, building things is faster than ever. You can get a working macro, a script, even a small app in a few a hours. The barrier to creating something has basically collapsed.
Which means the ownership problem gets worse.
Before AI, building something took enough effort that most people wouldn’t bother. They’d work with whatever tools they had, even if those tools were somewhat broken. But now, instead of wrestling with Nate’s semi-broken spreadsheet, anyone can just build their own version. I call this the rebuild reflex. It’s when it feels easier to rebuild something from scratch than to understand and maintain what already exists.
And project deadlines accelerate this. You’re even more inclined to build rather than maintain because the known effort of creating something new feels safer than the unknown effort of debugging someone else’s thing. Even if it’s objectively slower, it feels more in your control.
So, instead of one well-maintained tool, you end up with a dozen half-working ones. All doing roughly the same thing but uniquely for each project.
And well, from a numbers point of view, individual productivity goes up because everyone has a new tool that solves their problem. But what companies miss is the drift in quality and standards. When everyone does things their way, there’s no consistent bar for delivery anymore. How do you standardize the way people do things if they are all on unique tools ?
Not to mention, a graduate and a senior can both ask AI to build a column rundown spreadsheet. But the senior knows which features actually matter. They know enough to hone in on where normal spreadsheets fail. They know what “correct” means in context.
But a graduate who just started might just listen to the AI, even when it’s wrong. And if their manager is too busy to do a thorough review, that could lead to a real problem. I don’t even want to think about what happens when that graduate-made spreadsheet ends up in the hands of other graduates. (Yes, I’ve seen this happen.)
If you’ve got something manual and repetitive, come chat with me to see if we can build something to ease that burden.
The chat is always free.
The Missing Role
So what did Nate’s team actually need? Well, they needed someone who owned the tool. Someone who could filter through requests, decide what changes mattered, and actually had the time to make them.
In other words, a product owner.
Now, I know that sounds like a role most 20-person AEC firms can’t justify. And that’s kind of true because the reality is that most firms don’t have the volume of tools or the budget to warrant a full-time hire for that.
But that doesn’t mean the work doesn’t need to happen. It just means you have to be intentional about how it happens. Because if you make “being billable” compete against “working on internal tools” for the average person, being billable will always win. Which is why the tools die.
One option is working with someone external who can fill that role for you. Someone who helps develop and maintain your tools without pulling your billable staff off projects. That’s a lot of what I do for my clients. It means you don’t have to keep someone fully resourced on just the tools, and there’s no battle between being billable and internal development.
Not to mention I work with you to figure out the direction of the tools, I don’t just come in and assume control, we’ll still work together on it.
If that sounds like something that could help, reply to this email or book a time to chat through the button below.
Thanks for reading.