Let me paint you a picture of every terrible year-end retrospective I’ve ever attended:
The team sits in a conference room (or on a Zoom call, bless us) while someone with access to the whiteboard (always suspicious) asks “what went well, what didn’t go well, and what should we do differently?” Cue 45 minutes of thinly veiled blame disguised as “learnings,” passive-aggressive comments about missed deadlines, and at least one person who dominates the conversation while everyone else checks Slack.
The output? A Confluence page of action items that no one will ever look at again, zero accountability, and a team that feels slightly worse about themselves than they did before the meeting.
Sound familiar?
As a PM, retrospectives are supposed to be your secret weapon. They’re where you extract real insights from the chaos, build psychological safety, and actually improve how your team works. But most of the time, they’re just performative exercises that check a box on someone’s Agile playbook.
Let’s fix that.
Why Most Retrospectives Are Terrible (Especially When You’re a Woman Running Them)
First, let’s talk about why retrospectives fail, because understanding the problem is half the battle.
Traditional retrospective formats assume everyone in the room has equal power and equal safety to speak honestly. That’s adorable. In reality, junior engineers are terrified to call out senior engineers, everyone’s worried about looking bad in front of leadership, and God forbid you’re a woman running a retrospective where you need to address issues with male team members who already don’t think you should be leading the project.
I’ve had retrospectives where I asked “what could we improve?” and got silence. Not because everything was perfect, but because no one trusted that honest feedback wouldn’t be used against them later. I’ve had retrospectives where one senior engineer decided to turn it into his personal TED Talk about everything everyone else did wrong. I’ve had retrospectives where the only feedback I got was that my “communication style” could be “softer” (translation: stop holding people accountable for deadlines).
The other problem? Most retrospective formats focus on problems without creating any psychological safety around failure. When you ask “what went wrong,” people hear “whose fault was it?” And when people are in defensive mode, you get nothing useful.
The Pre-Work That Actually Matters
Here’s what I learned after running approximately one million terrible retrospectives: the quality of your retrospective is determined before anyone enters the room.
Two weeks before your year-end retrospective, send a survey. Not a “please rate your satisfaction on a scale of 1-10” survey. A real one with open-ended questions that give people permission to be honest:
What’s one thing that frustrated you this year that you felt you couldn’t bring up in the moment?
What’s one process we have that actively makes your job harder?
If you could change one decision I made as PM this year, what would it be and why?
What support do you wish you’d gotten that you didn’t?
The key is asking questions that normalize criticism and assume there are problems worth discussing. Anonymous surveys get you more honest data than any in-person conversation ever will.
I also send a separate survey specifically asking people to reflect on wins: What’s something you’re genuinely proud of from this year? What’s something a teammate did that made your job easier? What’s a decision that worked out better than expected?
Why separate surveys? Because when you mix them, people focus on the negative and breeze through the positive. You want real reflection on both.
Creating Actual Psychological Safety (Not the Fake Kind)
Let’s be honest: psychological safety has become a buzzword that gets thrown around by people who have no idea what it actually means.
Real psychological safety isn’t about being nice or avoiding conflict. It’s about creating an environment where people can take interpersonal risks (like admitting mistakes or challenging ideas) without fear of punishment or humiliation.
As a woman PM, you’re already fighting an uphill battle on this. Women are socialized to be accommodating and to smooth over conflict. When we do hold people accountable or address problems directly, we’re often labeled as aggressive or difficult. It’s exhausting.
But here’s the thing: a retrospective without honesty is useless, and honesty requires safety. So you have to be intentional about creating it.
I start every year-end retrospective with a few ground rules, and I’m explicit about them:
This is a blameless space. We’re talking about systems and processes, not attacking individuals. If someone makes it personal, I will redirect.
Disagreement is expected and welcome. Silence is not consensus. If you disagree with something, say so.
Everything said here stays here unless we explicitly decide as a team to share something more broadly.
I will take notes on themes, not on who said what. No one is going to be punished for honest feedback.
Then I share my own failures first. Not in a self-deprecating way, but in an honest, reflective way. “Here’s something I tried this year that didn’t work, here’s why I think it didn’t work, and here’s what I’m going to do differently.”
When you model vulnerability, you give other people permission to be vulnerable. And vulnerability is where the real insights live.
The Format That Actually Works
Forget the standard “what went well, what didn’t, what should we change” framework. It’s boring and it produces surface-level insights.
Here’s the format I use for year-end retrospectives:
Part 1: The Highlight Reel (30 minutes)
Go around the room (or the virtual room) and have each person share one thing they’re genuinely proud of from this year. It can be a technical win, a process improvement, a moment they helped a teammate, whatever. The only rule is that it has to be specific.
This does a few things: it starts the meeting on a positive note, it reminds people of wins they might have forgotten, and it surfaces accomplishments that might not have been visible to the whole team.
I take notes on all of these and later compile them into a year-end wins document that I share with leadership. Your team members should get credit for their work, and it’s your job as PM to make sure they do.
Part 2: The Hard Stuff (45 minutes)
This is where you dig into the survey data. I pull out the themes (not individual responses) and present them to the team. “Here’s what I heard: people felt like there wasn’t enough clarity on priorities. People felt like they were context-switching too much. People felt like their feedback on the roadmap wasn’t being incorporated.”
Then I ask: “Does this resonate? What am I missing? What’s the real issue underneath this symptom?”
The magic happens when you treat problems as puzzles to solve together, not as indictments of anyone’s competence. When someone brings up a legitimate issue, I literally say “thank you for bringing this up, this is exactly the kind of thing we need to address.”
I also use this section to address things I saw as problems that might not have come up in the survey. “I noticed we had three major production incidents this year that all stemmed from unclear requirements handoffs. I take responsibility for not catching that pattern sooner. What do we think the root cause is?”
Part 3: The Commitments (30 minutes)
This is where most retrospectives go to die. Everyone agrees to “communicate better” or “improve documentation” and then nothing changes.
Instead, I focus on three specific, measurable changes we’re going to make in 2026. Not 10 things. Three. And for each one, we identify:
What exactly are we going to do differently?
Who owns making sure this happens?
How will we know if it’s working?
When will we check back on progress?
For example: Instead of “improve documentation,” we might commit to “every technical design doc must include a ‘how to test this’ section before it goes to engineering, PM owns enforcing this in the review process, we’ll know it’s working if QA reports fewer questions about test coverage, we’ll review in Q1 retro.”
Specificity is everything. Vague commitments produce vague results.
Part 4: The Meta-Retrospective (15 minutes)
This is my secret weapon: I end every retrospective by retrospecting on the retrospective itself.
“Was this useful? What would make these more valuable? What should we stop doing? What’s one thing you wish we’d talked about that we didn’t?”
It sounds meta (because it is), but it’s how you continuously improve your own process. And it signals to the team that you’re serious about making these meetings actually worthwhile.
Handling the Difficult Moments
Let’s talk about what happens when things get uncomfortable, because they will.
When someone dominates the conversation: I interrupt politely but firmly. “Thanks for that perspective, I want to make sure we hear from everyone. Let’s get some other voices in here.” Then I directly call on someone who hasn’t spoken. “What’s your take on this?”
When someone makes it personal: I redirect immediately. “Let’s focus on the process, not the person. What about the system made this outcome more likely?”
When you’re getting blamed for something: This is the hardest one, especially as a woman. Your instinct might be to defend yourself or deflect. Don’t. Acknowledge the feedback, ask clarifying questions to understand the real issue, and commit to addressing it if it’s valid. “I hear that the priority changes felt chaotic. Help me understand what would have made that better from your perspective.”
When you get silence: Don’t fill it. Silence is uncomfortable, but sometimes people need time to think. I count to 10 in my head before prompting again. If you still get silence, try a different approach: “Let me ask a more specific question…” or “What if I share what I observed and you tell me if I’m off base?”
The Follow-Through That Separates Great PMs from Everyone Else
Here’s where most retrospectives fall apart: nothing happens afterward.
Within 48 hours of your retrospective, send a summary email that includes:
The wins you celebrated (people love seeing their accomplishments documented)
The themes that came up in the “hard stuff” section
The three specific commitments you made as a team, with owners and timelines
A clear statement about what you personally are committing to doing differently
Then, in every sprint planning or team meeting for the next quarter, reference those commitments. “Remember we said we were going to improve our requirements handoff process? Here’s where we are on that.”
Accountability is what turns retrospectives from feel-good exercises into actual improvement mechanisms.
The Self-Retrospective You Need to Do
Before you facilitate your team’s retrospective, do your own. As a woman in tech leadership, you need to be honest with yourself about what worked, what didn’t, and what you’re going to do differently.
Ask yourself:
Where did I let my fear of being seen as difficult prevent me from holding people accountable?
Where did I overcompensate by being too accommodating?
What feedback did I get this year that I initially dismissed as sexist but might have had a kernel of truth? (This one is painful but important.)
What support did I fail to ask for because I was trying to prove I could do it all myself?
Where did I advocate effectively for my team, and where did I let them down?
Write this down. Not for anyone else. For you. Because you can’t improve your team’s processes if you’re not also improving your own leadership.
The Reality Check
Here’s the truth: even if you run the perfect retrospective, you’re still going to face resistance. You’re still going to have team members who don’t engage. You’re still going to have leadership that doesn’t prioritize the process improvements you’ve identified.
But you know what? You’re a PM. Navigating resistance and driving change despite obstacles is literally your job description. The question isn’t whether it’s going to be hard. The question is whether you’re going to do it anyway.
Your year-end retrospective isn’t just about closing out 2025. It’s about setting the foundation for how your team operates in 2026. It’s about building trust, creating accountability, and demonstrating that you’re serious about continuous improvement.
So make it count. Run a retrospective that doesn’t suck. Run a retrospective that doesn’t blame. Run a retrospective that actually moves the needle.
Your team deserves it. And so do you.
