Part 1 · 1 chapters · ~8 min

Strategy Documents

Strategy versus goals and plans, Rumelt's kernel (diagnosis, guiding policy, coherent actions), engineering strategy in Will Larson's sense (write five design docs, then extract the strategy), vision documents, aligning many teams, making trade-offs explicit, and reviewing strategy over time.

Diagnosis, policy, actions

code

# Engineering strategy: money movement, 2027
## Diagnosis
Payout failures cost 310 support tickets/month and ₦4.1M in manual reconciliation time. 70% trace to three rails
integrated separately, each with its own retry logic, none with automated reconciliation. Each new rail repeats this.
## Guiding policies
1. Every rail integrates through the adapter platform (shared idempotency, retries, status mapping).
2. No rail goes live without automated daily reconciliation against the ledger.
3. We accept slower launches of new rails (+3 weeks each) in exchange for this.
## Actions (Q1-Q2)
- Build the adapter platform with rail 2 as the first customer (team payouts, by Feb)
- Migrate rails 1 and 3 (by May); retire the per-rail retry code
- Make reconciliation a release gate in the rail launch checklist (by Jan)
## What we will not do
- Build our own switching; integrate more than two new rails before the platform exists

Larson's method: engineering strategy is often best written by generalising from several real design decisions (five design docs reveal the recurring choices) rather than from a blank page.

A STRATEGY HAS A KERNEL

Richard Rumelt, Good Strategy Bad Strategy (2011)

swipe the figure sideways, or tap expand for full screen

1/4

diagnosis

Name the crux of the situation simply: "Our payout failures come from three partner rails with no retries and no reconciliation; every new rail repeats the same mistakes."

the crux, simplyhardest and most valuable part