Tickets Across Timezones
With many technical support teams adopting Follow-the-Sun (FTS) models, I assumed there were already well-documented industry best practices. But I searched a bit, and I don't really see anything out there that speaks to my personal experience as a support engineer, and the high-performing teams I've observed. Here are some notes based on what I've seen work best.
What is FTS?
The first time I heard about the FTS model was when Amazon announced they were using it. They mentioned that their engineers no longer worked shifts but instead "followed the sun," meaning their day ended before sunset. This approach distributes workload across timezones so that everyone works during their normal waking hours, accommodating our natural diurnal rhythms.
The core idea is to distribute your workload across teams in different timezones worldwide, so each team only works when the sun is up in their location.
The Devil's in the Distribution
It's important to consider how you distribute the workload. In a perfect world, an engineer resolves a ticket during their shift. The next best thing, the same engineer works on the ticket until completion, even if it takes a few days. The main goal is to avoid handing over tickets across timezones.
Why avoid handovers? As beneficial as the FTS model is, there's a cost associated with handing over in-progress work across timezones and teams. Think of the telephone game from childhood, where a message is whispered down a line of kids and changes dramatically by the end. This illustrates the risks of transferring work: miscommunication, loss of valuable context, duplicated effort, and added complexity.
Minimizing the Cost
Sometimes handovers are unavoidable. Here’s how to minimize the risks and costs associated with them:
The Shift Handover Meeting
FTS works best when there’s a daily meeting between incoming and outgoing teams. This meeting doesn't need everyone on the team; only those handing off and taking on work should attend. The meeting should be led by someone from the incoming team, such as a team leader, senior engineer, or project manager.
The FTS/Handover Comment
Every ticket being handed over needs a handover comment. This comment should get the incoming engineer up to speed quickly and serve as a record for tough tickets that cycle through FTS multiple times. Include a problem statement, a goal statement, and a summary of work done during the outgoing shift.
Filter Tickets Aggressively
The goal is not to hand over tickets that have already been worked on. The person running the handover meeting acts as a gatekeeper, ensuring only high-priority tickets with time constraints and a proper handover comment are handed over. Push back on tickets that don’t meet these criteria. Handovers are expensive—don’t make them more costly or difficult than necessary.
