Why You Don’t Hear Bad News Fast Enough

The most expensive question in engineering is: “Why didn’t we know sooner?”

A demo fails. A dependency slips. An integration blocks a release. Everyone saw pieces of it coming, but nobody connected the dots early enough to change the outcome.

People usually blame communication breakdowns, lack of urgency, or misalignment. But the real issue runs deeper.

Bad news doesn’t move slowly because people are careless. It moves slowly because the organization makes it slow.

If you want to lead well at scale, this is the truth to internalize: Problems don’t hide themselves—systems hide them.

Great engineering leaders don’t wait for honesty to show up on schedule. They design teams, operating cadence, and decision flows that identify drift early, when it’s still cheap to fix.

Drift Always Starts Quietly

Most risks don’t enter a room with sirens. They drift.

• A test that “almost always” passes.

• A team that quietly stops demoing.

• A dependency that slips by a day or two.

• A roadmap re-baselined so often that the original timeline is forgotten.

Individually, each one is small. Collectively, they point to something bigger.

Diane Vaughan called this normalization of deviance in her study of NASA’s Challenger disaster—the slow acceptance of minor issues until they no longer looked like issues at all.

Engineering teams slip into this pattern faster than they realize—not because people are reckless, but because drift is easy to live with.

Until it’s not.

Leaders get blindsided when they assume silence equals health. It rarely is. Silence is drift.

Slow Truth = Slow Decisions

Decades of Standish Group CHAOS Report data show a consistent pattern: teams that resolve decisions quickly succeed far more often than teams that let decisions linger.

Decision latency destroys execution. And nothing slows decisions more than late truth.

If risk shows up at the last minute, the decision does too. If the decision is rushed, so is the solution. If the solution is rushed, the team burns trust. And when trust erodes, people hesitate to escalate the next problem.

You don’t need more process. You need earlier signals. The teams that avoid drift don’t wait for risk to announce itself.

High-Performing Teams Hear What Others Miss

Some of the most useful thinking on early warnings comes from high-reliability organizations—aircraft carriers, surgical teams, nuclear operations. Karl Weick and Kathleen Sutcliffe studied these environments and found a shared mindset: the best teams don’t look for big failures. They look for tiny anomalies.

A slightly unusual delay. A detail that doesn’t sit right. A deviation from the plan that nobody wants to name yet.

These teams know big failures start small.

Engineering isn’t aircraft-carrier flight operations, but the pattern holds. Most failures begin as minor inconsistencies that quietly calcify into patterns—like:

• The integration that’s always “almost ready.”

• The service that keeps needing “a quick patch.”

• The team that stops asking questions in standup.

“Watching for them” can’t just mean hoping someone notices. It has to show up in how you run the org:

• A standup where one of the prompts is, “What feels off right now?”

• A retro where you explicitly ask for “small things we’re starting to tolerate.”

• A simple review where you scan key projects for anything that keeps slipping “just a little.”

Weak signals only help if you build places for them to land.

Teams Don’t Hide Problems—Systems Do

People don’t stay quiet because they’re dishonest. They stay quiet because every org has unwritten rules:

• Don’t raise issues too early—it can sound negative.

• Don’t escalate—it can make you look incapable.

• Don’t question the timeline—it’s already promised.

• Don’t bring up risk—leaders want certainty right now.

Engineers are smart. They adjust quickly.

Amy Edmondson’s research on psychological safety explains why people speak up or stay quiet. When the cost of honesty feels high, people default to silence. And in most engineering orgs, the price feels high by default.

But this isn’t just cultural. It’s structural.

If the escalation channel isn’t explicit, people won’t escalate. If leaders respond defensively, people learn to wait. If bad news causes chaos, the organization teaches teams to avoid it.

Gergely Orosz writes often about this dynamic: teams escalate late when they expect leaders to minimize concerns, or when past escalations died in place.

If you’re only hearing about risk at the last minute, your team isn’t failing. Your system is.

You Can’t Scale Honesty Through Conversations Alone

My earlier article, “The Everything’s Fine Trap,” explored the micro side of this problem: how leaders ask better questions, earn honesty, and avoid optimistic framing in one-on-one conversations.

That’s essential, but it doesn’t scale.

With 10 engineers, you can hear the truth through direct conversation. At 40, you need patterns. At 100+, you need systems.

People raise problems. Systems catch what people miss.

You need both.

Your Reaction Becomes Policy

This is the part leaders underestimate.

When someone finally shares a hard truth, your reaction becomes policy even if you didn’t intend it to.

An engineer tells you, three months before a committed date, that a key dependency is at risk. You have a choice.

You can say, “We’ve already promised this—just do what it takes,” and watch them go quiet next time. Or you can say, “Thank you for flagging this early. Let’s walk through options and update stakeholders before this becomes a surprise.”

In both cases, you’re broadcasting whether early warnings are welcome.

If you get defensive, people wait longer. If you minimize it, they stop trying. If you punish it, drift becomes your operating model. If you thank them and act, they bring issues early next time.

Michael Lopp said it well: “Silence is a signal.” But your response decides what the next signal will be.

The best engineering leaders don’t want polished updates. They want the uncomfortable ones—the ones that change the plan before the plan collapses.

Great Leaders Build Early-Warning Systems

You can’t depend on heroic honesty. You need lightweight mechanisms that expose problems even when people don't want to.

These don’t need to be heavy. Simple is better.

At the team level, add one weekly question: “What changed since last week?” Not progress. Not status. Change. Scope, assumptions, dependencies, constraints. Drift lives in change, and this question forces it into the open.

Across teams, make one question non-negotiable: “Where are we misaligned right now?” Not “Are we aligned?” That invites optimism. Naming misalignment invites honesty. You’ll know it’s working when people start bringing up uncomfortable edge cases and ownership gaps.

For multi-team dependencies, maintain a short, visible risk log. No fancy fields. Just the dependency, the concern, the owner, and the next check-in date. The point isn’t documentation. It’s that anyone—including you—can scan it and see where the organization is betting on hope.

And give people a clear, safe path for escalation that doesn’t require political skill to navigate. That might be as simple as a named channel or mailing list where the only acceptable first response from leaders is some version of: “Thanks for raising this. Here’s how we’ll follow up.” No debating the risk in-thread. No public shaming. Just intake and the next step.

Early-warning systems don’t need to be complex. They need to be obvious.

Your Real Job: Make Risk Visible Early

At senior levels, your value isn’t measured by how well you respond to crises. It’s measured by how few crises reach you without warning.

• You don’t eliminate drift—you make it visible.

• You don’t eliminate risk—you expose it early.

• You don’t eliminate mistakes—you eliminate surprise.

The longer I’ve led teams, the clearer it’s become that exceptional engineering leadership isn’t about having perfect answers. It’s about building an organization that gives you the truth fast enough to do something about it.

If bad news moves slowly, everything else does too—decisions, fixes, learning, and trust.

If truth moves quickly, everything else accelerates.

Try This Next Week

Pick one project that matters. Ask the team three questions:

• What assumption changed recently?

• What drift have we quietly accepted?

• What truth haven’t we said out loud yet?

Then ask yourself a fourth: “Where would this information live if I weren’t in the room?”

If the honest answer is “nowhere,” you’ve just identified your next early-warning system to build. Don’t design it yourself. Ask the project lead to prototype the simplest possible mechanism that would’ve revealed this signal earlier—and review it together next week.

Early warnings are always there. Your job is to create the systems that actually catch them.