Too general, too specific, inside a team

The shift handover in Pune

Too general

For a while, the handover was a quick word at the desk: “Keep an eye on the Northlight tickets, it’s been busy.” Everyone nodded.

It felt efficient, and on quiet nights it was. On busy nights, tickets were dropped. A callback promised to a Northlight manager at 9am didn’t happen, because “keep an eye on” didn’t say anyone had promised anything. A priority incident still open with Application Support in Cork looked, to the incoming shift, like an ordinary ticket waiting in the queue.

The outgoing analysts knew the detail. The incoming ones didn’t. The handover was general language used with an audience that didn’t share the picture underneath it.

Too specific

After a bad week, the team swung the other way. They built a handover checklist of 60 lines: every client, every queue, every open ticket, every system’s status.

Nobody could fill it in properly in the ten minutes a handover allows. Within a month, analysts were ticking every box without reading it. The few lines that mattered were buried among the many that didn’t, and tickets were still dropped, now with a completed checklist beside them.

The right level

The fix was to get specific only where the ambiguity was real. Rohan’s team looked at the tickets that had actually been dropped and found three causes:

• Priority incidents still open with another team.
• Callbacks promised to a client at a set time.
• Known problems that would bring a wave of similar calls.

The handover now covers those three things precisely: each item named, with who owns it and what happens next. Everything else stays general: “the queue is normal”, “Northlight is quiet tonight”. The team agreed the three items once, wrote them on the team’s canvas, and now a handover takes five minutes and almost never drops a ticket.

When something changes, such as a new client with different service levels, the team revisits the list. Between changes, they don’t renegotiate it every shift.

Doing this in your own team

1. Look at what actually goes wrong, not at everything that could. The real ambiguity usually sits in a handful of places.
2. Get specific about those few things. Name what must be passed on, who owns it, and what happens next.
3. Leave the rest general. People who share the detail don’t need it spelt out.
4. Agree it once with the people involved, and write it down where the team works.
5. Revisit it when circumstances change, not every time it is used.

The same test works for any instruction you give: would someone who doesn’t share your picture know exactly what to do? If yes, general is fine. If no, and it matters, get specific.