Engineering managers as system designers
When output stops being scarce, managing output stops being the job. What is left is designing the queues, the gates and the loops that decide whether the output is any good.
An engineering manager described his week to me like this. Monday, a one-on-one where he could not think of anything useful to say, because the engineer’s output had roughly tripled and there was nothing to unblock. Tuesday, a planning session that took an hour to allocate work the team would finish in two days. Wednesday, he noticed that eleven pull requests were open and two of them had been open for nine days. Thursday, he spent the whole day reviewing code himself, badly, because he had not written in this part of the system for a year. Friday, a skip-level where his director asked why velocity was up and quality complaints were also up, and he did not have an answer he believed.
Nothing in that week was management as he had learned it. Every part of it was management as the job now is.
The short version of this piece: an engineering manager used to spend most of their effort making sure enough good work got produced. Production is no longer the scarce thing. What is scarce is the system that decides which produced work is trustworthy, and that system is now the manager’s actual product.
What the job was quietly optimising
Take the classic engineering manager responsibilities and ask what each one was for.
Hiring: increase production capacity. Onboarding: reduce time to production capacity. Unblocking: recover lost production capacity. Planning: allocate production capacity. Career development: increase individual production capacity over time. Retention: avoid losing production capacity.
That is not cynical, it is just the shape of the thing. Human throughput was the binding constraint on almost every software team that has ever existed, so an enormous amount of managerial practice grew up around maximising and protecting it. Every book, every framework, every performance rubric.
Remove that constraint, even partially, and a large fraction of managerial habit is now optimising something that is no longer scarce. You can double a team’s generation capacity and change nothing about how much good software reaches production, which is a genuinely disorienting experience for someone whose instincts were all built around the old bottleneck.
The constraint moved and nobody sent a memo
Here is the mechanical version of what happens.
Work enters the team as tickets or criteria. It gets built. It gets reviewed. It gets merged. It gets verified against what was actually wanted. Under the old shape, the build step dominated everything: it was slow, it was where the skill lived, and every other step was small by comparison.
Speed up the build step by five or ten times and it stops dominating. It becomes one of the cheap steps. And in any queue system, when you remove the constraint at one stage, the queue does not disappear, it relocates. It relocates to whichever remaining stage has the least capacity, and that stage is almost always human review.
This is the part managers keep missing, because the symptom is confusing. The team feels fast. Individual engineers report that they are getting more done than ever. And yet lead time from ticket to production does not improve much, or gets worse, because there is now a pile of work sitting in front of a review gate staffed by the same number of people with the same number of hours.
Then the second-order effect arrives. Reviewers under queue pressure do not review more slowly and carefully. They approve faster. Review quality degrades silently, nobody reports it, and eight weeks later the change failure rate tells you what happened. That is the mechanism behind “velocity is up and quality complaints are up,” and it is not a people problem. It is a queue design problem, which means it belongs to the manager.
Three systems the manager now owns
If the job is system design, it helps to name which systems.
Intake quality. Everything downstream is a function of what enters the pipeline. A team whose tickets are two vague sentences will generate confident wrongness at high volume, and no amount of review heroics will fix it, because reviewers cannot check work against an intent that was never stated. The manager’s leverage here is not writing the criteria, it is making it structurally impossible for underspecified work to enter the build stage. That means an intake standard, applied consistently, including on the day when the VP wants something by Friday. Especially then.
Review capacity and allocation. This is the new capacity planning, and almost nobody does it explicitly. How many changes per week can this team actually review at the depth those changes deserve? Which changes deserve depth and which deserve a skim? Who is qualified to review which areas, and is that list two people long? A manager who can answer those four questions is managing the real constraint. A manager who cannot is going to be surprised by their change failure rate.
The uncomfortable implication is that not everything should get the same review. A configuration change and a change to the permission model are both a pull request, and treating them identically is how you get slow reviews of trivia and fast reviews of danger. Risk-weighted review depth is unpopular because it feels like inconsistency. It is the only thing that makes the arithmetic work.
Feedback loops. How long does it take this team to find out it was wrong? That number used to be dominated by release cadence. Now it is dominated by whether anyone is checking outcomes at all. When generation is cheap, the failure mode is not “we did not build enough,” it is “we built things and nobody looked at whether they worked.” Instrumenting the loop from merge to observed outcome, and shortening it, is now a first-order managerial responsibility rather than a nice-to-have owned by whoever is enthusiastic about dashboards.
Intake standard
What is not allowed to enter the pipeline. The cheapest gate and the one most often waived under pressure.
Review budget
Changes per week reviewable at real depth, and who is qualified for what. Usually unmeasured and usually two people deep.
Risk weighting
Not every change deserves the same scrutiny. Uniform review is slow where it does not matter and shallow where it does.
Outcome loop
Time from merge to knowing whether it worked. When building is cheap, this becomes the real measure of a team.
Evaluating people when output is not the signal
This is the part managers ask about first and it is genuinely hard.
Performance conversations have always leaned on output, sometimes explicitly, usually implicitly. Volume shipped, complexity handled, speed of delivery. Those signals get noisy fast when a large share of the typing is done by something else. Two engineers with identical merge counts can be doing wildly different jobs, and the difference is invisible in the numbers.
The signals that still discriminate are all about judgement, and they are all observable if you look at the right artefacts.
Look at what someone rejected. An engineer who accepts everything the pipeline produces is not doing the job. The rejections, the “this passes the criteria but the criteria were wrong” moments, are the clearest evidence of engineering judgement available, and they leave a trail in review comments.
Look at the criteria they wrote. Specification quality is now a core engineering skill, and it varies enormously between people. Some engineers write acceptance criteria that anticipate four failure modes nobody else thought of. That is seniority, expressed in a new medium.
Look at what happened after their changes. Rework rate on someone’s work is a slow signal but an honest one. If a person’s merged work keeps coming back, volume is meaningless.
Look at what they made unnecessary. The highest-leverage engineers now often reduce work rather than produce it: deleting a subsystem, changing an interface so a whole class of tickets stops existing, noticing that two teams are building the same thing. This has always been true and it has always been badly rewarded. It is now the difference between a strong engineer and a fast one.
Signals that stopped discriminating
- Volume of changes merged
- Lines written
- Speed from assignment to pull request
- Number of tickets closed in a sprint
- Being the person who works late
Signals that still do
- What they rejected, and why
- Quality of the criteria they wrote
- Rework rate on their merged work
- Work they made unnecessary
- Whether others' work improves near them
The one-on-one problem
Back to Monday, and the conversation with nothing to say.
A lot of one-on-one practice is built around obstacle removal, which assumes an obstacle. When throughput is high and blockers are rare, the ritual gets hollow, and both people can feel it. The instinct is to fill the gap with process talk or, worse, to quietly stop having them.
The better move is to change what the conversation is for. Not “what is blocking you,” which now often has no answer, but “show me a decision you made this week that you were not sure about.” That question works because the volume of decisions per engineer went up sharply even as the volume of typing went down. Every accepted change is a decision. Every rejected one is a decision. The interesting material has moved, and the conversation has to move with it.
This also solves the evaluation problem, partly, because a manager who hears about twenty judgement calls a quarter has evidence of judgement, which is exactly what the output numbers no longer provide.
Where this breaks down
Four honest caveats, and the last one matters most.
Most managers are not equipped for this and are not being trained for it. Queue theory, risk-weighted gating and feedback loop design are systems engineering skills. The path into engineering management usually runs through being a strong individual contributor and then learning people skills. Nothing in that path teaches flow design, and telling managers the job has changed without giving them the vocabulary or the training is how you produce a lot of anxious people reinventing basic operations research badly.
Small teams should mostly ignore this. If you have four engineers and one product, the queue is short enough to manage by looking at it. Formal review budgets and risk weightings are overhead you cannot afford and will not benefit from. This whole framing starts to earn its keep somewhere around three teams and a system nobody can hold entirely in their head.
The people part did not shrink. I have written a lot about systems here, and it would be easy to read that as “management is now operations.” It is not. Anxiety is up in most engineering organisations right now, for obvious reasons, and a manager who responds by becoming a flow engineer while people quietly worry about their careers will have an efficient pipeline and an attrition problem. The systems work is additive. Nobody removed the other half.
Measuring the system can poison it. The moment review depth becomes a tracked metric, review depth becomes a performance. People will leave more comments, not better ones. This is Goodhart’s law and there is no clever escape from it. The most reliable approach I know is for the manager to read a sample of reviews themselves, form a private judgement, and never publish the number. That does not scale well, and I am not going to pretend it does.
The takeaway
The engineering manager’s job was mostly about production capacity because production capacity was the constraint. It is not the constraint any more, and the queue moved to review, where it is quietly degrading quality in a way that shows up two months later as a change failure rate nobody can explain.
The work now is designing intake standards, budgeting review capacity honestly, weighting scrutiny by risk, and shortening the loop between merging something and finding out whether it was right. Alongside that, an evaluation practice built on judgement rather than volume, because volume no longer tells you anything about a person.
If you do one thing: sit down and write the number of changes per week your team can review at real depth. If you cannot produce that number, that is the finding, and it is the most important gap in your management of the team right now.
The next piece takes on a question people ask nervously and half-joking, which is whether any of this leaves a role for the scrum master, and what happens to the ceremonies when the record maintains itself.