Burning Fires

The problem it solves

Even a manager with a capable team will end up prioritising based on who is asking, not because they cannot prioritise, but because they lack a system for managing requests. Everything that arrives arrives labelled urgent, and the label is usually applied by whoever wants the thing rather than by anyone weighing the consequence of leaving it alone.

A list isn't the problem, and most teams have a perfectly serviceable one. The difficulty is that a list has one dimension and the work has two, because what goes wrong if a thing is left alone is a different question from how long there is before that lands. Collapse the two into a single ordering and you tend to get an ordering that tracks who asked most recently and their position relative to yours, rather than consequence.

The outcome is one most managers will recognise. The thing that finally breaks is usually something that has sat on the list for months, one place below something that had a deadline and no consequence behind it.

The idea

Ask two questions, and ask them separately.

What goes wrong if nobody touches this? Not how annoying it is and not how visible it is, but what actually breaks, for whom, and how expensively.

How long before that lands? Not when it was asked for, but when the consequence arrives.

Cross the two and the pile becomes four piles, each with a different answer.

Enlarge: Sorted by what happens if you wait, rather than by who's asking.

Sorted by what happens if you wait, rather than by who's asking.Close

Sorted by what happens if you wait, rather than by who's asking.

The real fire is severe and immediate, and it's the one pile that justifies dropping whatever you're holding, though a normal week usually contains fewer of them than it feels like at the time. The loud fire is immediate and contained, which covers a noisy channel, an annoyed executive, or a date somebody set for themselves. It costs the same attention and the same context switch as a real fire, and returns nothing. The slow burn is the dangerous one, severe with no date attached, so nothing forces it onto the calendar. And the fourth pile is the one you let burn.

That last move is what makes the rest of it worth doing, because a triage system that keeps everything is a list with a diagram drawn on top of it.

How to use it

Do this with the real list in front of you rather than from memory, and do it with the people who'll have to live with the result.

Write down everything currently competing for the team's attention, including the things that have gone unwritten because they're just how it is here. Those usually turn out to be the slow burns.

For each item, say what breaks if it's left alone for a month, as a consequence rather than an adjective. "The on-call rota is unfair" is an adjective, whereas "two engineers are updating their CVs" is a consequence, and it places itself.

Then ask when, separately and afterwards, because doing both at once is how severity leaks into urgency, with a thing that feels pressing acquiring an importance it hasn't earned and a thing with no deadline quietly losing the severity it has.

Once everything is placed, do the two things that actually cost something. Name the let-it-burn pile out loud to the people affected by it, in a conversation with them rather than in your own notes. And put an artificial date on each slow burn, because that quadrant is defined by not having a real one, and anything without a date loses to anything with one, indefinitely.

Where it breaks down

Every concept here has one. It is the section most summaries leave out.

The axes are marked by the people competing for the attention. There's no outside check on severity, so severity inflates. Once the whole board sits above the midline the grid has stopped separating anything and you're back to a list with a picture attached, which is the same failure clinical alarm systems reach when each reading is an alert and the staff have stopped hearing any of them. The tell is distributional, so if each quadrant has something in it and none of them is crowded the axes are working, and a permanently deserted low- severity corner means they aren't.

It says nothing about capacity. Four real fires and two engineers isn't a prioritisation problem. The grid will place all four correctly and the team will still fail. That's a useful failure, because it converts a vague sense of overload into an arguable claim, but it isn't the claim the grid appears to be making.

Severity aggregates, and aggregation hides who. A change that's mildly annoying for two hundred customers and catastrophic for three lands somewhere on the axis that's true for neither group. Every single-score severity scheme has this problem and this one has no special defence against it.

Sometimes the loud fire is real. Attention from a senior person is itself a consequence, because it changes what gets funded, staffed and believed next quarter. Dismissing it as noise because the model has a word for noise is the most common way this gets used badly, and the model gives you no help in telling the two apart.

The evidence is thin, and it's worth being clear about how thin. Triage in medicine has a substantial literature behind it, and a two-by-two for a team's workload has very little. What it has instead is a mechanism, which is forcing apart two variables people reliably conflate, and that mechanism is well evidenced, because given a choice people take the task with the nearer deadline even when they know the other one pays more. Nobody has shown that teams using this grid produce better outcomes, and it's hard to imagine the study that would.

In one line

Sort by what happens if you wait, say out loud what you're letting burn, and put a date on the fire that hasn't got one.