Kingman’s Formula

A puzzle first. Your CPO signs off on the product decisions that need her, and she spends about 80% of her working time on that and work like it. Coding agents arrive, engineering ships faster, and the number of decisions headed her way goes up by an eighth. How much longer does each decision wait for her?

The intuitive answer is about an eighth longer. The answer from queueing theory is more than twice as long.

Kingman's Formula is the rule that explains the gap. It says the average time work waits in a queue grows with how busy the server is, divided by how idle it is, times how variable the work is, times how long each item takes. As a server approaches 100% busy, waiting time doesn't grow steadily. It explodes.

A telephone exchange, and a student who was told his math was useless

John Kingman got to queues through a summer job. As a Cambridge undergraduate in the late 1950s, he worked at the Post Office Engineering Research Station at Dollis Hill in London, in a small group that advised engineers on mathematics for telecommunications. When he told the head of the group he was interested in queueing theory, he was sent to read the back issues of the Bell System Technical Journal.

He came back with the classic results and was told, as he later wrote, "that much of the mathematical work was irrelevant to the real world." Most of it assumed customers are served in the order they arrive, and a telephone exchange of the time couldn't store waiting calls in order. So Kingman worked on a queue where waiting calls were picked at random. The exact solution was, in his words, "pretty uncomputable," but it had a useful approximation in heavy traffic, "when the traffic intensity is just less than its critical value." Then came the thought that set the direction of his early research: "This made me wonder whether there was a general phenomenon of robust approximation in heavy traffic, and so it turned out."

As a PhD student at Cambridge's Statistical Laboratory, he published the general result in 1961 as a three-page note, "The single server queue in heavy traffic," in the Proceedings of the Cambridge Philosophical Society. Its finding was that when a single-server queue runs close to full capacity, the messy details stop mattering. How long work waits depends mostly on how busy the server is and on how variable the arrivals and the service times are. Later textbooks wrote the approximation in a form now often called the VUT equation:

wait ≈ V × U × T

U  utilization factor     busy ÷ idle          ρ / (1 − ρ)
V  variability factor     how uneven the work  (ca² + cs²) / 2
T  time per item          the average time one item takes

Kingman went on to a long career in probability, and later ran the Isaac Newton Institute in Cambridge. The formula that carries his name became a staple of operations management, because it answers the question every manager of a busy resource asks: why did the line get so much longer when we only got a little busier?

One approver, five levels of busy

Here is the puzzle worked out. The numbers are illustrative. Say each sign-off takes the CPO half a working day on average, and both the arrival of decisions and the time each takes vary the way purely random events do. That's the textbook case where the variability factor is 1, and in it the formula isn't an approximation; it's exact.

Busy    Busy ÷ idle    Average wait before she starts on it
50%     1              half a day
70%     2.3            a little over a day
80%     4              2 days
90%     9              4.5 days
95%     19             9.5 days, about two working weeks

Going from 80% to 90% busy is an eighth more work. It more than doubles the wait, from two days to four and a half. Going from 90% to 95% roughly doubles it again. Nothing about the CPO got slower. She is doing the same work at the same speed, and the line in front of her is growing faster than her workload.

This is what our essay on the modern product development lifecycle describes when it says that as AI adoption spreads, "the work now piles up at the same review gates, waiting on people." The product development lifecycle isn't the software development lifecycle. Coding agents sped up Build, one stage out of seven. They didn't speed up the people who approve pricing, sign off on a launch, or settle a disagreement between two teams. They sent those people more work: more experiments needing a call, more specs needing sign-off, more questions about what was already decided. Every one of those is an arrival at a queue whose server didn't get any faster.

The other two letters

Utilization gets the attention, but the formula multiplies it by two other factors, and both are usually worse than the table assumes.

