We Turned All Developers Into Managers. Now What?

One day in March: five terminal sessions, three large pull requests, six codebases analysed for a business case, and a presentation built from scratch. I didn't write a single word myself, if you don't count the words I wrote to Claude.

The tiredness afterwards was a different kind. Not the good tired of solving something hard. Closer to decision fatigue, the kind that comes from supervising rather than doing.

I recognised it straight away, because managing agents is a lot more like managing people than it is like technology.

I felt like an underpaid air traffic controller with a heavy sleep debt at 5AM after a night shift.

Now look at your engineers. Some of them chose this profession precisely so they wouldn't have to do that, nor feel like that. I get why.

Different subordinates, same job

Think about what a line manager does in a day. They delegate. They coordinate work happening in parallel. They check progress, unblock people, review results, and make decisions with incomplete information. And they stay accountable for the outcome, even when somebody else did the work.

Now look at what your engineers do with coding agents. They delegate to them. They coordinate several in parallel. They check progress, resolve failures, review generated code, and make decisions about systems they didn't personally implement. And they stay accountable for the outcome.

Agents don't need career conversations or performance reviews. But the cognitive structure of the work is the same.

We spent decades building staff, principal and distinguished tracks because being excellent at software and wanting to manage people are different things. For a long time the only way up for a great engineer was management. A truly terrible idea. The ladders were the fix. The promise was simple: you can become exceptional at your craft without abandoning it.

Now you've handed everyone a team of agents and expect them to run it. Welcome to manager's world, pal!

The dashboard measures acceleration. Your engineers experience fragmentation.

Flow was the best part of the job for a lot of engineers (and, oh gosh, I miss it so much). Headphones on, four hours inside one difficult problem, and out the other side understanding a system a little better than before. Hours that produce very little visible output, and aren't wasted at all.

Supervising agents has the opposite shape. One finishes. Another gets stuck. A third needs clarifying. A fourth has produced hundreds of lines they now have to understand well enough to decide whether they should exist. Switch, switch, switch. And you don't remember where you were with that thing there.

By the end of the day your dashboard looks fantastic: more pull requests merged than anyone could write in a week. Ask the engineer what they did today and they can't quite say, because they spent the day supervising work instead of experiencing the making of it.

I know that feeling from the inside. I wasn't exhausted from the effort. I was exhausted from the amount of attention I had to put in.

Reviewing generated code is different work

Good engineers care about things users never see, understand or care about. The simplicity of an abstraction. The clarity of an interface. The quiet satisfaction of deleting code.

The usual answer is that craftsmanship moves up a level: designing the architecture, setting the constraints, recognising an excellent solution. There's truth in that. But it's slightly dishonest (and at times evil) to tell someone who loved writing software that reviewing generated software is simply a more advanced version of the same craft.

It's just different work, with different sources of satisfaction. Some of your people will love it. Others will hate it. Nobody should be surprised.

The first kind of engineer still matters

The traits that made someone exceptional ten years ago aren't exactly the traits that make someone exceptional now. An engineer who thrives on deep concentration may find constant orchestration exhausting. One who enjoys delegation and parallel problem-solving may thrive. That's not a ranking. It's what happens when you change the job.

Don't conclude you no longer need the first kind. Someone has to recognise when a reasonable-looking solution is fundamentally wrong. Someone has to diagnose the failures the agents can't. Someone has to care about quality beyond whether the tests pass. That depth only grows where people have time to understand the systems they're responsible for.

The questions you aren't asking

You're probably looking at agent adoption through productivity. How many engineers use them. How much faster you deliver. How much capacity you've unlocked. What percentage more you're shipping this month (40% more... 50% more...). Fair questions, but incomplete ones.

Do your engineers still enjoy the work? Do they feel ownership of what they ship? Do they have time to understand what they're accountable for? Are they growing, or just getting better at supervising machines?

I use these tools myself, and I don't want to go back to writing everything by hand. It's pointless as of October 2026. But the fact that an engineer can supervise twenty agents doesn't mean they should. Producing more and working sustainably aren't the same thing.

So where do we go from here?

Nobody has this figured out yet. I don't either. But we've been here before, and what worked then is a decent place to start.

We solved the original version by naming two jobs and letting people choose. The agent era needs the same honesty. Some people will orchestrate: they're good at delegating, switching and holding a dozen threads in their head, and you'll need plenty of them. Others will go deep. Neither is a protected species. You need the depth because someone has to catch the solution that looks right and is wrong, and someone has to diagnose what the agents can't. And an orchestrator's review is only as good as their understanding of the system.

If the mix you need is mostly orchestrators, say so when you hire and when you promote. Don't sell people the old job. And stop measuring the work by throughput alone, because a dashboard can't see what's being lost.

Say it, too, to the person who genuinely hates orchestrating and has no place for that in your company. It's hard to hear. It's only fair to say it out loud, and sooner is kinder than later.

Then ask. Not in an annual survey. In the one-to-one, every few weeks, because the job keeps changing under them. Before you ask how many agents an engineer can manage, ask whether they ever wanted to be the manager.

And when the answer is no, believe them. The mistake was never the agents. It was that nobody asked.