Engineering Manager, Team Lead, Tech Lead, and Architect roles are becoming harder than ever, but the problematic part is that many people don’t understand that and don't give the deserved credit.
The point about your manager seeing maybe 40% of your actual work is the one I'd underline hardest — after 26 years doing ICT consulting, the engineers and leads who got stuck weren't the ones doing bad work, they were the ones who assumed impact was self-evident and never narrated it. Your read on AI making the "player" half harder rather than easier matches what I'm seeing with clients too: the PR volume goes up, the judgment required to review it well doesn't get any cheaper, and somehow the credit still flows to whoever shipped the most lines. The "garbage PR nobody reviewed properly" pattern you describe is exactly the kind of unglamorous bottleneck that never shows up in a velocity dashboard, but decides whether a project actually holds together.
The mechanism you name — the review queue absorbing the productivity gains — is real, but I would locate the pressure one level deeper. When typing was expensive, a thin spec was survivable because the expensive step forced implicit decisions into the open. AI collapses that price, so every ambiguity the author never had to resolve now surfaces in review as disagreement about intent. What reads as slop-filtering is often a specification deficit: the reviewer is not just checking code quality, they are doing the authoring work of deciding what the system should do. Price the spec and accountability into 'what AI made cheap' before concluding the role got harder — the role got harder because the cheap step no longer hides the thinking it used to force.
I recognize a version of this in how I delegate. I often hand work over because I need relief, and by then I haven’t stopped to ask whether it’s ready for someone else to take on. Sometimes I haven’t even worked out whether the workflow is useful enough to keep doing. I’m asking someone to take over something I’m still figuring out myself, when I already have very little capacity left to help them.
There is a measurable reason this got harder, and it lands almost entirely on the player-coach. Faros AI tracked 22,000 developers across 4,000 teams: task throughput per developer up 33.7%, median code review time up 441.5%. The generation half of the job got cheaper for everyone. The verification half did not, and it concentrates on whoever has the deepest model of the system, which is the tech lead or the architect. LinearB's 8.1 million pull requests show the cost when that capacity is missing: AI-assisted PRs merge within 30 days 32.7% of the time against 84.5% unassisted. So the credit problem you describe has a staffing problem underneath it. Nobody budgeted for the review side of the change, and the player-coach absorbs the gap quietly until they burn out or leave.
I've seen some leadership manifestos calling for change, including player-coach expectations and larger spans of control like 20 reports for an EM. There is something of that in the Uber letter that explains their reasons for the recent layoff.
What I haven't seen is a concrete, grounded, explicit playbooks for changes like that to be implemented.
Assuming work week continues being ~40hs, you will have to trim down coaching 1:1s to 30-min every two weeks, and rely on senior IC to lead mini-crews and take some of the coaching with them. And create systems that can surface critical issues that need adhoc intervention.
Autonomous teams/crews are amazing, but they still need context and direction to operate at their best.
The diagnosis is right and I would push on where the advice lands. Both halves put the fix on the person absorbing the cost: build credibility, communicate impact, learn to say no. Useful individually, and it does not change the arithmetic. If agent-using teams open 6x the PRs, as the Linear data you cite says, and review capacity is unchanged, that is a queue. No amount of impact communication drains a queue.
What actually moved it for the teams I have run is making review a funded line item rather than a virtue. Allocate an explicit share of team capacity to review, and defend it in planning the same way you would defend on-call. It turns an invisible cost into a number a director can argue with, which is the only form leadership tends to act on. It also gives the player-coach something better than saying no, which is a budget that is visibly full.
The half nobody funds at all is deletion. If more code is the problem, someone has to be paid to remove it. I have never once seen that on a roadmap.
Loved the essay. I believe traditionally Architects/TLs are playing this type work - atleast in small organizations/moderate project capacity. As you rightly said, in large programs this would become very challenging specifically getting into coding- though AI assisted development would help certain extent.
I would argue it has always been hard.
These days, it's expected more often, which means more folks are trying to "figure it out" and realizing that it is a real challenge.
Indeed, the role has always been hard, now with AI, most people think it's easier, but it's actually the opposite -> harder than ever.
Expectation inflation is my new goto descriptor for what we’re leading through right now.
To your point, expectations have always been high. AI is inflating them even more.
The burnout risk in player-coach roles is real, and it underscores why financial independence matters early.
I keep seeing senior engineers in India over-index on salary growth and under-build their EPF/SIP cushion.
A high-pressure role can end abruptly — the corpus you build now is what lets you walk away on your terms.
The point about your manager seeing maybe 40% of your actual work is the one I'd underline hardest — after 26 years doing ICT consulting, the engineers and leads who got stuck weren't the ones doing bad work, they were the ones who assumed impact was self-evident and never narrated it. Your read on AI making the "player" half harder rather than easier matches what I'm seeing with clients too: the PR volume goes up, the judgment required to review it well doesn't get any cheaper, and somehow the credit still flows to whoever shipped the most lines. The "garbage PR nobody reviewed properly" pattern you describe is exactly the kind of unglamorous bottleneck that never shows up in a velocity dashboard, but decides whether a project actually holds together.
The mechanism you name — the review queue absorbing the productivity gains — is real, but I would locate the pressure one level deeper. When typing was expensive, a thin spec was survivable because the expensive step forced implicit decisions into the open. AI collapses that price, so every ambiguity the author never had to resolve now surfaces in review as disagreement about intent. What reads as slop-filtering is often a specification deficit: the reviewer is not just checking code quality, they are doing the authoring work of deciding what the system should do. Price the spec and accountability into 'what AI made cheap' before concluding the role got harder — the role got harder because the cheap step no longer hides the thinking it used to force.
I recognize a version of this in how I delegate. I often hand work over because I need relief, and by then I haven’t stopped to ask whether it’s ready for someone else to take on. Sometimes I haven’t even worked out whether the workflow is useful enough to keep doing. I’m asking someone to take over something I’m still figuring out myself, when I already have very little capacity left to help them.
There is a measurable reason this got harder, and it lands almost entirely on the player-coach. Faros AI tracked 22,000 developers across 4,000 teams: task throughput per developer up 33.7%, median code review time up 441.5%. The generation half of the job got cheaper for everyone. The verification half did not, and it concentrates on whoever has the deepest model of the system, which is the tech lead or the architect. LinearB's 8.1 million pull requests show the cost when that capacity is missing: AI-assisted PRs merge within 30 days 32.7% of the time against 84.5% unassisted. So the credit problem you describe has a staffing problem underneath it. Nobody budgeted for the review side of the change, and the player-coach absorbs the gap quietly until they burn out or leave.
I've seen some leadership manifestos calling for change, including player-coach expectations and larger spans of control like 20 reports for an EM. There is something of that in the Uber letter that explains their reasons for the recent layoff.
What I haven't seen is a concrete, grounded, explicit playbooks for changes like that to be implemented.
Assuming work week continues being ~40hs, you will have to trim down coaching 1:1s to 30-min every two weeks, and rely on senior IC to lead mini-crews and take some of the coaching with them. And create systems that can surface critical issues that need adhoc intervention.
Autonomous teams/crews are amazing, but they still need context and direction to operate at their best.
The diagnosis is right and I would push on where the advice lands. Both halves put the fix on the person absorbing the cost: build credibility, communicate impact, learn to say no. Useful individually, and it does not change the arithmetic. If agent-using teams open 6x the PRs, as the Linear data you cite says, and review capacity is unchanged, that is a queue. No amount of impact communication drains a queue.
What actually moved it for the teams I have run is making review a funded line item rather than a virtue. Allocate an explicit share of team capacity to review, and defend it in planning the same way you would defend on-call. It turns an invisible cost into a number a director can argue with, which is the only form leadership tends to act on. It also gives the player-coach something better than saying no, which is a budget that is visibly full.
The half nobody funds at all is deletion. If more code is the problem, someone has to be paid to remove it. I have never once seen that on a roadmap.
Loved the essay. I believe traditionally Architects/TLs are playing this type work - atleast in small organizations/moderate project capacity. As you rightly said, in large programs this would become very challenging specifically getting into coding- though AI assisted development would help certain extent.