Your Team Already Knows What's Broken. Can They Tell You?

The Phrase That's Killing Your Team's Early Warning System

"Don't bring me problems. Bring me solutions."

It is the kind of line that gets quoted on LinkedIn over a black-and-white photo of someone in a suit. It sounds decisive. It sounds like accountability. It sounds like the kind of thing a strong leader says to a room full of people who need to step up.

It is also, when you trace what it actually does inside an organization, one of the most expensive sentences a manager can speak. The phrase teaches your team that the cost of raising a half-formed concern is your time, your visible disapproval, and the quiet message that they should have figured it out themselves before walking through your door. The benefit of staying quiet is that none of those costs land on them. So they stay quiet. And the small fires you used to hear about at week three become structural problems you find out about at week thirty.

If you lead a team, the most important system you maintain is not your roadmap or your KPI dashboard. It is the pipeline by which information about what is broken travels to the people who can fix it. When that pipeline narrows, every other system you run gets slower, more expensive, and more fragile.

The cost of silence

History keeps trying to teach us this lesson, and we keep paying tuition.

The night before the Challenger launch in January 1986, engineers at Morton Thiokol pleaded with NASA to delay. They had data suggesting that the O-rings sealing the solid rocket booster joints became dangerously brittle in cold weather, and the forecast called for the coldest launch in the program's history. The concern was concrete, technical, and well-supported. It was also escalated through a layered, schedule-pressured decision process that rewards confident summaries and punishes inconvenient detail. By the time the conversation reached the launch decision, the warning had been softened, reframed, and overruled. Seven astronauts died seventy-three seconds after liftoff.

Seventeen years later, during the launch of Columbia, a chunk of insulating foam broke off the external tank and struck the orbiter's wing. Engineers on the ground recognized the strike and asked, more than once, for the Department of Defense to take high-resolution imagery of the wing in orbit so they could assess the damage. Those requests were denied at the management level. The judgment was that pursuing imagery would slow things down and that the strike was probably not serious. When Columbia broke apart on reentry in February 2003, all seven astronauts were killed. The Columbia Accident Investigation Board concluded that NASA's organizational culture had as much to do with the loss as the foam itself.

The pattern is not confined to spaceflight. In the years leading up to the 737 MAX crashes, Boeing engineers and pilots raised internal concerns about MCAS, the automated flight control system later implicated in the Lion Air and Ethiopian Airlines disasters. Concerns surfaced about training requirements, about disclosure to regulators, and about the pressure to keep the airplane competitive with Airbus on schedule and cost. Some of those concerns appeared in internal messages later released by congressional investigators. They did not change the airplane in time. Three hundred and forty six people died.

Each of these stories is, on the surface, a story about engineering. At a deeper level, each is a story about whether information could travel from someone who saw the risk to someone who could act on it. The technical failure was downstream. The communication failure was upstream. And the upstream failure had a culture behind it.

You probably do not run a launch program or a commercial aircraft program. You almost certainly run something where bad information held back too long can damage customers, employees, revenue, or trust. The mechanism is the same.

Why "bring me solutions" backfires

The instinct behind the phrase is reasonable. Leaders are tired of being treated as a complaints desk. They want their people to think, to own, to act. None of that is wrong.

The trouble is that the phrase does not actually train ownership. It trains filtering. The person closest to the problem now has two jobs: identify the issue, and pre-package a fix that is good enough to survive your reaction. If the fix is not obvious, or if the issue is bigger than one person can solve, the rational move is to wait. Wait until it is more clear. Wait until someone else is stuck. Wait until the leader hears about it from a customer instead of a teammate.

That is the version of accountability you actually get when you demand solutions before you accept problems. It is not initiative. It is hesitation dressed up as professionalism.

There is a better instinct. Frame the goal as raising issues with context, not raising issues with completed answers. The person who first sees a risk almost never has the full picture. They have a vantage point, not a strategy. Treat that vantage point as a gift, then bring the rest of the room into deciding what to do about it. Sometimes the issue is small and gets dispatched in two minutes. Sometimes it is a thread that, when pulled, reveals something the leadership team had no idea was there. Either outcome saves you money. Both outcomes require that the person who sees the thread feels safe enough to point at it.

The opposite of silence is not chaos

Whenever leaders hear this argument, an objection arrives quickly. If I let everyone bring me every concern, my calendar fills with whining. Where does accountability go.

The objection is fair. The answer is also clear. Inviting issues is not the same as accepting helplessness. Amy Edmondson, the Harvard researcher who has spent decades on what she calls psychological safety, frames it cleanly: psychological safety is permission to be candid, not permission to be careless. The team you are trying to build is one where people speak up early and own their part. The team you are trying to avoid is one where people stay quiet because the cost of speaking is high, and one where people speak constantly without ever doing anything about what they said.

A pipeline for issue raising helps with both. It separates the act of surfacing a concern from the act of solving it, which lets you reward both behaviors on their own merits. It gives you a structured way to hear the early warning without committing to an open-ended therapy session. And it lets you ask, in a clean way, what the person who raised the issue is willing to take on next.

The forum invites the issue. The follow-up assigns the work.

Build the pipeline

The most useful thing a leader can do this quarter is not write another vision deck. It is install a recurring rhythm where issues get surfaced, examined, and acted on. The rhythm only works if it has two pieces: a low-friction way for people to bring something forward, and a predictable place where it gets discussed.

Start with intake. Before raising an issue, ask the person to capture five things.

