Skip to content
← All writing

Triage is deciding what happens next, not sorting by size

· 6 min read · by Tan Gravam

The short answer

Triage is a decision about what happens next to each request, and it has exactly four honest exits: plan it, run a time-boxed discovery on it, park it with a review date, or decline it with a reason the requester can read. What most teams run instead is sorting — a weekly meeting that re-orders the queue, assigns priority labels, and decides nothing, so the same items return every week wearing new labels. The test for real triage is that a request cannot leave the meeting still undecided. The surprise is speed: deciding is faster than sorting, because a recorded park or decline never comes back next week, and a sorted item always does.

Most teams that say they triage requests are actually sorting them. The distinction sounds pedantic and is the whole game: sorting produces an ordering, triage produces decisions, and an ordering is what you have when nobody wanted to decide.

The sorting meeting

You have been in it. A weekly slot, a shared queue, forty-five minutes. Items get discussed, labels get assigned — P1, P2, "needs info" — sizes get guessed, and the queue leaves the meeting in a slightly different order than it entered. Nothing was refused. Nothing was committed. Every item survived, so every item returns next week, where the discussion repeats with the context a week staler.

The tell is the queue's age distribution: a sorting process accumulates items indefinitely, because sorting has no exit. The meeting is not deciding what happens to requests; it is curating their waiting room.

Triage has four exits

Real triage asks one question per request — what happens next to this? — and permits exactly four answers, each of them a recorded decision:

  • Plan it. The request is understood and worth taking towards a commitment.
  • Run a time-boxed discovery. The answer needs real work to find — so the work gets a goal and an end date, not an open-ended "we'll look into it". A discovery is a decision with a deadline, or it is a parking lot.
  • Park it. Not now — with a review date, or an explicit indefinitely. A park with no horizon is a decline that is embarrassed about itself.
  • Decline it. No — with a reason the requester can read. The no is a decision and gets recorded like one.

The defining rule: a request cannot leave triage still undecided. "Discuss again next week" is not an exit; it is the sorting meeting wearing a decision's clothes. If the room genuinely cannot decide, that is what the discovery exit is for — and it comes with a date.

Who sits in the room

Fewer people than you think, but the right ones: someone with the authority to refuse, and someone who can speak for the delivering teams' reality. That is usually two or three people, not a board. A triage session without refusal authority degenerates into sorting instantly, because the only decisions available to it are orderings — and a session without delivery reality commits to things no team was asked about.

What the room does not need: the full backlog, estimates for everything, or every stakeholder. Triage decides what happens next, not what things cost — sizing belongs to shaping and planning, done by the teams, not extracted in a meeting.

The fifteen-minute version

With a working door in front of it, triage is short. Requests arrive already clearing the two-question bar — what needs to change, and who is affected or why now — so the room is not doing archaeology. A typical week brings a handful of new requests; deciding a handful takes minutes. The meeting that takes an hour is the one processing its own backlog of previous non-decisions.

That is the counterintuitive economics: deciding is cheaper than sorting. A recorded park or decline never comes back next week. A sorted item always does, carrying its discussion with it. The sorting meeting is expensive precisely because it feels safer per-item — no one ever has to say no — and the cost compounds weekly.

What happens to the nos

Two of the four exits are refusals, and that ratio is the health of the whole system. A triage process that plans everything is not triaging — it is queueing with ceremony, and its commitments are diluted by everything it failed to refuse. The requester who gets a reasoned no in a week trusts the process more than one holding a slow maybe — and the parked items with review dates come back on their date, with their original context attached, instead of resurfacing randomly as someone's memory.

How DeliverySheet runs the step

The Decide step offers exactly the four exits and nothing else. A shaped demand waiting for its decision is visible as exactly that — the needs-a-decision pile, in plain sight rather than blended into a queue — and no exit can record a non-decision: a discovery cannot be opened without the date it must conclude, parking requires a review date or an explicit indefinitely-with-reason, and declining requires the reason. The sorting meeting's move — relabel it and carry it to next week — simply does not exist as an outcome. The step before it — turning a raw request into something decidable — is its own argument.

I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.

$189/month per workspace, unlimited members, 7-day free trial. I answer the support email myself.

More on turning a request into a decision

Read the overview: Turning a request into something you can decide on →