The Retrospective that wasn’t

I was in a retrospective meeting the other day. The agenda was straightforward: how did we get here, and how can we prevent it from happening again? The Figma wireframe didn’t match the current build. Stakeholders were confused. Somewhere between planning and execution, alignment slipped. So we began dissecting the sequence – what, when, why and most importantly, who was responsible.

But as we dug deeper, the meeting turned into a battlefield. Everyone was trying to defend their corner. Instead of collectively climbing out of the sinkhole, we just kept sinking further in. The goal was shared learning, but the energy turned defensive. Time was spent, but not necessarily well.

And somewhere in there, I saw something bigger unraveling an insight about leadership and responsibility.

1. Leadership: the silent burden

The biggest shift when moving from an individual contributor to a leadership role is not power. It is weight. You are no longer just responsible for your own deliverables, but for someone else’s output, learning curve, and even perception. You become the person who’s expected to “know better” and “fix it.”

But here’s the paradox: Leaders don’t always ask for help.

It is difficult to say, “I’m overwhelmed,” when you are the one setting direction. We start to internalize responsibility as personal failure. Asking for help feels like weakness. So we overcompensate with longer hours, tighter control, and silent stress. And more often than not by the time we ask for help, it is already too late. The damage is already done. We then sit analysing and fixing when we could have used our energy to overachieve. We feel like a failure even when we did everything right.

And just like that, we unknowingly model a culture of self-containment. If the leader won’t ask for help, why would the team?

2. The Ripple effect: Why no one asks for help

When leaders don’t model vulnerability, the message is clear: strength is silence.

So developers push through without raising their hand. Designers assume their ideas are flawed rather than misunderstood. Project teams become risk-averse. Instead of surfacing issues early, everyone waits until it is too late.

In the case of our retrospective, many of the gaps only became visible during the knowledge transfer. A timeline mismatch, missing documents, undocumented edge cases. Things that could have been clarified if someone had said, “I don’t get this,” or “Can you explain this again?”

But that didn’t happen. Not because people were careless but because people were unsure, and didn’t feel safe to voice it.

3. Responsibility: The buck doesn’t just stop, it rolls

Mistakes happen. Developers will miss something. Designers will overlook constraints. But the accountability rolls upward.

Team Leads carry the outcomes of their team. Project Managers carry the risks of the leads. And leadership carries the system that either enabled or prevented the fallout.

When people feel that any error will come back to haunt them, they protect themselves. The postmortem becomes more about blame than learning. But in reality, these issues don’t always surface immediately. Sometimes, they show up weeks later through escalations, handovers, or delayed feedback.

And that is a gift.

Because what emerges late often carries the clearest signals of what was missing early. If we can resist the urge to react defensively, we will find our best learning material in these delayed aftershocks.

4. Knowing what you don’t know

One of the most overlooked challenges in leadership and team collaboration is this: how do you solve a problem you don’t even know exists?

This came to light during the knowledge transfer (KT) in our project. The new team had ticked all the boxes. They shadowed the process, read the documents, and nodded through the walkthroughs. But weeks later, foundational gaps began to surface. Screens were built on assumptions. Dependencies were misunderstood. Questions that weren’t asked back then became blockers now.

But here’s the kicker: it is not that the new team didn’t try. They simply didn’t know what they didn’t know.

This isn’t an isolated KT problem. It might as well be a leadership one.

The real solution lies in designing systems and conversations that anticipate blind spots rather than pretend they don’t exist.

It means:

• Creating space for questioning, even when questions feel naïve or redundant.
• Avoiding one-off checklists and embracing layered handovers with review loops, sample tasks, or small parallel builds that surface real-time gaps.
• Encouraging “beginner mind” in team dynamics, where asking basic questions is rewarded, not ridiculed.
• Rotating roles or perspectives, so team members get exposed to functions outside their comfort zone this helps builds context, which builds confidence.

As leaders, it is easy to assume silence means clarity. But often, silence is just fear of being wrong or looking stupid. So the true mark of leadership is not just answering questions. It is making sure the right ones are being asked.

Because the difference between surviving and thriving in a handover or any transition, isn’t how much you know. It is how safely and openly you can admit what you don’t know.

Conclusion: From blame to better

What we needed in that retrospective wasn’t finger-pointing. It was collective insight.

Leadership is not about having the answers. It is about asking the questions that no one else is willing to ask. About being open when others are closed. And owning the silence that follows a hard truth.

Mistakes will happen. Misalignments will occur. But how we respond to them defines our leadership DNA.

In the end, retrospectives are less about the past and more about shaping how we move forward. Together. Stronger. Clearer. And a little more human.