Why Your Teams Keep Making the Same Commitments Every Quarter
By Rich Garcia, Co-founder of Mayetik · May 31, 2026 · 7 min read
Here's a pattern most engineering leaders recognize.
The retrospective runs. The problems get named. Auth v2 slipped because of upstream delays. The incident response process is still unclear after the third major outage. Dependency tracking is everyone's concern and no one's system. The team leaves aligned: these are the things we're going to fix. Commitments are made in the futurespective that follows — the forward-looking complement to the retrospective, where teams name what they'll ship, what they're depending on, and what conditions they expect to hold. Q3 is going to be different.
Then Q3 runs. The retrospective surfaces the same themes — sometimes verbatim. The futurespective makes similar commitments. The cycle repeats.
This is not a discipline problem. Most engineering teams that run retrospectives take them seriously. The people in the room mean what they say. The problem is structural: the accountability loop never closes because there's no infrastructure designed to close it.
The Gap Between Two Documents
The retrospective and the futurespective are usually treated as separate events. One looks back. The other looks forward. They happen in sequence, they reference each other in discussion, and they each produce their own notes — a slide deck, a Confluence page, a Notion doc.
That separation is where accountability breaks down.
A retrospective produces findings: what happened, what caused it, where dependencies failed, which teams felt the downstream consequences. A futurespective produces commitments: what we'll ship, what we're depending on, what conditions we expect to hold. The natural accountability question — did we do what we said we'd do? — lives in the gap between those two documents.
And because that gap is bridged only by memory and whoever happened to attend both meetings, the question is almost never formally examined. The prior futurespective's commitments don't surface automatically in the next retrospective. Nobody systematically compares what was promised against what happened. The loop stays open. The cycle repeats.
The Upstream Problem Nobody Can See Alone
There's a second failure mode that only appears when you look across teams, not within them — and it becomes acute in any organization running more than a handful of teams across multiple dependency chains.
Every engineering organization has dependency chains. Platform teams own infrastructure that product teams depend on. API services sit between upstream providers and downstream consumers. Auth systems, data pipelines, and deployment tooling each have downstream dependents who feel every slip before the originating team has even filed the postmortem.
When something breaks upstream, each affected team captures that experience in their own retrospective. "Our auth migration slipped because auth v2 wasn't ready." "Real-time streaming came in below spec because the pipeline changes weren't done." "We spent Q2 firefighting downstream consequences of a platform incident we had no visibility into."
Each of these is an accurate account of what a team experienced. None of them names the systemic constraint. If four teams are citing the same upstream team as a blocker — in four separate retros, in four separate documents — that's not four independent problems. It's one organizational problem that needs to be addressed at the organizational level. But no one is reading all four documents. No one is running the synthesis. The systemic pattern stays invisible.
This is the information that senior sponsors and programme managers need most — and the work your Head of Delivery has probably been trying to do manually for years. It's also the hardest to surface, because it doesn't exist in any individual team's retrospective. It only exists across them.
Closing the Loop
Closing the accountability loop requires three things: structured capture in both the retrospective and the futurespective, synthesis that makes findings and commitments explicit at the team and organization level, and a comparison mechanism that runs the two outputs against each other. When both events use designed interview questions — consistent across teams and cycles — the outputs become structured enough to store, compare, and act on. The prior futurespective's commitments can be tested against the next retro's findings, directly and explicitly, before the retrospective debrief begins.
What the Cycle Looks Like When the Infrastructure Is There
In Mayetik, the retrospective runs as a structured interview campaign. Each participant — one per team, or three, depending on how much depth you want — completes an interview designed around the questions that actually matter for the cycle: what worked, what broke down, what upstream dependencies caused problems, what slipped and why. The interviews are synthesized per team and then across teams.
The cross-team synthesis is where the upstream blocker picture becomes visible. If multiple teams independently cited the same upstream dependency as a constraint, the synthesis surfaces that pattern. It names the team, the severity, and the downstream consequences. This is the organizational intelligence that previously required a dedicated programme manager to assemble manually — running down each team's retro notes, identifying overlapping themes, writing the summary. The structured capture produces it as a byproduct.
The futurespective follows the same structure. Forward-looking questions: what commitments is your team making? What upstream dependencies are you counting on? What conditions would cause this commitment to slip? Per-team synthesis, then cross-team. The commitments are explicit, attributable, and stored.
Three months later, when the next retrospective completes its synthesis, the team runs a cycle comparison: the new retro's findings against the prior futurespective's commitments. For each commitment, a verdict: achieved, partial, or not evident. For each issue in the new retro, a check: did this same issue appear last cycle? If so, it surfaces as a persistent issue — a structural problem that commitments haven't resolved, not a one-off. New issues that didn't appear last cycle are separated out: what's genuinely new this quarter, as distinct from what keeps returning.
The team walks into the retrospective debrief with the accountability record already in hand. The conversation doesn't start from reconstructing what was committed to from memory. It starts from: here is what was committed to, here is what happened, and — critically — here is what the organization keeps committing to address without actually addressing.
The Difference Between Individual Accountability and Systemic Visibility
This distinction matters more than it might initially seem.
A commitment tracker — a Jira epic, a spreadsheet, a shared doc — can tell you whether a named item was completed. That's individual accountability. It's useful. But it answers the wrong question. The question it can't answer is why the same class of problem keeps appearing regardless of what gets committed to.
When the retrospective cycle produces a full commitment follow-through record — nine commitments from last futurespective, four achieved, three partial, two not evident — the interesting question isn't which individuals didn't deliver. It's what the pattern reveals about the organization. If the same upstream dependency keeps appearing in the "partial" and "not evident" rows across multiple cycles, that's not a commitment problem. It's an organizational design problem that commitments alone can't solve.
An issue that reappears in three consecutive retrospective cycles — despite being named in the futurespective each time — is no longer a failure to execute. It's a diagnostic signal: the organization is structurally unable to resolve this constraint through normal delivery channels. The commitment was sincere every time. The structure didn't change. Surfacing that distinction shifts the conversation from "why didn't we deliver this?" to "what would need to change organizationally for this to be possible?" — and that's a different conversation, for a different room, with a different set of people.
The persistent issues section of the cycle comparison is where that becomes visible. Without it, those signals stay distributed across individual teams' retrospective documents, where they look like execution failures. With it, they accumulate into an organizational pattern that leadership can actually act on.
What Changes
Before structured capture:
- Retrospective findings live in documents that aren't designed to be compared against anything
- Futurespective commitments are made without a mechanism to test them next quarter
- Upstream blockers that affect multiple teams are visible to each affected team and invisible to anyone looking across the organization
- The same problems recur because there's no structured record of whether they were addressed, only memory
After:
- Each retrospective and futurespective produces a structured synthesis stored as a comparable output
- Cycle comparisons make futurespective commitments testable against the next retro's findings — before the debrief, not reconstructed during it
- Cross-team synthesis surfaces the upstream dependency pattern that no individual team's retro can reveal
- Persistent issues are distinguished from new issues, making it possible to separate organizational design problems from execution failures
The quarterly cycle was designed to produce learning and accountability. The infrastructure to support that design just wasn't there.
The Compounding Problem
When commitments aren't tracked and findings don't accumulate, the retrospective teaches the same lessons every quarter. The organization keeps rediscovering what it already learned.
That's not a failure of intention. Every team that runs a serious retrospective intends to use it to improve. The failure is architectural: the process produces insights, but nothing ensures those insights compound or that commitments get tested. The retrospective becomes a ceremony rather than a system.
When the infrastructure is there, the cycle starts to compound in the way it was always supposed to. The findings from this quarter inform the questions for the next. The commitments from this futurespective become the accountability measure for the next retro. The patterns that persist across multiple cycles become visible as organizational constraints — not individual failures to execute — and can be addressed at the right level.
The problem was never the ceremony. It was the absence of the system.
Mayetik helps engineering leaders run structured retrospective and futurespective cycles, synthesize findings across teams, and generate cycle comparisons that turn quarterly commitments into a running accountability record. Start your free trial.
Start capturing knowledge today
Mayetik helps teams design better questions, capture structured conversations, and synthesize intelligence that compounds over time.
Found this useful? Share it.
Next in Part 4
What a Vision Rollout Engagement Should Leave Behind
You ran the workshops. You facilitated the all-hands. The deck landed. Six months later, execution is stalling on exactly the tensions the vision was supposed to resolve — and you get a call. The conversations from that engagement contained the intelligence the client needed. None of it was in the deliverable.