Observability Is Not Surveillance

Two dashboards, same data, opposite outcomes. We have watched this happen enough times that it is no longer a coincidence, it is a pattern.

The first one is owned by a platform team. It tracks review wait times, build failures, cycle time, how often an outage gets reopened. The engineering manager opens it when the pipeline stalls and asks only one question, which is whether the system is healthy. When the dashboard shows a problem, the conversation moves to capacity, to dependencies, to whatever changed in the work. Nobody on the team covers their screen when that dashboard is up.

The second one is owned by the same kind of company, and it tracks almost the same rows. It tracks activity per person, active minutes, idle gaps, how many times someone was away from the keyboard. The engineering manager opens it and asks whether the team is actually working. When the dashboard shows a problem, the conversation moves to a person, to whether they are pulling their weight. The entire team knows that dashboard exists, and the entire team has adjusted to it. Meetings got slightly longer. Faces got slightly more present. Work got slower.

Here is the strange thing. The two files on disk probably look identical. A table of numbers with a name attached. The difference was never the rows. The difference was what the rows were allowed to claim.

The boundary is a claim about a person

Most engineering organizations believe the boundary between observability and surveillance is a privacy question. It is not. It is a question of scope, and scope has a sharp edge.

Observability ends at the moment a collected signal is allowed to make a claim about an individual. Before that line, the numbers describe a system, its load, its failure modes, its health. After that line, the numbers describe a person, their effort, their worth, their slack. That line is not a privacy slider. It is a category change. You can collect every byte a system produces and still be doing observability, as long as every sentence you are permitted to draw from it is a sentence about the system and never about the person.

The trouble is that the line is invisible in the data itself. A row for review wait time belongs to observability the day you read it as team load, and becomes surveillance the day you read it as proof that one reviewer was slow. Same pixel. Different claim. That is why so many tools drift over the line without anyone noticing. The drift does not happen in the database. It happens in the question the dashboard is built to answer.

Why the drift feels so reasonable

Start with the honest admission that measuring is seductive. Once you see a number go up, you want it to go down, and the fastest way to make a number move is to attach it to a person and make them feel it. This is exactly how a healthy engineering metric turns toxic, and it happens in four quiet steps.

First, you take a system metric and break it down by person. Review wait time becomes per reviewer. Cycle time becomes per engineer. This feels like fairness, but it is not, because systems are the thing being measured and systems are shared.

Second, you move the unit of truth from the metric to the trend. Now a single bad day on a noisy chart is framed as a decline, and a decline is framed as a fact about the person rather than a sample.

Third, you attach an expectation. The manager does not say the system is under load, they say we need this person to be faster. The dashboard stops describing and starts instructing.

Fourth, you close the loop with a consequence, or even a rumored one. And once the consequence exists, the data is no longer a measurement of anything. It is a contract everyone learned to perform against. The dashboard only shows behavior that has been shaped by the dashboard. That is not observability. It is a game, and games have losers.

Every step feels like a small, reasonable improvement. That is what makes the drift invisible. You are never one decision crossing a line. You are four decisions, each of which sounded like good management at the time.

What the metric is allowed to claim decides everything

The cleanest way we have found to hold the line is a single rule, and it is worth stating plainly.

A measurement is observability if its best explanation is about the system. It is surveillance if its best explanation is about the person.

Take the same number and test both readings. If review wait time rises and the deeper story is that the team was reorganized, the dependency migrated, the spec was late, then the number is doing its job. It pointed at a system problem you can change. If the number's only story is that this one person is slower, then the number has quietly started governing people, and every fix you build from there will be a fix about the wrong thing, a fix that makes the dashboard happier without making the work healthier.

Here is the practical test that catches the drift early. When you act on a dashboard, name the sentence your action was based on. Then read that sentence back to the team out loud and ask a brutal question. Does this sentence blame a system, or does it blame a person? If you cannot say the sentence without flinching, the dashboard has crossed the line, and the crossing happened the day the number was allowed to make that claim, not the day someone acted on it.

The deeper cost of cheap measurement

There is an even more important reason to hold the line, and it has nothing to do with employee happiness, important as that is. It is about destroying the very signal you were trying to read.

Here is what nobody says out loud. The moment a measurement becomes a target people can feel, it stops measuring. A review time dashboard that gets used to shame people will produce faster, worse, angrier reviews, and then a dashboard full of small green numbers that describe nothing but fear. A presence tracker will produce more presence and less thought. An activity rank will produce a team that games clicks and loses the deep work that made the team valuable in the first place.

The signal does not just get distorted. It gets erased. You spend the whole year watching a dashboard that has become a performance, while the actual health of the system, the reason you built the dashboard, quietly rots underneath it, invisible because everyone is busy being watched instead of watching the work.

That is the real argument against surveillance, and it is not a moral one. It is that surveillance is a self defeating measurement strategy. It kills the thing it measures.

The uncomfortable conclusion

Observability and surveillance are not the same thing wearing different labels. They are opposite uses of the same data. One is the discipline of finding the cause of a system problem. The other is the habit of treating a system problem as if it were a personal one, which guarantees you never find the cause, because there is no personal cause to find.

We think the right instinct is not to monitor people less because it feels uncomfortable. It is to monitor systems more, because that is the only monitoring that is honest, that does not erase its own signal, and that actually finds the thing worth fixing.

Before you ship your next engineering dashboard, or before your existing one gets one more per person column, ask the one question this post keeps coming back to. What is the strongest sentence the dashboard is allowed to produce? If that sentence can name a person, the dashboard has already decided who to blame. If it can only name the system, you are doing the work of finding the cause, which is the work that actually fixes things.

Try it this week

Open your engineering dashboard and read its three most prominent charts out loud as statements. Write down what each one actually claims about the team. Then sit with an engineer for an hour, or with yourself if you are the one who built it, and ask whether the team would be comfortable having that claim read in a room they are not in. If the honest answer is no, you do not have an observability problem, you have a surveillance problem, and the dashboard is not broken, it is working exactly as it was designed to.

Finding the cause is our daily work. And the first cause worth finding is the one hiding inside your own dashboard.