Three weeks before a platform migration at a large telecom, every line on the program dashboard was green. Scope green, schedule green, risk green. I was running operations on the receiving end of that cutover, and I remember thinking the board looked too clean for a project that size. It was. On the Friday before go-live, a lead engineer mentioned, almost in passing, that one integration had never actually passed in the staging environment. It had been “nearly there” for five weeks. Nearly there is not green. We moved the date, which was embarrassing in a steering meeting and far cheaper than the alternative.
That dashboard was a watermelon. Green on the outside, red the whole way through. Once you have seen one, you see them everywhere, and you stop trusting a wall of green the way a smoke detector that never chirps stops being reassuring.
The color is a judgment, and judgments drift optimistic
Red, amber, green status is treated like a measurement. It is not. It is somebody’s opinion about reality, converted into a color, usually by the person whose work the color describes. One widely shared breakdown of watermelon reporting puts it plainly: most of the time the color is a judgment about reality, not reality itself, and “optimism becomes confidence, hope stands in for evidence.” Nobody sets out to lie. They round up. The integration is nearly there, the dependency will probably land, the contractor says next week, so the honest-feeling call is green with a mental asterisk. The asterisk does not survive the trip to the dashboard.
What makes this worse than ordinary optimism is that the bias has a direction and it sharpens exactly when you need accuracy most. Reports get more optimistic, not less, as the deadline approaches, because by then a red status carries the added weight of “and I knew and did not say.” The status that would help you most, early and honest, is the one the system is least likely to produce.
Why green survives until it cannot
The reluctance to pass bad news up a hierarchy is one of the better-documented failure modes in project work. Researchers Mark Keil and H. Jeff Smith named it the “mum effect” and built a theoretical model of why people stay silent on troubled software projects: a communication gap, fear of consequences, and team solidarity all push toward keeping quiet. The instinct is not laziness. It is a rational read of the room. If the last three people who flagged a red got grilled, you have learned what red costs.
The scale of that silence is larger than most leaders assume. In research cited by Jim Detert and Amy Edmondson on why employees are afraid to speak, 85 percent of professionals surveyed reported at least one occasion where they felt unable to raise a concern to their boss. That is not a few timid people. That is almost everyone, at least sometimes. When the concern happens to be “the project I own is slipping,” the pressure to round up to green is enormous, and the person feeling it is usually the one holding the most accurate picture of the risk.
The product manager sits in a bad spot here. You rarely own the engineering work, so you depend on other people’s colors to build your own. If their green is soft, your status rolls their softness upward and adds a layer of your own. By the time it reaches an executive, three rounds of optimistic rounding have compounded, and the person with the least direct visibility is the one making the launch call.
The all-green report is the one to distrust
Here is the reframe that changed how I read status, and it comes straight out of Amy Edmondson’s work. In her study of 51 hospital teams, the teams that reported more errors turned out to have better outcomes, not worse. They were not making more mistakes. They were surfacing them. The weaker teams were burying theirs. The difference between the groups was visibility, not competence.
Apply that to a status meeting and the comfortable interpretation inverts. A board that is all green is not evidence of a healthy program. It is evidence that the red is not reaching you. Those are completely different claims, and leaders routinely treat the first as if it were proven when only the second is. A team that reports “on track” for two months and then announces a three-week slip did not suddenly fall behind. It sat on the problem, hoping it would resolve before anyone had to say it out loud. The error rate was never the issue. The reporting latency was.
I have watched both cultures up close. On the fractional side, through Ops Harmony, I have walked into companies where the weekly review was a parade of green and the operators privately rolled their eyes, and into others where a director would open with “we have a red this week, here is what I need” and the room leaned in instead of flinching. The second kind of company shipped more reliably. Not because it had fewer problems. Because its problems arrived while they were still cheap.
What I ask for instead of a color
I have stopped accepting a bare color on anything that matters, and I ask for three things instead.
First, the evidence behind the color. If a workstream is green, I want the observable fact that makes it green: the integration passed in staging on Tuesday, the contract is signed, the load test hit target. “We think we’re fine” is not green; it is an unexamined amber. Forcing the evidence turns a feeling into a claim someone has to stand behind, which is most of the cure.
Second, a leading indicator, not a trailing one. “On schedule” describes the past. I want the thing that will be red before the schedule is: an integration that keeps failing, a dependency owner who has gone quiet, a test pass rate drifting the wrong way. That is the same discipline behind a proper delivery confidence check, which surfaces execution risk before it hardens into a missed date rather than after.
Third, and this is the one that actually moves the culture, I treat a red as a request for help and never as an opening for blame. The watermelon writeup lands on the same point: if you want the truth to travel, you have to make it safe to send. That is not a soft sentiment, it is incentive design. The first time someone raises an early red and gets support instead of a cross-examination, you have bought yourself every future early warning on that team. The first time they get grilled, you have bought yourself a season of green dashboards and ugly surprises.
None of this requires a new tool or a heavier reporting template. It requires the product manager to stop consuming colors as facts and start asking what each one is standing on. The job on a status call is not to collect reassurance. It is to find the red early enough that moving a date is still the worst thing that happens, the way it was for that migration, instead of finding it the hard way on go-live night. The green that survives real questions is worth something. The green that only survives because nobody asked is the most expensive color on the board. For the single hard conversation that follows once you do find the red, the discipline of the bad news briefing is the other half of this skill.