The instinct when managing a team is to want fewer problems. Fewer bugs, fewer complaints, fewer disagreements. It feels like progress. However, there’s a version of “no problems” that should make you nervous: when nobody is raising any.
If your team has zero concerns about a plan, that doesn’t necessarily mean the plan is good. It might mean people don’t feel safe speaking up. Or they’ve learned that raising issues gets them labeled as negative. Or they’ve simply stopped caring. None of those are good.
Silence is the actual problem
I’ve seen this happen in teams. Someone makes a decision, asks for feedback, and gets nothing but agreement. No friction, no debate, everyone’s aligned. It feels good in the moment. But what usually happens is the problems surface later, when they’re more expensive to fix, and everyone says “I knew this was going to happen” after the fact.
The issue isn’t that people didn’t see the problems. It’s that they didn’t think it was worth raising them. Maybe the last person who pushed back got shut down. Maybe the culture rewards consensus over honesty. Whatever the reason, the result is the same: the team is flying blind while everyone pretends to see.
Zero bugs means nobody’s testing
This applies to software too. If a codebase has zero reported bugs, that’s not a clean bill of health. It might mean nobody’s testing it, nobody’s using it, or the people who found bugs didn’t bother reporting them. A healthy project has a steady stream of issues being opened and closed. That’s what active development looks like.
The same logic applies to processes. If nobody has complained about a workflow in years, it probably means people have worked around the problems instead of raising them. They’ve adapted to the dysfunction rather than fixing it.
What you actually want
You don’t want fewer problems. You want problems surfaced early, when they’re still small enough to fix. That means building a team where people are comfortable saying “I think this is going to break” before it breaks, not after.
This is harder than it sounds. The natural response to someone raising a problem is to treat it as negativity, especially when you’re already committed to a plan. However, the teams I’ve seen work best are the ones where pushback is expected, not punished. Where the first response to “I see a problem here” is “tell me more” instead of “we’ve already decided.”
The uncomfortable version
The real test is whether you want to hear the problems that are about you. Not problems with the codebase or the timeline, but with how you’re managing. Whether your meetings are useful. Whether your priorities make sense. Whether people actually feel heard. That’s where most managers draw the line, and it’s exactly where the most important feedback lives.
If nobody on your team is telling you what’s wrong, it doesn’t mean nothing is wrong. It means they’ve decided it’s not worth telling you.