A while back, a former colleague gave me a call to check in on a challenging organisational project I was working on. I explained that things were proving to be quite difficult; targets were constantly shifting, there was a lack of communication and the business growth potential I was sold on when accepting the project was quickly proving to be untrue.
“You’re a builder,” he interrupted. “Forget all that. You need to build something. Come do it with me.”
It was serendipitous timing for them. Their new startup was about to take flight and here I was sounding like a fish out of water, potentially ripe for the picking.
I chuckled and dismissed the pseudo-offer light-heartedly. I assumed they weren’t particularly serious anyway since I hadn’t written code commercially for years. But after I hung up, their seemingly off-hand statement began to echo louder in my mind.
“You’re a builder.”
“You’re a builder.”
“You’re a builder.”
They weren’t wrong. I was a builder. I had spent the better part of two decades writing software, developing systems of various shapes and scales and taking real joy in seeing them come to life. Even today, I still love tinkering with code in my own time, spinning up proof-of-concepts and exploring new technologies. But my day-to-day building days were behind me, or so I thought.
From early leadership to building differently
When I first started managing people, I had a team of two. It was easy to keep coding and largely ignore the “management” side of things. They were capable, self-managing and didn’t require much oversight. My contribution was still tangible. I could see my code shipping, my fixes going live, my solutions making an impact.
As the teams grew, so did the demands on my time for managing them. Sprint planning, stakeholder meetings and hiring decisions consumed the space I once used for writing code. The frustration crept in. My pride had always come from building things and seeing them used, but now it was buried under layers of process and decision-making. I felt disconnected from the work I loved.
Then came Directorial and Executive opportunities. Bigger titles, bigger teams and a bigger gap between me and the code. The projects I worked on shifted from weeks to months, from months to quarters and sometimes it would be years before the results would become visible.
As a CTO, I can no longer afford the time to obtain instant gratification in fixing a bug and pushing it live. My “commits” now are cultural changes, strategic investments and organisational shifts that may not show dividends for some time. It was a difficult concept to grasp at first. My brain was wired for the dopamine hit of “problem → solution → delivery,” but in leadership the feedback loop is much longer and I had to learn to find joy in a process that is inherently slow.
Redefining what “Building” means
It took me a while to realise that I was still building, I had just changed the materials and the scale.
Today, I build teams by bringing together talented people, giving them the right tools and creating an environment where they can do their best work.
I build processes, not for bureaucracy’s sake, but to help people work better together, avoid burnout and deliver consistently.
I build strategy by mapping out where we’re going, making trade-offs and aligning technology to business goals.
I build culture so people feel safe to speak up, to try new things and fail without fear.
I build vision by connecting the dots between leadership intent and individual action so everyone knows how their work matters.
Most importantly, I build people. One of my proudest moments as a leader is seeing someone I’ve mentored grow in their career, sometimes even leaving the company for a bigger role. It’s bittersweet, but it reminds me that leadership is about planting seeds, not holding onto them.
When your projects span years, finding joy means noticing and celebrating the smaller builds along the way. Waiting for the “big launch” or “successful acquisition” to feel proud will leave you and your teams starved for motivation.
For me, those smaller “builds” look like:
- A new hire hitting their stride in record time
- A team retrospective where people are genuinely laughing and engaged
- A stakeholder saying “That process is so much smoother now”
- A junior engineer presenting confidently to the exec team
These are all signs that the structure you’re working on is taking shape. They are proof that building is happening, even if the final result is still in progress.
Advice for aspiring leaders
If you’re an engineer looking to move into leadership, or if you’re already there but feeling disconnected from “real” building, here’s what I’ve learned:
- Redefine your output. Your deliverables are no longer pull requests. They’re team health, strategic clarity and organisational resilience.
- Shift your feedback loop. You can’t rely on instant gratification. Instead, set shorter milestones inside long-term goals so you can measure and celebrate progress.
- Invest in people, not just projects. Code will be rewritten, architectures will change. The people you grow will carry your influence for years.
- Stay close to the craft. Even if you’re not coding day-to-day, keep your skills alive. Tinker, experiment and stay curious so you can empathise with your teams and make informed decisions.
- Find joy in the abstract. A system design might be invisible to end-users for months, but seeing your team collaborate, innovate and solve problems together is the build.
Full circle
When my former manager called me a builder, I initially took it as a misread, as if I’d been pigeonholed into my old identity as an engineer. But they were right. I am a builder. I just build differently now.
Where I once built codebases, I now build capacity. Where I once built features, I now build futures. And the truth is, the joy I get from seeing a person grow, a culture shift or a strategy take hold is every bit as satisfying as shipping the perfect piece of code.
It just takes a little longer to compile.
