There’s a good reason why development teams often ask for retrospectives to be a leadership-free zone. It’s not about hiding information. It’s about protecting a space for trust, vulnerability, and improvement—the very things that make high-performing teams possible.
Let’s unpack why.
Development is personal
Unlike many business functions, software development is the act of turning ideas—sometimes vague ones—into something real and usable. Every line of code is the product of dozens of tiny decisions, informed by historical knowledge, creativity, and experience. The “right” answer isn’t always clear, and there’s rarely just one way to solve a problem.
That makes the work personal, and therefore, the space for feedback sensitive.
Psychological safety isn’t optional
Healthy development teams hold each other accountable. They build parts of a product independently, trusting those pieces will come together into something whole. That kind of coordination demands psychological safety—space to admit what’s not working, share failures, and improve together without fear of judgment.
Most developers have worked in environments where hierarchy silenced vulnerability. Retros are one way teams protect themselves from returning to that place.
Coding is an exercise in failing first
A lot of great code is written with the intent to fail—initially. Developers build tests that break so they can prove when something is truly fixed. Iteration is the name of the game. That doesn’t make the developer weak. It makes them good at their job.
So, why should they pretend to be perfect in a retro?
When someone outside the team, especially someone who signs the checks, is present, the tone shifts. Even unintentionally, feedback becomes filtered, defensive, or performative. The value of the retro—the honesty, the self-improvement—drops.
Retros are for the team, not the org chart
Retros aren’t performance reviews. They’re not about shaping up to leadership expectations. They’re about the team, together, examining how to improve their ways of working—based on their shared experience, not external pressures.
If you're not part of that daily rhythm, you won’t have the full context. And if you show up in that space, even as a passive observer, you change the dynamic.
This isn’t speculation—it’s behavioral science. The observer effect tells us that people change their behavior when they know they’re being watched. We’ve all felt it. An offhand comment from a CEO becomes an instant backlog item. A critique that might spark improvement gets swallowed. The room gets quieter.
So... why do you want to be in the retro?
That’s the real question. If you’re a leader and you feel the need to join a retro, pause and ask yourself:
- What do I hope to learn?
- Can I get this insight another way?
- Do I trust the team and their manager to surface what matters?
- Is my presence helping or hindering?
If your goal is to unblock the team or coach leadership, great. But there are more effective ways to do that—ways that don’t compromise the team’s psychological safety.
Consider meeting with the team outside the retro. Or better yet, work through the team’s leadership structure. That ensures accountability without trading trust for information.
"But other departments don’t ask for this much psychological safety..."
Maybe that’s true. And it’s also... irrelevant.
Most departments don’t work in the same iterative, failure-embracing way developers do. They’re not expected to regroup every two weeks, admit what’s not working, and improve on the fly while maintaining velocity. If anything, we should be asking why other departments don’t have the same space for candor.
Retros require vulnerability. Without it, they’re just another meeting.
Trust the process or improve it thoughtfully
The next time you ask for a retro summary or sit in on a retro, think about what happens after. If you use that information to question the team, or worse, punish failure, don’t be surprised when participation drops and honesty dries up.
Trust is hard-won. Let’s not trade it away too easily.
👋 Want help improving your product team’s process or psychological safety? Crema’s Product Team Assessment is designed to surface exactly where trust, velocity, and collaboration can be strengthened. Learn more →
