Delivery framework

Choose work that overlaps the target role, contains real decisions, and has enough observable impact to survive follow-up. Recency matters less than ownership and depth.

• You made or materially shaped key decisions
• The project had a non-obvious constraint or failure
• Results can be measured
• The scope matches the level you are targeting

Give the business or technical pain, who experienced it, and the cost of leaving it unsolved. Constraints explain why your architecture was reasonable.

• Baseline latency, reliability, cost, or workflow
• Scale and growth envelope
• Timeline, team, legacy, or compliance constraint
• Explicit non-goals

Use “we” for shared context and “I” for decisions, analyses, experiments, and influence you personally drove. Name partners rather than absorbing their work.

• Decision you owned
• Alternative you evaluated
• Person or team you aligned
• Artifact or mechanism you produced

Do not jump from activity to outcome. Explain how the mechanism changed a system metric and how that metric changed user, business, or engineering results.

• Before and after measurement
• Experiment or rollout evidence
• Scope of affected users/services/teams
• Known confounders and remaining gaps

A mature retrospective explains what you would choose now, what condition would make the rejected alternative better, and which risk still remains.

• What you would redesign
• What surprised you
• What scaled poorly
• Which decision created lasting leverage