A primer on agreeing the target before buying the dashboard
Agreeing the target before buying the dashboard from the start, for a room that contains both engineers and the people who'll live with it.
Most write-ups of this start in the middle. We'll start earlier than strictly necessary, because nine times in ten the confusion comes from a word two people are using differently, not from the mechanism.
A dashboard without an agreed target is decoration. It shows a line going up or down and leaves the interpretation to whoever's in the room, which means the interpretation changes with the audience.
GRAPHS DON'T DECIDE ANYTHING
Put a latency graph on a wall and you'll get two readings of it. Someone will see a spike and worry; someone else will see the average and relax. Neither is wrong, because nothing has been agreed about what good looks like. The graph can't settle it.
A target settles it. Not because the number is scientifically correct, but because it was agreed in advance by people who weren't yet under pressure. That's the entire value: it converts an argument during an incident into a fact you established when everyone was calm.
PICK THE MEASURE PEOPLE FEEL
Most systems measure the thing that's easy to instrument rather than the thing anyone experiences. Server-side response time is easy. Whether a person got their answer in a reasonable time is what matters, and those come apart badly once retries, queues and client rendering are in the path.
Ask what the person on the other end would complain about, then find the closest thing you can measure. It'll be less tidy than a server metric and considerably more useful.
Made concrete: a sample chain of custody passes through several pairs of hands, and each of them believes it owns the record. What's above is how you let all of them be right without letting any of them silently overwrite the others.
A TARGET YOU'D ACTUALLY MISS
The number should be one you could plausibly fail, or it teaches you nothing. A target you've never come close to breaching isn't a target, it's a compliment. And it means you have no idea how much headroom you have.
It also has to have a consequence attached. If missing it doesn't change what gets worked on next month, it's not a target, it's a note. That's usually the harder conversation and the one worth having.
Picture an environmental testing lab at around 20,000 samples a month. The naive version works perfectly in testing and falls over the first day two lab managers touch the same sample chain of custody in the same second.
WHERE IT GOES WRONG
- A missed target with no consequence, so the number is decorative by the second quarter.
- A wall of graphs and no agreement about which of them would justify stopping feature work.
- Measuring server-side latency while users experience retries and client rendering.
- A target so generous it's never been breached, teaching you nothing about your headroom.
Agree what good means before you buy something to display it.
THE SHORT VERSION
None of this is advanced. It's ordinary practice that gets skipped when a date is close, and then paid for with interest by whoever's on call.