What do I do when the trend goes down?

Why this question matters more than the measurement

Two of the engineering leaders we interviewed asked essentially the same thing, and neither was asking about the tooling:

"How do I know when there is a problem, and what do I do about it?"

"What do these trends mean? How do I act on it for good?"

A signal nobody knows how to act on is a dashboard, and dashboards get ignored. Worse, a signal acted on badly is actively harmful — it trains the organisation to stop producing it. So it's worth being specific about what each pattern means.

First: variation is normal

Before reading anything into a decline, it's worth being clear that movement is the expected state. Every project encounters problems and resolves them. A team that hits a hard integration issue on Tuesday and finds a way around it on Thursday should show a dip and a recovery — that's the signal working, not the project failing.

Real delivery isn't green all the time, and a team that reports as though it were has either stopped taking the question seriously or has learned that anything below green causes trouble. Both are worse positions than a project with visible ups and downs.

So the skill worth developing isn't reading the number. It's distinguishing "not good" in a business-as-usual way — the ordinary state of a project where people are finding and solving problems — from "not good" in a we-need-help way. Both look like a decline. Only one needs you.

The practical consequence: your job is awareness, not reaction. Most dips need nothing from you beyond noticing them. What you're watching for is the minority that don't recover on their own — and you can only distinguish those from ordinary variation if you have enough ordinary variation to compare against.

This is also the answer to the micromanagement worry. Seeing every team's signal doesn't oblige you to act on every team's signal. Knowing is not intervening. The value of the portfolio view is that it lets you leave the healthy teams alone with more confidence, not that it gives you more to chase.

Three shapes, three responses

A gradual decline

Four consecutive check-ins moving 4.4 → 4.2 → 3.9 → 3.6.

This is the most valuable pattern and the easiest to miss, because no single week looks alarming. It usually means something is going wrong slowly: scope creeping, an estimate that was optimistic, a dependency that keeps almost arriving, or accumulating small problems none of which justifies raising a flag.

What it warrants: a conversation, not an escalation. This is what a one-to-one with the team lead is for, and the useful question isn't "why is the number down" — which puts them on the defensive about a number they didn't individually produce — but "what's changed in the last month?"

What it doesn't warrant: a review, a recovery plan, or an executive update. A gradual decline is early. Treating it as a crisis converts a cheap intervention into an expensive one and guarantees the next decline gets hidden.

A sharp drop

4.3 last week, 2.8 this week.

Something happened. A discrete event — a failed integration, a departure, a scope change imposed from outside, a load test that went badly. Somebody on that team knows exactly what it was.

What it warrants: asking, promptly and directly. One leader described exactly the right move: "When you feel that something is blowing up you'd be able to sit down with the team leads and figure out next actions." Any attached comments or blockers usually tell you before you ask.

Worth noting: a sharp drop is often less concerning than a gradual one. It means the team recognised a problem and registered it immediately, which is the system working. The gradual slide is the one where nobody has yet named what's wrong.

One person diverging from a confident team

Five people at 4, one at 2.

The most commonly ignored pattern, and often the most valuable. Sometimes it's noise — someone having a bad week, or new to the project. Sometimes it's the only person who has looked closely at the thing that's about to break.

The value here comes directly from anonymity. In a meeting, that person would probably have stayed quiet; disagreeing with the group's confident mood is expensive, particularly when you can't fully articulate why yet.

What it warrants: curiosity, and no attempt to identify who it was. The productive move is to ask the team lead whether there's a part of the work that's less well understood than the rest — not to hunt for the dissenter. Chasing the individual destroys the mechanism that produced the signal.

What the signal doesn't tell you

It doesn't diagnose. It's a smoke detector, not a diagnosis — it tells you where to point your attention and nothing about the cause. Any conclusion you reach about why comes from a conversation, not from the number.

It also isn't a performance measure. A team that reports declining confidence is doing exactly what you asked. Treating a low signal as a reflection on the team, rather than information from the team, is the fastest way to never see a low signal again.

The failure mode to avoid

One head of engineering, responsible for a large product line, told us something that should be pinned above any portfolio dashboard:

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

This is the central risk of any early-warning signal. If a dip reliably produces a senior leader appearing with questions, the team learns that dips are expensive, and the numbers become smooth. You'll have built an elaborate mechanism for measuring what people think you want to hear.

Two habits that prevent it:

• Route through the team lead by default. Your response to a declining trend should almost always be a conversation with one person, not an appearance in front of the team.
• Sometimes do nothing visible. Not every dip needs a response, and most don't. Watching a decline for another cycle is a legitimate choice, and letting teams see that you don't panic at amber is what makes the next honest signal possible. Intervene when the team needs help — not every time you notice something.

Another leader described the opposite failure — attention going to the wrong places: "We waste a lot of cycles on projects that are in the green, but we want to talk about the red projects." A portfolio signal should let you spend less time on the healthy ones, not more time on all of them.

What about false positives?

A fair question, asked directly in our research: "How are you going to manage false positives? How are you going to manage false negatives?"

Both exist. A team can dip because of something unrelated to delivery — a difficult week, a reorganisation, an unpopular decision elsewhere. And a team can stay confident about something that fails anyway, which is a false negative and the harder of the two.

Two things reduce the noise. The trend matters more than the reading, so a single anomalous week resolves itself. And the response to a signal is a conversation rather than an action, so the cost of a false positive is a ten-minute discussion — not a recovery plan.

False negatives are the real limitation, and worth stating plainly: if the whole team is confident about something that fails, this measurement will faithfully report their confidence. It measures belief, not reality. What it reliably catches is the gap between what the plan says and what the people doing the work believe.

How Genchi presents this

Each initiative shows the current aggregated score, the distribution of recent individual values, and the trend across the last several check-ins — so the three shapes above are visible at a glance rather than needing reconstruction.

Comments and blockers appear alongside, attributed, because a blocker needs an owner. Across a portfolio, colour-coding means the initiatives worth a conversation stand out without you reading anything.