Hello again: what I've been building (and what I'm building next)

The last time I wrote here was December 2020.

I said I wasn't making grand plans, would write when I felt like it. Not rush anything.

Then I didn't and five years went by. Not because I was idle, but because the work changed me more than I expected — and I didn't notice it happening.

This is me trying to make sense of that change.

I used to think good engineers had good answers

At Specle, as CTO, I thought leadership meant having the right technical and product answers. When things went wrong, I stepped in harder. When decisions were messy, I absorbed them myself.

It worked, until it didn’t.

What I learned, slowly and uncomfortably, was that being right doesn’t scale. Owning everything doesn’t scale. Heroics don’t scale. High-level board decisions — even when technically informed — combined with carrying technical risk taught me that most failures aren’t technical. They’re organisational. The code just makes them visible.

That experience rewired how I think about responsibility.

Then I learned that answers don't matter if the system fails in the real world

When I joined char.gy, we were fewer than ten people, figuring out both the hardware and software side of the EV charging equation.

When you do customer support and pick up the phone at 1am because someone can’t get their car charging so they can finally rest, you learn to value reliability. You learn that the shape of your code has to bend to the shape of real customer pain.

When I joined, we were three devs, our CTO included. The charging success rate was about 85%. Four years later, when I left, we had a focused development team of eight, and that number was 94%. Support tickets were down 70%. Availability sat above 99%.

I like to believe those numbers changed because an identity was forged, both collective and individual. I stopped thinking of myself as someone who builds elegant systems and started thinking of myself as someone who reduces real-world failure. The dashboards mattered more than the abstractions. Network health mattered more than diagrams.

That was the point where “good answers” stopped being the goal. Fewer broken experiences became the goal.

Then I learned that systems don't become reliable — teams do

At Ventrata, the technical problems were familiar. The people problems weren’t.

Introducing tests and quality practices wasn’t a technical argument, it was a cultural one. The hardest part wasn’t convincing people that tests are good. It was learning how to create conditions where the team wanted quality without being coerced into it.

This was the shift from “I know what good looks like” to “my job is to help the team discover what good looks like.” When that clicked, my role changed. I cared less about how much I bring with me to the room and more about whether the rest of the room has space to grow and breathe.

The thread I didn't plan

Looking back, the thread through my consulting days at Unboxed, then Specle, char.gy, and Ventrata is this: I keep ending up in places where things need to work for people who don’t care about our technical reasons for failure.

The job isn’t writing the most perfect Ruby. It’s delivering value and reliability to real people: artwork that’s correct so a print run doesn’t fail; someone who just wants their car charged so they can get to work tomorrow; a couple trying to book tickets for a once-in-a-lifetime experience.

Somewhere along the way, my identity changed:

• from writing good code
• to building reliable systems
• to growing teams that can build reliable systems without me in the loop

If I’ve learned anything worth writing down in these five years, it’s this: reliability is the constraint that exposes everything else you’re bad at.

What's next: being responsible for people, not just outcomes

In March 2026, I'm joining Cleo AI as a Tech Lead Manager. It's my first formal people management role.

The stack is new in parts, as it always is. The responsibility is not. The difference is that now the primary system I'm responsible for is a group of humans doing complex work under pressure. If that system fails, no amount of personal technical competence fixes it.

I'm nervous and incredibly excited. That feels like the right emotion to bring into a role where your mistakes have second-order effects on other people's growth and careers.

Why I'm writing again

Five years ago, I thought writing was optional. Now I think it’s part of doing this job well.

Writing forces me to notice when my identity shifts. It’s how I catch myself before I drift back into old habits: tilting at windmills alone, hoarding context, confusing “being right” with “being useful.”

I’m not promising frequency. I am promising intent: to write about the parts of engineering leadership that don’t show up in architecture diagrams — the tradeoffs, the failure modes, and the slow work of building teams that don’t depend on one person to save them.

The version of this work that’s worth doing is the one where fewer people are blocked by our mistakes. If I can make that a little more likely, for my teams or for someone reading this, then writing again is worth it.