When Everything Is Priority One
27 May 2026I gave a talk at Agila Sverige this week about what happens when you don’t prioritize. Or more precisely, when everything is marked as priority one.
The premise was simple. I asked people what they thought should be in a talk about this problem. I got 163 answers. I told the audience I would go through all of them.
Then I showed them what that feels like.
The Point
I didn’t actually present 163 points. The joke was the experience of being told we would sit through all of them. That moment of dread - “we’re going to be here forever” - is exactly what happens to teams when every project is priority one. The list never ends. Nothing gets finished. Everyone is exhausted.
The audience laughed. Then we moved on to why this keeps happening.
It’s Not Only Anecdotal
This isn’t just a feeling. The costs of “everything is priority one” have been measured, studied, and documented for decades across multiple disciplines.
Attention Residue (Sophie Leroy, 2009) shows that when you switch tasks, part of your attention stays on the previous task. Your performance on the new task suffers. The more you switch, the worse it gets. This is not about willpower or discipline - it’s a cognitive limitation.
Little’s Law (John Little, 1961) is a mathematical proof, not an observation. It states that the average number of items in a system equals the arrival rate multiplied by the average time in the system. Put simply: if you double the work in progress without increasing throughput, you double the cycle time. More simultaneous projects means everything takes longer.
Context Switching Cost (Gerald Weinberg, 1991) quantifies the overhead. Working on two projects at once costs you 20% productivity. Three projects: 40%. Five projects: 80% of your time is spent on coordination, status updates, and mental context switching. Only 20% goes to actual work.
Normalization of Deviance (Diane Vaughan, 1996) explains how organizations drift into accepting chaos as normal. Small deviations from the plan are tolerated. Then bigger ones. Eventually, the organization accepts as baseline what was once considered unacceptable. This pattern preceded both the Challenger and Columbia disasters at NASA. It also precedes project disasters in software teams.
Why It Persists
If the costs are this clear, why does it keep happening?
Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.” Organizations optimize for visible metrics - velocity, story points, number of features shipped. These metrics don’t capture the hidden costs: technical debt, team exhaustion, coordination overhead, or the opportunity cost of saying yes to everything.
Opportunity Cost Neglect: Every yes to a new project is an implicit no to speed, focus, and quality on everything else. But because the cost is distributed and invisible, it doesn’t feel real. So we keep saying yes.
Brooks’s Law (Fred Brooks, 1975): “Adding manpower to a late software project makes it later.” The instinct when projects are struggling is to add more people or more projects to justify the existing headcount. Both make it worse. Communication overhead grows as N(N-1)/2. A team of 20 has 190 communication channels.
What to Do About It
The Theory of Constraints (Eliyahu Goldratt, 1984) offers a framework. Every system has one bottleneck that controls throughput. Optimizing anything other than the bottleneck is waste. Find your bottleneck. Protect it. Let everything else wait.
This means:
- Limit work in progress
- Dedicate people to few projects, not many
- Say no more often
- Measure outcomes, not activity
- Challenge “we’ve always done it this way”
None of this is easy. It requires organizational discipline and the willingness to disappoint people in the short term for better results in the long term. But the alternative - normalized chaos, exhausted teams, and nothing ever finishing - is worse.
Further Reading
I’m publishing a series of deep dives into the research behind these concepts. Each post explores one concept in detail - the science, the implications for software teams, and what to do about it.
Part 1: Attention Residue: The Cost of Context Switching
More coming soon.
Patrik Gustafsson
Software Engineer & Organizational Designer
acyclic.eu | LinkedIn