Latest / New Manager Conversations with Fexingo: First 90 Days, Managing Former Peers, and Leadership Basics / How New Managers Can Run a Team Retrospective That Builds Trust
Transcript
- Lucas: You are about three weeks into your first management role. Your team just shipped a feature — late, but it shipped. You want to do a retrospective to figure out why the timeline slipped. But you're nervous because you used to be one of the engineers on this team, and the person who missed their deadline is your friend. Luna: That is a really specific tension — and honestly, it's one of the hardest things a new manager has to navigate. How do you run a meeting designed to surface problems without making people defensive? Lucas: Right, and a team retrospective is one of the most powerful tools a new manager has, but it's also the one most new managers avoid because they're afraid it'll turn into a blame session. So today I want to walk through a real example from a friend of mine — she was a first-time engineering manager at a mid-sized tech startup, about 80 people, and she ran her first retro about six weeks into the role. Luna: Let's hear it. What was the situation? Lucas: Her team had a recurring problem — deployments to production kept getting delayed. Not by a lot, but consistently by a day or two. And it was starting to erode trust with the product team. So she scheduled a one-hour retrospective, but before the meeting she sent out an anonymous Google Form with three questions: What worked well this sprint? What didn't go well? What's one thing we should change? Luna: Anonymous input first — that's smart. It lets people share concerns they wouldn't say out loud, especially if the issue involves a teammate. Lucas: Exactly. And she made it clear in the email that the meeting was not about blame — it was about improving the process. So when the team came in, she put the anonymous responses up on a screen, grouped into those three buckets. And the pattern was immediately clear: three people mentioned that the code review process was a bottleneck. Not one person, but three independent responses. Luna: So the data itself made the case. She didn't have to point fingers. Lucas: She didn't. And then she had the team brainstorm solutions together. They decided to try a new rule: no pull request should have more than two reviewers. They agreed to test it for two weeks. And she made sure to follow up in the next retro to see if it worked. Luna: That follow-up is key — if you don't circle back, people stop taking the retro seriously. They feel like it's just venting with no action. Lucas: Before we go deeper on the structure, I want to be honest about something. This show exists because listeners like you support it directly — no ads, no sponsors. A small group of listeners already chips in monthly at buy me a coffee dot com slash fexingo, and that's what pays for the research, the recording, the editing — all of it. Luna: Yeah, and it means we can keep making episodes exactly the way we want — focused on practical help, not selling anything. So if you've gotten something useful out of any of these episodes, that's the place. Lucas: Okay, back to that retro. The format she used is the classic three-part structure: What worked, what didn't work, and what to change. But the most important rule is this: the manager speaks last. You let everyone else share their perspective first, and then you add your own observations. Luna: Why last? Because if you speak first, you anchor the conversation. People might hold back what they really think to align with you. Lucas: Exactly. And as a new manager, you want the team to own the retro. If you're the one pointing out all the problems, it feels like a performance review. But if the team surfaces the issues themselves, they become invested in fixing them. Luna: I've also seen managers use a timer for each section — like ten minutes for what worked, ten for what didn't, then ten for changes. It keeps the meeting from dragging. Lucas: That's a great tip. The friend I mentioned used a timer, and she also had one explicit ground rule: no names. If someone said 'John's pull request was too big,' she would redirect to 'Yes, some pull requests were too large — how can we prevent that?' She depersonalized it. Luna: That takes practice. It's easy to let a name slip. But it's worth enforcing, because once people feel safe, the quality of feedback goes way up. Lucas: And here's something I think new managers underestimate: the 'what worked' section is just as important as the problem section. If you only focus on the negative, the team leaves feeling defeated. But if you celebrate a win — even a small one — people feel motivated. In her case, one thing that worked was that automated tests caught a bug before it hit staging. So she made sure to thank the person who wrote those tests. Luna: That also builds trust. People see that you notice the good stuff, not just the gaps. Lucas: Now after the retro, she sent a one-page summary within 24 hours. It listed the top three issues, the agreed-upon changes, and who was responsible for each action item. And then — this is the part most people forget — she added those action items to the team's shared task board as actual tickets, with due dates. Luna: So it wasn't just a meeting artifact. It became part of the workflow. Lucas: Exactly. And two weeks later, in the next retro, she started by reviewing the action items from the previous one. The 'limit reviewers to two' rule had been implemented, and the team agreed it had reduced the deployment delay by about a day. Not a huge improvement, but measurable. And the team felt good because they had made the change themselves. Luna: I think that's the real win for a new manager — you're not solving the problem for them. You're creating a structure where they solve it themselves. Lucas: And that builds a culture of continuous improvement. Once a team sees that their input leads to real change, they start bringing up issues proactively, not just in the retro. They'll flag a process problem in Slack mid-sprint, because they know it will be taken seriously. Luna: What about resistance? What if someone on the team is skeptical of retros — thinks they're a waste of time? Lucas: That's common, especially if the team has had poorly run retros in the past. The key is to make the first one so productive that the skeptic changes their mind. That means having a clear agenda, keeping it to an hour, and actually implementing the changes. Nothing wins over a cynic faster than seeing their suggestion become real. Luna: And if they still resist? Lucas: Talk to them one-on-one. Ask what they'd like to see different. Maybe they prefer written feedback over a meeting. Or maybe they want a shorter session. You can experiment. The retro format is flexible — some teams do a 30-minute stand-up retro, some do a monthly two-hour session. Luna: You mentioned the three-part format. Are there other formats that work for new managers? Lucas: Sure. There's 'Start, Stop, Continue' — what should we start doing, stop doing, and continue doing. That's easy to remember. Or 'Mad, Sad, Glad' — what made you mad, sad, glad? That one is more emotional, so it works best if the team already has high psychological safety. Luna: Which one would you recommend for a brand-new manager? Lucas: Stick with 'What worked, what didn't, what to change.' It's neutral, it's action-oriented, and it's widely understood. Once you've done a few, you can try other formats to keep it fresh. But don't get fancy too fast. Luna: And how often should a new manager run a retro? Every sprint? Every two weeks? Lucas: If the team works in two-week sprints, then every two weeks. If they work more continuously, once a month is fine. The important thing is consistency — the retro should be a fixed, recurring event on the calendar. Not something you skip when things get busy, because that's when you need it most. Luna: And if nothing went wrong? If it was a perfect sprint? Lucas: You still run it. You spend more time on 'what worked' and 'what to change' — maybe you look for small improvements. A perfect sprint is rare, but even then, you can ask: how do we replicate this? What conditions made it perfect? That's valuable. Luna: So the retro is never wasted. It's always about learning, even when everything goes well. Lucas: Exactly. And for a new manager, that learning orientation is your strongest signal to the team that you're not there to judge them. You're there to help them do their best work. Luna: I think that's a good note to end on. One final tip — if you're a new manager listening, and you're nervous about your first retro, start small. Pick one or two team members who you trust and ask them to be your allies in the meeting. They can help steer the conversation if it gets tense. Lucas: Great advice. And remember, the goal is not to have a perfect retro. The goal is to start a habit of reflection and improvement. The first one might be awkward. But the tenth one will transform how your team works. Luna: Alright, that's it for this episode. We'll be back with another one soon.