Your Engineers Just Became Managers

This didn’t happen all at once. The shift has been building for well over a year. But recently it accelerated to the point where I had to admit the job is different now: every engineer on my team manages a team.

Not a team of people. A team of agents. Each of my engineers directs a small army of them: writing code, running experiments, drafting docs, chasing down bugs. The org chart got deeper without adding a single human. And that changed what it means to lead them.

The biggest practical change is that the work moved left. The highest-leverage thing an engineer does now happens before any agent runs: writing the spec. What’s the expected outcome? What does good look like? What are the acceptance criteria, the edge cases, the definition of done? That used to be the preamble to the real work. Now it is the real work. The agents execute against whatever you specify, so the spec is the product. Vague spec in, confident garbage out, at machine speed.

I used to manage velocity, code quality, design judgment, career growth. Pretty standard. Now I manage something else entirely: how well my engineers manage.

Because here’s the thing nobody put in the onboarding docs for the agent era. Delegation is a skill. Verification is a skill. Knowing what to hand to an agent, how to specify it, and how to check the work, that’s a skill. And it turns out the engineers who were great at writing every line themselves aren’t automatically great at directing agents. Different muscle.

The new failure mode I watch for is the confident rubber stamp. Agent output looks right. Tests pass. It ships. And nobody on the human side actually understood what went in. I’ve started asking a question in reviews that I never needed before: walk me through what the agent did and why. If the engineer can’t, we have a problem that no amount of passing CI will fix.

Hiring changed too. I used to probe for raw engineering ability: how do you think, how do you design, how do you debug. I still do. But now I’m also probing for delegation judgment. Can this person break work down so an agent succeeds? Can they write a spec tight enough to execute against? Do they know when not to use one? The strongest candidates have started describing their process the way managers describe theirs: clear direction in, real review out, accountability that stops with them.

And that last part is the part I repeat the most. What hasn’t changed: ownership. The human ships it, the human owns the outage. Agents don’t get paged at 2am. You do. If your name is on the commit, your name is on the incident. I don’t care how many agents touched it in between.

The uncomfortable truth is that some engineers hate this shift. They got into this craft to write code, and now the job asks them to direct traffic instead. They’re not wrong about what changed. The job did change under them. Managing agents is management, full stop: setting direction, reviewing work, being accountable for outcomes you didn’t personally produce. Engineers who wanted to stay individual contributors are discovering the “individual” part got complicated.

But some engineers are thriving in this world, and they’re worth studying, because they’re showing everyone else what the job is now.

First, the spec writers. The engineers who always wrote good design docs, who were slightly annoying about acceptance criteria, who asked “but what should it do when” three times in every planning meeting. Their old habit just became the core skill of the profession. They were shifting left before it had a name.

Second, the skeptics. The engineers who never trusted anyone’s code without reading it, including their own. The ones who reviewed junior PRs line by line and caught the thing everyone else waved through. Paranoia turned out to be a feature. They review agent output the same way, and they catch what the rubber-stampers miss. In a world of fluent, confident machine output, the person who reads skeptically is the last line of defense.

Third, the practitioners. They kept their hands on the craft. They still build, still debug, still read the code instead of skimming the diff. This matters more than ever, because you can’t review what you can’t do. Their judgment is what makes the whole system work. The engineers who stopped practicing and became pure directors are the ones getting surprised.

Fourth, the context builders. They figured out early that agent output quality is a function of context quality. So they invest in the environment the agents run in: clean repos, good docs, clear patterns, runbooks that actually explain why. Every hour they put into context pays back across every agent run that touches it. It’s a flywheel, and they’re the ones spinning it.

And fifth, the multipliers. They took all that leverage and aimed it at bigger problems. Instead of closing more tickets, they took on system-level work: architecture, platform, the gnarly cross-cutting stuff that used to need a whole team. One thriving engineer with good agents now does the work that used to take three. They didn’t get faster at the old job. They got a bigger job.

Here’s the career part nobody says out loud yet: these engineers are becoming the obvious picks for tech lead and staff roles. Not because they chased the title, but because they’re already doing the work. Directing effort, reviewing outcomes, owning results, setting direction for a team. The promotion case writes itself. The ladder didn’t change. The rungs just got wider.

Leadership used to be about scaling humans. Now it’s about scaling judgment. The engineers with the best judgment win, whether the hands on the keyboard are theirs or not.