Latency is a business metric, not an engineering one 

For most of its life, our network performance reporting was a next-day product. An event happened, the pipeline ground through the night, and the numbers landed on someone's desk the following morning. Everyone accepted this. It was simply how long the data took.

That framing is the mistake. ~12+ hours of latency is not a technical characteristic of a pipeline. It is a decision about who in the organisation is permitted to respond to reality, and how late.

The ~12+-hour tax

When data is a day old, the shift that could have fixed the problem has gone home. The engineer who saw the anomaly is no longer on the console. The context that made the number interpretable (what changed, what was deployed, who was on call) has evaporated. What arrives the next morning is not information. It is archaeology.

So the organisation adapts. It builds a second, informal reporting layer out of instinct and phone calls. It escalates on hunches because the numbers are too slow to argue with. It over-provisions, because capacity is cheaper than being wrong in public. None of that appears on a latency dashboard, and all of it is paid for.

What ~15 minutes changes

We rebuilt the global data platform for the Network Services business unit around a single question: can the person who can fix this see it while they can still fix it? That put the target inside a shift, not inside a day. We landed at ~15 minutes.

The interesting outcomes were not the ones we wrote in the business case:

• Escalations became evidence-led rather than instinct-led, because the evidence arrived in time to be quoted.
• The informal reporting layer atrophied, and with it a large amount of unmeasured human effort.
• Capacity decisions tightened, because the cost of being wrong dropped along with the feedback loop.
• Teams started asking better questions, because a question you can answer within the hour is worth asking.

Benchmarks are a floor, not a target

There are industry specifications covering how performance data is exchanged, and they are useful right up to the point where they become the ambition. An interface standard describes how systems talk to each other. It does not tell you how late your business can afford to find things out. Those are different questions, and only the second one has a cost attached.

The right latency target is not the one a standard permits. It is the one that puts the decision back in the same shift as the event.

How to argue for it

Latency programmes are hard to fund because the benefit sits in other people's budgets. The engineering cost is concrete and yours; the savings are diffuse and theirs. That asymmetry kills more of these projects than any technical obstacle.

The argument that works is not about pipelines. It is about decision latency: name the decisions that are currently made late or made blind, put a cost against being late on each one, and show what the number becomes when the data arrives inside the window where the decision still exists. Then the conversation is about the business, and the pipeline is an implementation detail, which is exactly what it is.