Sequencing Under Zero Spare Capacity

Overview

Every plan in this module runs into the same wall. The structural work is correct, the sequence is sound, and there is nobody to do it.

“No spare capacity” is the normal condition rather than a crisis, and the architect’s job is not to escalate until capacity appears. It is to produce a sequence that is executable with the capacity that exists, which means treating capacity as a hard constraint in the design rather than a risk in the appendix.

What money does not buy

The reflex is that a funded initiative solves this. It does not, for three reasons worth being precise about.

New engineers cannot touch the oldest system productively for months. A long-lived codebase holds knowledge that is not in the code, and a new hire needs a substantial ramp before changes there are safe. Budget converts into capacity on the parts of the system that need no history almost immediately, and into capacity on the legacy core only after a long delay.

The scarcest resource is usually one specific person’s attention. Every plan that touches the legacy core needs review from whoever holds its context, and that person is already the bottleneck on the existing programme. Money does not duplicate them, and hiring around them does not work because the review is the constraint, not the typing.

Hiring has a lag and a cost of its own. Recruiting, onboarding and mentoring are drawn from the same senior people whose time is the constraint — so a hiring plan makes the bottleneck worse before it makes it better.

So the honest statement is: funding buys capacity for greenfield work quickly, and for legacy work slowly. That single asymmetry determines the correct sequence.

Sequence by dependency on scarce context

graph TD
  A["<b>Needs no legacy context</b><br/>new hires productive in weeks<br/><i>schedule first</i>"] --> B["<b>Needs a stable contract</b><br/>one review, then independent<br/><i>schedule second</i>"]
  B --> C["<b>Needs deep legacy context</b><br/>bottlenecked on one person<br/><i>schedule last, in small slices</i>"]

  classDef a fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef b fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef c fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A a
  class B b
  class C c

Order the work by what context it requires rather than by architectural tidiness. The constraint is attention, not money or headcount.

Ship value before you finish

The rubric item, and the discipline that protects a long programme from cancellation.

A sequence that delivers nothing until it completes is a sequence that will be cancelled, because at some point in a multi-quarter programme priorities change and the question “what have we got for this?” is asked. A programme with user-visible results behind it survives that question; one with architecture behind it does not.

This is also the strangler’s native advantage, from the previous topic: each slice moved is value delivered. The equivalent discipline for a new platform is to order capability by what can reach users soonest, even when that is not the order an architect would choose for elegance.

Two further protections worth building in:

Make each stage independently useful. If the programme stops after stage two, stage two should still be worth having. This is a stronger requirement than incremental delivery and it changes sequencing decisions.

Put the riskiest assumption in the earliest stage that can test it. Modules 4 and 6 found the arithmetic of this initiative turns on a single measured quantity; a sequence that defers testing it is a sequence that discovers its central problem late.

Protecting the sequence from the capacity it does not have

Finally, the thing to write down explicitly: what this plan does not ask for. A plan that silently assumes a few engineers will become available is a plan that fails quietly. One that states “this sequence requires no additional capacity from the existing programme, except N hours of review in stage three” can be checked, agreed, and defended — and it is far more persuasive to the person whose team would otherwise have been volunteered.

The sequence the constraints actually permit

Funding is approved — about $1.2M a year — and there is no spare engineering capacity, because the migration consumes it. Both facts are fixed.

Apply the asymmetry. The money hires two or three engineers. They can be productive within weeks on anything with no legacy dependency, and they cannot safely change the 2016 Rails monolith for months. Meanwhile every change near the monolith needs Ivan Petrov’s review, and he is already the constraint on the migration.

That ordering is forced, and it inverts the architecturally tidy sequence:

Stage one — the retrieval path only. It reads product documentation and the support console; it does not touch the monolith. New hires can build it, which means it starts immediately with no draw on existing capacity. It also ships user-visible value first: deflecting documented questions is visible to support agents and to customers within a quarter.

And it tests the riskiest assumption early. Modules 4 and 6 established the whole business case rests on the share of tickets answerable from existing documentation — about 38% by the current audit. Stage one measures that for real rather than trusting the audit, which is exactly where the programme’s central uncertainty lives.

Stage two — characterization tests on the monolith’s credit and scheduling behaviour. Small, bounded, and it needs Ivan’s context rather than his implementation time: review of tests that describe behaviour he knows. The previous topic established this work serves the migration too, which is what makes asking for it reasonable.

Stage three — the action path, in the narrowest possible slice. One action tier, parallel-run against human agents before anything executes. This is the part that genuinely needs deep legacy context, and it is scheduled last because that context is the scarcest input in the company.

What the plan explicitly does not ask for. No engineers moved off the migration. No new team formed. From the existing programme it asks for one thing only: a bounded amount of principal-engineer review time in stages two and three. Saying that in the proposal is what distinguishes it from every initiative Tomas Beck has learned to be wary of.

And it survives being stopped. If funding is withdrawn after stage one, the company has a working deflection capability and a measured answer about its documentation. That is a real result, not a half-built platform.

Feeds the workbook

This is your migration sequence artifact. Two rubric items land on it directly: it must deliver user-visible value before it completes, and it must not assume capacity that does not exist. State explicitly what you are not asking for.

Check your understanding

1. Take a plan you have seen. What capacity did it quietly assume, and where would that have failed?
2. Reorder a programme you know by dependency on scarce context rather than architectural tidiness. What moves?
3. If your programme were stopped after its second stage, what would the organisation actually have?

---

→ Capacity is the binding constraint, which makes anything that multiplies it worth examining carefully. — AI applied to legacy