Priya manages a small support team, and last winter her company switched to a new ticketing and paging setup. On launch Monday, the first urgent ticket sat unassigned for forty minutes because the routing rule pointed to a group that no longer existed. Nobody was careless; the plan simply never imagined that moment. Afterwards the team asked one another the questions that follow every stumble, and Priya wrote them down. The questions below turn her notes into a guide to running a pre-mortem before changing how support works.<\/p>\n
It is a short meeting held before you switch on a new support process, tool or schedule. You announce that the change has already caused trouble, and everyone writes down the reasons. The purpose is to find ordinary, fixable gaps while you still have time to fix them. Priya’s team now runs one before any change that touches how customers reach them.<\/p>\n
Testing checks what you thought of. A pre-mortem looks for what you did not. A test of the routing rule would have passed, because the rule worked exactly as written; the failure was in an assumption about who would be in the group. Tests confirm the plan, and pre-mortems challenge the plan, so you need both.<\/p>\n
People who will live with the change: the engineers on rota, the person who answers the first message, someone from the team that raises the most tickets, and a quiet new joiner. Priya found that the newest person often named the simplest risk, since they had no habit of assuming how things work. Keep the group small enough that everyone speaks.<\/p>\n
For support processes, the same families show up again and again:<\/p>\n
Seeing your own team’s version of these written on cards is often the moment people realise how much each of them had been quietly carrying in their heads.<\/p>\n
About forty-five minutes: five to introduce, five of silent writing, twenty for reading and grouping, and fifteen for choosing actions. Anything much longer starts to feel like a complaint session. If the change is small, fifteen minutes is enough.<\/p>\n
Pick the three most likely and most damaging items and give each an owner and a date before the launch. In Priya’s case the first item, the routing group, became “check every rule against the current staff list the day before launch”. The second was a plain checklist for the night-to-day handoff, and the third was a note on the old support address pointing people to the new one. Principles like these sit comfortably alongside the ideas in the basic principles that keep software delivery effective<\/a>, where small, reviewed changes are the norm.<\/p>\nIs there anything to learn from security teams?<\/h2>\n