When junior team members flag risks and get ignored, IT projects pay the price. Why “senior knows best” is costly, and how leaders can make challenge safe.
“#@*&%# boomers!”
The young project manager entered the office kitchen, slamming the door so hard I’m amazed it stayed on its hinges.
I asked if he was OK and, after assuring him that anything he told me would stay between us, he explained that he had just flagged what he saw as a critical risk. His concern hadn’t been investigated and then dismissed. It had simply been dismissed.
What he told me seemed reasonable. I was there as a PMaaS (Project Management as a Service) PM, working on a different project, but I suggested he escalate. Long story short, he did. The risks he flagged were acted on.
I’ll never forget that day. Partly because I had to Google what a “boomer” was (Ed’s note: which arguably makes him one), but chiefly because it was the first day I noticed the pattern we’ll discuss here. And to be fair to the person who waved his concern away, this isn’t a generational issue. They could just as easily have been 35 as 65. What counted was their seniority, not their birth year.
Some of the most expensive IT project failures begin with a warning that nobody acts on.
A junior analyst spots a dependency that does not make sense.
A test engineer notices a pattern in defects.
A business user questions whether the new process will actually work on the shop floor.
A graduate asks the question everyone else has stopped asking: “Why are we doing it this way?”
Sometimes the evidence is incomplete, sometimes the issue is misunderstood … but sometimes the real problem is simpler: the person raising the concern is junior, the decision has already been made, and challenging it feels more dangerous than accepting it.
In IT project management, that is an expensive cultural habit.
When “senior knows best” becomes the default, a small, fixable issue can grow into an expensive and highly visible delivery failure.
Project fails always call ahead
IT projects rarely fail without warning signs.
More often, the warnings exist at team level but are filtered, softened, or suppressed before they reach decision makers. Research on troubled software projects has found that employees and contractors may be reluctant to pass on unwelcome but constructive information, so accurate signals about failure don’t move up the hierarchy.
This is not a new problem.
About 25 years ago, I read an article, Blowing the Whistle on Troubled Software Projects. Worse still, it referenced cases from the late 1980s!
It is not simply a communication problem.
It is a power problem.
When “senior knows best” becomes the operating norm, people learn that silence is safer than scrutiny. A blame culture makes this worse: rather than examining the underlying issue, organisations target the messenger. Over time, staff conclude that staying quiet carries less personal risk than raising a concern.
The result is a project that appears controlled in the status report while becoming progressively less controllable in reality.
For further reading on this, I recommend Kristina Dahlin’s eye-opening article from earlier this year: “The Most Expensive Mistake Is Not The Error, But Continuing It”.
Fresh eyes see what familiarity hides
Every project team develops blind spots.
People become attached to decisions they helped make. They normalise workarounds. They stop questioning assumptions that were reasonable six months ago but no longer fit the business, the technology, or the delivery reality. Familiarity can create efficiency, but it can also create tunnel vision.
The case of that door-slamming PM is not isolated.
As a fresh pair of PMaaS eyes, I’ve flagged meetings where the same risk had been discussed four times without a decision, a dependency that everyone assumed someone else owned, a stakeholder who had stopped contributing, a “temporary” solution that has quietly become permanent and more than one plan that is technically plausible but operationally unrealistic … each time, a junior project team member had already raised the issue.
So why was I listened to and not them?
External perspectives like ours do add value, we do look at a situation afresh, but a less world-worn pair of internal eyes can be just as effective.
In project delivery, a fresh view can be the difference between a risk being raised and acted upon early, and a risk being discovered during go-live.
Create an environment where the best available insight, wherever it sits in the organisation, can influence the decision.
Psychological safety is a delivery control
Psychological safety is often discussed as a culture initiative. In IT projects, it is also a delivery control.
Teams perform better when people feel able to speak up, share ideas, challenge assumptions, and engage in debate without fear of recrimination. Research on psychologically safe teams links that environment to greater willingness to raise issues, share knowledge, collaborate, and learn.
For a CIO or delivery leader, the practical question is simple:
Do people believe that raising a concern will improve the project, or damage their standing?
If the answer is unclear, your project has a hidden risk.
What “senior knows best” gets wrong
Seniority brings pattern recognition, commercial judgement, political awareness, and accountability. Those things matter.
But seniority does not make someone infallible. It does not guarantee visibility of every operational detail. And it certainly does not make a senior opinion more valuable than an early warning from someone closest to the work.
The strongest project cultures do not replace senior judgement with junior opinion. They combine them.
Senior leaders should set direction, make decisions, and create the conditions for honest reporting. Junior and mid-level colleagues should be expected, not merely permitted, to challenge, question, and flag emerging risk.
A useful reframe is: “Seniority earns influence. Evidence earns attention.”
Practical ways to break the pattern
Leaders do not need a culture programme to start changing this. They need visible behaviours.
- Ask better questions: Replace “Are we on track?” with “What are we choosing not to see?”
- Thank the messenger: When someone raises an uncomfortable issue, respond with curiosity before judgement.
- Separate the issue from the person: Make it clear that identifying a risk is not an accusation of failure.
- Use red, amber, green honestly: If amber always means “fine, really,” the reporting system has stopped working.
- Invite challenge by name: Ask quieter team members directly: “What would concern you if you were in my role?”
- Act visibly: Nothing builds trust faster than a concern being investigated, addressed, or clearly explained.
- Bring in independent assurance early: Do not wait until the project is visibly struggling to seek an outside view.
Conclusion
The most dangerous project culture is not one where people make mistakes. Mistakes are inevitable in complex IT delivery.
The danger is a culture where people see the warning signs, understand the potential consequences, and decide that speaking up is not worth the risk.
Removing “senior knows best” does not mean removing leadership. It means using leadership to make challenge welcome, evidence matter, and honest reporting safe.
The best project leaders do not need to be the people with all the answers. They need to create teams where the right questions can be asked, uncomfortable evidence can be examined, and decisions can change when the facts demand it.
Because the observation that saves a project may not come from the most senior person in the room. It may come from the person who has been quietly wondering why nobody else has questioned the plan.
So, here’s a question for every project sponsor, programme director, and delivery leader:
If someone on your team spotted a serious flaw in your plan tomorrow, would they feel safe enough to tell you?
Not sure whether early warnings are reaching you? A fresh, independent pair of eyes can often spot what familiarity hides. Talk to Stoneseed about how our PMaaS project managers bring objective challenge to your delivery, before small risks become expensive ones.
Sources, Inspiration And Further Reading:
Blowing the Whistle on Troubled Software Projects
https://cacm.acm.org/practice/blowing-the-whistle-on-troubled-software-projects
The Most Expensive Mistake Is Not The Error, But Continuing It
https://www.cbs.dk/en/articles/most-expensive-mistake-not-error-continuing-it
Creating Psychological Safety in the Workplace
https://www.tandfonline.com/doi/full/10.1080/08956308.2023.2164439