You Don't Have to Build Your Own Automation Tools
Leverage the strengths of others
Do you ever wonder why event halls always have this old, musty kind of carpets ?
It’s a weird thought to have but I am in the corner of one now. After “networking” for the past hour or so, I needed a break. So, I found a corner with a tall round table and I am just leaning on it at the moment. With a drink in hand, I just stared at the room full of people shaking hands and probably exchanging contacts.
Out of the corner of my eye, I see someone walking towards me.
Do, I know him? Oh wait, it’s Dan
I first met Dan about maybe six months ago now at another similar networking event. He’s an engineer who runs his own structural consultancy.
As he walked over, I was frantically trying to recall the last thing we talked about.
Just as I shook his hand, I remembered.
The last thing he told me was that he was trying to turn his list of Excel spreadsheets that ran some calculations for him into Python scripts. We were talking about how maintaining and distributing Excel spreadsheets is hard and that Python is a better approach. A single script, even if it’s 100s of lines long is arguably easier to read than a single spreadsheet with many formulas and tabs.
So, after we exchanged pleasantries, I asked about how it was going.
He sighed. “We have even more Excel sheets now.”
He continued, “I even had it planned out too. We had a good three months of no projects, I sent a few people to some Python bootcamp. They came back and just as we started to make some scripts but we got more projects again. So, we had to park it and it’s been four months since.”
What’s worse is that the new projects meant Dan’s team had to make modifications to the old spreadsheets. So not only are there new ones, there are different versions of the old ones too now. Getting new projects in that down time also meant he team members that learnt Python probably don’t even remember what they’ve learnt anymore.
Dan knew the value of automation, the value of computational tools but he just didn’t have the time or the energy to implement things.
“I just want someone to solve the problem for me,” he said. “I don’t want to learn all this stuff. I just need it to work.”
We continued talking for the rest of the event and I am thankful for Dan for bringing me out of this zoned out stupor as we talked more through the night.
But unfortunately this isn’t the first time I’ve heard a story like this. In fact, I think it’s the typical way most teams operate.
Innovation vs Execution
Then tension is everywhere. How can you spend time innovating, which really means experimenting, when you have too much project work to do? Why spend time on something that “may” give you a return, when you can just solve the problem now for a client ?
When executing on projects brings in revenue, innovation becomes something that just cost more money and opportunity. Even when you know that innovation is how you become more efficient. The fact that it costs money and takes time away from actually delivering the projects is reasons enough to stop most teams from doing it.
I’ve seen teams say “we’ll get to it eventually” or “it’s something we’ll do when things slow down.” Well, things never slow down and “eventually” never comes. The backlog of “important but not urgent” improvements just grows until someone leaves or the problem becomes critical. And then you’re left in fire fighting mode because the deadline is tomorrow.
But I get it. Project work is always urgent. And urgent always wins.
And that tension isn’t going away and it shouldn’t. Projects bring in revenue and provide real-world context that informs what’s actually worth building.
But most companies spend so much time executing that they never get around to innovating.
Let’s build this internally
The current state of technology is dangerous because it makes you feel like with a bit of grit and some time, you can build anything you want. Especially with AI, it feels like you can solve anything really quickly.
But the reality is that anything worth building still requires context and expertise.
Think about it. You’re an engineer running a consultancy. You know there’s value in automating your calculations. But to do it yourself, you need to learn Python, figure out best practices for building maintainable scripts, test it across different project types, document it so others can use it, and maintain it when things break.
All while still delivering on projects. Still answering client calls. Still running the business.
That’s a lot to ask.
I know it feels like with AI or any computational tools, this should be easy to do. But it’s not.
The most successful teams I’ve worked with bring in someone whose job is building these tools, someone who’s already made the mistakes, already knows the patterns, already has experience turning messy workflows into clean solutions. A few calls, some back and forth on what the problem actually is, and they get a tool that works.
Meanwhile, their engineers stay focused on what they’re good at.
This isn’t about never building anything in-house. If you see a problem and can solve it with a quick Excel macro, go for it. Low-risk experiments are how you learn. But when the DIY solution itself starts causing headaches and you don’t have the time or the skill to develop something substantial to solve your problems, that’s when finding someone who can solve it properly really helps.
The Real Cost of Waiting
I really hope Dan finds the time to actually turn his Excel sheets into Python scripts. I know he wants to make things better but he just doesn’t have the time or the skill. And he’s too busy to slow down and figure out another way.
And given how good Dan is at his job, he’ll keep getting new projects and will never find the time.
Well, you might wonder “if it ain’t broken, why fix it?”
Except it is broken. Not in an obvious way, but in all the invisible ways that add up. It’s the type of inefficiency that builds up over time. The cost also isn’t just the inefficiency of managing dozens of spreadsheets. It’s the opportunity cost of what Dan’s team could be doing instead. It’s the mental load of knowing there’s a better way but never having the bandwidth to pursue it. It’s all the things Python scripts might unlock down the line that Dan will never discover because he’s stuck maintaining the system he already has.
You Don’t Have to Build Your Own Automation Tools
The most successful teams I’ve seen don’t try to DIY everything. They bring in someone whose job it is to build these tools, someone who’s already made the mistakes, already knows the patterns, already has experience turning messy workflows into clean solutions. A few calls, some back and forth on what the problem actually is, and they get a tool that works. Meanwhile, their engineers stay focused on what they’re good at.
This isn’t about never building anything in-house. If you’ve got some time and want to learn Python, then building something is how you will learn. But it takes time and effort that you don’t always have. If you just need the problem solved, that’s when finding someone who can solve it makes sense.
If you’ve been thinking about a problem like this, something on your backlog that never seems to get done, I’d be happy to chat. Sometimes it’s about finding the right tool, sometimes it’s rethinking the process, and sometimes it’s just talking through what’s actually worth automating.
Thank you for reading. Consider subscribing if you haven’t, it really helps me know my writing here is useful.