Does Your Tool Still Fit the Way You Work?
Don't wait until it's too late.
About ten years ago, a steel roof panel fabrication company built an internal tool that changed how they worked. With some inputs and a button, the tool turned an engineer-designed Excel spreadsheet into a 3D model and drawings. It became an integral part of their client delivery process.
For what they needed at the time, it was perfect. They delivered faster and more consistently than they ever had before.
But over the decade, things changed. The company grew and started taking on more custom projects from clients. They expanded from one product line to five. They are now also looking to migrate to Tekla Structures, a more modern program than what they were using. And all this while, there were no updates to the tool. It still used the same templates and workflows from a decade ago.
I was brought in because they wanted to explore migrating their tool to Tekla. I thought it was going to be straight forward, after all, most companies don’t have such a strong workflow. But what I found instead, was a tool that was poorly designed, full of hard-coded variables and worst of all deeply entwined with old processes. The kind of thing where changing one thing breaks everything else, a glass cannon, if you will.
The tool also only worked for one out of five product lines. The templates that once standardized their process now blocked the custom work their clients were asking for. And moving to Tekla meant an overhaul of 15 years of accumulated process decisions and assets.
Needless to say, the quote was expensive. And sadly but unsurprisingly, they didn’t accept it.
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:
How tools drift
So this is actually one of the most common ways internal tools become a problem. The tool was right when it was built. It met the needs of the entire business. In fact, it even enhanced their delivery.
But time doesn’t stop and neither do the needs of the business. As they grew, the people that worked on the tool left and it was never maintained nor updated. When that happens, the context for why the tool was built the way it was goes with them. The tool bifurcated from what the business needed it to do. Yet, they kept using it because it was easier to workaround it than to update it, at least, until now.
In my experience, there are three ways a tool falls out of alignment with the people using it.
The process changed but the tool didn’t.
The team refines how they work. They adopt new standards, restructure how they deliver projects, maybe even expand into a new line of business. But the tool stays locked in time.
Sometimes it’s because nobody budgeted for updates or maintenance. But most of the time it’s the sunk cost fallacy, companies think once they invested in building the tool, they should only reap the rewards. That they’ve invested three months into development, so why would they keep putting money into it?
Success expanded the scope.
Counterintuitively, sometimes success is why internal tools fail. I’ve seen cases where the first release was so well-received that requests flooded in. And instead of redesigning and integrating those properly, new features just got tacked on. And on. And on. Until updating it means untangling years of organic growth that was never structured to scale.
The tool kept taking on more responsibility without the proper foundations to support it. Making a tool for one person and making a tool for a company are very different endeavors. So, it becomes more brittle as time passes, making both the usage and maintenance of the tool progressively harder.
The team outgrew it.
Tools work best when there’s a solid process behind them. The fabrication company built templates for their tool, which is smart because the more standardized the process, the easier it is to automate on top of it. That meant for repeat clients, they could save about 50% of turnaround time.
But adding templates also meant tightly coupling the tool to their old program. And as the company took on more custom work and expanded their product lines, they outgrew those templates. Every time they tried to update them, something broke. So they stopped trying and just worked around it instead.
Now, the templates that once sped up their delivery, now hindered the work they actually needed to do. The tool went from working for them to working against them.
Subscribe to CodedShapes and I’ll send you my free guide on how to actually apply technology to your projects
Why it’s hard to notice
These three things happen when nobody’s monitoring the alignment between the tool and the company. It also doesn’t help that the tool doesn’t give you any indication of misalignment.
The tool technically still works and since it’s too fragile to update, people just work around it. They add a manual workaround here, a workaround there. Each one doesn’t feel like a big deal. But, over time, these workarounds then become the default mode of operating.
The fabrication company only found out about this misalignment when market pressure forced them to move. By then, fixing it was expensive and an operational nightmare, when it could have been a series of small, incremental updates spread over years.
Functional vs alignment
So, it comes down to what I call functional vs alignment.
Most tools work, they are functional. You put in the inputs and it spits out a result. It does exactly what it was designed to do.
But that’s the baseline, it’s what any tool should do at its minimum. The better question is whether the tool is aligned to the way you work. As in, when you have new processes, does the tool work the way we want it to?
“Functional” is a technical question. “Alignment” is then a people and process question. It’s about whether the tool matches the way the team actually operates right now.
A tool can pass every technical check and still be the wrong tool for the job. And depending on how far the tool has drifted from the current process, it becomes a burden rather than an advantage.
That’s much harder to find because you can’t test for it. There’s no error message that says “this tool no longer fits your process.” And in fact, what people don’t always realize is that the more you build now, the more you have to maintain.
Misalignment is dangerous precisely because it’s not visible until it’s already expensive to fix.
What actually fixes this
The instinct is usually to rebuild. A clean slate with new requirements and fresh energy. That’s what the fabrication company wanted. They didn’t want to deal with the complexity of an old, poorly designed tool. So the idea, was to migrate what made the old tool work into a new one.
Which for them, even though they declined my offer, is the best move. Because the old tool has diverged too far from the original design. But if they simply rebuilt the tool and not maintained it, they would be repeating this cycle over again.
The good news, is that there are two things anyone can do to break the cycle. They are simple but like most things, they aren’t easy.
Check the fit regularly.
This is the biggest lever you have. Any time an existing tool causes friction or you find yourself making a workaround, ask: does this tool still fit our process?
This single question combined with having regular review sessions will ensure that the tool is aligned with how any business is moving. If there’s friction between the tool and the way you’re working, it’s a signal that the tool might be out of date and it’s time to put in a fix while it’s small.
And if you can document everything diligently, you end up with a history of how both the tool and your process have evolved, which is incredibly useful the next time someone asks “why does it work this way?”
Make room for small changes.
If the person closest to the tool can see the drift but can’t do anything about it, you’re just watching the problem grow. It doesn’t always mean rebuilding. Sometimes people just need the room to make incremental changes without it turning into a budgetary affair.
I have seen this time and time again when drafters make manual workarounds for internal Revit plugins. Whether the plugin really should just be updated but the company didn’t want to invest in the plugins anymore until it was causing them too much trouble.
If you budget for maintenance from the beginning, smaller adjustments made earlier will cost a fraction of what they cost later. Let the problems accumulate and the effort / time it takes to fix them will compound.
When the tool has already drifted too far
Okay, what if you’re already in trouble? The workarounds have calcified and incremental updates just makes things worse.
Then, unfortunately, you do have to rip off the band-aid and rebuild. But this time you have the chance to do it right, with proper design, documentation, and communication. You give the new tool a better chance of surviving longer than the old one.
It’s expensive but there are some suggestions on how to ease the cost of it. Like building features incrementally or rolling out new updates over a period of time rather than a hard switch between the old and new.
The hard part was never building it
Building the right tool is a moment in time. The requirements are clear, there’s energy and momentum. People are excited, you have AI, and it can even be fun.
The hard part is keeping it the right tool as time goes on. I keep coming back to maintenance because I’ve seen tools that had good intentions and design decay from the harsh reality of time and changing business needs. If a tool is critical to your business, it should evolve with the business. Not stop the day it launched.
And I get why companies don’t prioritize this. Tool maintenance isn’t a full time job, it needs attention regularly but not constantly. The problem is that hiring someone just for that is hard to justify. Which is why the default is to only work on it during their “free time”. Maintenance, as important as it is, gets squeezed in-between projects.
That’s a lot of what I do. Yes, I build tools but I also stay close to the work after we’re done. After we build something, we have what I call a “Hypercare phase”. A dedicated time each month specifically for the kind of alignment work that we’ve seen here. It’s not squeezed into free time nor is it only when something breaking, it’s built into the engagement from the start.
If you’ve got a tool that still works but doesn’t quite fit anymore, or if you’re about to build something, I’d love to hear about it. Simply reply to this email or use the button below to book a call.
If you’re thinking about bringing computational design into a project, I’m happy to talk through what you’re working on.
Thanks for reading,
Braden