Your project may not have a problem with risk identification. It may have a problem with people feeling safe enough to report the risks they have already identified.
Have you ever felt like you were running a firefighting department rather than managing a project?
One issue after another. A delayed delivery. A design coordination problem. A contractor who has fallen behind schedule. A resource shortage that suddenly becomes urgent. Just as you put out one fire, another one starts somewhere else.
It can feel as though problems are appearing from nowhere. But are they really that unpredictable?
Consider this: what if someone on your team had already noticed the warning signs? What if they suspected that a milestone would be missed, that a particular activity was falling behind, or that an assumption in the programme was unrealistic?
And what if they chose not to say anything?
Perhaps they were worried about being blamed. Maybe they had raised a similar concern before and been dismissed as negative. Or perhaps they simply did not want to be the person who brought bad news to a meeting where everyone was celebrating progress.
By the time the problem becomes impossible to ignore, everyone seems surprised. Yet, when you start asking questions, you discover that the warning signs were there all along.
The project did not necessarily lack risk visibility. It lacked the conditions for people to speak up.
For technical professionals moving into leadership, this is an important distinction. Your ability to deliver projects depends not only on identifying risks yourself, but also on creating an environment where your team can identify, communicate and address risks before they become crises.
Let’s explore how you can do that.
What Is a Bad News Culture?
A bad news culture is an environment where people learn that reporting problems comes with personal consequences.
The messenger is labelled negative, difficult or insufficiently committed to the team’s success. Instead of exploring the issue, the leader becomes defensive. The conversation shifts from resolving the problem to questioning the person who raised it.
Sometimes, the response is more subtle.
Someone raises a concern about the project schedule, and the immediate response is, “We have already discussed this.”
Another team member highlights a potential quality issue, only to hear, “Why are you always looking for problems?”
And then there is the ever-popular corporate rule: “Don’t bring me a problem unless you have a solution.”
I understand the intention behind this advice. Leaders want people to take ownership, think critically and contribute to solutions rather than simply complain.
But taken too far, this expectation can be counterproductive.
What happens when someone identifies a serious risk but does not yet know how to resolve it? Do we really want them to remain silent until they have figured everything out?
By then, the opportunity to intervene may have narrowed considerably.
A junior engineer might notice a discrepancy in the drawings but be unsure how it will affect construction. A project manager might recognise that the programme is becoming unrealistic but need input from several disciplines before proposing corrective action. A team member might spot a weakness in a proposed solution without knowing what the alternative should be.
These people have valuable information. They do not need to have all the answers before they are allowed to contribute.
Identifying a problem is a contribution. Helping solve it is the next step.
As a leader, your responsibility is to make room for both.
Why Technical Teams Sometimes Stay Silent
Technical professionals are trained to analyse, solve problems and provide answers. This is a valuable strength, but it can create an uncomfortable dynamic when a problem is raised without a clear solution.
Leaders may become impatient. Team members may feel pressure to appear competent. And gradually, people begin filtering what they share.
They report what they can defend. They delay reporting what they are still investigating. They keep concerns to themselves until they have gathered enough evidence to protect themselves from criticism.
Unfortunately, project risks rarely wait for us to feel ready.
There is also a power dynamic at play. When a senior stakeholder has already committed to a particular approach, challenging it can feel like challenging their competence. A team member may decide that preserving the relationship is safer than questioning the assumption.
And when people repeatedly see colleagues criticised for raising concerns, they learn from those experiences.
Nobody needs to announce that bad news is unwelcome. The culture communicates it through everyday reactions.
The result? Leaders receive a filtered version of reality.
Meetings become more positive. Progress reports look reassuring. Risks appear manageable. Until suddenly, they aren’t.
The challenge is not to eliminate bad news. It is to make sure you hear it early enough to do something about it.
How Leaders Can Encourage Their Teams to Speak Up
1. Get Your First Reaction Right
When someone brings you bad news, your first response matters more than you might realise.
Imagine a team member tells you that a critical activity is likely to delay the next project milestone.
Your immediate reaction might be frustration. You may wonder why the issue was not identified earlier, why the team has not taken corrective action, or how you are going to explain the situation to the client.
Those concerns may be legitimate. But if your first response is to interrogate the person or express anger, you risk discouraging the next person from speaking up.
Try starting with:
“Thank you for flagging this. What do we know about the issue so far?”
Then explore the situation.
What has happened? What is the potential impact? What remains uncertain? What needs to happen next?
Notice the difference. You are not pretending the problem is insignificant, and you are not promising that there will be no consequences. You are directing attention towards understanding and resolving the issue.
You can still ask why the risk was not identified earlier. You can still challenge poor planning or a failure to follow agreed procedures. But first, establish the facts and determine what needs immediate attention.
A grounded first response tells your team that bringing you bad news is not, in itself, a punishable offence.
And remember, you are setting an example for how the rest of the team should respond. If you expect your team members to remain calm when problems arise, they need to see you practising the same discipline.
2. Separate the Message from the Messenger
This is where your technical background can become a real advantage.
As a technical professional, you understand the importance of examining evidence, testing assumptions and distinguishing between a person’s opinion and the facts of a situation.
Apply that same discipline when someone challenges a decision or raises a concern.
Suppose a team member tells you that the proposed construction sequence is unlikely to work. Your first thought might be that they are being unnecessarily pessimistic or resisting a decision that has already been made.
Pause.
Instead of evaluating the person, examine the message.
What evidence supports their concern? What assumptions are they questioning? What would need to be true for their assessment to be correct?
They may be wrong. Their analysis may be incomplete. Or they may have spotted something you and the rest of the team overlooked.
You cannot know until you investigate.
This principle is particularly important when working with experienced technical teams. People need to know that they can challenge an assumption without being treated as disloyal.
Equally, separating the message from the messenger does not mean accepting every concern without scrutiny. It means evaluating concerns on their merits rather than dismissing them because of who raised them or how uncomfortable they make you feel.
The next time someone disagrees with you, ask yourself: “If this information had come from someone I particularly respected, would I be responding differently?”
That question alone can reveal a lot about your leadership habits.
3. Watch Out for Silence: The Parable of the Naked King
Remember the story of the emperor who paraded through the streets wearing imaginary clothes?
Everyone could see that he was naked, but nobody wanted to be the person who said it. Each person assumed that others either could see something they could not or were simply unwilling to challenge the situation.
It took someone willing to speak plainly to expose the obvious.
Project teams can fall into a similar trap.
Everyone agrees that the schedule is achievable. Nobody questions whether the resources are sufficient. The team accepts that a critical delivery will arrive on time, even though the supplier has already missed two commitments.
The assumptions become accepted facts simply because nobody challenges them.
As a leader, pay attention when your team agrees with everything you say. Of course, sometimes you will be right, and agreement is perfectly reasonable. But consistent agreement, especially around complex or high-risk decisions, should prompt you to look a little closer.
Are people genuinely convinced, or have they decided that challenging you is not worth the effort?
One way to test this is to invite disagreement deliberately.
Ask questions such as:
- “What assumptions are we making that might not hold?”
- “If this plan fails, what is the most likely reason?”
- “What would someone from outside this team challenge about our approach?”
- “What information might we be overlooking?”
You can also ask a team member to examine a proposal from the perspective of a sceptical reviewer.
The objective is not to create conflict for its own sake. It is to make constructive challenge part of the decision-making process before reality does the challenging for you.
4. Acknowledge and Reward Early Warning
This is an area I am personally working on.
When your natural tendency is to avoid conflict, it can be tempting to keep conversations comfortable. You may prefer to focus on what is working rather than dwell on what might go wrong. You might even delay challenging an issue because you do not want to appear negative.
Recognising that tendency is an important first step.
Leadership requires us to get comfortable with a certain amount of discomfort. Sometimes, the most valuable conversation is the one that interrupts an otherwise pleasant meeting.
And the same principle applies when your team raises concerns.
If someone identifies a risk early, acknowledge the contribution. Thank them for bringing it forward. Recognise the value of the information, even if the risk turns out to be less significant than initially thought.
For example:
“I’m glad we are discussing this now, while we still have options. Let’s work through the potential impact and decide what action is needed.”
That response reinforces the behaviour you want to see.
Importantly, rewarding early warning does not mean rewarding carelessness or treating every minor issue as a crisis. It means recognising that timely, honest reporting is valuable, even when the information is inconvenient.
You should also examine your own behaviour after an issue has been raised. Did you thank the person but later criticise them for the consequences? Did you invite openness in a meeting and then dismiss the concern when it challenged your preferred approach?
People pay attention to what happens after they speak up.
Your stated values matter, but your consistent actions teach the team what is genuinely acceptable.
5. Make Exploring Failure Part of Your Culture
One of the best ways to improve project risk management is to create regular opportunities to explore what could go wrong before it does.
This does not require a lengthy workshop or another complicated reporting template. You can start with a few deliberate questions during routine project meetings.
Before a major milestone, ask the team to identify the assumptions on which success depends.
During programme reviews, explore activities where small delays could have a disproportionate impact on subsequent work.
Before approving a technical solution, discuss the conditions under which it might fail.
And after a setback, examine what the team can learn without turning the review into a search for someone to blame.
A useful technique is a pre-mortem. Ask the team to imagine that the project has failed or missed a major milestone. Then invite them to work backwards and identify the most plausible reasons.
This changes the conversation. Instead of asking people to criticise a plan they have already invested in, you give them permission to imagine an undesirable outcome and identify what might have caused it.
You can make this even simpler by introducing one question into your regular project meetings:
“What’s the one thing we are all pretending is not a problem for this project, when it actually is?”
Give people time to think. Do not rush to fill the silence. And when someone responds, resist the urge to explain immediately why their concern is unfounded.
Listen first.
You might discover that the team has been working around an unresolved interface issue, that a key resource is stretched across too many activities, or that everyone is relying on a delivery date nobody has actually confirmed.
These conversations help turn risk management from a document-driven exercise into an everyday leadership practice.
The more regularly you explore potential failure points, the less unusual it becomes to discuss them openly.
Turning Openness into a Project Leadership Habit
Creating a speak-up culture is not a one-off announcement. It is built through repeated interactions, especially when the information being shared is uncomfortable.
Here are three practical actions you can take in your next project meeting:
First, invite one challenge. Before finalising an important decision, ask the team what could make the plan fail. Make it clear that you are looking for useful insight, not negativity.
Second, acknowledge the messenger. When someone raises a concern, thank them before moving into problem-solving mode. This small action can influence whether they bring you the next concern early or wait until it becomes unavoidable.
Third, follow through visibly. If someone raises an issue, show what happens next. Investigate it, assign responsibility, agree on an action or explain why no further action is necessary. People are more likely to speak up when they see that their input is taken seriously.
You can also review your own leadership behaviour at the end of each week. Ask yourself: “When did I make it easier for someone to disagree with me? And when might my reaction have made it harder?”
You do not need to get this right every time. What matters is your willingness to notice, learn and adjust.
Final Thoughts: The Risk You Don’t Hear About
As technical leaders, we spend considerable time managing schedules, budgets, quality, resources and project risks. We develop registers, hold review meetings and establish escalation procedures.
These are all important. But none of them can fully compensate for a team that is afraid to tell the truth.
The most dangerous project risk may not be the one recorded in your risk register. It may be the concern sitting quietly in someone’s mind because they do not believe it is safe to raise it.
A strong project leader does more than ask for accurate reports. They create the conditions in which accurate reporting becomes possible.
That means responding calmly to bad news, separating the message from the messenger, challenging assumptions, acknowledging early warnings and making the exploration of failure a normal part of project conversations.
You will not eliminate every surprise. Some risks will emerge despite your best efforts, and some problems will genuinely be difficult to predict.
But you can reduce the number of avoidable surprises caused by silence.
So, at your next project meeting, try asking this question:
“What do you see happening on this project that I might not be seeing?”
Then listen carefully to the answer.
Your team may already have the information you need to prevent the next fire. Your job is to make sure they feel safe enough to tell you before it starts.
Leave a comment