“Bad news does not get better with age.”
I remember walking with a colleague as he was heading into a meeting. As we got close to the room, he said something like, “Well, I hope they don’t ask about Project X.”
I understood the feeling. Nobody enjoys walking into a room hoping to defend a messy project, and nobody wants the awkward question, the uncomfortable pause, or the moment where everyone turns toward the part of the work that is not going well.
However, this instinct is backwards: you want the hard questions so you can explain what you know, what you do not know, what is being done, and what decision is needed, because the alternative is not silence: the alternative is that people talk about the problem when you are not there.
The Conversation Will Happen Somewhere
When a project is in trouble, silence is not neutral.
- Worried stakeholders will try to make sense of the situation.
- A confused team will fill in gaps.
- Leaders without enough information will build their own story from whatever signals they can see.
Avoiding the hard question does not make the organization less concerned; it makes the organization less informed.
Avoiding the hard question does not make the organization less concerned; it makes the organization less informed. A hard question in the room gives you a chance to replace guessing with understanding. It also gives you a chance to show what responsible leadership looks like: say what is late, name the tradeoff, identify the dependency, make the needed decision explicit, and when you do not know yet, say what you are doing to find out.
Hard Questions In One-On-Ones
With your own team, an engineer may bring you a problem, a concern, a fear, or a messy early signal: the technical direction may be shaky, a teammate may be struggling, the deadline may be less realistic than people have been saying, a partner team may be frustrated, or the engineer may be worried they are not the right person for the work.
None of that is fun to hear, and it is still much better than not hearing it. This is where Stephen Covey’s habit, “seek first to understand, then to be understood,” matters in a very practical way: before I explain, defend, or solve, I need to understand what they are seeing and why they are worried.
If the problem is real and your team does not bring it to you, you still have the problem. You just have it in the dark. By the time it surfaces, you may discover that you have two problems: the original technical or project problem, which has been sitting unaddressed, and a trust problem, because your team did not feel safe enough, clear enough, or supported enough to bring it to you earlier.
The most dangerous problems are the ones people have learned not to mention.
Psychological safety can sound like a buzzword until you have worked on a team that lacks it. On that kind of team, risks stay hidden, people polish status, engineers wait until they are certain before raising concerns, and problems arrive late, fully grown, and harder to fix.
On a healthier team, people can say, “I am worried about this,” before they can fully prove it. They can ask for help early, surface risk while there is still time to change the plan, and trust that the first response will be curiosity instead of blame. That is not just better for morale; it is better operationally.
Make The Questions Welcome
You cannot simply announce that hard questions are welcome and expect people to believe you, because people watch what happens after the question.
If someone raises a concern and gets punished, dismissed, mocked, buried in defensiveness, or handed the entire mess alone, the lesson is clear: do not bring problems early.
A different lesson forms when the response is curiosity, clarity, shared ownership, and action. That does not mean every concern is correct. Some hard questions are unfair, some framings are wrong, and some worries are missing context. The first move should usually still be to understand: what are they seeing, what are they worried will happen, what decision do they think is needed, and what are we missing?
The Question Is A Signal
A hard question is a warning light, an invitation, the first visible sign of a risk that has been growing quietly, and a chance to build trust by facing the truth directly.
A hard question is a chance to build trust by addressing the issue directly.
As a leader, I want that signal while it is still useful. I want the engineer to tell me before the project is fully off the rails. I want the stakeholder to ask while there is still time to reset expectations. I want the awkward topic in the meeting before it becomes the hallway narrative.