A quarter of a million pounds and not one line of code

The first project I fully managed without writing a single line of code was worth more than £250k. A multi-brand bar website for a client who'd been with the company since it was founded. So: high value, long relationship, plenty of history to live up to, and a project manager who until fairly recently had been a developer. No pressure at all.

I'd made the move deliberately, but a decision made deliberately can still come with a fear attached, and mine was specific. I was worried I'd spend the whole project mourning. That I'd sit in meetings itching to do the real work, and that "the real work" would forever mean the code, because that's what my hands had been trained to think of as work for years.

Waiting for the itch

After the creative phase was done, I kept waiting to feel like I was missing something. The urge to open VS Code and just get cracking myself.

It never came.

I want to be careful with that sentence, because it sounds like a boast and it isn't. Plenty of excellent hybrid PMs keep a foot in the code and are better for it. But for me the itch simply didn't arrive, and its absence told me something useful: the move hadn't been an act of giving something up. It had been a change of instrument. Which mattered, because the alternative reading, that I'd walked away from a craft I'd miss forever, had been sitting quietly in the back of my head since the day I stopped being a developer.

The developer brain doesn't leave. It repoints.

Here's what actually happened to all that technical thinking: nothing dramatic. It didn't switch off. It just changed what it was paying attention to.

Dependencies, mostly. Sequencing. And, more interesting to me, conversations between a designer and a developer that were going to cause a problem in three weeks if nobody stepped in. If you've spent years debugging, you know the feeling of reading code and sensing that something is wrong before you can say what. It turns out projects give you the same feeling. Two people politely agreeing in a meeting while quietly meaning different things is an integration bug that hasn't run yet. A dependency nobody has said out loud is a race condition with a calendar invite. The developer brain is extremely good at spotting these, because it spent years being punished for missing their technical equivalents.

That's the part I'd never have predicted: the most valuable thing I brought from development wasn't knowledge of how websites get built, useful though that is when someone's estimating. It was the habit of treating a system with suspicion. A project is a system. It has coupling, it has hidden state, it has parts that fail silently. I stopped debugging code and started debugging conversations, and honestly the error messages are worse.

The site outlived my involvement, which is the whole job

I'll be honest about the ending, because the LinkedIn version of this story would tidy it up: I wasn't there when it launched. I left the company during pre-launch QA. Not the finale I'd have written for myself.

But that site is still live six years later, and I take a bit of pride in that. More than a bit, actually. Longevity is the quiet metric nobody puts on a case study. Awards get won at launch; the truth about a build arrives over the following five years, in how it handles new brands, new content, new hands maintaining it. A £250k website still earning its keep six years on says the foundations were right, and the foundations were the part I managed. The fact that it didn't need me in the room for the final weeks isn't a hole in the story. Given what I now think the PM job actually is, it might be the point of it.

If you're technical and eyeing delivery

I haven't written code since 2020. Or at least, that was true until recently, but that's another article.

What I can tell you from the far side of the move is this: the technical background didn't hold me back. It made me better at the job. And yet the fear I carried into that first project is one I've since heard from nearly every technical person considering delivery: that the move is a downgrade of their skill, a shift from making things to talking about things being made.

It isn't, and the framing is wrong. You're not throwing the skill away. You're aiming it at a bigger and messier system, the one made of people, briefs, budgets and deadlines, where the failure modes are less documented and the stack traces are conversations you weren't in. Everything you learned about how systems break still applies. You just apply it before the sprint starts instead of after the build fails.

So if you've got a technical background and you're considering a move into delivery, don't write it off as a disadvantage. It isn't one. It's the thing the other candidates will be missing, and unlike them, you'll know within one project whether the itch to open the editor ever shows up. Mine didn't. Yours might not either. There's only one way to find out, and it pays surprisingly well to look.