1. What I am seeing. Observation, not interpretation. The check-in calls are taking thirty minutes, not the fifteen we scheduled. We have shipped three releases in a row with rollback.
2. Why I think it matters. Impact, scope, and who is affected. This might bleed into the renewal conversation. This will slow our roadmap by a sprint.
3. How confident I am. A hunch, a pattern, or something confirmed. Marking confidence honestly is the difference between a thoughtful escalation and a five alarm fire that turns out to be steam.
4. What I have already tried or ruled out. This is where ownership shows up. Not as a finished solution, but as evidence that the person has done the work to make the issue worth your time.
5. What I am asking for. Awareness, a decision, help, or escalation. Naming the ask short circuits twenty minutes of guessing.

Five questions. A teammate can fill them in over coffee. They are not a gate; they are a runway.

Then put the runway on a calendar. Most teams do well with three layers. A weekly issues review, no longer than thirty minutes, where new items get aired and triaged. A monthly blameless postmortem on something that actually went wrong, where the goal is to learn rather than to assign fault. A quarterly systemic pattern review, where the team looks at the issues that have piled up over twelve weeks and asks what they say about the underlying system.

You do not need expensive software. You need a recurring meeting, a shared list, and the discipline to actually run it.

Make the postmortem actually blameless

The phrase "blameless postmortem" has been popular long enough that almost everyone uses it, and almost no one means it. The version most teams run is structured to look blameless while quietly producing a name. The official root cause is "human error." The action item is "have a follow-up conversation with the engineer." Nobody is fired. Nobody is named in the document. Everyone in the room knows exactly who the meeting was about.

That is not blameless. That is plausible deniability with a wiki page.

A proper blameless postmortem starts from a different premise. Any sufficiently complex system will eventually produce a failure, and the failure tells you something true about the system. The right question is not who did this. It is what made it possible. What process allowed this change to ship. What signal did the team miss. What incentive was pushing in the wrong direction. What documentation was wrong, missing, or out of date. What pressure was loud enough to drown out the engineer's better judgment.

If your postmortem produces a person's name as the root cause, you have not run one. You have run a tribunal in costume. The crosshairs landed on the easiest target, the human at the end of the chain, and the system that produced the failure walks away unbothered, ready to produce the same failure again.

A useful test: when the postmortem is finished, would the engineer who made the mistake be willing to read the document out loud to the team. If the answer is no, the document is still about the person. Rewrite it until it is about the system.

This is not a soft practice. It requires leaders to give up the small dopamine hit of identifying a culprit and to invest, instead, in the slower work of changing the conditions that produced the mistake. The reward is that the next mistake is different from the last one, instead of identical to it.

It is worth noting that this is not a new idea. Toyota has spent decades giving any worker on the assembly line the right to pull a cord, called the Andon, that stops the entire line when a defect appears. Not to assign blame. To examine what allowed the defect to leave the previous station. The point of the Andon cord is the same as the point of a real postmortem: surface the problem early, look at the system, and keep the people who saw it first inside the conversation.

What leaders should actually say

There is a moment, in every conversation about psychological safety, where a manager asks, what do I actually say. The answer is unglamorous. You say the same kinds of things, calmly, every time someone brings you something hard.

When an issue is raised, your first sentence should acknowledge that the person did the right thing by raising it. Not in a saccharine way. Plainly. Thanks for surfacing this. Walk me through what you are seeing. The phrase you do not use is, what is your proposed solution. That can come later, after the issue is well understood.

When the issue turns out to be small, still close the loop. Tell the person what you decided, why, and what they can expect to hear if it gets bigger. Small issues that get dismissed without explanation teach people that raising small issues is unwelcome. The next small issue, the one that turns out to be a big one, will not get raised.

When the issue turns out to be real, the most important thing you can do is publicly credit the person who saw it first. Not because they need praise, but because everyone watching needs to learn that surfacing risk is a way to get noticed in this organization, not a way to disappear from it.

The last lever is consistency. People do not learn psychological safety from a value statement on the wall. They learn it from watching what happens to the third or fourth or seventh person who brings forward a concern that turns out to be inconvenient. If those people get listened to, thanked, and brought into the next conversation, you will have a team that hands you problems early enough to solve them. If those people get a sigh and a redirect, you will have a team that hands you problems exactly one minute too late.

What you are choosing

Every leader is, whether they realize it or not, building one of two organizations. In the first, problems travel quickly to the people who can act on them. In the second, problems are rounded off, deferred, and routed around the people in charge until they finally become impossible to ignore. The first kind of team is calmer. The second kind looks calmer for a while and then, all at once, is not.

The phrase you say at the door of your office decides which team you are running. Retire "don't bring me problems, bring me solutions." It was not honest the first time it was repeated, and it has not become more useful with age. Replace it with something simpler and more demanding. Bring me what you are seeing. Bring me what you have tried. Bring me what you are asking for. We will figure out the rest together.

Then build the pipeline that makes the promise real, run the cadence that keeps it honest, and run postmortems that earn the word blameless. The early warning system you build this quarter is the one that will save you in the next.

Sources

• Amy Edmondson, The Fearless Organization, on psychological safety and team learning.
• Diane Vaughan, The Challenger Launch Decision, on the normalization of deviance at NASA.
• Columbia Accident Investigation Board Report, Volume I, August 2003.
• Peter Robison, Flying Blind: The 737 MAX Tragedy and the Fall of Boeing.
• House Committee on Transportation and Infrastructure, Final Committee Report on the Boeing 737 MAX, September 2020.
• Jeffrey Liker, The Toyota Way, on the Andon cord and built-in quality.