Span of control and decision load

Day 26: Span of Control Is Now Measured in Open Decisions, Not Headcount

Your org chart says you manage four people. Count what's actually waiting on you and you might find thirty decisions. Your company sizes manager roles on the first number: how many reports you get, whether your team gets flattened, whether you can "take a few more." Once your engineers run coding agents, that number stops tracking the real load. This lesson gives you a measure that does.

The Tuesday tally

One Tuesday I wrote down every decision that was waiting on me. I had 4 reports and 31 open decisions: architecture calls, agent-generated PRs that needed real judgment and not a lint pass, scope questions, risk sign-offs. Years earlier I managed 11 engineers who wrote their code by hand, and on a normal day that list ran to about 10. On paper my job had got easier. My calendar disagreed. The rest of this lesson covers why that happens and how to measure it on your own team.

Why the old number fails

Span of control was always a stand-in. What actually mattered was coordination load, and headcount happened to be easy to count. In 1933 V. A. Graicunas, a management consultant, showed that a manager's possible relationships grow far faster than the number of reports. He counted direct one-to-one links, links with groups of reports, and the cross-relationships between reports. His formula is n(2^(n-1) + n - 1). With 4 reports you get 44 relationships. With 8, 1,080. With 10, 5,210. Lyndall Urwick used this to argue that a manager whose reports' work interlocks should have no more than about 5 or 6 of them. You'll usually hear that quoted as 5 to 7.

Those rules held for decades because of an assumption nobody said out loud: one engineer produced roughly one engineer's worth of decisions. Count the people and you had a fair proxy for the things that needed a manager's judgment. Coding agents broke that assumption.

What actually changed

On the agent-heavy teams I've worked with, an engineer typically runs 3 to 5 agent streams in parallel in Claude Code, Codex, Cursor background agents or similar tools. Code got much cheaper to write. Decisions didn't get cheaper at all. Every stream keeps throwing up moments that need a judgment call:

• ▹Scoping questions. The agent took the ticket literally. Do we extend it or cut it?
• ▹Review calls: the code works, but is this a design we want to live with?
• ▹Integration conflicts, where two streams changed the same module in ways that don't fit together.
• ▹Safe-to-merge moments, when the change touches auth, payments, migrations or production config.
• ▹Ownership. An agent refactored a shared library. Who maintains it now?

Engineers settle most of these on their own. The hard ones get escalated: the ambiguous ones, the cross-team ones, the ones that carry real risk. Those land with you. So one engineer running four agent streams brings you the decisions, risks and review load of a small team, and a single 1:1 now covers what three people's work used to. That's how a manager of 3 agent-heavy engineers ends up more stretched than a manager of 10 who code by hand.

The new unit: open decisions (open loops)

Definition: an open decision is any choice that is either blocked on you, or being quietly made for you because you're too slow to make it. Your decision load is the number of these open at the same moment.

• ▹Kind 1, blocked decisions: someone is waiting for you. A PR is parked for your review, a scope question is sitting in your DMs, a migration needs your sign-off. You can see these and they annoy people, so they tend to get cleared.
• ▹Kind 2, shadow decisions: nobody waits. The engineer, or their agent, picks an option and keeps going. A PR gets approved and merged because it's old. Scope grows because nobody said no. A risky dependency goes in because asking felt slower than shipping.

Kind 2 is the dangerous one. A blocked decision costs you speed, and you can see it happening. A shadow decision costs you correctness and alignment, and you find out later: in an incident, in a rewrite, or when you notice the architecture drifted while you were in meetings. Agents make shadow decisions far more likely because an agent never stalls waiting for you. It just carries on with its best guess.

How-to part 1: the 5-day decision tally

You can't manage a load you haven't measured. Keep a plain log for five working days. Every morning and every afternoon, write down each decision that's currently waiting on you, and tag it by type and by age.

• ▹Scope: what's in, what's out, what gets cut.
• ▹Architecture: design choices that will be expensive to undo.
• ▹Risk: sign-off that something is safe. That covers security, data, prod access, compliance, or an agent touching a sensitive module.
• ▹People: performance, conflict, growth, hiring.
• ▹Review: a PR or design doc that needs your judgment, not just a click on approve.
• ▹Age: how long it's been open (under 1 day, 1 to 2 days, more than 2 days).
• ▹Shadow decisions go in the log too, whenever you find one. These are things decided without you that you'd have wanted a say in. Mark them S.

date,time,id,type,description,source,age_days,shadow
2026-10-13,09:00,D-01,risk,Agent PR rewrites token refresh in auth-service,Linh/agent-3,2,N
2026-10-13,09:00,D-02,scope,Export feature: include CSV or ship JSON only?,Minh,1,N
2026-10-13,09:00,D-03,architecture,Two agent streams added competing retry wrappers,An/agent-1+agent-2,3,N
2026-10-13,09:00,D-04,review,Agent-generated migration for orders table,Huy/agent-2,1,N
2026-10-13,16:00,D-05,scope,Admin filters added beyond ticket (found merged),Minh/agent-4,0,S

At the end of each day, count open items by type and by age bucket. A spreadsheet pivot table does the job. Here's what my week looked like:

Day   Scope  Arch  Risk  People  Review  Total  Open >2 days
Mon     6     5     7     2       8      28       6
Tue     7     5     9     2       8      31       9
Wed     5     4    10     3       7      29      11
Thu     6     5    11     2       6      30      12
Fri     4     4     9     3       6      26      10

Risk was the column that surprised me. I'd expected review to dominate, since that's what everyone complains about. Instead, risk sign-offs on agent output climbed every day through Thursday while review shrank, and they aged worse than anything else. They were also the decisions I least wanted made by default. When an agent produces a clean diff to an auth flow, "looks fine, merge" is exactly the wrong default. Don't stop at the total, either. The over-2-days column doubled from Monday to Thursday while the total barely moved.

