If you have a dog, you already had some management training.
I have been making that joke for a long time. Since my daughter twisted our arm to get a dog, and now we are on our second one. Dogs are great people, and easy to manage!
You give clear commands. You keep him on a short leash. You correct bad behavior. You make sure he does not grab some old bone off the ground, or wander into the street. Easy.
Here is what my week looks like now, and I suspect yours is similar.
I break the work into pieces. I hand out the pieces to Claude Code. I wait. Something comes back that is not what I wanted, so I verbalize again, more precisely. I hold multiple threads in my head. I spend most of my energy on thinking through and saying exactly what I want, because saying it exactly is the difference between usable and garbage. I have everything captured in the spec.
I have not written much code by hand in months. I have been running a team.
It really is management
My impression is not that this resembles managing engineers. In fact it is. It truly feels like running a small team at a startup, which is the only kind of engineering management I ever wanted to do.
Startup engineering management is the variant that was already almost pure coordination. Everybody is senior, or at least smart. Nobody needs babysitting and micromanagement. There is no HR bureaucracy, thank God. What is left is decomposing work, discussing architecture and approaches, assigning subprojects, and catching what comes back wrong. Which is exactly what we do with the coding agents now.
The failure modes also carry over. If an agent confidently returned something wrong, you were not clear in what you wanted. Ambiguous goal, not enough stress on specs and tests, not enough critical pushback applied, etc. Just like with people.
The people part was always overrated
The common wisdom is that the hard part of management is the people management. Well, I disagree.
Managing engineers is easy. You keep them challenged and busy, you make sure they get public appreciation, you reward initiative, and you make sure they have regular raises. Everything else, the frameworks, the ceremonies, the quarterly development conversations, the OKRs and such, is scaffolding built by people who could not deliver those simple things.
It is not hard to understand that your engineers want interesting work and more money. But in practicality it takes budget you control, the ability to keep the work challenging when a big part of it is just minutiae that have to be done, and enough standing to get the team the recognition.
Most engineering managers cannot deliver any of it, because they have no freedom of maneuver. And you do have to be creative enough to keep challenging people, and to provide professional growth to them.
Now the human-agents combo removed the part that was overrated, and left the part that was always the actual work.
The tax was optional all along
The old wisdom was you needed people to grow your career. But the price was a calendar chock full of meetings, and inevitable office politics. Every geek who refused to pay that price stayed an individual contributor and watched people who could not develop products get promoted.
This price just went away. You can command a team now with no requisition, no interviews, no permission from an org chart. My son runs close to ten agents at once. He is burning through a two hundred dollar a month Codex plan doing it. Two hundred dollars a month for ten workers who are relentless, never need a raise, don’t complain, and are always in the office.
That is the revenge of the geeks.
Two career ladders, one of them throttled
Both ladders existed on paper. Only one had a rate limit.
Principal engineer title was gated on demonstrated technical acumen, and it was a real deal. People evaluating you could tell. Few slots. Years of visible work. Somebody senior had to put his name in for you. Getting there was brutally hard, and everybody who tried knows it.
The management ladder had no such gate. The qualification was appearing competent to people who could not evaluate the technical work, having a calm demeanor, being a team player. And the slots multiplied with headcount. Director hires director to become a senior director.
So one path was throttled by hard proof and the other by growth. Growth in a successful business was fast. Rational people read the odds and crossed over. I do not blame them. The system priced meeting attendance above technical judgment, demonstrably, for at least twenty years.
I watched Cisco run this at scale under Chambers and thought it was ruinous. People switching to the management ladder lost competence fast. They were told to drop what they were previously good at, and fully focus on people management. But the technical competence fades away. The vocabulary survives. You still know the words, you can still run the meeting, you can still sound like someone who knows. What goes is the hunch, the nose. You lose the ability to look at a design and smell that something is wrong before you can articulate why. And nobody notices, including you, because your output is now measured in headcount and KPIs rather than in things that work.
Revealed, not displaced
The pure people manager existed to run other people. Keep them aligned, carry information up and down, take the blame when it went wrong. Agents do not need any of that. They have no morale and no career. There is nothing left for him to manage, and the one thing that would have saved him is what he gave up to get the job.
Some managers earn their pay in air cover. Budget, shielding the team from organizational stupidity, absorbing the political hit, saving the team from layoffs. There are truly great people who do this well.
But notice what that is. It is political defense, not engineering management, and it is worth exactly as much as the surrounding org is dysfunctional. In a small startup it barely exists, which is why this new agentic work feels like startup management and not like Cisco management.
Some of the managers can come back. If the job is specify, review, correct, then a manager who used to write code has a real shot at it. He knows the vocabulary. He can still read a diff. Enough of the old shape is there that the work feels available to him again in a way it did not two years ago.
The problem is what he is reviewing with. His intuitive model of the tech stack is ten years stale and he has no way to measure how stale, because measuring it takes the instrument that decayed. He knows enough to be dangerous.
Set him next to a junior. The junior does not know, and knows he does not know, so he checks everything twice to be safe. The returning manager does not check, because nothing in front of him looks unfamiliar. He recognizes the shape of what came back, feels the old competence, signs off. And his sign-off carries weight the junior’s never will, because nobody downstream is going to argue with the director about a design review.
And who owns the error? Claude Code?
The ceiling moved
Human management caps out somewhere around seven reports, because people need attention and there is only so much of you. The number gets attributed to Napoleon, which is probably not true but has never stopped anyone from repeating it.
Agents need no attention. So the cap moves, and it does not move to how many threads you can juggle. Multitasking is hard, but multitasking is not the binding constraint. But the real crux is whether you can still tell good work from work that merely looks good. Especially when the volume of work skyrockets.
A manager can stop coding and still be a good manager, because the team supplies the technical judgment. Driving agents, there is no team to hold it. Your only instrument for telling good from plausible is having done the work yourself, recently enough that the smell is still fresh.
Which means the delegation instinct, a virtue in real management, can become a liability quickly. Every hour you spend only specifying and reviewing is an hour your nose degrades.
My son can run ten agents concurrently because compute is cheap and he pays for it himself. He is young, and good at planning and multitasking. He has also never spent a year maintaining something he wrote badly, which is where I got most of what I use to review his kind of output.
Where the next ones come from
I used to read assembly. To check whether the compiler had done something inefficient. I was good at it, and it mattered, and I have not done it in thirty years. I have not missed it once. The compiler just got good enough that the skill stopped mattering. You don’t validate the machine code anymore.
Now, will coding agents become so good the work does not have to be validated and reviewed by a competent human?
It definitely happened with the compiler. But the compiler is a predictable tool. Same input, same output. Bugs are reproducible and easy to fix by the vendor, and the quality converges to high.
Models currently do not act like that. Ask twice, get two answers. Wrong and right answers are delivered equally confidently. So the human has to be in the loop, and make decisions. If the model produces a lot of code, one can’t validate each and every line, but still has to have the nose for correctness.
If that changes, this essay ages badly and the whole worry dissolves. If it does not change, the smell is still the job. But how do you keep it if you stop coding?
I run my three agents. My son runs ten of his. Neither of us knows where the next generation gets the sense of smell, and I am not certain anymore that it will need one.