Prime Directive

The Retro That Turned Into a Trial

I’ve run retrospectives where the real work started before I even opened the facilitation. You’d walk into the room and feel it — the particular stillness of people who’d already decided what the meeting was going to be. Someone’s getting blamed today. The question was just who.

This one was a project post-mortem. A mid-size software firm, a six-month delivery that slipped by three months and shipped with more known defects than anyone was comfortable with. The VP of Engineering opened the session. He didn’t say “let’s find out what we could all do better.” He said — and I’m paraphrasing only slightly — “I want to understand how we got here and who made the decisions that led to this.”

The room went to ice.

Two developers pushed their chairs back from the table so subtly they probably didn’t know they’d done it. The QA lead started taking extremely detailed notes, which in my experience means “I am documenting everything that happens in case I need it later.” The project manager, whose name was on every status report, was visibly calculating. Not thinking. Calculating.

What followed was ninety minutes of competitive self-defense dressed as retrospective. Every person in the room managed their exposure carefully. Information came out in parcels, hedged and qualified. Nobody said anything that implicated themselves without immediately pointing at a structural factor or a constraint from elsewhere. The data that would have been most useful — the moments where people knew something was wrong and didn’t escalate, the decisions that felt locally rational but were globally damaging — stayed locked up tight.

At the end of it, the VP had a list of individual failures. The team had a shared understanding of nothing. And nobody was the slightest bit more equipped to handle the next complex delivery any differently.

That’s what happens when you hold a retrospective without the Prime Directive. Not always in such dramatic form — sometimes the stakes are lower, the defensiveness more subtle. But the mechanism is the same. When people believe they’ll be judged, they optimize for judgment. And optimization for judgment is the enemy of the honest, systemic examination that retrospectives are supposed to produce.

Norm Kerth named this problem in 2001 in Project Retrospectives: A Handbook for Team Reviews. His solution was a single sentence, written to be read aloud at the start of every retrospective. Twenty years later, it remains one of the most important sentences in the practitioner’s toolkit — and one of the most misunderstood.

The Sentence That Changes the Room (If You Actually Mean It)

The full text of the Prime Directive:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

If you’ve been in the agile space for any length of time, you’ve probably heard this read at the start of a retrospective. Maybe you’ve read it yourself. And if you’re honest with yourself, you’ve probably also been in retros where it was read — earnestly, with good intentions — and then violated within the first fifteen minutes when someone said “so why didn’t the team flag this earlier?” with an unmistakable edge in their voice.

That’s the gap between reciting the Prime Directive and actually using it. Let’s close the gap.

The “Regardless of What We Discover” Opening

The first four words do something specific and important. They make the Prime Directive unconditional. Not “in cases where the situation was genuinely complex” or “assuming people were trying their best.” Regardless. Whatever emerges in this room, we enter it with a particular stance.

This matters because the temptation to apply the Prime Directive selectively — to invoke it for ambiguous situations but abandon it when you find what looks like a clear failure of judgment — is almost irresistible. “Okay, but in this case, everyone can see what went wrong.” Maybe. But that certainty is almost always premature, and the “regardless” is doing the work of holding that certainty at bay long enough to find out what was actually true.

”The Best Job They Could” — What That Doesn’t Mean

This is where the skeptics show up. I hear it in coaching classes regularly: “That can’t be right. We know some people didn’t do their best work. Some people made decisions that were obviously wrong. This is just a way of letting bad behavior off the hook.”

I understand why it lands that way. The phrase sounds like it’s saying “everyone is equally skilled and equally effort-ful and outcomes are purely random.” That’s not what it means.

What it actually means is a conditional claim about information and context. Given what this person knew, given the skills they had at that moment, given what resources were available and what the situation looked like from where they were standing — they did the best they could. Not the best possible. Their best, given their actual circumstances.

That conditional clause is the whole thing. It’s not a claim that everyone is equally capable. It’s a claim that people’s behavior makes sense when you understand their context — and that your job in the retrospective is to understand that context, not to judge behavior in the abstract.

The sophisticated read of the Prime Directive is that it’s an epistemological stance, not a moral one. You’re not saying “no one bears any responsibility for anything.” You’re saying “we will not pretend to understand what happened until we actually understand it.” Blame is a premature conclusion. The Prime Directive is what keeps you in the investigation long enough to find the real causes.

The Systems Thinking Lens

This is the part Kerth understood deeply, and it’s the part that makes the Prime Directive more than a feel-good opener.

When teams ask “who screwed up?”, they’re assuming a model of failure where the primary cause is individual behavior. One person made a bad decision, or didn’t work hard enough, or didn’t have the right skills. Fix or replace the individual, and the problem goes away.

