What a programme retrospective round is testing
Formats vary. Some loops give you the topic in advance and expect slides; others ask you to talk without them. Either way the panel is checking three things at once: whether you operated at organisation scope, whether you think in outcomes and cost, and whether you are honest under questioning.
That makes it different from the behavioural question about the work you are proudest of. That question is about your standards. This one asks for a structured account of an investment, with numbers the panel can challenge.
Choose a programme where you owned the decision to start it, the budget or headcount, and the result. A programme you joined halfway or merely sponsored on paper will fall apart at the first "why did you decide that?".
The structure, slide by slide
A twenty-minute programme retrospective holds about eight slides if you leave time for questions. A structure that works:
| Slide | Content | Time |
|---|
| 1. The problem | Business cost of the problem, with the baseline | 2 min |
| 2. The bet | What you proposed, the alternatives, what you asked for | 2 min |
| 3. Key decisions | Two or three choices that shaped the outcome, and why | 3 min |
| 4. Adoption | Usage over time, by team | 2 min |
| 5. Impact | Before and after, with attribution limits | 3 min |
| 6. Cost against plan | People, time, money, overrun explained | 2 min |
| 7. What I got wrong | One decision you would reverse, one you got lucky on | 3 min |
| 8. What it changed | What the organisation does differently now | 1 min |
The misses slide gets as much time as the impact slide. That is deliberate, and assessors notice it.
Worked retrospective: one shared deployment pipeline
The figures here are illustrative and stand in for your own.
The problem. Forty services each had their own hand-built deployment scripts. The median lead time from merge to production was nine days. Two incidents in the previous year came from a manual step being skipped.
The bet. You proposed one shared deployment pipeline and asked for six engineers for three quarters, 18 engineer-quarters in total. You rejected buying a hosted product because two regulated services needed controls it could not provide at the time.
Key decisions. You migrated the two hardest services first, not the easiest, to prove the pipeline could handle them. You did not mandate migration until the pipeline was faster than the old route for the team using it.
Adoption. By the end of the third quarter, 31 of the 40 services deployed only through the new pipeline, about 78 percent against a target of all 40. The evidence is pipeline logs, not a migration tracker: a service counts only when its last ten production deployments went through the pipeline.
Impact. Median lead time for migrated services fell from nine days to two, a reduction of about 78 percent. Deployment-related incidents in migrated services fell to zero over two quarters, which is too short a window to claim much.
Attribution. In the same period, two teams also adopted trunk-based development, which shortens lead time on its own. Because services migrated in waves, you can compare migrated and not-yet-migrated services in the same months. You claim the gap between those two groups, not the whole change.
Cost against plan. The programme used 22 engineer-quarters against 18 planned, about 22 percent over, because the regulated services needed an approval step designed with the compliance team.
What I got wrong. You did not involve the compliance team until the second quarter. Bringing them in at the start would probably have removed most of the overrun. Separately, two teams with unusual build tooling never migrated, and you now think they should have been explicitly excluded at the start rather than chased for six months.
Evidence of adoption is where most retrospectives are thin
Leaders tend to report what they launched. A panel wants to know what people kept using once nobody was pushing them. Good adoption evidence is behavioural: share of deployments, share of traffic, repeat usage, and what happened after any mandate was lifted.
If adoption came from a mandate, say so. A mandated migration can still be right, but it tells the panel nothing about whether engineers valued the result. The platform page on stalled developer-portal adoption show the same distinction from the platform side.
Quantified impact without a baseline is just output
Presenting outputs as impact is the commonest way to lose this round. "Migrated 31 services", "trained 200 engineers" and "launched in Q3" are activity. Quantified impact needs a before figure, an after figure, a metric someone outside engineering cares about, and a statement of how much of the change you are not claiming.
The second half of that trap is overclaiming. Most panellists at this level have run programmes themselves and will ask what else changed. A candidate who has already separated their contribution from the background trend looks like someone who can be trusted with the next budget. A candidate who claims the whole improvement invites the panel to discount everything else they said.
If you never measured a baseline, say so plainly and use the best reconstruction you have, such as historical ticket data or deployment logs. Inventing precision you did not have is worse than admitting the gap. It also gives you a ready lesson for the misses slide.
Handling the questions
Expect follow-ups on the weakest number and on the people who disagreed with you. Prepare for both. Know which figure finance would challenge, and know the strongest argument your opponents made at the start.
When you do not know an answer, say what you would check and where. A programme retrospective is partly a test of how you behave when your own work is under examination, and calm precision there counts for as much as the results.
Spend as long on what you got wrong as on what went well. The misses section is where the panel decides whether to believe the impact section.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).