V, variability. The table assumed the textbook amount of randomness. Real decisions are lumpier. Decisions bunch up before planning and launches. Some sign-offs take ten minutes and some take a week of back-and-forth with legal. If that lumpiness pushes the variability factor from 1 to 2, every wait in the table doubles, and the 90% row becomes nine days instead of four and a half. A weekly decision meeting makes this worse in a quiet way: it turns a steady stream of decisions into one batch a week, and batching raises the variability of arrivals.

T, time per item. Each sign-off's half a day isn't all judgment. A lot of it is reconstruction: finding the Slack thread, reading the spec, working out who already agreed and what this decision touches. T appears in the formula twice, which is the part people miss. It multiplies the wait directly, and it's part of utilization, because utilization is arrivals times time per item. Cut T and you lower both factors at once.

That double effect makes T the strongest lever in the formula. In the 90% row, if each sign-off took 20% less time, the CPO would be 72% busy instead of 90%, and the average wait would fall from four and a half days to about one.

Where Brief fits: working all three factors

Brief is the product strategy agent, and the approver's queue is where it does some of its most direct work. As the homepage puts it, Brief "works across all product stages, not just Build. It captures decisions where they happen, connects them into one graph, and acts on them." Read against Kingman, each part of that maps to a factor in the formula.

The queue becomes visible. You can't manage a queue you can't see, and a decision queue usually lives in inboxes, DMs and someone's memory. Brief keeps proposed decisions separate from recorded ones, and the decision list filters by status, so what's waiting is one filter away. Coding agents can call brief_list_pending_decisions for the same list. The homepage's example is D-241, a seat-based pricing decision "waiting on CPO sign-off since Sep 26," with an owner and four linked sources. In the same example, the CPO's weekly brief leads with D-241 under Needs your decision and shows the three launches holding on it, slipping three to five weeks. That's the cost of a wait, put in front of the one person who can end it.

Fewer arrivals reach the busiest person (U). Not every arrival at a CPO's desk is a decision. Many are questions about decisions already made, or about who should make one. On the homepage, an engineer asks on a Jira ticket why it can't ship, and Brief answers with the three decisions that apply, including the pending one. When the engineer asks who can sign off, Brief names the owner. Neither question became a meeting. When a decision does need to be made, a proposal can name Who should decide?, so it goes to the right owner, not by default to the busiest person in the room. Our PDLC essay describes the end state as companies redesign around agents: "Material decisions go to a named owner, routine ones stay with the team."

Rework doesn't come back as new work (U again). Build moving faster than its decisions is how rework starts: code written against a pricing model nobody approved comes back as another decision, another review and another meeting. Coding agents connected over MCP call brief_ask before they write code. In the homepage example, an agent asked to add per-seat pricing learns that D-241 is pending, holds the change, and flags a related security review. From a terminal or CI pipeline, brief ask --mode check checks a proposed change against existing decisions. Each held change is one rework arrival the approver never sees.

Each sign-off starts with context (T). A proposal in Brief can carry its context and considerations, its sources, and a Re-evaluate when condition. Decisions can be proposed where the discussion happens: /propose in Slack creates one from a question, and Brief may propose a structured decision from a conversation when you mention @Brief. On the homepage, the CPO's brief tells her that finance and sales already signed off in #product-leads on Sep 26. The half day she would have spent reconstructing that is the T in the formula, and it's the one factor that shrinks the wait twice.

Decisions flow instead of batching (V). A decision proposed in the thread where it came up enters the queue when it's ready, not on Thursday at the weekly meeting. That doesn't make decisions arrive evenly, and nothing will. It removes one source of bunching that the organization created for itself.

None of this makes a CPO decide faster, and Kingman's math wouldn't expect it to. The judgment in a sign-off is the irreducible part of T. What the formula shows is that the judgment is rarely what makes decisions wait. The waiting comes from utilization near the top of the curve, from batching, and from the time spent rebuilding context before the judgment can start. Those are the parts Brief works on. At 90% busy, every hour taken out of a sign-off, and every question answered without reaching the approver, buys back far more waiting than it costs.

How busy is the person your decisions wait for, and what happens to everyone downstream when the agents add another eighth?

Objections