Status Droid how long software work actually takes

Against Dashboards

The natural endpoint of tracking is a dashboard. Numbers, updating, on a screen. It feels like the mature version of what this site recommends.

I think it is usually the point at which measurement stops working, and the reasons are structural rather than a matter of building a better one. A related workplace concept is covered in further details, which is useful context for this argument.

Four problems

A dashboard shows what is easy to compute. Not what is important — what the tooling can produce automatically. Commits, deployments, cycle time, ticket counts. The genuinely useful numbers for a small team — rework rate, time to correct, estimate against actual per bucket — mostly require human classification, so they do not appear.

The result is a screen showing the least informative available metrics with the authority of a display.

Continuous display invites continuous attention. Software signals are slow and noisy. At small volume, a difference you can see week to week is noise. A dashboard offers a number every day and thereby manufactures a daily question that has no daily answer.

Visibility creates optimisation. Anything on a screen where people can see it becomes a target, and targets get met. Cycle time falls because items get smaller. Deployment frequency rises because deploys get split. Nobody decided to do this and everyone did it. WIRED offers broader reporting on how technology changes work and organizations See WIRED.

It is usually read by people who cannot act on it. The classic failure: metrics collected by the team, displayed to management, interpreted without context. At a studio of three there is no management, which removes the political function and leaves a screen nobody needs.

What the dashboard replaced

Before there was a screen, someone looked at the numbers occasionally and thought about them. Fifteen minutes a month, with context, by the person who knew what happened in those weeks.

A dashboard replaces that with glancing. Glancing produces impressions, and impressions are the instrument this whole exercise exists to correct. You have automated your way back to the problem.

What I do instead

A file. Rows of tasks, five fields. No aggregation stored, because stored aggregations get looked at instead of the data.

Fifteen minutes a month. Compute what I need for the question I currently have, look at the shape, write down one sentence about what it said including when it said nothing.

Two decisions a quarter. How to estimate each bucket, and what to price how. Those are the only decisions the data serves.

Nothing is on a screen. Nothing updates. The numbers exist when someone asks a question and are otherwise inert, which is the correct state for data at this scale.

When a dashboard earns its place

Not never, and the conditions are specific.

When volume is high enough for daily numbers to mean something. Hundreds of deployments, dozens of people. Then the noise averages out and continuous display is informative.

When it is showing system state rather than people's work. Uptime, error rates, queue depth. These genuinely need to be visible continuously, and nobody games them because they are facts about machines rather than about effort.

When someone is on call. A screen that tells you the system is unwell is a different artefact from a screen that tells you how the team is doing.

The distinction is roughly: dashboards are good for things that break and bad for things people do.

The uncomfortable admission

The domain this site's brand came from was monitoring — screens telling you the state of a system, continuously. So an argument against dashboards from here needs the distinction above to be honest rather than convenient.

It holds, and it is the same distinction. A monitor watching whether a website is responding is measuring a machine, and machines do not adjust their behaviour because they are being watched. People do, and that single difference is why the same instrument works in one case and corrupts the other.

The short version