Every two weeks, your team sits in a room and tells you what's broken. Then nothing happens. Two weeks later they tell you again. Around the fourth time, they stop.
You won't notice the day it happens. The retro still runs. The board still fills with sticky notes. People still write "communication" and "too many meetings." The notes get safer and blander, and you read the calm as progress.
It isn't progress. It's a team who learned the lesson you taught them.
James Ferguson, culture coach and author of The Confetti Culture Playbook, boils it down to one line: listening without action makes people stop sharing. If you don't act on what you hear, they stop telling you. I've watched this quietly wreck more engineering teams than any bad hire.
Silence has two causes. You control both.
Elizabeth Wolfe Morrison and Frances Milliken at NYU Stern studied why people keep quiet at work. In their write-up of the research, 85 percent of the working MBA students they interviewed had been in situations where they felt unable to raise a concern at work. The people who stayed quiet held two beliefs. Speaking up would cost them. And speaking up would not make a difference.
Most leadership advice obsesses over the first belief. Be approachable. Don't shoot the messenger. Make it safe. All good advice. I've written about how the boss sets the color of the report myself.
The second belief gets far less attention, and engineers hold it in bulk. Your engineers aren't scared of you. They're tired of repeating themselves. They raised the flaky test suite in March. And June. And September. The test suite still flakes. Nobody punished anyone for mentioning it. Nobody fixed it either.
Morrison and Milliken flagged a nasty side effect. Top management tends to read silence as consensus and success. From the outside, a quiet retro looks like a healthy retro. Often it's a team who gave up.
The research on retros is not kind
Agile teams treat the retrospective as their engine of improvement. The studies suggest the engine often idles.
Timo Lehtinen, Juha Itkonen and Casper Lassenius followed 37 team-level retrospectives in a large, distributed software organization for almost three years. Certain topics recurred over long stretches. Some repeats were natural. Others were waste, because the team had no control over the problem, or the problem was too complex to fix at team level. The team kept raising it anyway.
A Norwegian group led by Torgeir Dingsøyr studied the retrospective reports of a large-scale agile program. They counted 109 issues and 36 action items. Roughly one action for every three problems raised.
I'm not sure about this part: the study's abstract doesn't say how many of those 36 actions the teams completed. Given what I've seen in the field, I wouldn't bet on all of them.
Yanti Andriyani, Rashina Hoda and Robert Amor interviewed sixteen practitioners across four agile teams and sat in on their retros. One of the core activities they found was analyzing previous action points. Their warning: teams don't reach the deeper levels of reflection by holding the meeting alone.
Put those three together. Teams raise more problems than they act on. The problems outside their control keep coming back. And the meeting by itself does not produce learning. The missing piece is you.
The problems your team cannot fix are yours
Here's the pattern I see most. The retro surfaces a problem the team owns: "our code reviews take too long." They fix it. Good.
Then the retro surfaces a problem the team doesn't own. The staging environment belongs to another department. Someone two levels up sets the release calendar. Product swaps priorities mid-sprint. The team writes it down. The note goes in the "escalate" column. Escalate means you.
And you're busy. You mention it in a meeting. Somebody nods. Six weeks later the note is still on the board, curling at the corners.
This is the category Lehtinen's team called waste. The team cannot fix it, so every repeat costs them time and teaches them something. The lesson: the stuff hurting us most is the stuff nobody above us will touch.
Gallup puts a number on what this costs. Only three in ten US workers strongly agree their opinions seem to count at work. Gallup estimates moving to six in ten would cut turnover by 27 percent and safety incidents by 40 percent, and lift productivity by 12 percent. Your retro is where opinions either count or don't. Every two weeks. In front of everyone.
A dead action item is louder than a live one
When you act on feedback, the team notices once. When you ignore it, they notice every sprint, because the note is still there.
Wikipedia's employee silence page summarizes research by Vakola and Bouradas: once employees lose hope leaders will address the real problems, the result is continued silence. Nobody announces they've given up. They stop writing the hard notes. They save the honest version for the pub.
So the retro board turns into a museum of complaints nobody acted on. The new starter reads the museum on day one and learns the rules without anyone saying a word.
How I run the loop now
I got this wrong for years. I treated the retro as the team's meeting and stayed out of it. I thought staying out showed trust. It showed indifference. Here's what I do instead.
Open every retro with the last retro's actions
Before anyone writes a new note, review the old ones. Done, not done, dropped. Out loud. If someone dropped an action, say who and why. Often the answer is me.
Cap the actions at two
Three is too many. Ten is a wish list. Pick the two causing the most pain and give each a named owner. Everything else waits. Saying "not now" out loud beats a silent "never."
Hand me the ones the team cannot fix
Any action outside the team's control lands on my list, with a date. I report back at the next retro, even when the answer is no. "I asked for a second staging environment. Finance said no until Q2. Here's what I'm doing in the meantime." A no with a reason keeps the channel open. Silence closes it. I wrote more about closing the loop inside a week in Being in the Room Isn't Listening.
Count the repeats
Keep a tally of how many retros each issue has appeared in. Anything past three is a leadership failure, not a team failure. Mine. Take it to your one-on-one with your own boss, because it's your escalation now.
Kill one annoying problem fast
When a team is new or morale is low, find one cheap, irritating problem from the retro and fix it within days. The size of the fix doesn't matter. The speed does. It proves the loop works.
Go first on the uncomfortable stuff
Your team won't write the honest note until you show them it's welcome. I covered this in Psychological Safety Starts With Emotional Honesty. Name your own mistake from last sprint before you ask for theirs.
The honest read on your retro
If your retros feel calm, ask why. Calm teams exist. So do teams who quit telling you things. From the front of the room, they look identical.
Pull up your last six retro boards tonight. Count the action items. Count how many shipped. Then count how many times the same problem showed up again.
The gap between those numbers is your team's answer to a question they've stopped asking out loud: does saying anything here make a difference?
What does your board say?