Aviv Ben-Yosef wrote up his thoughts on engineering leadership in 2026 a few weeks ago, and the thing I liked most about it is how little he thinks has changed. The mechanics of producing code are different, and the job of leading the people who produce it mostly isn’t. He’s yet to see a company that removed its managers because of AI and came out ahead, he still thinks six to eight people is a team and more than that is several teams with nobody looking after them, and he still thinks a meeting that builds a team is not a cost. I agree with most of it, and I want to add something he leaves implicit about why the fundamentals held.
What the managers were for
The case for deleting managers goes something like this. Engineers can now do far more on their own, so there’s less to coordinate, so you need fewer people whose job is coordinating. The first step is roughly true, and the second is backwards. When delivery speeds up, coordination gets harder, because teams that are sprinting don’t stop to talk to each other the way teams that are walking do, and more work in flight means more places where two teams are building towards different assumptions without knowing it. I say that as someone who thinks teams should be as autonomous as you can possibly make them. Autonomous teams still have to talk to each other, and somebody still has to make sure that happens, even when it’s no longer the manager doing the talking for them. The third step fails because coordination was never the whole job anyway, and the orgs that believed it was are the ones Aviv is describing.
Most of what a good manager does is judgement about people and situations, and most of the rest is caring about the people enough to act on that judgement. Which two engineers shouldn’t be on the same project right now, whether the person who went quiet in the design review is bored or overloaded or interviewing, whether a customer escalation is a real pattern or one loud account. None of that got cheaper when code did. If anything it got more expensive, because as Aviv points out there is now far more surface area touching Product, and far more decisions arriving at once about which of the things being started should stop.
Something I notice in my own work is that the humans who are good at this were never doing it because it was in the job description. They do it because they’re interested in the people they work with, and that interest is the thing you can’t automate and can’t fake for long. I wrote about the noticing part in September. The acting-on-it part needs time in the week that isn’t already spoken for, and I think that time is what we’ve been quietly taking away.
Why 100% utilisation stops a team being a team
Aviv’s section on utilisation is the one I’d make everyone read. He describes a team where every meeting felt painful, where design reviews and code reviews and standups all read as hours lost from output, and he says the result over time is a team that isn’t really a team. “100% utilization was problematic before, and it remains that way now.”
If everyone is fully loaded, nobody has the capacity to help anyone else, and a team is mostly made of people helping each other. The review that would have caught the design flaw doesn’t happen because the reviewer has their own thing due. The quick pairing session that would have unblocked the new starter in twenty minutes becomes two days of them flailing politely. The person who noticed a colleague was struggling doesn’t follow up, because following up is not on their list and their list is full. Each individual is at a local maximum, and the whole is worse than it was when people had slack.
AI makes this failure easier to fall into, because it gives every individual a visible personal productivity gain and no obvious team one. If I can ship twice as much on my own, every hour I spend in your design review looks like a worse trade than it did last year. Each engineer is right to feel that, and an organisation that optimises for it stops being a team. I’ve written before about why individual gains don’t add up at team level, and I’m not going to repeat the mechanics here. The short version is that the team-level gain has to come from people having time for each other, and that’s the time that just got reallocated.
I’ve seen the other side of it too. When one of my teams had some real slack in it, we used the room to rethink how the team was organised and to get people properly aligned on what they were there to do, and everyone was happier for it. None of that would have happened with the diary full.
Why manager utilisation went beyond 100%
What strikes me about this year’s data is that the industry mostly didn’t delete the managers. It did something that looks like the opposite and lands in the same place.
LeadDev’s Engineering Leadership Report for 2026 has 37% of engineering leaders doing more hands-on technical work than a year ago, and among engineering managers specifically the share who are deeply hands-on went from 20% to 35% in twelve months. The same survey has 45% of leaders working more hours than this time last year, one in three managers considering going back to an individual contributor role, and 41% saying their team is less motivated than it was. Those numbers are being reported as a trend, and the trend has a cheerful name, the player-coach. I’d read them together as something else. We took the people whose job was judgement and attention, gave them a coding agent, and filled the hours that judgement and attention used to live in.
I don’t think managers writing code is wrong. A manager who can still read the codebase has better judgement about it, and the AI tooling has made it far cheaper to stay close. The problem is the arithmetic. If the share of managers who are hands-on went up by fifteen points and the hours went up too, the time came from somewhere, and I’d bet it came from the one-to-one that got moved twice, the design review attended on mute, and the awkward conversation that keeps not happening. Those are exactly the things Aviv says you can’t remove without the team stopping being a team. We didn’t remove them by deleting the role. We removed them by running the role at 150%.
I’ve watched the pull happen with my own managers. The code is right there, the agent makes it quick to pick up, and it feels like progress in a way a one-to-one never does, so the hours creep up. I’ve had to talk people out of it more than once, and the conversation is usually a reminder to delegate, which is the thing they were promoted to do. Delegate to the team, that is, not to the agents.
Keep the managers, and leave room in their week
So I’d keep Aviv’s list and add one item to it. Keep the managers, keep teams at a size one person can actually know, and keep the meetings that build a team while cutting the ones that don’t. Then budget a manager’s week the way you’d budget anyone else’s, with room in it for the work that doesn’t produce an artefact, because that work is the job. If your managers are coding more than they were a year ago and working longer hours too, something has been dropped to make room, and it’s usually the work nobody measures. You tend to find out what it was when someone good resigns.