Your dashboard is green. Your sprint review went fine. Your status report says "on track."
Walk downstairs and ask the engineer nearest the door what's broken. You'll get a list before you finish the question. The flaky test everyone reruns until it passes. The deploy script only one person understands. The deadline nobody believes in. The service held together with a cron job and a prayer.
They know. You don't. Nobody told you, because nobody asked.
This one comes from Dan Greene of Radical Candor, who joined me on my podcast, Corey-osity Unleashed, earlier this year. His line: your team knows what's broken, you haven't asked. He's right. Here's why it happens, and what to do about it.
The famous iceberg is a myth. The problem is real.
You've seen the "Iceberg of Ignorance." It claims top management knows 4% of the problems in an organization, middle managers 9%, supervisors 74%, and front-line staff 100%. It gets credited to a 1989 study by a consultant named Sidney Yoshida at the car parts maker Calsonic.
Here's the awkward part. Nobody seems to have read the original. Corporate Rebels admit they "couldn't get our hands on the original." A search by Shepherd Partnership found no trace of the paper in Google Scholar, and they call it an urban management myth.
So stop quoting 4%. Those numbers are folklore.
The pattern behind them is not folklore. Researchers have studied it for decades, and they keep finding the same thing.
In 2003, Frances Milliken, Elizabeth Morrison and Patricia Hewlin at NYU Stern interviewed 40 employees about the issues they keep from their bosses. Their study in the Journal of Management Studies found most of them had stayed quiet about a concern at work. NYU Stern puts the figure at 85 percent. The top reason? Fear of being seen in a negative light and of damaging relationships with the people above them.
Read it again. Not laziness. Not apathy. Fear of what happens to them when they say it.
Why engineers go quiet
Engineers are not shy people. Put two of them in a room with a whiteboard and they will argue about tabs and spaces for an hour. So why do they go silent about the problems with real stakes?
Because they've done the math.
Somebody raised the concern about the database migration last year. The response was "we'll deal with it after launch." After launch never came. The next time, someone else raised the capacity issue and got labeled "negative" in a performance review. The lesson spread faster than any all-hands memo. Speaking up costs you. Staying quiet costs the company. Guess which one people pick.
The DORA research team uses Ron Westrum's model of organizational culture, and it names this problem outright. In a "pathological" culture, messengers are punished. In a "bureaucratic" culture, they're neglected. In a "generative" culture, they're trained. DORA's research found a high-trust, generative culture predicts software delivery performance and organizational performance.
Notice the middle option. Neglect. Most engineering leaders I know would never punish a messenger. They'd be horrified at the idea. They ignore the messenger instead. They nod, say "good point," and move on to the next agenda item. The engineer learns the same lesson either way.
Your open door is not an invitation
"My door is always open."
I've said it. You've said it. It does almost nothing.
An open door puts the whole burden on the person with the least power. They have to decide the problem matters enough. They have to decide you'll listen. They have to walk into your office and risk looking like a complainer. Then they have to hope you act on it, or at least tell them why you won't.
Most people run the calculation and stay at their desk.
The fix is to reverse the direction. Don't wait for problems to walk in. Go and fetch them.
How to ask so people answer
Asking sounds simple. Most leaders do it badly. "Any concerns?" at the end of a meeting, with thirty seconds left on the clock, is not a question. It's a ritual. Everyone knows the right answer is "no."
Here's what works for me.
Ask a question with no safe "no"
Swap "Any problems?" for "What's the thing most likely to bite us in the next month?" or "What's the most annoying part of your week?" These questions assume a problem exists. They make "nothing" the odd answer instead of the default.
Ask one to one, and ask more than once
Nobody tells the truth about a failing project in front of the person who championed it. Ask in private. Then ask again next week. The first answer is a test. People want to see what you do with a small problem before they hand you a big one.
Run blameless postmortems, and show up
Google's SRE team built its incident process around this. Their postmortem chapter says it plainly: "If a culture of finger pointing and shaming individuals or teams for doing the 'wrong' thing prevails, people will not bring issues to light for fear of punishment." Their fix: focus on contributing causes, not culprits. Their argument is simple: you fix the system, not the person.
The same chapter makes a point people skip. Google reinforces the culture "through senior management's active participation." If the VP never reads a postmortem, the team knows how much postmortems matter.
Measure it
DORA offers six survey statements for gauging your culture. One of them is "Messengers are not punished when they deliver news of failures or other bad news." Put it in your next team survey. Score it from one to seven. If the number surprises you, good. Now you know something you didn't.
What you do next matters more than the asking
Here's where most leaders fall down. They ask. They get an answer. Then nothing happens.
Fear is not the only reason people go quiet. A 2012 study of aircrew by Bienefeld and Grote found crew members spoke up about safety-critical information only 52% of the time, and "feelings of futility" made the list of reasons. People stop talking when they believe nothing will change. One ignored answer does more damage than never asking at all, because now you've proven the pessimists right.
You don't have to fix everything. You have to close the loop. "We're fixing the flaky test this sprint." "We're not rewriting the billing service this quarter, and here's why." Both answers tell people the message landed. Only silence tells them it didn't.
And thank the messenger. Out loud. In front of the team if they're comfortable with it. The engineer who told you about the migration risk saved you a weekend of incident calls. Treat them like it.
The cost of not asking
I noticed a thread trending on Reddit this week about Amazon reaching out to people it laid off and inviting them back. Amazon has cut more than 30,000 positions and now wants some of those people back. The same report cites Robert Half research: three in 10 US hiring managers who cut roles after bringing in AI later had to rehire for the same or similar jobs.
I'm not going to pretend I know what went on inside Amazon. But I know what those numbers look like from the inside of any company. Somebody on the ground knew those roles mattered. Somebody knew the plan had a hole in it. The question is whether anyone with the power to act asked them before the decision, or after.
After is the expensive version.
Go and ask
Your team already has the list. They've been carrying it around for months. Every one of those problems will surface eventually... in an outage, a missed deadline, or a resignation letter.
You get to choose when you hear about it.
So here's your homework for this week. Pick three people on your team. Sit down with each of them, one to one. Ask, "What's broken around here we're pretending isn't?" Then stop talking. Write down what they say. Next week, go back and tell them what you did about it.
What's on the list your team hasn't shown you yet?