I once watched a Head of Product complain themselves out of credibility.
At first, it worked.
They were good at spotting problems. A delayed decision, a weak process, a technical dependency, a customer issue, a handoff that was not working. Some of the issues were real. Some were exaggerated. Some were just the normal mess of a company trying to move quickly.
But everything was raised with the same level of concern, and to too many people.
The CTO heard it. The CEO heard it. Peers heard it. People who were nowhere near the detail heard enough to form an opinion.
Over time, the story became simple: Product was blocked, Engineering was the problem, and the CTO was not doing enough.
The CTO eventually left.
For a short period, the narrative looked correct. The blocker had been removed. The company had acted. People could tell themselves the problem had been found.
Then the same issues continued.
Roadmaps were still unclear. Priorities still changed. Handoffs still broke. Teams still disagreed about what mattered. The absence of the CTO did not magically create a better operating system.
That is when the noise started to reflect back on the person who had been making it.
People began asking different questions. If the CTO was the whole problem, why were the problems still here? If Product had seen all of this so clearly, why had they not created a better workflow? Were they escalating issues, or were they just narrating dysfunction?
Eventually, it was not just the CTO under scrutiny. The wider department was.
A lot of people left.
That is the bit people forget about noise. It might damage someone else’s reputation first, but it also reveals your own judgement.
Noise is not clarity
The mistake was not raising problems.
Good companies need people who say when things are broken. Silence is not maturity. Silence is how bad systems survive.
The mistake was raising problems in a way that created more heat than light.
A useful escalation makes the next step clearer. It gives context, ownership, severity, options, and a recommendation. It helps people understand whether something is a fire, a risk, a tradeoff, or just friction.
Noise does the opposite.
Noise makes everyone aware that something feels wrong, but not necessarily wiser about what to do next.
There is a big difference between saying:
This is broken.
And saying:
This is broken, here is the impact, here are the options, and this is what I recommend.
The first might be true. The second is useful.
That difference matters more as you get more senior. At junior levels, spotting problems is valuable. At senior levels, simply spotting problems is not enough. You are expected to improve the system around them.
Noise damages both sides
When you repeatedly raise loosely structured problems about another team, you shape how that team is seen.
If the people listening are not close to the detail, they will often remember the mood more than the facts. Engineering is slow. The CTO is blocking us. Product keeps getting let down.
Those statements may contain some truth. That is what makes them powerful. But partial truths are dangerous when they travel without context.
Once someone becomes the blocker in the company story, every action starts getting interpreted through that story. A normal tradeoff looks like avoidance. A reasonable pushback looks defensive. A missed deadline becomes proof of a pattern.
That is not a fair way to diagnose a system.
But noise does not only hurt the target. It hurts the person creating it.
Every escalation teaches people how to read your judgement. If you raise ten small things like they are major risks, people do not conclude that you are thorough forever. Eventually they conclude that you struggle to prioritise.
If you tell everyone about the problem but do not improve the workflow, people do not conclude that you are transparent forever. Eventually they conclude that you are better at describing dysfunction than fixing it.
If the person you blamed leaves and the problems continue, people do not keep looking in the same direction forever. Eventually they look back at you.
That is what happened here.
The noise helped create a simple story. But once the simple story failed, the noise became evidence of a deeper problem.
Covering yourself is not leadership
There is a subtle trap in all of this.
The Head of Product could say, truthfully, that they had raised the issues. They had warned people. They had made the risks visible. They had protected themselves.
But protecting yourself is not the same as improving the system.
A paper trail can prove you saw the problem. It does not prove you handled it well.
Leadership is not making sure everyone knows something is broken. Leadership is helping the right people understand what is broken, why it matters, who owns which part, and what should happen next.
That is much harder than complaining.
It is also much more useful.
Bring signal, not noise
The answer is not to stay quiet. The answer is to make the problem useful.
A noisy escalation says:
Engineering is blocking us again.
A useful escalation says:
We are blocked on X because Y decision is unresolved. It affects Z customers and will delay the release by a week if we do not decide by Friday. Product recommends option A. Engineering prefers option B because of this tradeoff. We need a decision from these people.
One creates atmosphere. The other creates movement.
People do not lose respect for you because you raise problems. They lose respect when raising problems appears to be the whole contribution.
Anyone can point at a messy process, a broken handoff, a slow team, an unclear priority, or a leadership decision that has not been made quickly enough. Sometimes those things are true. But truth is not enough.
The person who earns trust is the person who makes the problem easier to act on. They bring context, name the tradeoffs, separate what needs a leadership decision from what the team can fix, and avoid making every problem bigger by adding an audience. That kind of person reduces load on the organisation. The noisy person adds load, even when they are right.
That is the difference between raising a problem and throwing a problem into the room.
-
Do not create noise and call it transparency.
-
Do not broadcast every issue and call it ownership.
-
Do not mistake being right about the symptoms for being right about the system.
The company may believe the noise at first, but eventually it will ask a harder question.
Not “who did you blame?”
What did you make clearer?
What did you help fix?