How-to part 2: reading your number

Nobody has a validated benchmark for decision load yet, and I'm not going to make one up. These are the rough bands I check myself against. I define them by behaviour, because the raw count swings a lot depending on how you slice decisions:

• ▹Comfortable. Most decisions close within a day or two, and you can explain the reasoning behind each one. Your 1:1s still have room for growth conversations, not just triage.
• ▹Stretched: the pile of decisions older than 2 days keeps growing. You batch decisions into late-evening sessions, and 1:1s turn into decision queues. People start opening with "I know you're busy, but…".
• ▹Rubber-stamping, where decisions get made by default. You approve PRs because they're old, not because you've judged them. Every week you find shadow decisions after the fact. You sign off on risk without reading the diff.

The count isn't what gives it away. What gives it away is the point where decisions start getting made by default. Watch for these signs:

• ▹Your PR approvals cluster on the oldest PRs, not the riskiest.
• ▹Scope drifts and nobody can tell you who agreed to it.
• ▹Your S (shadow) tally is above zero most days.
• ▹Engineers stop escalating. Things aren't fine; escalating just doesn't get an answer any more.

How-to part 3: three levers that cut decision load without adding headcount

Lever 1: push decision rights down, with explicit boundaries. This builds on the delegation lesson earlier in the series. Vague delegation like "use your judgment" produces shadow decisions. Explicit delegation produces decisions someone owns. Write it down: "You own everything inside the billing module, including agent PR review and merge. Escalate only if it changes a public API, touches money movement, or needs a migration." Those decisions now belong to the engineer, and they stop being open loops for you.

Lever 2: set standing policies, so whole classes of decisions are made ahead of time. One policy can remove dozens of individual decisions a week. Write the policy down, then enforce as much of it as you can with tooling (CODEOWNERS, branch protection, required checks) so it doesn't depend on anyone remembering.

# team-decision-policy.yaml (human-readable policy; enforce via CODEOWNERS + branch protection)
agent_prs:
  auto_owner_review:   # engineer who ran the agent reviews and merges; manager not needed
    max_lines_changed: 200
    paths: ["services/catalog/**", "web/components/**", "docs/**"]
    requires: ["tests pass", "no new dependencies", "no schema changes"]
  tech_lead_review:
    paths: ["services/orders/**", "shared/**"]
  manager_signoff_required:   # the short list that stays with me
    paths: ["services/auth/**", "services/payments/**", "infra/prod/**"]
    triggers: ["db migration", "new third-party data flow", "permission changes"]
scope:
  ticket_expansion_under_half_day: engineer decides, note it in the PR
  ticket_expansion_over_half_day: ask product owner, not manager

Lever 3: promote a senior engineer to tech lead for agent orchestration. Their job is to own integration conflicts between streams, set agent conventions (prompts, context files, test gates), and do first-pass review of risky agent output. Whatever your org chart calls it, that's a middle layer. Give them the title and the decision rights in writing. If you don't, they'll do the work and the escalations will still come to you.

The research view, briefly

My PhD work at RMIT is on multi-agent systems, and this pattern comes up there all the time. Multi-agent systems use hierarchical coordination for a reason. The Contract Net Protocol, holonic architectures, and today's orchestrator-worker setups for LLM agents (Anthropic's "Building effective agents" post describes this pattern) all add structure, because a flat network of capable agents drowns in coordination messages. If every agent can talk to every other agent, the number of possible conversations grows roughly with the square of the number of agents, and negotiation crowds out useful work. Agent-heavy human teams now behave the same way. Each engineer plus their agents acts like a capable sub-team. In a flat structure, conflicts have nowhere to get resolved locally, so every escalation climbs to one node. That node is you.

The org-design warning for directors and founders

If you're flattening the org on the logic that "AI makes everyone 10x, so each manager can take 12 to 15 reports," check decision load per manager first. That logic assumes AI shrinks coordination. On agent-heavy teams it does the opposite. More output means more decisions. More parallel streams mean more integration conflicts and more risk sign-offs. The managers and tech leads you're about to cut are the layer that was soaking up that coordination cost, and you'd be cutting them just as the cost goes up. The org chart won't show the damage. You'll see it months later as rubber-stamped PRs, scope drift, and incidents traced back to decisions nobody remembers making. Before you change anyone's span, ask each manager for one week of decision tallies, and plan around that data instead of headcount.

Exercise: before Day 27

• ▹Run the tally for one full day. Log every decision waiting on you, tagged by type and age, with shadow decisions marked S.
• ▹Circle your biggest column and your three oldest items.
• ▹Pick one standing policy you could write this week that would remove at least five of those decisions.
• ▹Take the number to your 1:1 with your own manager, framed so it can't be waved away: "My headcount is 4. My decision load is 31. Here's what's in it, and here's what I'm doing about it."

Extend your knowledge

• ▹V. A. Graicunas, "Relationship in Organization" (1933), and Lyndall Urwick's writing on span of control. This is where the numbers everyone still quotes came from, and the reasoning behind them.
• ▹Anthropic's "Building effective agents" post. Compare its orchestrator-worker pattern with your own team structure and ask where your orchestrator layer is.
• ▹Will Larson's "An Elegant Puzzle" (sizing teams and managers) and Camille Fournier's "The Manager's Path". Reread their span guidance with decision load in mind, not headcount.
• ▹Hands-on: set up GitHub CODEOWNERS and branch protection on one repo to enforce a single standing policy for agent PRs, then compare your tally before and after.