Pick the Decision. Latency Answers Itself.

A VP of operations at a mid-market services company spent six weeks of engineering hours getting a pipeline dashboard to update in real time.

Websocket plumbing. A streaming layer in front of the data warehouse. Two engineers pulled off other work to make the numbers move the second a job status changed in the field. Real-time. “The team needs to see what’s happening right now,” she told me. “We can’t be making decisions on yesterday’s data.”

I sat in on the Monday ops call where the dashboard was finally being used. The meeting opened. She pulled up the screen. The team walked through pipeline numbers, technician load, jobs at risk. The numbers were live. Nobody touched the page for the next forty-five minutes. The decisions they made were the same decisions they had been making off the daily roll-up since the year before.

Same shop, sister scene, three months earlier. A regional ops director at a different client sat in front of a daily-refreshed dashboard while a backed-up dispatch board burned down for ninety minutes. She did not know to check it until the daily refresh fired at six the next morning. By then, six service windows had slipped and the customer-callback queue had doubled.

Two dashboards. Two failures. Opposite directions. Same root cause.

The argument nobody is having on a whiteboard

Here’s the thing. Most teams treat the real-time vs. delayed question like it is a tooling decision. “How fresh can we get the data?” Engineering quotes the price. Leadership weighs it against the budget. Somebody picks a number. Pipeline dashboards refresh every six minutes, or every six hours, or every six seconds, depending on which side of the meeting lost.

That is the wrong meeting.

The latency on the dashboard is not a tooling decision. It is a downstream artifact of a different decision that almost nobody is naming out loud. What is this dashboard for? Not in the slide-deck sense. In the precise sense. What decision does a person make when they look at this screen? How often does that decision happen? What is the cost of being wrong by a minute, an hour, a day?

You answer those three, and the latency picks itself. You skip them, and you end up either commissioning a real-time stream for a decision you make over coffee on Monday morning, or running a daily refresh on a fire that needed a human in the room within ninety minutes.

Same word on the dashboard. “Pipeline.” Two completely different jobs.

The two columns of the Prep List that decide this

Here’s the thing. We have a tool for this. We call it the Prep List. It’s a scorecard you run on any candidate system you are thinking about handing to AI, automation, or a freshly-built piece of internal tooling. Score the system 1 to 5 on four dimensions. Repeatability. Volume. Definability. Reversibility. Add them up. The top of the list is what gets built first.

For dashboards, two of those columns do almost all the work, and they are the ones nobody on the engineering side ever looks at.

Definability is the first column. Can you describe what “this dashboard supports a good decision” looks like, in one sentence, before any code gets written? If yes, this dashboard has a job. If no, it does not have a job, it has a wish. Most dashboards in most operations are wishes. “I want to see what’s going on.” That is not a decision. That is a vibe.

Repeatability is the second column. How often does the decision the dashboard supports happen? Weekly ops review. Daily standup. End-of-shift handoff. The moment a high-value customer escalation lands. The answer to “how often” is the answer to “how fresh does the data need to be.” The decision sets the cadence. The cadence sets the latency. You do not back-derive a decision from a refresh rate you already paid for.

A weekly ops review tolerates four days of latency, easily. The data has been over for half a week. The team is not making the call again until the following Monday. Real-time numbers on a screen they look at once every seven days is a waste of every dollar engineering spent on the streaming layer. The Prep List, run on the system honestly, would have scored Repeatability as a 2 and Definability as a 1, and the verdict would have been “keep with the Chef.” Translation. Do not build this. The decision is not ready.

A dispatch escalation, on the other hand, scores Repeatability as a 5. It happens many times a day, in the same shape. And it scores Definability as a 5. Everybody in the building knows what “this is on fire” looks like. A daily-refreshed dashboard for that decision is the opposite mistake. Now you have under-built. The decision needed hourly information, and the system gave it whatever was true at six in the morning.

The two failure modes are not symmetric in cost, but they are symmetric in cause. Both come from skipping the Definability and Repeatability conversation and going straight to the latency question. They are literally the same operator habit, dressed in opposite costumes.

What “we need real-time data” actually means

I want to be careful here because the VP of operations was not careless. She had read a piece somewhere about real-time data being the modern standard. She had heard a peer at another company brag about their streaming dashboard at a conference. She walked into the engineering conversation with a posture that sounded like leadership. “We need to be making decisions on what is true right now, not what was true yesterday.”

That sentence is unobjectionable in the abstract. It is also where the operator habit lives.

You haven’t named the decision the dashboard supports.

Once you name it, the sentence either holds or it does not. “We need to be making decisions on what is true right now” is true for a dispatch supervisor watching twenty-three jobs at three in the afternoon. It is not true for a VP scrolling pipeline numbers during a Monday ops call. The same sentence, two decisions, two completely different latency answers. The mistake was treating the sentence like it had one answer.

The same mistake shows up in the inverse. The regional ops director who missed the escalation window did not undershoot on purpose. She had inherited a tool that refreshed daily. Nobody had ever asked, when the tool was commissioned, what decision does this support and how often does it happen? The default refresh cadence got chosen by whoever wrote the data pipeline, on a day when nobody on the operational side was in the room. The cost showed up months later, the first time the decision really mattered.

A dashboard is a system the way a recipe is a system. It only works if you can say what plated well looks like before you start cooking. If you cannot describe the decision the dashboard exists to support, you cannot describe what plated well looks like, and the latency question is a question with no anchor. You can pick any answer and defend it, because there is no decision the answer has to serve.

That is the work that gets skipped. Right? The question feels too basic to ask out loud in front of engineering. Of course we know what this is for. We are looking at pipeline. Nobody wants to be the one in the room saying “but what decision, specifically, do you make from this screen, and how often.” And so the question never gets asked, and engineering builds whatever was on the requirements doc, and the dashboard ships with a latency that was never tied to a decision.

The sister failure mode worth seeing once

This is the same root system as The Dashboard Delusion, where the question was am I measuring the right thing? That piece sits on Ingredient #6 of the Professional Recipe. This piece sits one frame back. Before you measure the right thing, you have to know what decision the measurement is supposed to feed. The latency question is the second-order version of the same conversation. What decision, how often, how reversible.

It is also a cousin to Three Handoffs at Ninety Is Seventy-Three. Same operator habit, different shape. You spent a budget you never named. That post named accuracy budgets. This one names latency budgets. They both come from the same place. You did not write down the spec before you ran the system, so the system spent the budget invisibly.

Yeah. There it is.

The Monday move

Pick one dashboard you have. Any one of them. The one in the ops review, the one in the morning standup, the one you opened twice this week and could not say what for.

Write down one sentence. This dashboard exists to support the following decision. Then a second sentence. That decision happens roughly this often.

The latency requirement just defined itself. Anything tighter than what the decision needs is overspending. Anything looser is undershooting. The dashboard you have is either right-sized, over-built, or under-built, and you can tell which one in about ninety seconds without writing a line of code.

If you cannot finish either sentence in plain language, the dashboard does not have a job yet. It has a wish. The fix is not engineering. The fix is a thirty-minute conversation with whoever actually uses it about what decision it is supposed to feed and how often. Most of the time, that conversation ends with somebody saying “oh.”

Does that make sense? That oh is the work.

Pick the decision. Latency answers itself.

Original framework. Distilled from client work and the meeting where the concept clicked.

Framework spine: The Prep List, specifically the Definability and Repeatability columns. Read the full framework. Sister piece: The Dashboard Delusion. Cousin piece: Three Handoffs at Ninety Is Seventy-Three.