Unfinished Initiative Load

An architecture function of 5 people has 6 migrations in flight. Each reports about 40% complete. On a status page that looks like a productive quarter. In the estate it means 6 pairs of systems running at once, 6 sets of synchronisation or dual-write code, 6 sets of runbooks that describe two shapes of the world, and zero realised benefit, because an architecture migration pays out on completion and not before.

The arithmetic is worse than the percentage suggests. The remaining 60% of each is the hard part: the services with no owner, the forked copies, the client nobody can contact. And the coexistence machinery itself has to be built, operated and then removed, which is work that exists only because the migration is unfinished. Percentage complete measured in services is usually a large overstatement of percentage complete measured in effort.

Unfinished initiative load is simply the count, maintained deliberately and treated as a capacity limit rather than as a status report.

Why it matters

Architecture backlogs are ranked by value and effort, and ranking says which item to start. It says nothing about how many may be in flight, so a function under pressure to be responsive starts a seventh. Every start is locally defensible and the aggregate is an estate that permanently runs two of everything.

The cost is paid in three places. Infrastructure, because both ends run; people, because on-call must understand two systems and the bridge between them; and change velocity, because every new feature has to be built against both shapes or against the bridge. The third is the largest and the least visible: a team shipping into a half-migrated subsystem routinely pays 30 to 50% more per change, and reports it as the subsystem being complicated.

Implementation patterns

• Count initiatives, not tasks, and define an initiative as finished only when the old path is deleted and the coexistence code is gone. "Migrated" with the old system still running is not finished.
• Cap the count at what the function can finish in one planning cycle. For a 5-person architecture group that is 2, occasionally 3. The cap is the useful part; the ranking only decides which 2.
• Finish before starting. When a seventh item is urgent, something in flight is explicitly paused with its coexistence state documented, or something is abandoned and reverted. Both are better than six at 40%.
• Publish the oldest unfinished initiative's age. Anything past 4 quarters is almost certainly never going to finish on its current plan and should be re-cut into something completable.
• Re-cut rather than start. If an initiative cannot be finished within two cycles, the right move is to split it into a part that can be finished and a part that is not yet justified.
• Budget the removal work up front as a named deliverable, because deleting the old path is the step that always loses to the next new thing.

Industry example

A 300-engineer enterprise software vendor consolidating onto one deployment platform ran 5 concurrent platform migrations for 3 years. Each was reported at between 30% and 70%; none finished. The observable consequence in production was 2 of everything — two ingress paths, two secret stores, two CI systems — and a platform group whose entire capacity went to keeping the bridges working. The change that moved it was not more people: it was a cap of 2 concurrent initiatives, with the other 3 frozen in a documented state, which finished the first two in a quarter and made the third cheaper because the bridge it needed had already been deleted.

Failure scenarios

• A legacy column that never empties, with the team maintaining 12 systems where it used to maintain 6.
• Coexistence code becoming load-bearing, so the bridge built as a temporary measure acquires its own consumers and can no longer be removed.
• Reorganisation mid-flight, after which no team can say what state the migration is in, and the safest action is to leave both ends running.
• A stalled initiative used as a reason to block work — new features refused because "we are migrating", for a migration that is not progressing.
• Progress theatre: reporting the easy 70% of services as 70% complete, which makes the next planning round believe the remaining work is small.

Trade-offs

A hard cap means saying no to legitimate, well-argued, high-value work while something less exciting is finished, and it will be unpopular with whoever brought item seven. It also risks finishing the wrong thing, because the cap commits capacity before new information arrives.

The counter-argument is arithmetic: two finished migrations deliver two benefits and remove two coexistence costs, while six at 40% deliver nothing and cost more than doing none of them. Where the work is genuinely parallel and independent — different teams, different subsystems, no shared bridge — the cap can be higher, and that is the condition to test before loosening it.

When not to use it

Do not apply a cap to initiatives that are cheap to leave half-done. An opt-in client library, a new dashboard, a lint rule rolled out team by team: these can sit at 40% adoption indefinitely with no dual-run cost, because nothing has to be kept consistent between the two states.

It is also the wrong instrument where the constraint is not attention but a hard external date — three regulatory migrations with statutory deadlines must all run, and the answer is to buy capacity or renegotiate scope, not to pick two. Choose the cap when the limit is the organisation's ability to finish; choose funding when the limit is the calendar.

Interview question

Q: You join as the first architect at a company with 6 migrations in flight, each reported around 40% complete, and a backlog of 14 more proposals. The CTO asks which of the 14 to start. How do you answer?

What a strong answer covers: declining the question as asked, because starting a seventh makes the estate worse regardless of which one · the measurement to take first, namely the dual-run cost of each in-flight initiative and the age of the oldest · the move to finish two and explicitly freeze or abandon the rest, with the frozen state documented · why effort-complete differs from services-complete and how to estimate the tail · the cap as a standing rule with a named number · and the one exception worth carving out, which is work with a statutory date.

Quick check

Quiz: Six migrations each 40% done, five architects. What is the estate paying? Both ends of all six plus six bridges, with none of the six benefits realised — more than either the old or the new estate would have cost alone.

Flashcard: Why does an architecture backlog need a concurrency cap and not just a ranking? — Ranking says which to start; only a cap stops an estate accumulating permanent half-migrations, each paying for two systems and delivering no benefit until it finishes.