A ticket gets created on Thursday for work that started on Monday. The description is written to match what's already been done, because by Thursday that's the only version anyone can reconstruct.

Nobody did anything wrong on Monday. Someone asked, the work looked small, and starting was faster than defining. The record came later so the work would be visible, which was the responsible instinct. What it produced is a record that documents an outcome instead of governing a decision.

I see this in organizations that would tell you their intake process is fine, and by their own description it is. The form exists. The queue exists. Work still begins outside it, and the paperwork catches up afterward.

Filling the record afterward gives you the friction without the control

A record created before work starts can change what happens. It can send a request back, reveal that two teams are being asked for overlapping things, or make someone notice that the thing being requested has an owner already.

A record created afterward can't do any of that. The cost is already committed. What it can still do is take time to write, generate fields for people to complete, and create the appearance of a process, which is why intake work has a reputation for being overhead. In that sequence it genuinely is overhead. All of the friction arrives and none of the decisions do.

That's also why adding fields usually makes things worse. Leadership sees requests arriving in poor shape and responds with more structure. More structure applied after the start point produces longer forms filled in retrospectively. The organization ends up paying for process and receiving none of what process is for.

The gate is a small amount of information, collected early

A gate isn't a business case and it isn't a full specification. It's the minimum needed to own a request and place it in line, which is a much lower bar than most intake designs assume.

Four things carry it:

  • Who needs it, and who can say it's finished. These are often different people, and confusing them is how work gets accepted by someone who wasn't in a position to accept it.
  • What finished means. Stated concretely enough that two people would agree on whether it happened.
  • Roughly what it will take. Order of magnitude. Effort, and any spend or ongoing obligation it creates. A number given in a minute is worth more than a precise one given in a week.
  • What moves if this starts now. The one people skip, and the one that turns a request into a decision.

That's the whole gate. If answering those four takes longer than a short conversation, the request usually isn't ready, and that's useful information rather than an obstacle.

Missing context and open uncertainty aren't the same thing

This distinction decides whether a gate is workable or whether it becomes a reason to refuse everything.

Plenty of real work starts without knowing how it'll be done. That's normal and the gate shouldn't block it. What the gate asks about is who it's for, what finishing looks like, roughly what it costs, and what it displaces. Those can be answered even when the approach is genuinely unknown, and a request whose method is uncertain can pass the gate cleanly.

Missing context is different. It's when nobody can say who accepts the result, or what would count as done, or what this pushes aside. Starting there means the definition gets constructed during the work by whoever's doing it, and then renegotiated when someone else sees the result.

Uncertainty about method resolves as the work proceeds. Missing context doesn't resolve. It gets decided by default.

Size the gate to the request

A gate applied uniformly to everything will be routed around, and it should be. A password reset and a platform migration don't need the same conversation, and pretending otherwise is how a reasonable rule earns a reputation for bureaucracy.

Small, reversible, low-cost requests need a light version, often just a routing decision and an owner. Requests that create ongoing cost, cross several teams, or are hard to undo need the full four. The proportion is a local judgment about your own work, not something anyone can set from outside.

The rule that doesn't flex is the entry point. If some requests can bypass the gate because of who's asking, then the gate is optional, and an optional gate is a suggestion that'll get overruled in the busiest weeks.

Returning a request isn't a rejection

The output of a gate that catches something shouldn't be a refusal. It should be a specific question, sent back quickly, naming what's missing.

This part is worth getting right, because the phrasing determines whether the mechanism survives. A request arriving without enough context isn't a failure by the person who sent it. Organizations rarely tell people what's needed, and rarely make it easy to supply. The request is incomplete because nobody defined complete.

A returned request that says "who accepts this as finished, and what should move to make room" is teaching the format. After a few rounds most requests arrive with the answers already in them, and the gate stops being something anyone notices.

A weak intake process asks for information after the cost has already been incurred. A working gate asks early enough for the answer to change the decision.