The Rise of the Professional Ticket Mover

A ticket changes teams three times, gains a detailed comment history, and ends the week with its original problem intact. Everyone can explain what they did to route it. Finding someone who can explain how to finish it is harder.

There is real work in coordinating across teams. I have no problem with that. I have a problem with organizations that confuse successful routing with successful delivery.

The distinction matters because the people doing useful coordination can look remarkably similar to the people maintaining the loop. Both send messages, schedule conversations and update records. The useful question is what the next person can do after the handoff.

A handoff should reduce the work of understanding

A good handoff gives the next person enough information to act: what failed, what was checked, what decision is needed, and who can make it. It carries the reasoning that prevents another team from repeating the same investigation.

A bad handoff says “please investigate” and attaches another ticket. The recipient reconstructs the problem, asks the same questions, and eventually discovers why the previous team sent it away. The administrative history gets longer while the usable understanding barely changes.

This isn't fixed by requiring a longer template. A form can contain a lot of text without answering the one question blocking the work. The important information might be the actual destination of a network request, the specific failing step, or the person authorized to accept a particular risk.

Useful coordination finds that missing piece. It can also establish that the request is unnecessary and should stop. Closing a loop that should never have existed is a perfectly good outcome.

Follow one request through its decision points

Consider a hypothetical deployment that needs a network rule. The application team files a request. Networking asks for a destination nobody recorded, and the ticket goes back. A coordinator can keep nudging both teams without resolving that missing information.

The valuable intervention is to identify the destination and the required access, record the purpose and scope, and bring the decision to somebody who can make it. If security needs to review an exception, that is a real decision with a named owner. If the application can use an already supported path, the original request may be the wrong solution.

Neither outcome is improved by pretending the review is unnecessary. Nor is it improved by routing the same incomplete request faster.

Following the request all the way through reveals where the work changed from an engineering task into an unanswered question. A ticket status might hide that distinction. The record should say what decision is outstanding and what evidence the decision-maker still needs.

That is a narrower question than the total time a change spent waiting, which I discussed in A Week for a Five-Minute Change. Here I care about whether a handoff gives someone enough understanding and authority to take the next step.

Keep ownership of the outcome visible

Different teams can legitimately own different parts of the work. Networking shouldn't have to guess what an application needs, and an application engineer shouldn't silently approve their own access exception.

Somebody still needs to keep track of the original outcome while those teams contribute. That person needs a clear way to expose a stalled decision, obtain missing information, and escalate a dependency. An owner who can only forward messages has been given responsibility without much ability to act.

For a difficult handoff, I would want a short record of the current constraint, the next decision, the decision owner, and the evidence already available. A date for checking back is useful when it reflects an actual commitment. It is less useful when it becomes another reminder that nobody has agreed to do anything.

Automating reminders can reduce the effort of chasing a decision. It cannot supply the authority to make it. That is the same limitation behind automating an unclear organizational process.

Recognize the person who ends the loop

A clarified dependency, a well-supported escalation, or a decision to delete an unnecessary request can save more work than another status update. Those contributions deserve recognition, including when they come from people whose work is mostly coordination.

Measuring only code output would miss them. Counting reassigned tickets can miss them too. A person who prevents repeated investigation might leave fewer visible activities in the system than someone who keeps the same request circulating.

Look at a few completed requests and ask where understanding improved. Who established the missing scope? Who obtained the decision? Who noticed that two teams were answering different questions? Give those contributions the same specificity you would give a technical fix.

Then examine a request that is still stuck. If the latest handoff doesn't make its next decision clearer, another reassignment is unlikely to help. Find the information or authority that is missing and put that in front of the person who can use it.