The engineering intake process, end to end

Ask to see a team's intake process and you will usually be shown one of two things: nothing — requests arrive wherever they arrive — or a bureaucracy: a twelve-field form, a weekly triage board, a category taxonomy someone maintains. Both fail the same test, from opposite directions. The question a requester actually has is what happened to my request? — and neither the void nor the committee can answer it.

A working intake process has four parts. None of them is a meeting.

Part one: one door

Every request goes through the same entry point. Not because channels are bad — requests will always arrive via Slack, email and hallway — but because what arrives in a channel gets entered at the door, by whoever received it, in under a minute. The door is where a request starts existing on the record; the channel is just where it was first spoken.

The alternative is the shadow queue: some requests in the tracker, some in a spreadsheet, some alive only in a senior engineer's memory. A prioritisation built on a partial list is not a prioritisation — the requests that bypassed the door still consume the capacity, they just do it invisibly.

Part two: a two-question bar

A request enters when it states what needs to change, plus at least one of who is affected or what happens if nothing changes. That is the whole bar, and it is deliberately not "any two of three": impact and urgency without a stated need is the shape of every doomed project — enormous pressure attached to a void.

Below the bar, the request is not rejected; it is handed back with the one question that clears it, on the same day, while the requester still has the context in their head. Most requests clear on the second attempt, sharper than they would ever have become in a backlog. The form itself needs two required fields and no more — every additional field is paid for by the requester at the moment their patience is shortest, and answers a question that belongs to a later stage.

Part three: triage with recorded exits

Triage is the step where someone with authority decides what happens next, and the test of it is that every request reaches one of four recorded exits:

• Plan it — 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 instead of an open-ended "we'll look into it".
• Park it — not now, with a review date or an explicit indefinitely.
• Decline it — no, 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. Deciding is faster than sorting, because a recorded park or decline never comes back next week, and a sorted item always does. The meeting shrinks as the process works: with a bar at the door and real exits, most weeks there are a handful of requests to decide, and deciding a handful takes minutes.

Two of the four exits are ways of saying no, and that ratio is the health of the whole system — a no that exists on the record is what keeps the yes credible.

Part four: visible movement

The requester who can see that their request went from "arrived" to "being shaped" to "parked until March, because the migration blocks it" does not chase anyone. The requester who sees nothing chases — or worse, escalates, because escalation is the only lever that visibly works on a black box. Most of the social pain attributed to "difficult stakeholders" is a rational response to a door that leads to silence.

Visibility also has a quieter function: it is what makes the waiting state honest. A request pending one answer from legal is waiting, which is a state — with the question, who was asked, and a follow-up date — not just old.

What the process deliberately lacks

No category picker — categories are for reporting, and whoever needs the report can tag later. No priority field — priority is the team's decision, not the requester's claim. No sizing at the door — sizing an unshaped request produces a guess wearing units. No approval chain — the door is a bar, not a gate with politics. Each of these, added with good intentions, moves work onto the requester that belongs to a later stage, and the requester responds the way people respond to forms that interrogate them: they go back to the hallway.

How DeliverySheet runs this

The product is this process, held by software rather than discipline. Capture is the door, and the two-question bar is enforced deterministically — a request enters with a stated need plus an impact or a trigger, and there is no override. Paste a Slack message or an email and the AI drafts the structured fields; what it cannot do is lower the bar. Decide offers exactly the four exits, a discovery cannot be opened without the date it must conclude, and a demand's state is visible to anyone in the workspace who looks — the record answers "what happened to my request?" without anyone being chased. The argument for each part is spread across the intake overview; this page is the assembly manual.