How do I stop being blindsided by projects going off track?

What the blindside actually looks like

A head of engineering responsible for around 100 engineers described it to us like this:

"I trusted what I was told by the dev manager. Two weeks before the summit, I was told they weren't going to deliver everything that was promised."

Note what is not in that account. Nobody lied. There was no missing process — this organisation ran one-on-ones, a status tool, and regular delivery reviews. The dev manager wasn't incompetent. And the team knew, well before two weeks out.

This is the shape almost every blindside takes: the information existed inside the organisation for weeks, and arrived at the person who could act on it at the exact moment acting had stopped being possible.

Why asking more often doesn't help

The instinctive response is more contact — more check-ins, more reviews, more direct questions. In our conversations with 29 engineering leaders, the people doing this most diligently were not better informed. Several were worse off, for two reasons.

The question invites the answer

"How's it going?" is a social question before it is an informational one. The honest answer — "I'm less sure than I was last week, and I can't tell you exactly why" — is difficult to say out loud to someone senior, especially when you might be wrong, and especially when saying it triggers attention you'd rather not have. "Fine" is easier and usually turns out to be true. Until it doesn't.

Attention has a cost the team can feel

A head of engineering for a large server product told us plainly:

"Me jumping on an issue is threatening to engineers."

A leader who responds to every flicker of doubt with intervention teaches the organisation to stop flickering. The teams adapt: they raise concerns later, when they're certain, which is exactly when it's too late to be useful.

The real mechanism: summation

A group project manager described the underlying problem in three words — "human summation at every level".

Between the engineer who first notices something is wrong and the executive who needs to know the date is at risk sit two or three people. Each one summarises. Each summary is shorter than its input, and each is written by someone with a legitimate reason to present considered judgement rather than raw uncertainty — that is, after all, their job.

The compression isn't random. It systematically removes the same thing at every level: the doubt. "The integration is behaving strangely and I've lost two days to it" becomes "some risk on the integration" becomes "on track, minor risks being managed." Nobody has lied. The uncertainty has simply been rounded off three times.

A project manager gave us the numbers as he saw them:

"Ninety per cent of the time it's a direct update. Ten per cent embellished if the team is almost shipping the thing — leading to sugar coating."

Ten per cent doesn't sound like much. But it isn't distributed randomly — it clusters precisely on the projects that are in trouble, which are the only ones you needed the report for.

What actually changes the outcome

Three properties, which you can look for in any approach, tool or otherwise.

1. Go directly to the people doing the work

Every layer between you and the source is a place where doubt gets rounded off. A signal that comes from everyone on the team, rather than from one person's summary of the team, doesn't pass through summation at all. It also surfaces disagreement — and disagreement within a team is usually the earliest signal available.

2. Make the honest answer cheap

Most reporting formats make expressing doubt expensive. A project manager explained why traffic lights fail at exactly this:

"Switching a ticket from green to yellow is such a big step change that it sets off all the alerts. There is a cost to calling out problems."

If the only way to express growing unease is to trigger an escalation, people wait until they're certain. A scale — where moving from 4 to 3 is a small, private act rather than an alarm — lets doubt register while it's still early enough to matter.

3. Watch the trend, not the reading

A single measurement tells you almost nothing. The same team at 3.5 means one thing if it rose from 3.0 and something quite different if it fell from 4.5. Drift is the signal; the level is context.

How much warning does this actually buy?

Worth being straight about this, because it's the question that matters and it's easy to overclaim.

A confidence signal will not tell you that a project will slip by eleven days. It doesn't know that, and neither does the team. What it reliably surfaces is the gap between the plan of record and what the people doing the work believe — and that gap opens well before a date formally moves, because dates move only when someone is finally forced to admit the gap exists.

In practice this means you find out at the point where the team has become uneasy, rather than at the point where they've become certain. The distance between those two moments is the window in which changing scope, moving people, or moving the date is still a decision rather than a scramble.

How Genchi does this

Genchi asks every team member one question at a cadence you choose: how confident are you that we'll achieve our goal? Answered one to five, in Slack or email, in about two seconds.

Responses are aggregated before anyone sees them, so the team can be honest without anyone being individually identifiable. You see the distribution, the trend across recent check-ins, and any blockers people chose to raise. Across a portfolio, every initiative carries a current colour-coded signal, so the teams that need attention stand out without you reading anything.

The design follows directly from the research above: it goes to the whole team rather than one summariser, it makes registering mild doubt a two-second private act rather than an escalation, and it keeps a record so the direction is visible.