You're Not Managing Engineers Anymore. You're Allocating Judgment.

Everything in engineering management was built to allocate one thing: engineer-hours.

Sprint planning hands them out. Estimation prices them. Headcount requests buy more of them. Roadmap negotiation is a fight over how many of them a thing costs. Performance review measures how well someone spent theirs. Span of control limits how many of them one person can supervise.

The whole discipline is a system for handing out a resource that now stretches on demand.

I don’t mean people stopped mattering. I mean the exact thing you were handing out — hours of human execution — no longer limits your output. You can add execution capacity this afternoon, at a known price, without opening a headcount request.

So what actually limits you?

The number of serious decisions your team can make well each week. How many changes it can genuinely verify. How many systems it truly understands. How much accountability it can carry. That is the cap, and not one management ritual you own was built to hand it out.

Sprint planning hands out a resource that stopped being scarce. The thing that is really capped is judgment, and almost nobody has a way to hand that out on purpose.

This is part thirteen of Rethinking the SDLC. Twelve pieces of mechanism led here. This one is about the org that runs it.

Three pools that stretch in three different ways

#

Start with the model that rearranges everything else. Your team has three kinds of capacity, and treating them as one number is the root mistake.

Execution capacity: stretches on demand, can be bought, close to unlimited. Agent lanes. You can add them today. The limit is money, not headcount, and the price is falling. Managing this pool is a cost problem: track spend per workflow, know what each outcome costs, set budgets, kill the losers, feed the winners.

Verification capacity: stretches a little, and you build it rather than buy it. Gates, evidence, hostile adjudication, mutation testing, traffic replay, policy checks. Machines do the work, but designing it is human and slow. Once the machinery exists you can scale it fast. You cannot produce the machinery in a quarter.

This is the pool that decides whether your execution capacity turns into shipped value or into unsold stock. DORA’s ROI model — roughly $11.6M in first-year returns on $8.4M invested for a 500-person org — comes with one condition attached: the maths only holds for organizations with strong platforms and CI. That condition is a statement about this pool. Strong CI is verification capacity.

Judgment capacity: hard-capped, slow to grow, impossible to buy. Architectural decisions. Serious approvals. Refusals. Root-cause calls where the evidence is unclear. Understanding a system well enough to know whether a change is safe.

This pool grows at the speed of human experience. You cannot hire it quickly — a senior engineer needs six months to have judgment about your systems, whatever they knew before. You cannot train it in a workshop; I’ve written about how everyone trained their engineers and the gap didn’t move. It is built by being answerable for consequences, over time.

Now here is the management failure behind almost every bad outcome in agent-heavy organizations: they scale pool one, ignore pool two, and burn pool three to absorb the difference.

You see it in the data. LeadDev documented an organization that lost three mid-level engineers in six to eight weeks while shipping 40% faster — right until the incidents arrived. A survey of 2,147 engineers found 71% often feeling like a middleman between AI output and results. Plandek’s 2026 benchmarks across 2,000+ teams show the bottleneck moving cleanly downstream into review, testing, and integration, with the slowest quarter of teams taking 35+ hours to merge a PR.

Every one of those is the same story from a different angle: unlimited pool one, missing pool two, and pool three quietly taking the strain until it breaks.

The lane is the unit of ownership

#

The question I get most often is “who owns an agent?”, and it names the wrong thing. The right unit is the lane: one specific workflow, running at a specific autonomy tier, with specific capabilities.

You cannot own an agent, any more than you can own a compiler. You can own a lane. It has a purpose, a blast radius, a track record, a cost, and consequences.

Every lane needs exactly one human owner, and the ownership is real:

• The verification requirements. What proof a change from this lane must arrive with.
• The autonomy tier. How far it may go without a human, and the evidence that justifies it.
• The capability grant. Identity, tools, egress, credentials.
• The runbook. What normal looks like, the failure modes, what the on-call may do about each.
• The outcomes. When this lane ships something bad, a name answers for it.
• The money. Cost per verified outcome, and whether it beats what a human would cost.