That model is wrong most of the time. Not because people are blameless, but because individual behavior happens inside systems — structures, processes, incentives, information flows, cultural norms — that shape what’s possible and what’s likely. A developer who deployed without adequate testing didn’t just decide to take a shortcut. That developer was operating in an environment where the testing suite was slow, the release schedule was tight, the PM was pushing hard, and cutting corners had been quietly normalized for months because the business pressure was always there and nothing bad had happened yet.

The Prime Directive shifts the lens from “who” to “what conditions.” It asks: what made this outcome likely, given the system these people were operating in? That’s a radically different question — and it points at radically different solutions. Individual blame leads to individual fixes. Systemic understanding leads to systemic improvement.

Kerth wasn’t the only one making this argument in 2001. It’s the core insight behind Sidney Dekker’s work in safety science, behind the blameless postmortem movement in tech operations, behind every serious approach to organizational learning. The Prime Directive is the practitioner-friendly version of a deeply rigorous idea: most failures are produced by systems, not individuals, and treating them as individual failures makes the system worse.

Psychological Safety as the Mechanism

Here’s the practical reason the Prime Directive works: it changes what information surfaces.

When people believe they’re in a safe environment — meaning, when they genuinely believe that honest disclosure won’t result in blame or punishment — they share information they wouldn’t otherwise share. The developer says “I knew this was a risk and I pushed through anyway because we were behind.” The project manager says “I didn’t escalate because I was afraid of how it would look.” The team lead says “I didn’t understand the integration requirements and I didn’t want to admit it.”

Every one of those disclosures is gold for a retrospective. Every one of them is the kind of information that actually illuminates what happened. And every one of them disappears when people are in self-protection mode.

Amy Edmondson’s research on psychological safety, developed at Harvard Business School through the 1990s and 2000s, confirms this empirically: teams in high-psychological-safety environments report more errors, admit more mistakes, and ask more questions than teams in low-psychological-safety environments. Higher safety, more disclosure. More disclosure, better learning.

The Prime Directive creates psychological safety by design. It’s a social contract established before the retrospective starts. Everyone in the room agrees, explicitly and out loud, that honest disclosure is safe here. That agreement changes the game.

The Misuse Pattern (And Why It’s So Common)

There is a failure mode you will encounter, probably often, and it looks like this: the Prime Directive is read at the start of the retro, everyone nods, and then the retro proceeds as though it hadn’t been read at all.

The facilitator says “what went wrong this sprint?” Someone mentions a deployment issue. Someone immediately says “yeah, that’s because [name] pushed to production without running the full suite.” The tone is pointed. Everyone notices. The engineer who pushed the code goes quiet for the rest of the session.

The Prime Directive just became wallpaper.

This happens because reading a sentence is not the same as establishing a belief. If the team’s actual underlying model is “we find the person who caused the problem and make sure they know it was their fault,” a ritual recitation doesn’t displace that model. It just adds a polite preamble to the same old retro.

Effective facilitation of the Prime Directive means returning to it actively — not just reading it at the start but enforcing it as an active norm throughout. When someone’s language turns toward blame (“why did you…”), bring it back. “Let me pause there — let’s understand what the situation looked like at the time. What information did the team have when that decision got made?”

The Prime Directive is a coaching move, not a script. You read it to set the intention. You facilitate to maintain it. The difference between the two is the difference between a retrospective that produces insight and one that produces resentment.

What This Changes About Your Coaching

Opening Retrospectives

The standard approach is to read the Prime Directive and move on. I’ve been moving away from that for years.

Instead, take three to five minutes to actually discuss it. Ask the team: “What does this mean to you, in the context of this sprint?” Let them say it in their own words. Invite a team member to explain why they think it matters. Sometimes I’ll ask: “Has anyone ever been in a retro where this wasn’t true? What happened?” The stories that come out of that question do more to establish psychological safety than any number of readings of the text.

When I’m working with a team that has a history of blame-heavy retros — and you can usually tell from the body language before a word has been spoken — I’ll also make the contract explicit: “Before we start, I want to name something. In this room, for the next ninety minutes, our job is to understand what happened, not to assign fault. If something comes up that sounds like blame, I’m going to interrupt it. That’s not me protecting anyone — it’s me protecting the quality of the conversation.” Most teams visibly relax when you name it.

The other thing I’ll do: reference it mid-retro when needed. Not punitively — not “excuse me, you’re violating the Prime Directive.” But a gentle redirect: “Let’s step back a moment. What were the constraints at the time? What did the team know before that decision was made?” The Prime Directive is a direction to point toward, not a rule to enforce.

