I first published a version of this piece on LinkedIn in 2021, when the argument ran on Weinberg’s table and Kniberg’s prioritisation illustrations alone. They carry the “don’t do everything at once” point well enough. What I have built since is a working Cost of Delay tool over a 1,470-story engineering portfolio, grounded in Don Reinertsen’s Principles of Product Development Flow—the source of both the cost-of-delay economics and the WSJF / CD3 prioritisation heuristic—and the practical cost-of-delay work of Joshua Arnold, who did as much as anyone to turn it into something teams actually use. The “cost of delay” is no longer a rhetorical lever for me; it is a number per story per month, and it changes which conversation is worth having on a Monday. Also, the Cost of Delay work has shown me that most of the value comes from focus, not necessarily getting the prioritisation perfect.

Gerald Weinberg’s book “Quality Software Management: Systems Thinking” is more than 30 years old. While it’s not one of the most highly-read and recommended classics in the adaptive canon, it’s the source of a frequently quoted table of data:

Weinberg's Table 2-1, waste caused by project switching: at five simultaneous projects, 75 percent of working time is lost to context switching

Weinberg, Gerald M. (1992) Quality Software Management: Systems Thinking. Dorset House, p. 284.

Visualised as a graph, the waste caused by context switching really stands out:

Bar chart of Weinberg's data: working time per project collapses from 100 percent to 5 percent as simultaneous projects rise from one to five, while switching waste climbs to 75 percent

Worse, the waste caused by project switching isn’t due only to the losses related to cognitive overhead. Failure to prioritise often leads to less revenue and even building the wrong product.

(Credit where credit is due: I first saw a version of the following illustrations presented by Jeff Sutherland, who adapted it from Henrik Kniberg. I’ve created new illustrations and expanded on them a bit. Kniberg’s own video on this exact topic is very much worth a watch.)

Let’s suppose your company wishes to ship three products: A, B, and C. To ship a product, a development team must complete tasks 1, 2, and 3 corresponding to that product:

Three products A, B, and C, each shipping once its three tasks are complete

Most companies are not very good at prioritising work. As a consequence, the prevailing belief is: “Everything is important. Get started on everything immediately!” The traditional delivery timeline might look like this:

Traditional interleaved timeline: tasks alternate A1, B1, C1, A2 and all three products ship together in early summer

Depending on your software and how you break down your work, your roadmap probably looks like:

Roadmap view: products A, B, and C all in flight from January to July, overlapping the whole way

Either way, notice that we are interleaving each task and that products A, B, and C are ready at roughly the same time, several months after we started.

The adaptive approach is very different. Instead, we proactively prioritise the work and focus on limiting our work in process:

Adaptive timeline: Product A ships in late January, B in early March, D in early April

There are at least three significant advantages to this adaptive approach: lower cost, more revenue, and better product/market fit.

Lower cost of development

We lose 20% or more of our productivity in the traditional approach due to context switching waste. In this example, the company could go about twice as quickly if they switched to developing one product at a time instead of three.

The interleaved timeline with the context-switching overhead marked on task A1

More revenue, earlier

The switching waste is the smaller loss. Because we have nearly finished products B and C before finishing A, we had to do nearly three times the work (not including the context-switching waste) before we could ship Product A (in late May). Had we prioritised and focused, we would have been able to ship Product A in early February. Had we done so, we may have been able to collect revenue and feedback from our customers starting nearly four months earlier. In fact, the savings from not context-switching between projects may mean that we could ship products A, B, and C before we would have been able to ship just A in the traditional model.

Comparison of the two timelines: Product A ships in early February under focus instead of late May under interleaving

Better product/market fit

Products are rarely independent, and building the wrong product can be costly. In this example, we believed before starting the work that the customer needed Product C. We took the adaptive approach and built A (more valuable and/or cheaper) first. When we delivered A to our customers in early February, we learned that they liked it a lot and didn’t need C after all. Instead, they wanted us to work on D. We took February to finish most of B and get the initial prototypes for D built.

Adaptive timeline where early customer feedback replaces Product C with Product D

We can see that prioritisation and focus serve everyone: developers, stakeholders, and customers.

Good prioritisation is not a zero-sum game

Further, good prioritisation is usually not a zero-sum game. Many stakeholders will argue aggressively for their product to be worked on right away (and it’s no surprise: they may even have a bonus tied to it being completed by a certain date). However, the waste caused by project switching and the cost of delay is so significant that failure to prioritise may make all stakeholders worse off. In this case, the stakeholders behind projects A, B, and C agreed to prioritise based on the cost of delay and all were better off than if they had insisted that everyone’s work be tackled at once.

The same three epics, priced

Five years on, this argument became software. The infographic below, from my current delivery-intelligence work, prices the same scenario with cost of delay: keeping all three epics in flight collects $42.50 of value by the end of July; finishing one at a time collects $138.75 in the worst order and $176.25 in the best. That is roughly 3–4× the value, and the ordering mattered far less than the focus.

Infographic pricing the same three epics with cost of delay: $42.50 with all three in flight; $138.75 to $176.25 finishing one at a time

Feel it in five minutes: the character factory game

You don’t have to take my word for any of this, or Weinberg’s. Grab a pen, a sheet of paper with three columns, and a one-minute timer. Three customers each want a complete set of 25 characters—letters, numbers, vowels—and nothing partial counts. Round 1: keep all three orders moving by writing one character for each customer in turn. Round 2: finish one customer’s set before starting the next. One minute each. (The game is after Henrik Kniberg’s multitasking name game; I learned it via Monica Yap.)

The character factory game: round 1 keeps all three orders moving and delivers nothing; round 2 finishes one set at a time and delivers two

The card assumes the same writing speed in both rounds. Focus still wins—two complete sets against none—because a complete set is what a customer can actually use. Run it live and a second effect appears: your total character count drops in round 1, because every switch costs a beat. That drop is Weinberg’s table on one sheet of paper, and the delivered sets are the revenue argument in miniature. Try it with your team this week.

Some book links here are Amazon affiliate links; if you buy through them I may earn a small commission, at no cost to you.