The Gap Between What You Said You'd Do and What You Did

The quarterly retrospective is forty minutes in. The facilitator has asked what went well, what didn't, and what the team would do differently. The answers are good — specific, honest, grounded in the quarter's actual work. The authentication refactor slipped into Q4. The infrastructure migration surfaced technical debt nobody had scoped. The two P1 incidents in October consumed more capacity than the on-call rotation was built to handle. The action items are documented.

Near the end, someone asks what to carry into the next planning cycle. A participant opens a tab — the futurespective document from three months ago. She reads the commitments out loud: ship the authentication refactor, reduce P1 incidents by 40%, complete the infrastructure migration. She reads the anticipated risks: third-party payment processor dependency, capacity constraints from two planned absences, unknown technical debt from the migration.

The room goes quiet. The futurespective had anticipated the migration risk exactly. The P1 incidents it flagged as a risk had materialized as an outcome — but nobody had noted during the retro that the team had predicted them. Three of the five commitments never came up in the forty-minute conversation. The two documents describe the same quarter and share almost no language.

The Loop That Isn't Closed

A futurespective is a prediction. It records what a team believes will happen over the coming quarter: the commitments they intend to keep, the risks they expect to navigate, the conditions they assume will hold. A retrospective is evidence. It records what actually happened: where the work went, what intervened, what the team learned.

Put together, they answer a question that neither can answer alone: where does this team's planning consistently part ways with its execution?

Run separately — which is how almost every team runs them — they answer different questions in different conversations, three months apart, without reference to each other. The futurespective is filed when the retro begins. The retro starts fresh, asking what happened without asking what was predicted. The gap between the two documents — where the team's planning assumptions are either validated or contradicted — is never examined.

This is not a process failure. Most teams run good retros and good futurespectives. The problem is structural: the two meetings are not designed to talk to each other. Each produces a document. Nothing connects them.

What the Gap Contains

When you put a futurespective next to the retrospective it precedes, the gap between them contains three distinct signals — each pointing at something different about how the team plans and executes.

Unmet commitments are the most visible: the authentication refactor that appeared as a commitment in October and as an item that slipped in January. One cycle, it's a single data point — something intervened, the plan didn't hold. Three cycles, it's a structural constraint: something about the conditions in which this team works prevents them from delivering this category of work, and the planning process hasn't named it.

Anticipated risks that still materialized are a different signal. The team flagged the P1 incident risk in the futurespective and experienced exactly that in October. The anticipation was correct — but the retro treated the incidents as something that happened to the team rather than something the team had predicted. When a risk appears in both documents, the question isn't whether the team saw it coming. It's why the anticipation didn't change the outcome, and whether the underlying condition has been addressed or only predicted again.

Then there are retro findings with no futurespective counterpart at all: events significant enough to shape the quarter's work that nobody had anticipated. A single blind spot is noise. A category of blind spots that recurs — the same type of event appearing in retro after retro without ever appearing in a futurespective — is a systematic gap in how this team models its own risk environment.

A retro that runs without the futurespective produces findings but cannot distinguish between them.

What Accumulates Across Cycles

One cycle comparison produces a picture. Three produce a pattern.

When the same commitment goes unmet in Q1, Q2, and Q3, the question is no longer why the team didn't deliver in Q3. The question is what condition across all three quarters prevented delivery — and why the planning process hasn't surfaced it. The answer is almost never effort. It's usually something structural: a dependency on a team that can't be coordinated in time, a category of work that expands when scoped in detail, a capacity assumption that doesn't hold when competing priorities arrive. The pattern across three cycles makes the structural constraint visible in a way that a single retro cannot.

When the same category of risk is flagged every futurespective and materializes every quarter, the question shifts again. The team has been correctly anticipating the risk for three consecutive quarters. The question is why it keeps materializing — what it would take to change the conditions rather than continue to predict the outcome. That question is only askable after the pattern is visible. It cannot be asked from inside a single cycle.

The pattern also accumulates in the other direction: commitments that were made and kept, risks that were flagged and avoided. A programme lead who can say "we have kept every commitment in this category across four cycles" has evidence. Everyone else has intuition. The cycle comparison is what converts one into the other.

What the Programme Lead Gets

The programme lead who runs futurespectives and retros as separate quarterly events has two documents and a quarter of distance between them. The pattern, if it exists, is in the programme lead's memory — accumulated informally, invisible to anyone who wasn't present for every cycle.

The programme lead who runs the cycle comparison has a closed loop. The futurespective's commitments are surfaced in the retro automatically — the question "what did we say we'd do?" is always in the room. The retro's findings are surfaced at the next futurespective — the patterns from last quarter inform the predictions for this one. The planning cycle is no longer a sequence of isolated events. It is a feedback loop.

After three cycles, the programme lead can say with precision which categories of commitment their team reliably delivers and which they consistently fall short on. They can say which risks their team anticipates accurately and which they systematically miss. They can say whether the gap between prediction and outcome is narrowing — whether the cycle is actually improving — or whether the same gaps are reappearing quarter after quarter with different labels.

That's a different position than running a good retro. A good retro tells you what happened. The cycle comparison tells you what kind of team you are — what you see clearly, what you miss, where your planning process is calibrated and where it isn't. That intelligence doesn't exist in a single meeting. It only exists in the relationship between meetings.

What the VP of Engineering Sees

A VP of Engineering running multiple teams sees something the cycle comparison makes possible: cross-team pattern recognition that no single team's loop can produce.

Some gaps are team-specific — the authentication team consistently underestimates integration work; the platform team consistently overestimates migration speed. Those are team-level calibration problems, visible in the team's own cycle comparison, addressable with the team.

Other gaps are consistent across teams: every team that touches the third-party payment processor flags it as a risk in the futurespective and encounters that delay in the retro. That's not a team-level planning problem. It's an organizational dependency that no single team's retro will surface as a pattern, because no single team runs enough cycles with that dependency to see it repeat. The cross-team view makes it visible.

The VP who has this view can separate team gaps from organizational gaps. Without it, both look the same — a recurring retro finding, attributed to the team that experienced it, addressed at the team level. The dependency surfaces in a different team's retro the following quarter. Then again the quarter after that.