Reading a public sector casework system through agreeing the target before buying the dashboard

We inherit systems more often than we start them. This is how we read one: what we look at first, and what each thing tells us about decisions made by people we'll never meet.

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.

The exception handlers were the most honest documentation in the repo. Every branch that swallowed an error marked a spot where caseworkers had once been paged and somebody had made it stop.

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.

The schema told the real story. Three nullable columns added in one migration, all named after a case record field, all populated for precisely the weeks when a statutory clock was missed because the case had two owners was an open ticket.

WHERE IT GOES WRONG

• 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.
• A missed target with no consequence, so the number is decorative by the second quarter.

Agree what good means before you buy something to display it.

THE VERDICT

Better than its reputation. Most of what looked like bad engineering turned out to be a sensible answer to a constraint that had since been lifted, and nobody had gone back to check.