30 mins only(2)

Lesson 16: Run a Short Operational Reflection

Lesson 16: The 30-Minute Reflection That Actually Makes a Difference (And Why Longer Ones Usually Don’t) 

Let me be honest: a lot of reflection on the typical business operations turn into group therapy sessions. People talk, people vent, everyone feels heard, and nothing really changes. You leave thinking you accomplished something, but a week later, the same issues pop up. I’ve seen it happen again and again – even in teams with the best of intentions. 

Here’s what I learned (the hard way): the real problem isn’t that teams don’t care, or that they’re not trying hard enough. The problem is the format. You go in without a sharp structure, and what do you get? Someone says, “Here’s what went wrong.” Someone else chimes in with a different version. Maybe a third person adds some backstory, and suddenly you’re forty-five minutes in with two fuzzy takeaways and a weird sense of unresolved tension. Nobody’s learned anything actionable. 

I used to run these kinds of retros for years. Slowly, the evidence piled up that things weren’t working. Same types of problems. Same messy failures – just dressed up in new incidents. People felt better, sure, but nothing got better. 

You know what finally changed things? Ruthless constraints. Thirty minutes. Three simple rules. Three clear actions. No exceptions. 

Here’s the rule I live by now: 

If you move too fast, you don’t reflect – you just repeat your mistakes. But reflection without action? That’s just the same conversation on a loop.

Most teams, if we’re being honest, don’t get that balance right. Some rush through incidents, slap a fix on, and move on. That’s how you rack up technical debt, process debt, and – worst of all – a culture where people quietly assume certain problems will never go away. 

Others swing the other way, spending way too long reflecting without any real focus. You get therapy-style retros. Lots of talking, not much changing. 

A 30-minute reflections cuts through that. It’s just long enough to dig into what happened, but not so long that the conversation spirals into blame or personal narratives. It forces you to leave the room with three clear, assigned, and measurable actions. That’s how you close the loop after a wild release or a failed experiment. Thirty focused minutes, and you’ve turned chaos into lessons you’ll actually use next time. 

Let me give you a real example: 

Our team once released a new feature, and the support tickets exploded right after. The knee-jerk response? “Who screwed up?” But chasing blame never gets you real answers – it just makes people defensive. So, before anyone could start finger-pointing, we called a tight 30-minute retro. Three ground rules: stick to the facts, focus on what actually caused the problem, and no stories about intentions or excuses. Just what happened, and why. 

Here’s an exact agenda: 

  • First five minutes: Shared the numbers – support ticket volume, exact types, and what changed after release.
  • Next ten: Each team member got two minutes to say what they personally saw. Not what they thought caused it, or what should’ve happened, just the facts they had in front of them. 
  • Then eight minutes: We picked the biggest issue and ran a quick “5 Whys” to chase down the true root cause (not every possible cause – just the one that had a real impact).
  • Last seven minutes: We set three actions, each assigned to one person, with a deadline and a success check.
  1. Write the missing rollout documentation within 48 hours.
  2. Add the overlooked config to the test suite before the next release.
  3. Add a documentation check to our pre-release checklist, effective now.

We posted these to the team channel before anyone left. 

The results? The following release had zero related support tickets. Not “fewer,” zero. The issues never resurfaced, because we hit the real causes directly. Thirty minutes, three clear fixes, and we never had the same problem again. 

So, how do you run this kind of reflection? 

Stick to a fixed agenda: 

  • 0–5 min: Share outcomes. State the numbers. How many incidents? What did customers feel? Anchor the conversation in facts, not opinions.
  • 5–15 min: Facts-only sharing. Each person gets two minutes for what they witnessed. No stories, no theories. The facilitator has to jump in if anyone starts drifting into interpretation.
  • 15–23 min: Find the root cause of the biggest issue. One “5 Whys” deep dive. Don’t try to cover everything – go deep on what really hurt.
  • 23–30 min: Lock down exactly three actions, each with a name, a due date, and a simple way to measure success. Ruthlessly prioritize to keep it to three. Post them before anyone signs off – the few minutes after the meeting are the danger zone where actions get forgotten.

Then in the next weekly meeting, check in on all three. No action fades into the background. 

Here’s the honest truth: I used to think longer retros were better. More time, more voices, more psychological safety – you’d think that leads to more improvement, right? For me, it just led to more emotional release, less action. People left feeling heard, but nothing meaningful changed. 

The shorter, tighter retro actually gets results. When you have just ten minutes to find what broke, you focus on what matters. In seven minutes for actions, you skip the fluff. The urgent but unimportant stuff falls away. 

So, take a look at your last big incident or botched release. Was there a retro? Did you leave with specific next steps, each with a clear owner and a deadline? If not, it’s time to try a thirty-minute retro, no matter how long it’s been. Root causes don’t go stale. 

I’ll be back next in the lesson with how to Standardize Repeatable Play. See you then.