Sequencing With No Spare Capacity

Overview

The previous topic ordered the bets by what is cheap to undo. That ordering assumes you can act on it, which requires engineers who are not currently doing something else.

In most organisations worth hiring an architect into, there are none. This topic is about sequencing when capacity is genuinely fixed — which is the normal condition, not an unlucky one.

Capacity is fixed on your horizon

Three reasons the “we’ll hire” answer does not apply to a twelve-month roadmap.

Hiring takes months, and a new engineer is net negative for a while — they consume the attention of the people who already know the system. Within a planning horizon of a year, new headcount affects the back half at best.

Contractors need the same scarce commodity: the time of people who understand the domain. A system that nobody can explain quickly cannot absorb outside help quickly.

And the capacity that matters is rarely generic. It is the few people who understand the component you need to touch, and they are already the bottleneck on everything else.

So treat capacity as fixed. Every “yes” is a “no” somewhere, and the only question is whether the “no” is chosen or discovered.

The zero-sum picture

With the first AI slice AI slice Strangler migration Keep running

Product work displaced fixed capacity

The bar does not get longer. Adding anything pushes something past the edge, and the only choice is whether you name what it is.

Three honest sources of capacity

There are only three, and “we’ll find efficiencies” is not among them.

Displacement — something currently in flight stops or slows, deliberately, with its owner’s agreement.

Deferral — something planned but not started moves later in the year.

Scope reduction of your own initiative — the thin slice, below.

Anything else is wishful. In particular, be suspicious of the claim that the new work will be absorbed “alongside” existing commitments; that is displacement with no name attached, and what it displaces is usually quality or the migration’s pace.

What to do first when everything is first

Two criteria, applied in this order.

Most learning per unit of capacity. Which slice resolves the most uncertainty about your riskiest bet? Information bought early is what makes the expensive decisions later cheaper, and the Utility Tree’s high-risk leaves tell you where the uncertainty is.

Earliest user-visible value. Which slice produces something a real user experiences? This is not product-management instinct; it is political survival. An initiative with nothing to show by the end of a quarter loses its sponsor’s attention in a company where everything competes.

These two criteria usually agree, and when they conflict, take the learning — but only if you can show something to someone within the quarter anyway.

The structural move that serves both is the thin vertical slice: one narrow path through every layer, end to end, rather than one complete layer across every path. A thin slice exercises the whole architecture on real traffic, which is where the surprises are, and it ships. Building the retrieval layer completely before anything can answer a question is horizontal, comfortable, and defers every unpleasant discovery to the latest possible moment.

The displacement statement

The artifact this topic produces is one sentence per commitment:

To do X by date D, Y slips to date E. Owner of Y: name. Agreed: yes/no.

Write it in the roadmap, not in a footnote. Three things follow from having it.

It converts an invisible cost into a decision somebody made. It gives whoever owns the engineers something concrete to agree or object to, early, which is far cheaper than their silent deprioritisation of your work in month four. And it protects you when the trade bites: the question “who decided this?” has an answer.

The cost is personal and real. You become the person who took something away from a team, in writing, with your name on it. The alternative is being the architect whose initiative never quite moved and who never found out why — and that is the more common fate.

The first slice, and what it costs someone

Capacity is fully consumed by the strangler migration, and Tomas Beck owns all 140 engineers.

The thin slice: deflection only, on the top band of documented “how do I…” questions, read-only, one region, served into the existing support widget. No actions. No second region. No paid tier.

Why this one: it exercises the whole retrieval path on real traffic, which is where the accuracy and cost assumptions get tested, and it produces a number Maya Ortiz can show. It resolves the riskiest parts of bets 1 and 3 — in-region latency and whether the cheap routing tier holds up — without touching the action surface that Lena Fischer and Dev Raghunathan have not yet agreed oversight boundaries for.

The displacement statement: to ship the deflection slice by end of Q1, the Go service extraction planned for the billing read path slips from Q1 to Q3. Owner: Tomas Beck. Agreed: this is the conversation to have in week one, not month four.

Note what the slice deliberately does not do. It does not satisfy Priya Shah’s two-quarter revenue commitment, because the paid tier needs the agent actions. That is a real conflict, it is named rather than smoothed, and the next topic is about settling it in the open.

Feeds the workbook

The rubric requires that your roadmap account for zero spare capacity and say what gets displaced. One displacement statement per quarter, with an owner’s name, is the test. A roadmap that fits comfortably into existing capacity has not been checked.

→ You have a sequence and you know what it costs. Three stakeholders want three different orders, and each is right about their own driver. — The roadmap as a negotiation