Lesson 0046 · Initiative Lead · Module 2
Compare Options and Record Decisions
Senior judgment is not having the first answer faster. It is exposing credible alternatives, buying evidence where uncertainty matters, and leaving a decision future teammates can reconstruct.
Mission tie-in: explicit forces turn architecture from personal taste into organizational reasoning. Decision records make that reasoning durable without freezing it.
Knowledge: design it twice, decide once
For any consequential choice, produce at least two genuinely different designs. “Kafka” versus “managed Kafka” is one mechanism with two suppliers. For carrier failure, credible options are: fail the whole request synchronously; accept and retry from a local outbox; or route work to an agent queue. Compare them against the drivers from lesson 0043.
| Option | Buys | Costs | Evidence |
|---|---|---|---|
| Synchronous failure | least code; immediate truth | outage blocks outcome; poor recovery | fails availability scenario |
| Persist intent + worker | accepted request survives outage | pending state; retries; operations | fits recovery and latency scenarios |
| Manual agent fallback | fastest pilot; human judgment | queue capacity; slower response | viable below 50 cases/day |
Use a spike only when evidence could change the decision. A spike has one question, a timebox, a result format, and a discard rule: “In four hours, measure carrier label p95 and duplicate behavior under timeout using the sandbox; publish numbers and throw away the harness.” “Explore the carrier API” is an unbounded implementation prelude.
Match decision apparatus to reversibility. A local class shape can be changed in a pull request. A public contract, data ownership boundary, expensive vendor, or privacy model deserves broader advice and a written record. Review with the people who carry the consequences: product for outcome, design for experience, security/privacy for trust, operations for failure, and affected teams for contracts.
Use an Architecture Decision Record (ADR) for one decision:
- Status
- Accepted · 12 September · owner: Returns team
- Context
- Carrier outages must not lose eligible requests; peak 40 rps; pilot team owns one deployable.
- Forces
- Availability scenario, 800 ms decision target, operational simplicity, no duplicate labels.
- Options
- Synchronous failure; local intent + worker; manual-only fallback.
- Decision
- Store intent transactionally, process from worker, make carrier call idempotent, expose pending.
- Consequences
- New worker and retry visibility; customer can continue; on-call owns queue health.
- Revisit when
- Volume exceeds worker capacity, carrier offers durable async API, or queue SLO misses twice.
Keep ADRs immutable as historical facts. If the decision changes, write a new one that supersedes it. A one-page record written near decision time beats a forty-page design document updated after everyone has forgotten the disagreement.
Name the decider before review. Advice should improve a decision, not create consensus veto. Record meaningful dissent and the evidence that would prove it right. Psychological safety and technical rigor meet here: a concern can survive even when its preferred option does not.
| Smell | Underlying failure | Move |
|---|---|---|
| “Everyone agreed.” | Dissent or decider disappeared. | Name both explicitly. |
| spike becomes production | No discard rule existed. | Define evidence, timebox, disposal. |
| ADR describes only choice | Future readers cannot reconstruct why. | Record context, forces, consequences. |
| every change needs review board | Apparatus ignores reversibility. | Set decision thresholds. |
Skill: spend evidence where it changes decisions
A useful technical spike must have:
Which decision most deserves an ADR?
Why record a revisit trigger?
Practice: write one decision, not one design epic
Pick an initiative choice that would be expensive to reverse. Draft two meaningfully different options, compare them against named drivers, and identify the largest unknown. If evidence can change the choice, write a timeboxed spike. Then write the one-page ADR, including dissent and a measurable revisit trigger.
Reveal: the ADR compression test
A teammate arriving in six months should be able to answer: what was true, what mattered, what alternatives were real, who decided, what was chosen, what price the team accepted, and which changed fact should reopen it. Everything else can be linked rather than copied.
Your win
You can compare real options, cap uncertainty with targeted spikes, scale review to reversibility, and preserve architectural reasoning in a decision record people will read.
Read and watch deeper
- A Philosophy of Software Design, Ousterhout — ch. 11: design it twice.
- Architecture Decision Record, Fowler — concise decision, context, ramifications, advice, and superseding records.
- Software Architecture: The Hard Parts, Ford et al. — trade-off analysis and architecture decision records.
- Reference: Initiative Playbook · option, spike, and ADR templates.
Give the ADR and driver set to your agent-teacher and ask it to steelman the rejected option, find an unstated consequence, and propose a precise revisit trigger.