The side channel is rational

Every team with an intake process also has the other intake process: the DM to the engineer who helped last time, the hallway ask, the request smuggled into a meeting's final two minutes. The official channel has a form and a queue. The side channel has results. Guess which one grows.

The side channel is not a discipline problem

The standard response is enforcement: "please file a ticket", pinned channel rules, a bot that replies with the form link. It fails, always, and it deserves to — because the requester's behaviour is correct. They ran the experiment. The form produced silence for three weeks; the DM to Deniz produced an answer by lunch. Asking them to prefer the silent channel is asking them to care more about your process than their problem, and nobody does, including you when you are the requester somewhere else.

Policing the side channel while the door leads nowhere also sends a message you did not intend: we know the official path doesn't work — please use it anyway. That costs credibility on exactly the day you need requesters to trust a new process.

What the side channel costs anyway

Rational for each requester, expensive for everyone: side-channel requests consume real capacity that no plan accounts for, so the committed work slips by an amount nobody can point to. They route by relationship, so the loudest and best-connected win regardless of merit. And they are refused by silence when the engineer is busy — the request just evaporates, which is a slow maybe with even less record than usual. The side channel is not free answers. It is an invisible intake process with worse governance.

Make the door the fastest path to an answer

The fix inverts the incentive instead of fighting it. The door wins when it reliably beats the DM on the only metric requesters have — time to a real response:

• Below the bar: same-day handback. A request missing its need or its stakes gets the one clarifying question back while the context is still warm.
• Above the bar: a decision within the week. Not delivery — a recorded exit: planned, in discovery with a date, parked with a review date, or declined with a readable reason.
• Visible state throughout, so "what happened to my request?" has an answer nobody has to chase.

A reasoned no in five days beats a warm maybe in five weeks, and requesters know it — the fast no is the relationship-preserving move, not the threat to it.

And walk the DMs to the door

The side channel never fully closes, and does not need to. The rule that works is small: a request that arrives as a DM gets entered at the door by whoever received it — a minute, in front of the requester, "logging it so it actually gets decided". No scolding, no redirect, no friction for the asker. The engineer stops being an invisible queue and becomes a doorway; the request stops being a favour and becomes a record. The door takes two questions, so this costs almost nothing — which is the entire reason it happens.

Run both halves for a quarter — the fast door, the walked DMs — and the side channel empties on its own, for the same reason it filled: people route to whatever answers. The goal was never channel purity. It was that every request, however it arrives, reaches a decision someone recorded.