By any sensible reading of an org chart, I have no business being in this file. I’m a Head of Software Engineering. My calendar reckons I should be in a room somewhere talking about headcount and roadmaps. Instead it’s late, everyone sensible has logged off, and I’m three retries deep into a release that refuses to tag itself, muttering at a Rust workspace I built with my own hands.

So why am I here? I’ve been asking myself a version of that question for about twenty-five years, and I think I’ve finally got an answer. It’s just not a flattering one.

I’m a builder, and that isn’t really a choice

Strip away the job titles and I’m a builder. I like to make things, I like to solve problems, I like to learn how something works by taking it apart and putting it back together slightly differently. That urge predates every role I’ve ever held and it has survived all of them. In jobs where I wasn’t allowed to scratch it, I went and built in the open instead, which is a polite way of saying open source has spent years absorbing energy my day job wouldn’t take.

I’ll go further, because being coy about it helps no one: it’s closer to an addiction than a hobby. I don’t fully switch off. The current outlet, when I’m not in a terminal, is converting a campervan, which is just software engineering with worse error messages and a real risk of electrocution. The shape of the thing changes. The compulsion doesn’t.

Underneath the building there’s a less charming engine, and I might as well name it: a fairly grim case of impostor syndrome. I wrote about it years ago when I stopped calling myself “Dev in Charge”, and a decade on it hasn’t gone anywhere. The only thing that ever quiets the anxiety is staying genuinely good at the thing, and staying good at the thing means using it. I’m a firm believer in use it or lose it. People say technical skill is like riding a bike, you never forget. Maybe. But step away for a few years and when you climb back on, someone’s bolted a jet engine to the frame and moved the pedals. The bike doesn’t wait for you.

What it actually buys

Here’s the part that justifies the indulgence, because on its own “I enjoy it” isn’t a reason to stay technical as a leader, it’s a reason to have a hobby.

The load-bearing belief is simple, and it’s the one line I’d carve into the desk: I will never ask an engineer to do something I’m not willing to do myself. Everything good about staying hands-on flows from that. Because I’m still in the work, I can give my engineers proper support, the right tools and a clear path, rather than guessing at what they need from a slide. I can steer them through a genuinely hard technical call instead of nodding along. I can sniff out a duff estimate, mine or theirs, because I know what the work actually costs. And I can hold them to account with a straight face, because the accountability runs both ways. They answer to me for what they ship, and they get to hold me to account for what I contribute. That second half is the bit a lot of technical leaders quietly drop, and it’s the half that earns you the right to the first.

The bill, and who paid it

I’d be selling you a fairy tale if I stopped there, so here’s the cost, and some of it is steep.

The obvious one is burnout. I’ve been there more than once over the years, and it’s the single biggest reason I now pitch myself deliberately as a Technical Leader rather than an Engineering Manager. I can do the manager stuff, the HR and the planning and the project-management bollocks, and after enough years in the role I do it well, because it demanded that I did. But competence isn’t appetite. Given the choice I’ll take a technical problem or a bit of mentoring over running the process around either, every time, and spending your days on work you’re good at but don’t much enjoy is its own slow road back to the wall. Sticking to my strengths isn’t ego, and it isn’t an admission I can’t do the rest. It’s self-preservation, learned the hard way.

The steeper bill came due at home. When my kids were small I poured my own time into pushing my skills and chasing the next rung, even starting my own agency. Between that and the burnout, I missed big chunks of their early years, and that is one of the real regrets of my life. I’m not going to dress it up or hide it behind a lesson. It was my decision, I made it, and I own it. I’m immensely proud of the people they’ve grown into, and since their mum and I separated I’ve put everything I have into giving them a stable home, the builder instinct quietly turning into a nest-building one, which is the better use of it. I put this here, plainly, because if you’re reading this with a young family asleep upstairs, I’d sooner you heard it from someone who got the balance wrong than learn it the way I did. The code will still be there next year. They won’t be five next year.

And there’s a smaller, daily cost that I still haven’t fully mastered: knowing when to put the keyboard down. A builder who can’t stop building is exactly the person who becomes the bottleneck, disappears down a rabbit hole, or hoards the interesting problem that would have stretched someone on the team. Stepping back to let them solve it, when every instinct I have is screaming to just fix the bloody thing, is genuinely one of the hardest skills I’ve had to learn, and some days it still feels like walking a knife edge. Open source is a big part of how I manage that. It’s a release valve, somewhere I can let the compulsion run with no brakes on, precisely so I’m not stealing the meaty work off the people I’m meant to be growing.

Does it still count when the robot types?

Fair challenge, given the year. I build solo now with an AI pair, to the point where it’s changed how I branch and release. So when a model writes a good chunk of the actual characters, am I still “writing the code”?

I think I’m doing it more than ever, and I’m certainly learning faster. My typing is genuinely terrible, a quarter-century of practice and still mostly thumbs, so being freed from being the typist is no loss at all. What’s left when you take the keystrokes away is the part that was always the point: reading, reviewing, judging, steering. I can review more code, faster, than I ever could when I was the one hammering it out, and I can run several projects at once by pointing my judgement at each in turn. That is leadership work and engineering work at the same time, which is rather the whole thesis.

It did not come free, mind. I was elbow-deep in AI and ML long before GPT made it fashionable, and I’ve seen the messy version up close. Getting to the point where the tools are good enough and I’ve built the guardrails and habits that make them safe took a long time and a lot of getting it wrong. Owning the judgement when the machine does the typing is harder than it sounds, not easier. The typing was never the hard bit.

What I’d actually put my name to

Not that every leader should write code. Plenty of excellent ones don’t, and they’re brilliant at the parts of the job I’m middling at. The narrower, truer claim is the only one worth making: I lead better when I stay in the work, because it’s the only way I know to support, steer and be held to account without faking any of it, and because I meant that line about never asking for what I won’t do myself.

Staying technical isn’t the job. It’s the thing that lets me do the job honestly. I’m a builder who learned, slowly and at a price I’d rather have not paid, how to keep building without it costing the people around me what it once cost the people closest to me. That’s the balance I’m still working at. I suspect I always will be.