Three rules make it hold. One owner, never a team — “the platform team owns it” means nobody owns it at 3 AM. Ownership can be passed on but never shared, and passing it on is an event with a handover, like an operations shift change. And a lane with no owner gets switched off, not written up as a risk. That last rule is the only version of this policy that survives contact with reality.

This is the org-chart argument I’ve been making for a while — agents belong on the org chart with roles, owners, and KPIs — with a sharper unit of ownership. Not “who owns the agent?” Who owns this lane, at this tier, with these permissions.

Span of control goes down, not up

#

Here is the take that will annoy the people building headcount models right now.

The common assumption is that agents let you flatten the org: fewer engineers, more output, so more engineers per manager and fewer managers. I think that is backwards, and the orgs that act on it will spend 2027 undoing it.

Span of control was never limited by how many people a manager could keep track of. It was limited by how many people a manager could coach, judge, and answer for. Agents do not reduce that load. They add a second one on top.

A manager in an agentic org is now accountable for:

• The humans: growth, evaluation, and — new and hard — deliberately building judgment in people whose work no longer builds it automatically.
• The lanes: tiers, owners, verification requirements, incidents, and economics.
• Splitting work across three pools that stretch in different ways.
• The judgment budget: which decisions actually get human attention this week.

That is a bigger job with more sides to it, not a smaller one. And the coaching half got harder, because the old way of building engineering judgment — do the work, be wrong, feel it, learn — is exactly what agents took away. Anthropic’s randomized trial found developers learning a new library with AI scored 17 percentage points lower on mastery than those who learned without it. LeadDev’s 2026 Engineering Leadership Report has 38% of leaders worried juniors get less hands-on experience.

So here is my actual prediction: fewer engineers per manager, more managers per engineer, and a very different kind of manager. The manager who was good at coordinating human work will struggle. The one who can reason about risk, verification, and autonomy — who can look at a lane and say “that tier is wrong for that blast radius” — becomes the most valuable person in the middle.

I will take the argument against seriously: smaller teams shipping more is real, and I have seen it. But look at which teams. They are the ones with strong verification capacity and deep understanding of their systems — high pool two and high pool three. Small teams work because those pools are full, not because agents made supervision free. Cutting management to pay for agent spend drains exactly the pools that make agents pay off.

Allocate the judgment budget explicitly

#

This is the practical heart of it, and it is the ritual that replaces sprint capacity planning.

Estimate the pool. Per week, per engineer, how many serious decisions can they make well? Not answer — make well, with real understanding. My working number is small: about five to eight for a senior engineer, alongside their other work. Argue with the number. The point is that it has a limit, that you can roughly know it, and that nobody writes it down today.

Then allocate it against demand, in this order:

1. Class C/D approvals — changes you cannot undo, and architectural ones. Not negotiable.
2. Architecture and boundary decisions — the highest-value use, and the first one to get squeezed out.
3. Verification design — deciding what proof each change class needs. It pays off forever, which is why it should never be the thing you do with what’s left over.
4. Unclear incident calls — the ones no rule covers.
5. Judgment-building work for humans — see below. This is an investment, and it belongs on the list, not in the gaps.
6. Everything else — and this is the giveaway. If Class A review, mechanical verification, or routine fixes are eating judgment budget, you have a missing mechanism, not a capacity problem.

Then track how far you go over. When demand passes the pool, one of three things happens: decisions get made badly, decisions get made slowly, or decisions get rubber-stamped. All three are invisible in your dashboards, and all three do their damage later. Approval theater is a capacity signal, and it is the one your metrics will never show you. Merges still merge, queues still drain, and everything looks better as it gets worse.

Which is why the honest management question is not “how much can we ship?” It is: how much can we ship that we actually understand and can stand behind? That number is your real capacity, and it is the only one worth planning against.

Fund scar tissue as a line item

#

The hardest problem in this whole series, and I want to be honest that I don’t think anyone has fully solved it.

