Player-coach considered harmful
Aug 13th 2026 | leadership | management | ai | engineering
I've been reading a load of articles about the rise of the player-coach and, unless you're running a ten person startup, they're wrong. As Flavor Flav wisely said, don't believe the hype.
The setup is always the same. LeadDev's 2026 numbers show hands-on work among engineering managers jumping from 20% to 35% in a year. AI has flattened the cost of turning an idea into software, so the manager who last shipped code in 2019 can pick up tickets again.
Zuckerberg moved his desk into Meta's AI lab. Sergey Brin came out of retirement to code on Gemini. Calm down, everyone, that isn't a sea change, it's a tech billionaire midlife crisis. And if you want a picture of why this is trickier than it looks, try imagining the Meta engineer who tells Zuck his approach is wrong.
Forget Zuck's desk though - the serious version of this is Block. In March, Jack Dorsey and Roelof Botha published an entire org doctrine / rambling history essay (very Jack Dorsey coded) arguing that hierarchy is a two thousand year old routing protocol and AI can do the routing now. Three roles survive: individual contributors, directly responsible individuals, and player-coaches, who replace managers outright. It landed five weeks after Block cut 4,000 people, 40% of the company.
Which is the tell. Player-coach isn't what you land on after thinking hard about ownership. It's what you call it when there's nobody left.
To be fair, Block's version is more defensible than the one the think-pieces are selling. They're not asking managers to code on top of the coordination work, they're claiming the coordination work is gone, so what's left is craft and people. Fine - that's the good bit. But the player-coach still develops the people. That's the bit that follows you into code review - we'll get back to this in a bit.
The numbers are real and the observation underneath all this is correct. The conclusion is the rub. The gap between an engineering manager and an IC was never about who had the hours spare to write code. It was never a capacity problem - and the managers who thought it was were usually the ones who don't really know what being a manager is all about.
The IC's job is to build the product. The manager's job is to build the team and the environment that team builds the product in.
AI changed the economics of producing software. It didn't touch that.
You are never just another engineer
Here's the bit the player-coach hypetrain is missing. Think about what happens when you open a pull request.
It sails through. Approved faster, fewer comments, everyone moves on. Obviously. The junior who spotted the bug spends twenty minutes drafting a comment that won't sound like correcting their manager, then bins it. Nobody requests changes on the person who writes their review, and anyone who does is spending political capital to say what they'd have said to a peer for free.
Architecture is worse. Your design doc turns up with your job title stapled to it and people push back a fraction less hard, all while you're sat there sincerely saying "tear this apart, I want the disagreement." You can't opt out of that any more than a CEO can say "treat this as just a suggestion." It's the same reason founder mode goes wrong when it curdles into micromanagement - authority distorts the room whether you like it or not.
So the code with your name on it gets the least scrutiny in the whole repo. Is that a dynamic someone would design on purpose? I bloody hope not.
You own the process - right people in the room, dissent surfaced rather than swallowed, a decision made instead of dying in a Slack thread. ICs own the technical judgement and the commits that come out of it.
Cross that line often enough and you hollow out the role you're meant to be growing. If you're making the architectural calls and merging the code that matters, what exactly does your staff engineer own? You've made yourself the decision maker and left them the keyboard grumpily approving your mid vibe code.
Get more technical, not less
Non-technical engineering managers have never been successful - you can't coach engineers, challenge ideas or improve engineering culture if you have no idea what it is. Managers and ICs should both be up to their elbows in engineering. What differs is which problems they point it at, and cheaper code doesn't change that one bit. Player-coach isn't a new idea either - we've run that experiment plenty of times and it mostly produces "king engineer" archetypes that repress the potential of their best team mates.
There are exceptions, obviously. At ten people you're wearing four hats and there just aren't the humans for clean boundaries. Fine. Make that compromise with your eyes open. Just don't dress it up as an operating model.
Point it somewhere better
None of this is me cheering for the manager who's last IDE was TextMate. AI really does hand technically capable managers the ability to build again, which is the most fun part of the job coming back. The only question is what you build.
The obvious answer is product code, because that's what "software engineering" looks like in most people's heads. It's also the one thing on the list that already has an owner.
Everything else doesn't. The engineering environment around the team is under-built at every company I've worked at, and always for the same reason - building it meant pulling engineers off product work and convincing someone that was worth it. That's why your onboarding docs are stale and why nobody ever built the thing that would have made releases bearable.
That cost has collapsed. So build tooling and harnesses. Documentation that maintains itself. Agent infrastructure and guard rails. Shared skills, prompts and workflows. Analytics that answer the questions you have. Anything that tightens a feedback loop or makes the right behaviour the easy one.
An example. At Yoto, engineers were working out good ways to use AI on their own, including writing some very useful Claude skills. Sharing them was completely ad hoc, so six people solved the same problem six times and nobody knew about it. If the good stuff stays local the org gets almost none of the value.
So I build a low-friction, Claude-native way to contribute skills to our internal marketplace. Not product. Not a decision taken off an IC. Infrastructure for the culture I wanted - engineers compounding on each other's work instead of quietly reinventing it. A leader I advise hit the same question and came up with a different answer, the development harness their engineers use every day. A year ago that's a proposal and a quarter of someone else's time. Now it's a weekend.
So yes, go for and vibe code but build things that support the job you actually have: the environment and culture your engineers build within, the machinery that makes their work easier. The ICs have the product features covered.
Don't use AI to become an IC again. Use it to become a better engineer of your engineering organisation.