Post-Incident Reviews and Blameless Postmortems

The Prime Directive is foundational to what the DevOps and SRE communities call the blameless postmortem — the approach to incident analysis that’s become standard at high-performing engineering organizations from Google to Netflix to Etsy.

The thesis is simple: when you blame individuals for incidents, you get two problems. First, you don’t fix the system conditions that made the incident possible, so it happens again. Second, you create an environment where people hide near-misses, avoid taking risks, and optimize for not being blamed rather than for building resilient systems. You end up with people who are very careful and systems that are very fragile.

The Prime Directive cuts through this by establishing up front that the goal is systemic understanding. In a postmortem context, this means asking questions like: What in our deployment process made this outcome possible? What in our alerting made it harder to detect? What in our communication patterns delayed the response? What assumptions about system behavior were incorrect?

The questions are about conditions, not characters. Nobody in the room is “the person who caused the outage.” Everyone in the room is a source of information about how the system behaved and why.

I’ve coached teams through postmortems where this reframe was transformative. An engineer who’d been terrified to admit they’d made a configuration error opened up completely when they understood the room was interested in understanding the conditions, not documenting the culprit. The story they told — about the config interface, the ambiguous documentation, the time pressure, the assumption that the change wouldn’t affect the adjacent service — was a roadmap to three separate improvements the team made in the following sprint. None of that gets said in a blame-oriented postmortem.

Coaching Teams With Low Trust

Here’s an honest note from the coaching trenches: the Prime Directive is harder to use, and more necessary, with low-trust teams.

Teams that have experienced blame in the past — or whose organizational culture routinely uses people as explanations for failures — have usually developed very effective defensive behavior. They’re not being difficult. They’re being rational, given their experience. “If I say what I actually think happened, it will be used against me” is a reasonable belief when that’s what has happened before.

With these teams, the Prime Directive can’t be dropped in as a pre-meeting ritual and expected to work. It needs to be backed up with facilitation behavior that consistently demonstrates that the social contract is real. That means redirecting blame language every single time, not just the first time. It means noticing who has gone quiet and creating space for them to speak without risk. It means being willing to shut down conversations that are trending toward trial, even when the people driving them are senior.

It also means being honest about the limits of the retrospective. If the organizational culture outside the room will use retro output to punish people, the Prime Directive can’t fully protect them, and pretending otherwise is its own form of bad faith. Sometimes the coaching work is to name that tension explicitly and help the team navigate it with their eyes open.

The Prime Directive describes the right conditions for a retrospective. Sometimes the coach’s job is to create those conditions in the room even when the organization isn’t providing them outside it. That’s harder and more important than reading a sentence.

What It Looks Like in the Room

Priya had been an agile coach at a healthcare technology company for two years, mostly working with delivery teams building patient-facing applications. The company was in the middle of a difficult quarter — two major releases had slipped, a key client had escalated their dissatisfaction, and the executive team was visibly anxious.

She was called in to facilitate a retrospective for a cross-functional team that had just completed — sort of completed — a release that had taken eleven weeks longer than planned. Priya knew going in that the team had fractured somewhere around week seven. She’d heard the word “blame” used by three different people in three separate conversations before the retro even started.

She arrived early and set up the room. Sticky notes, markers, three columns on the whiteboard. Standard enough setup. But instead of putting “What went well / What didn’t / What do we change” on the columns, she left them blank for now.

Eight people filed in. A product manager named David who was visibly tense. Three developers — Kenji, Aminata, and a junior dev named Tyler who looked like he’d rather be anywhere else. A UX designer, Sofía, who’d joined the team mid-project. Two QA analysts, Priscilla and Will, who sat together at the end of the table. And the engineering lead, Rajiv, who’d been one of the people to use the word “blame” with Priya in the hallway.

Priya didn’t start with the Prime Directive immediately. She started with this: “Before we get into what happened, I want to ask everyone to think back to week one of this project. Not the end. Not the hard parts. Week one. What did you think this release was going to look like?”

She gave them three minutes to write on stickies. Then she asked two people to share. Not to analyze — just to share what they’d written.

David said: “We thought it was a six-week project with well-defined requirements.”

Kenji said: “I thought the integration points were figured out. They weren’t.”

Priya nodded. “Good. That’s where we started.” She pulled out a copy of the Prime Directive — she had it printed on a single card — and read it aloud.

Then she said: “I want to explain why I read that now instead of at the end, when we’re talking about what happened. This sentence is a reminder that in week one, everyone in this room made decisions based on what they knew in week one. The decisions might look different from where we’re sitting today. But they were made by people who were doing the best they could with what they had. Our job this afternoon is to understand what they had. Not to judge what they did with it.”