Engineering judgment comes from consequences. You learn a change is dangerous by making a dangerous change. You learn to distrust a fix that looks right by shipping one that wasn’t. That loop — do, fail, own it, understand — is how every senior engineer you respect got there.

Agents took the “do” out of most work. So the loop never runs, and nothing replaces it. Not courses, not sitting next to someone, not documentation. Consequences are the ingredient.

So growing judgment stops being a side effect of the work and becomes something you have to schedule and pay for. In practice:

Route work to humans deliberately, for development reasons, and say so. Not because the human is faster — they aren’t. Because this person needs to own this subsystem end to end, and that means having built and broken part of it. Put it in the plan as time set aside for growth, so nobody tidies it away as waste.

Give real ownership early, with real blast radius, bounded. A junior who owns a lane — its verification, its tier, its incidents — builds judgment fast. A junior who reviews agent output builds fatigue. Same hours, opposite outcomes. This is the single most important choice in how you shape junior work now.

Treat incidents as a way to grow people, not as a punishment. Nothing builds judgment faster per hour than an incident. Rotate people into them on purpose, with a senior alongside, and stop treating on-call as a tax to be squeezed down.

Pay for understanding. Assign people to learn systems they didn’t build, and have them deliver an architecture document, a set of invariants, and a runbook. Then check it by having them defend it. That is a real work item with a real output, and it pays down the one debt that damages everything else.

Two people should be able to explain every critical subsystem. Track it. Where the answer is zero, you have a system your organization no longer owns, and no amount of cheap execution buys that back.

What to stop doing

#

• Stop planning agent lanes in story points. Points priced human hours. Plan lanes by cost per verified outcome, and by how much judgment they eat.
• Stop measuring individuals on throughput. Under agent volume it counts lanes, not contribution. Measure lanes owned and how they turned out, verification designed, judgment made visible.
• Stop treating review capacity as spare time. Make it a stated budget, like on-call.
• Stop presenting adoption rates to leadership. Uber reported 95% adoption and admitted the link to product outcomes “is not there yet.” It is a comfort blanket.
• Stop letting seniors drift into being the verification layer. That is your highest-value pool spent on your lowest-value work, and they will keep volunteering because it feels responsible. Point them at building the gate instead.

Governance is the management skill now

#

Here’s what I think the job actually becomes, and why I find it more interesting rather than less.

For thirty years engineering management was mostly about coordination: getting the right work to the right people in the right order, and clearing obstacles. That is a real skill, and much of it can now be automated. Agents coordinate work well, and the ordering problems that ate whole planning meetings mostly disappear when execution stretches on demand.

What remains is governance: deciding what may happen autonomously and what may not, who is accountable for which lane, what proof is required for which class of change, how autonomy gets earned and revoked, and how humans acquire the judgment the system depends on.

That is not paperwork. It is designing a production system where most of the execution is machine and all of the accountability is human. Get it right and a small organization runs like a much larger one. Get it wrong and you have built a very fast way to ship things nobody understands — which is the same as a very fast way to have an incident nobody can explain.

DORA’s amplifier finding is the whole thing in one sentence: AI makes a good organization dramatically better and a weak one dramatically worse, faster. The thing being amplified is the quality of your management. That is uncomfortable, and it is the most useful fact in this series — because unlike model capability, it is entirely yours to change.

The agents do the execution. The humans own the outcomes. Deciding who owns which outcome, and making sure they’re actually capable of owning it, is the job now.

So here is the question I would take into your next planning session, before any roadmap talk. How many serious decisions did your team make last week, and how many of them did the people deciding genuinely understand?

If the second number is clearly smaller than the first, you have found your constraint. And you will not fix it by adding another lane.

I lead AI transformation for a global SaaS platform, and the three-pool model plus lane ownership is how I actually plan. If you’ve built a judgment budget, or your span-of-control numbers are moving the other way from mine, I want to compare — this is the piece I’m least certain about and most interested in. Find me on X, LinkedIn, or Telegram.