You Have Real-Time Observability on Your Servers. Why Not on Your Business?

In roughly a decade, engineering organisations went from monitoring systems to observing them. The distinction sounded academic when it was proposed and turned out to be the difference between knowing something broke and knowing why.

Monitoring answers questions you thought to ask in advance. You decide what matters, set a threshold, and get told when it is crossed. It works well for known failure modes and not at all for unknown ones — and in a complex system, most failures are unknown, because they emerge from interactions nobody predicted.

Observability is the property of a system being instrumented densely enough that you can ask new questions of it after the fact, without shipping new code. You are not watching a fixed set of alarms. You are able to interrogate the system's actual state.

Every executive reading this has real-time observability on their infrastructure. Almost none has it on the business that infrastructure exists to serve.

The translation is closer than it sounds

Three ideas from engineering observability port directly.

High cardinality. Infrastructure observability got useful when it became possible to break a metric down by dimensions you had not pre-aggregated — this customer, this region, this version. Business reporting is still overwhelmingly pre-aggregated. You get revenue by segment because someone built that view. Asking for revenue by segment, by tenure of the account manager, for accounts that changed owner in the last two quarters, is a data project rather than a query.

Correlation across services. The value of a distributed trace is that it follows one request across every service it touches, revealing that the slow checkout is actually a slow authorisation call three hops away. Organisations have the same problem and no equivalent instrument. The revenue miss originated in a recruiting decision made eleven months earlier, and nothing in the reporting stack connects those two facts because they live in different functions with different systems and different owners.

Continuous rather than periodic. Nobody would accept infrastructure telemetry delivered monthly, fifteen days in arrears, formatted as a slide. That is the standard reporting cadence for the business itself.

You would not run a payments system on a monthly report. You are running the company that owns it on exactly that.

The sensor engineering never needed

Here the analogy breaks, and the break is the interesting part.

A server has no opinion about its own state. Every fact about it is machine-emitted, which is why infrastructure observability could be built entirely from telemetry. An organisation is not like that. A large share of what determines its near-term performance exists only as human judgement: whether the sales team believes the forecast, where operations staff hit friction, whether leadership privately doubts the strategy they publicly endorsed.

Call that human sensor data. It is generated continuously by everyone in the company, captured almost never, and it moves earlier than anything in the financial record — because financial statements record transactions that already closed, while confidence and friction change the conditions that produce those transactions.

An observability practice that instruments only digital telemetry reproduces the existing blind spot at higher resolution. It has to instrument both.

A minimum viable version

For a company of a few hundred people, this is a quarter of work, not a platform migration.

Pick four questions whose answers would change a decision, and which no current report answers. Write them down before looking at any data, so the instrumentation serves the questions rather than the reverse.

Establish one human sensor stream. A short recurring pulse to a defined population, same questions every time, tagged to function and process. Consistency matters far more than sophistication — you are building a trend line, and a crude measure tracked consistently beats a sophisticated one tracked once.

Make one cross-function join possible. Choose the two datasets that have never been readable against each other and make them so. The first genuine correlation you find will pay for the exercise.

Shorten the cadence before adding sources. Weekly beats monthly more than a new data source beats the absence of one.