She paused. “That’s harder than it sounds, especially when things went sideways and it was frustrating and you’re still frustrated. I’m going to ask us to try anyway.”

Tyler, the junior developer, visibly exhaled. It was small enough that most of the room didn’t notice. Priya did.

The retro unfolded over ninety minutes. Priya had structured it as a timeline — they built the story of the release collaboratively, week by week, with everyone contributing stickies to a shared narrative. The timeline structure did something important: it made the systemic factors visible as they went rather than at the end.

By week four on the timeline, the picture was already telling the real story. The integration requirements had been underdocumented. Three separate teams owned pieces of the interface and none of them had a single owner coordinating the decisions. When Sofía had flagged a UX concern about the patient intake form in week three, the concern had been recorded in a backlog but hadn’t reached the people building the form until week seven. The gap between “concern raised” and “concern addressed” was four weeks — not because anyone ignored it, but because the information flow between the UX work and the development work had no clear path.

Rajiv, the engineering lead, had a moment somewhere around week six on the timeline. He’d been the one who signed off on the internal milestone that everyone now knew had been optimistic. Priya watched him watching the timeline and she could see him preparing to explain himself.

She stepped in before he could. “Before we go further — what information did you have at the end of week six, Rajiv?”

“The integration work was showing green in our status dashboard,” he said. “But the dashboard was only getting updated by the team that owned the service. They were reporting on their piece. Nobody was reporting on whether the pieces were talking to each other correctly.”

“Who owned that?” Priya asked, genuinely curious.

A beat. Then David, the product manager, quietly said, “Nobody did.”

That was the center of the retrospective. Not Rajiv’s sign-off. Not the underdocumented requirements. Not Sofía’s concern sitting unactioned for four weeks. The system had no one responsible for end-to-end integration status, and the dashboard was giving a confident false signal.

Every one of those individual decisions — Rajiv’s sign-off, the unactioned UX concern, the incomplete reporting — made complete sense given what each person knew and owned. The system had distributed responsibility in a way that guaranteed this outcome, or one like it, eventually.

They generated action items, and for once the items were structural: an integration owner role for cross-system projects, a dashboard change to surface cross-team dependencies, a process for escalating design concerns to the development team within five business days. Nobody was put on a plan. Nobody was named in the summary as “responsible for the delay.”

At the end, Priscilla, one of the QA analysts who’d said almost nothing in the first hour, spoke up. “I want to say something. I’ve been in three other postmortems about project delays at this company. I’ve never been in one where I didn’t leave feeling like someone’s reputation just took a hit. I said more honest things in this room in the last ninety minutes than I have in the previous three combined.”

Priya thanked her. Then she asked: “What made it different?”

Priscilla thought for a moment. “You kept redirecting us back to ‘what did we know then.’ Every time it started to feel like a blame session, you pulled us back to the timeline.”

The Prime Directive wasn’t a sentence Priya had read at the start of the meeting. It was the framework she’d been facilitating from for ninety minutes. The sentence was the setup. The facilitation was the proof.

Go Deeper

• Kerth, N.L. (2001). Project Retrospectives: A Handbook for Team Reviews. Dorset House Publishing. The source text. Kerth coined the Prime Directive here and provides the full context for how it functions within a structured project retrospective. Essential reading — and the retrospective design he describes still holds up.

• Dekker, S. (2006). The Field Guide to Understanding Human Error. Ashgate Publishing. Sidney Dekker’s foundational work on safety science and the “new view” of human error — essentially the academic version of the same argument the Prime Directive makes. Dekker’s “bad apple theory” critique is the intellectual backing behind blameless postmortems. If the Prime Directive feels philosophically incomplete to you, Dekker will give you the rigor.

• Edmondson, A.C. (2018). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley. The empirical foundation for why psychological safety — the environment the Prime Directive is designed to create — produces better outcomes. Edmondson’s research makes the case from first principles. Pairs naturally with any retrospective facilitation work.

• Allspaw, J. (2012). “Blameless PostMortems and a Just Culture.” Etsy Code as Craft blog. The blog post that launched the blameless postmortem movement in DevOps. Allspaw applies the Prime Directive’s logic to incident analysis specifically. Short, sharp, and worth assigning to any engineering team doing postmortems.

• Derby, E. & Larsen, D. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf. The practical complement to Kerth’s foundational work. Derby and Larsen build the Prime Directive into their five-stage retrospective structure and give facilitators a full toolkit for making it real rather than ritual.