You're Too Good At Fixing Things
Is fixing that thing still the best use of your time ?
Being a “digital” person in the AEC (Architecture, Engineering, Construction) is a weird place to be. Especially, if you work for a consultancy.
To put it simply, there are two modes of operating. Fire-fighting or tool building.
Fire-fighting is solving problems on projects. Scripting, pulling data, fixing models, whatever it takes to get the job done as quick as possible. These are where tools like Grasshopper, Dynamo or Python shine because no one cares about how robust your solution is. They just want results.
Tool building is the polar opposite. It’s when you’ve seen a problem enough times that you decide to invest in a proper tool, something reusable. It’s more like conventional software development, and it’s probably why I got into this field in the first place.
But the problem though is that these two operating modes are not equal. Working on projects is billable to clients. Tool building, even though more beneficial in the long run, isn’t.
So, there’s always a bias towards fire-fighting.
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 Competence Trap
If you’ve been doing this for a while, you know how this plays out. You start out as someone who can solve problems quickly. You’re good with Grasshopper or Dynamo or whatever the tool is. People notice and love having you on their projects because you’re efficient and deliver at a high quality.
You start earning a reputation of putting out fires. You solve problems well, deliver at a high quality and let’s face it, you’re also cheap. So, to some extent, putting out fires becomes your value.
So, what happens when you want to build something? You’ve been fire-fighting long enough to see where a proper tool would help everyone. But the team doesn’t see you as the person who builds things, they see you as the person who fixes things.
And those are two very different roles, even if they use the same skills.
You know that if you could free up a week or two, you’d be able to build something that would make things just way more efficient. A true proper tool that could solve the pain points that you’ve been seeing so often on projects.
But every time, you sit to start, you get interrupted. Someone, somewhere needs your help. You’re just too good at putting out fires. And because it’s urgent and billable, you say yes.
Why “Just Block Time” Doesn’t Work
All the time hacks in the world can’t save you here. You can’t just “carve out time” or try one of those calendar-blocking things. If a project needs you, it doesn’t care when you’ve blocked your calendar or what AI tools you’re using. It needs you to put out those fires now.
And if you do manage to protect a few hours, building and fire-fighting require completely different kinds of energy. You can’t fix someone’s Revit model all morning and then design a new tool in the afternoon.
Well, you can. You just won’t do it well. If you’re like me, you’d be tempted to rush the tool building process because you don’t know when is the next time you will get to it.
Building requires a clear head, a longer time horizon, and the mental space to think about problems that aren’t screaming at you. You really do need the space to just sit with the problem.
Subscribe to CodedShapes and I’ll send you my free guide on how to be more efficient with technology
What Actually Helps
The antidote, as you might guess, is simple.
If you can’t carve out time within a day, you have to carve out whole days or even weeks.
And that means choosing which fires to fight and which to let burn. I said it was simple but it definitely isn’t easy.
Essentially, you have to say no. Which means letting people down. And being okay with people seeing you as the “bad guy” because you didn’t help them. That’s unfortunately, the cost of setting boundaries. You have to learn to undo the reputation that got you where you are.
I don’t know about you, but that’s the hardest part for me. Even though fire-fighting is stressful, there’s a camaraderie to it. You have people around you trying to solve the same problem and when you do, you feel like a hero.
That elated sense of accomplishment when you fixed something under pressure or delivered when the timeline was ridiculous is unparalleled.
When you’re building things that prevent the next ten fires, nobody even knows it happened. The system rewards the dramatic rescue, not the prevention. And unfortunately, making people more efficient is less dramatic than rescuing them from projects.
Balancing Tools and Projects
I’ve definitely not figured this out. I still have weeks where every day is reactive. But I am trying to get better at protecting that all too important tool-building time.
Also, I have noticed that if you’re only valuable because you fix things, that’s a trap. I mean, my value isn’t speed or being “on-call” all the time. It should be my expertise and that means I should be working on things that bring the most value.
That could be fire-fighting if the project was really high profile and valuable. Or it could be tool-building because there is something vital that needs to be built.
The point here is that if I see something that I can build that prevents fires, I should do that, instead of wanting to work on projects all the time. Because it’s all too easy to get swept up by the urgency of projects.
The art is in balancing the billable and urgent projects with building things that actually make a long term difference.
If you’ve been in the same spot as me, I hope this article helped you think through things a bit more and if you’ve been wanting to build something for a while now but are stuck in fire-fighting mode, reach out by either replying or emailing me at braden@bradenkoh.com. Maybe we’ll find something awesome to work on together.
As always,
Thanks for reading.
~Braden