Reducing engineering interrupts from support

Ask an engineering team what support costs them and you will get a number about tickets. Ask what it actually costs and you get a different answer: the interrupt. A question in a channel at 11:40 does not cost ninety seconds — it costs the ninety seconds plus the twenty minutes of rebuilt context on the other side, and it lands on whoever is most responsive rather than whoever is least busy.

The useful framing is that interrupts are a queue nobody manages. Tickets have owners, priorities, and aging reports. Interrupts have none of that, which is why they are simultaneously the most expensive support channel and the least visible one.

Sort a month of support-to-engineering escalations by what the engineer actually did, and a large share resolve into one of three sentences: that is a known issue, that is expected behaviour, or that is a duplicate of the thing we shipped a fix for on Tuesday. No engineering work happened. The escalation existed because the support person could not tell which bucket the report belonged in.

That is the class to attack first, because it is the cheapest to remove. The information needed — has this been reported before, does it match a recent change, which module does the described behaviour live in — is mechanically derivable. It just was not attached to the ticket at the moment somebody needed it.

The reason interrupt load never improves is that it is not counted. Ticket dashboards show the formal queue; the DMs, channel questions, and shoulder-taps that make up most of the real load appear nowhere. The first move is to make them countable, which usually means making them filable: if the fastest way to ask an engineer is a message that becomes a tracked ticket, the shadow channel and the queue stop being different things.

Then split escalations by outcome — identification, genuine engineering work, or misrouting — and track the first bucket as its own number. It is the one that should fall. The second bucket is real work and should not, and a rollout that suppresses it is hiding escalations rather than removing them.

What survives triage is real, and it still should not arrive as a broadcast. The pattern that works is a named support rotation on the engineering side: one person per week is interruptible, and everyone else is not. The rotation absorbs the interrupt cost deliberately instead of distributing it randomly across the team, and it gives support a person to ask rather than a channel to shout into.

The policy version of this — "please file a ticket instead of DMing" — fails reliably, because it asks the requester to do more work in exchange for a slower answer. The rotation succeeds because it does not ask the requester to change anything.

This is the specific problem FlowTux is built around. Triage is grounded in the linked repository and resolved-ticket history, so a report arrives with the probable files ranked, a known-issue check already done, and duplicates collapsed into the original ticket rather than multiplying it. The escalations that remain carry that diagnosis into a linked Jira, Linear, or GitHub issue, so the engineer starts from a hypothesis rather than a title.

The number to watch after rollout is not tickets closed. It is escalations that never happened — the identification bucket going to near zero while genuine engineering escalations stay flat.