--- title: "Triaging engineering requests · DeliverySheet" description: "Request triage fails when it produces an ordering instead of decisions. The four exits, who sits in the room, and the fifteen-minute version." canonical_url: "https://www.deliverysheet.com/blog/triaging-engineering-requests" last_updated: 2026-08-21 meta: author: "Tan Gravam" "og:description": "Request triage fails when it produces an ordering instead of decisions. The four exits, who sits in the room, and the fifteen-minute version." "og:image": "https://www.deliverysheet.com/_og/s/o_379d675a625448c1.png" "og:image:alt": "Triage is deciding what happens next, not sorting by size — DeliverySheet essay card" "og:image:height": "600" "og:image:type": image/png "og:image:width": "1200" "og:title": "Triage is deciding what happens next, not sorting by size — DeliverySheet" "twitter:description": "Request triage fails when it produces an ordering instead of decisions. The four exits, who sits in the room, and the fifteen-minute version." "twitter:image": "https://www.deliverysheet.com/_og/s/o_379d675a625448c1.png" "twitter:image:alt": "Triage is deciding what happens next, not sorting by size — DeliverySheet essay card" "twitter:title": "Triage is deciding what happens next, not sorting by size — DeliverySheet" --- > Index of every page on this site: [llms.txt](https://www.deliverysheet.com/llms.txt) [← All writing](https://www.deliverysheet.com/blog) # **Triage is deciding what happens next, not sorting by size** 21 August 2026 · 4 min read · by [Tan Gravam](https://www.deliverysheet.com/about) ## **How should you triage engineering requests?** **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](https://www.deliverysheet.com/glossary/triage): - **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](https://www.deliverysheet.com/blog/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.](https://www.deliverysheet.com/blog/saying-no-is-a-recorded-decision) 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](https://www.deliverysheet.com/blog/you-dont-need-a-scoring-framework). ## 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](https://www.deliverysheet.com/blog/engineering-intake-process) — 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](https://www.deliverysheet.com/glossary/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](https://www.deliverysheet.com/blog/what-makes-a-request-shapeable). Defined in the glossary: [Triage](https://www.deliverysheet.com/glossary/triage) 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 — card required, cancel before it ends and you're not charged. I answer the support email myself. [**Start 7-day trial **](https://www.deliverysheet.com/login?next=/app) [**See pricing **](https://www.deliverysheet.com/pricing) Not ready for that? Play [eight rounds of Request or topic?](https://www.deliverysheet.com/spot-the-request) It takes two minutes and needs no sign-up. ## **More on turning a request into a decision** [Read the overview: Turning a request into something you can decide on →](https://www.deliverysheet.com/topics/intake) - [What makes a request shapeable](https://www.deliverysheet.com/blog/what-makes-a-request-shapeable) Not every message is a demand. The floor is low but it is real: a need, plus either who it affects or what happens if nothing changes. - [An intake form is a door, not a net](https://www.deliverysheet.com/blog/the-intake-form-is-a-door) Most intake forms are nets — they catch everything and decide nothing. What the form should actually ask, and the one property that makes it work. - [An intake form template with two required fields](https://www.deliverysheet.com/blog/intake-form-template) A copy-paste intake form template for engineering teams: two required questions, one optional date, and the four exits every request must reach. ```json {"@context":"https://schema.org","@graph":[{"@id":"https://www.deliverysheet.com/#website","@type":"WebSite","description":"Turn raw work requests into structured, decision-ready demands before you commit people, budget, or a date. AI-assisted shaping, planning and commitment governance for engineering leaders.","name":"DeliverySheet","url":"https://www.deliverysheet.com/","publisher":{"@id":"https://www.deliverysheet.com/#identity"}},{"@id":"https://www.deliverysheet.com/blog/triaging-engineering-requests#webpage","dateModified":"2026-08-21","datePublished":"2026-08-21","description":"Request triage fails when it produces an ordering instead of decisions. The four exits, who sits in the room, and the fifteen-minute version.","name":"Triaging engineering requests","url":"https://www.deliverysheet.com/blog/triaging-engineering-requests","@type":["WebPage","FAQPage"],"breadcrumb":{"@id":"https://www.deliverysheet.com/blog/triaging-engineering-requests#breadcrumb"},"isPartOf":{"@id":"https://www.deliverysheet.com/#website"},"mainEntity":[{"@id":"https://www.deliverysheet.com/blog/triaging-engineering-requests#/schema/question/1"}],"potentialAction":[{"@type":"ReadAction","target":["https://www.deliverysheet.com/blog/triaging-engineering-requests"]}],"primaryImageOfPage":{"@id":"https://www.deliverysheet.com/#logo"}},{"@id":"https://www.deliverysheet.com/#identity","@type":"Organization","alternateName":"Delivery Sheet","description":"Turn raw work requests into structured, decision-ready demands before you commit people, budget, or a date.","name":"DeliverySheet","url":"https://www.deliverysheet.com","founder":{"@type":"Person","@id":"https://www.deliverysheet.com/about#person","name":"Tan Gravam"},"logo":{"@id":"https://www.deliverysheet.com/#logo"}},{"@id":"https://www.deliverysheet.com/blog/triaging-engineering-requests#breadcrumb","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","name":"Home","item":"https://www.deliverysheet.com","position":1},{"@type":"ListItem","name":"Writing","item":"https://www.deliverysheet.com/blog","position":2},{"@type":"ListItem","name":"Triage is deciding what happens next, not sorting by size","item":"https://www.deliverysheet.com/blog/triaging-engineering-requests","position":3}]},{"@id":"https://www.deliverysheet.com/blog/triaging-engineering-requests#article","@type":"Article","dateModified":"2026-08-21","datePublished":"2026-08-21","description":"Request triage fails when it produces an ordering instead of decisions. The four exits, who sits in the room, and the fifteen-minute version.","headline":"Triage is deciding what happens next, not sorting by size","inLanguage":"en","thumbnailUrl":"https://www.deliverysheet.com/_og/s/o_379d675a625448c1.png","about":[{"@id":"https://www.deliverysheet.com/glossary/triage#term"}],"author":{"@id":"https://www.deliverysheet.com/about#person"},"image":{"@id":"https://www.deliverysheet.com/#/schema/image/1"},"isPartOf":{"@id":"https://www.deliverysheet.com/blog/triaging-engineering-requests#webpage"},"keywords":["intake","triage","process design"],"mainEntityOfPage":{"@id":"https://www.deliverysheet.com/blog/triaging-engineering-requests#webpage"},"publisher":{"@id":"https://www.deliverysheet.com/#identity"}},{"@id":"https://www.deliverysheet.com/blog/triaging-engineering-requests#/schema/question/1","@type":"Question","inLanguage":"en","name":"How should you triage engineering requests?","acceptedAnswer":{"@type":"Answer","text":"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."}},{"@id":"https://www.deliverysheet.com/about#person","@type":"Person","jobTitle":"Founder","name":"Tan Gravam","url":"https://www.deliverysheet.com/about","sameAs":["https://gravam.com","https://twitter.com/TanGravam","https://github.com/TanGravam"]},{"@id":"https://www.deliverysheet.com/#logo","@type":"ImageObject","caption":"DeliverySheet","contentUrl":"https://www.deliverysheet.com/logo.png","inLanguage":"en","url":"https://www.deliverysheet.com/logo.png"},{"@id":"https://www.deliverysheet.com/#/schema/image/1","@type":"ImageObject","contentUrl":"https://www.deliverysheet.com/_og/s/o_379d675a625448c1.png","inLanguage":"en","url":"https://www.deliverysheet.com/_og/s/o_379d675a625448c1.png"}]} ``` ## Sitemap See the full [sitemap](https://www.deliverysheet.com/sitemap.md) for all pages.