Cross-Training Rhythms That Survive a Busy Month

Monday, 14:00, at Stonebridge Insurance. The calendar says "Cross-training: claims system, Tom and Aisha", and it has said so every Monday since the spring. The queue says sixty-one open tickets, two of them past their response target, and a claims handler on the phone who would like to know why her screen is grey. Tom looks at the calendar entry, drags it to Thursday, and takes the call. On Thursday he drags it to next Monday. By the time anyone counts, the half hour has been moved eleven weeks running. Aisha, who was going to be the second person who could run the claims system, still cannot sign into it. The calendar entry has been moved so often it has acquired a kind of momentum.

Nothing dramatic happened. Cross-training does not fail; it is postponed, each time for a reason that would convince anyone. The sum of the reasons is a desk that still has one person for every system it had one person for a year ago. The queue has a requester, a clock and a number. The half hour has none of those. Put them side by side on a Monday afternoon and the half hour loses every time, on merit.

Cross-training is deliberately teaching a second person to run a system that a first person already runs, in small scheduled pieces, until the second person can do it alone. A rhythm, in this article, is a slot that repeats at a fixed size on a fixed day whether or not the week is calm. That is the only kind of slot a busy desk ever keeps. This article is part of our Team Knowledge Sharing series. The audit in The Bus-Factor Audit tells you which systems to cross-train. This article is about how, and about keeping it going in the month the queue catches fire.

It starts with why cross-training is postponed rather than cancelled. Then come the four rhythms: the weekly half hour, the ticket swap, the shadow day and the teach-back. Next are what to cross-train first within a system, keeping the rhythm when the queue is on fire, and what counts as done. A short war story and the cross-training calendar to copy finish the article.

Why Cross-Training Is Postponed, Not Cancelled

Cross-training loses to tickets because it has none of the things that make a ticket urgent. The fix is to give it those things rather than to ask people to care more. A ticket has a requester who will chase, a target that will go red, and a place in the queue where everyone can see it. A calendar entry has a colour. When the two compete, the person deciding is not being lazy; they are triaging, correctly. The calendar entry is the lowest priority item on the desk every single time. The answer is to make it small enough that it never needs to win the argument, and fixed enough that nobody has to have the argument at all.

Small beats big, by a wide margin. I have run the two-day cross-training workshop, the one with the agenda and the sandwiches. I have run the half hour a week for twelve weeks. The half hour won by every measure I could think of. The workshop is cancelled by the first incident of the day. The attendee remembers a tenth of it a month later. Nothing was practised on a real system because the real system was busy being real. Twelve half hours survive because any one of them can be lost without losing the thing, and each one ends with a person having done something on the actual system. The sandwiches were nice. That is the whole case for the workshop.

Fixed beats flexible, because a slot that can move will move. "Sometime this week" is a slot that is always next week; "Tuesday at ten, thirty minutes, same room" is a slot that is occasionally missed and otherwise kept. The rule that makes it work is the one Stonebridge did not have: the half hour may move within the week, never out of it. Thursday is allowed. Next Monday is a skip, and skips are counted, which is the subject of a later section. Give the slot a fixed size, a fixed day, and a rule about moving, and the queue stops being able to eat it one reasonable decision at a time.

The Weekly Half Hour

The weekly half hour is one pair, one system, one outcome, and the outcome is written on the calendar entry before the slot starts. Not "cross-training: claims system" but "Aisha restarts the claims application service and confirms it from a handler's screen". A slot with a written outcome either achieved it or did not, which is how the next slot knows where to start. A slot without one is a conversation about the system, which is pleasant and leaves no mark on the grid. The outcome should be small enough to do in twenty minutes with ten to spare. If the expert thinks it needs an hour, it is two outcomes.

The learner drives and the expert narrates, and the keyboard is the whole difference. An expert showing a learner how a thing is done produces a learner who has seen it. A learner doing the thing with an expert talking produces a learner who has done it, badly, once. That is the first step to doing it well. The expert's job is to say what they are looking at, why the next step is the next step, and what they would expect the screen to show. And to keep their hands off the mouse even when it hurts. Especially when it hurts. The moment the expert takes the keyboard "just to speed this up" the half hour has become a demonstration.

Shape the half hour as five, twenty, five. Five minutes of why: what the system is for, what breaks, what a bad day looks like. Twenty minutes of doing the outcome, at the learner's pace, with mistakes allowed and reversed. Five minutes of writing down what the learner could not follow, because that is exactly what is missing from the runbook. It goes into the runbook the same day while it is fresh. Which document gets written first for a system, and why the runbook is the medium the half hour feeds, is in Documentation as the Sharing Medium.

Book the half hour as a ticket, not only as a calendar entry, and it stops being invisible to the queue. A ticket for "cross-training: claims service restart, Aisha with Tom" sits in the list with the other work. It is claimed by the learner and closed with a note saying what was done. It is counted at the end of the month with everything else the desk did. If you run QuerySolv, the claimed ticket shows on the queue with the learner's name on it. The closing note goes into the ticket's history. In that case, the record of who learned what is built as a side effect of doing it. A calendar entry, by contrast, has never once been reported to a manager.

The Ticket Swap

The ticket swap routes the next real tickets for a system to the learner instead of the expert, with the expert as the first person the learner escalates to. It is the rhythm that turns "can follow the runbook" into "can run it alone", because nothing teaches like a requester who is waiting. The mechanics are simple on any desk. Triage sends the claims-system tickets to Aisha for the next month, or the next ten tickets, whichever comes first. Aisha claims each one. Tom does not touch them unless she asks. Some tools can route a category to a person automatically; most small desks just tell the triager, and the triager is the routing rule.

The expert's rule during a swap is to answer questions and never take the ticket back. The temptation is enormous, because Tom could fix the grey screen in four minutes and Aisha will take twenty-five, and the handler is waiting, and Tom is right there. Taking it back costs one thing: the next twenty-five minutes Aisha would have spent getting to twenty, then fifteen, then four. The swap is an investment paid in slower tickets for a month. The return is a second person for a system, which is the only return the whole series is after. Tell the requester the truth, which is that Aisha is handling it and Tom is available; nobody minds, and most do not notice.

The expert writes what they would have done differently as an internal note on the ticket, not as a correction in the corridor. An internal note is a message on the ticket that the desk sees and the requester does not. It is the right place for "you restarted the service before checking the log; the log would have told you it was the licence". The note is attached to the exact ticket. It is there when the learner reads the ticket back. It is there in three months when a third person is swapped onto the same system and wants to know what the first learner got wrong. Corridor corrections evaporate by lunch. Notes compound.

Run the swap for a fixed span and then end it, out loud. An open-ended swap is just a quiet way of transferring a system to the junior person for ever. A month or ten tickets is long enough for the learner to meet the common failures and short enough to be felt as a sprint. At the end, the pair looks at the tickets together and the grid cell changes if it has earned the change. The next swap is set up with a different pair or a different system. The method of watching a learner work without taking over, the shadow and its reverse, is owned by Shadowing That Actually Teaches. The swap borrows it wholesale.

The Shadow Day

The shadow day is one day a quarter in which the learner sits beside the expert for whatever arrives. It exists for the knowledge that never comes in as a ticket. The monthly job. The vendor call. The thing the expert does at 08:15 before anyone else is in, that nobody has ever asked about because it has never failed. A half hour with a written outcome cannot find those, because nobody knows to write them down. A day of sitting beside someone finds them in the first hour. Usually the learner says "what was that you just did?" and the expert says "oh, that, that's nothing", and it turns out to be the payroll export.

Run the shadow day forwards in the first quarter and backwards in the second. Forwards: the learner watches, asks, and keeps a one-page log of everything the expert touched that the learner could not have done. That is a list of half-hour outcomes for the next twelve weeks. Backwards, the reverse shadow: the expert sits beside the learner and watches them take the day's tickets for the system. The expert says nothing unless asked or unless something is about to break. The reverse shadow is the test the forwards shadow sets. It is the day the expert finds out how much of what they know they have actually managed to pass on. Usually it is less than they thought and more than the learner thinks.

A shadow day costs a day of the learner's queue time, which is why it is quarterly. It is also why it is booked the way leave is booked: in the rota, in advance, with cover arranged. Booked any other way it is the first thing cancelled on the morning, and the learner spends the day on their own tickets with the expert four desks away. A shadow day that gets interrupted is still worth most of a shadow day; a shadow day that gets cancelled is worth exactly what a cancelled day is worth.

The Teach-Back

The teach-back is the learner explaining the system to a third person in ten minutes, and it is the test the other three rhythms are preparing for. The third person can be a colleague who has never touched the system, the newest technician, or the whole desk at its weekly huddle. The huddle is the natural venue and has its own article later in this series. The format is fixed: what the system is for, what breaks, how you tell, what you do first, when you stop and call for help. Ten minutes, standing, no slides. Slides are how people avoid finding out whether they understand something.

The teach-back catches the learner who can follow steps and cannot explain them. That is the most common state after a month of swap and the most dangerous. It looks like competence on every ticket where the steps work. A person who can say why the service is restarted before the cache is cleared will cope with the day the order matters. A person who knows only the order will restart the service twice and then phone the expert, who is on a beach. The expert listens to the teach-back and marks the gaps, gently, afterwards, and the gaps are the next half hour's outcome.

The grid cell changes to "alone" after a teach-back and a solo ticket, not after either on its own. The solo ticket proves the hands; the teach-back proves the head. A desk that only requires the ticket produces technicians who can do the thing on a good day. A desk that only requires the teach-back produces technicians who can describe the thing beautifully and have never done it under pressure. Both halves, then the cell changes, then the date and the ticket number go on the grid as the evidence.

What to Cross-Train First

Across systems, the first thing to cross-train is the one only one person can do that breaks most often; the audit ranks those and this article does not redo the ranking. Within a system, there is also an order, and it is the order of how often each thing is needed, not of how impressive it is. The restart first, because a restart fixes most things and a learner who can do it alone has already taken the most frequent call off the expert. The common failure second: the one error that comes in monthly, with its recognition test and its workaround. The scheduled job third, the monthly export or the quarterly renewal, because it is the one that fails when the expert is away. The rebuild last, if ever, because a rebuild is a project and not a rhythm.

Do not start with the rebuild. Every expert wants to start with the rebuild, because it is the thing they are proudest of and the thing that shows how the system really works. It is also the thing the learner will need once in four years. Suppose a learner has spent six half hours on the architecture of the claims system and none on restarting it. That learner can draw a diagram while the handlers wait. Save the architecture for the shadow day, where it comes up naturally, and spend the half hours on what the tickets actually ask for.

Keeping the Rhythm When the Queue Is On Fire

The rules for a bad week are decided in a good week, and written down, because nobody designs a policy well at 14:00 with sixty-one tickets open. Here are the ones that have held on the desks I have watched keep going. The half hour moves within the week, never out of it, and if it reaches Friday unmoved it happens on Friday at whatever time is left. The ticket swap pauses when the learner's own queue is over a threshold the desk agreed in advance, and resumes the day it drops under. The expert takes the system's tickets meanwhile and says so in the swap ticket, so the pause is on the record. The shadow day is rebooked within the quarter, not dropped from it. Only a major incident, the kind with its own lead and its own bridge, cancels a slot outright. Even then the slot is rebooked before the incident review closes.

Count the skips, and make three in a row somebody's problem other than the pair's. A skip is a slot that left its week; a pause is a swap that stopped for the agreed reason. Both go on the calendar template at the end of this article in a column of their own, and the column is read at the monthly review. One skip is a busy week. Two is a pattern. Three in a row means the desk cannot spare a half hour a week. A desk that cannot spare a half hour a week has a load problem that the pair cannot fix and the manager must. That is a different conversation from "please try harder to keep the slot". The skip count is how that conversation starts with a number rather than a feeling.

A queue that is on fire for a month is not a reason to stop cross-training; it is usually a reason the desk needed it. A desk digs out of a backlog by the one-time method in Backlog Recovery. The digging goes faster when more than one person can touch each pile, which is exactly what the half hours have been building. Keep the half hour through the dig-out, aimed at whichever system the backlog is heaviest in, and it pays for itself inside the month. The desk that suspends cross-training "until things calm down" has decided that things will calm down on their own. Things rarely do that.

Where the fire never goes out, and the slot is skipped most weeks for a quarter, stop treating it as a cross-training problem. A desk that cannot find thirty minutes a week per person is running at a load that the people on it will not sustain. That is the territory of Sustainable Pacing rather than of this article. The honest thing to put in the report is "cross-training skipped nine of thirteen weeks; the desk is running without slack", and to let that sentence do its work. A rhythm that cannot survive the month is a message about the month.

What Counts as Done

A system is cross-trained when the learner has done a real ticket alone and given a teach-back. The grid cell must also have changed to "alone" with a date and a ticket number beside it. That is the same evidence standard the audit uses, and it is deliberately higher than "we did some sessions". Sessions are the input. The cell is the output. A pair that has met for twelve weeks and produced no cell change has had twelve pleasant conversations. The grid will say so at the next audit, which is why the grid and the calendar are kept together.

When the cell changes, the pair rotates. The learner, now a second owner, becomes next quarter's expert for a third person. That is the cheapest cross-training there is. The newest owner remembers exactly what was hard to learn and the original expert has long forgotten. The original expert takes a learner for a different system, or becomes a learner themselves for something they hold no mark on. A desk where the senior person is only ever the expert is a desk where the senior person never learns anything, which they will eventually notice.

Keep the span honest. A learner who has not reached "alone" after a quarter has not failed; the plan has. Usually the outcomes were too large, the swap was taken back too often, or the slot was skipped. Look at the skip column before looking at the person. Then reset the outcomes smaller, restart the swap with a firmer rule for the expert, and give it another quarter. Cross-training is slow in the way that compound interest is slow, and the desks that keep it going for a year look, at the end, like different desks.

A Short War Story: After Peak Season at Bellweather Logistics

Bellweather Logistics ran four warehouses, and the link between the warehouse scanners and the stock system was built, tuned and nursed by Nadia. She was the only person on the six-person desk who could restart it correctly when it stalled, which it did every few weeks. Cross-training Nadia's integration was agreed every year and scheduled "for after peak season". After peak season there was the stock count, and then the spring projects, and then it was nearly peak season again. Cross-training was postponed through three peaks in a row without anyone ever deciding against it. Nadia handed in four weeks' notice in the autumn, two weeks before the fourth peak. She spent her notice period mostly on tickets because the queue was already full. The integration stalled nine days after she left, and the desk could not restart it. The warehouses picked and packed from printed lists for two days while a contractor was found. The contractor took six weeks and a paid engagement with the stock system's vendor to understand what Nadia had known. The operations director's review put the cost at the contractor, the vendor engagement, and two days of manual picking across four sites. It also counted a peak season spent one person short on the desk. The lesson the desk wrote on the wall was short: there is no after peak season.

The Cross-Training Calendar

The calendar below is one quarter of the weekly half hour on a single page, with the swap, the shadow day and the teach-back marked where they fall. Fill the pairs and systems from the top three on the bus-factor grid. Write the outcome for each week before the week starts, in one line, specific enough to be done or not done. Mark each week as done, moved within the week, or skipped, and count the skips at the monthly review. The last block records the evidence that lets the grid cell change.

CROSS-TRAINING CALENDAR — ONE QUARTER
Desk: ______________   Quarter: ________   Slot: ________ (day and time)

Rules agreed for a bad week
  Half hour: moves within the week, never out of it.
  Swap: pauses when the learner's queue is over ____ open; resumes on record.
  Shadow day: rebooked within the quarter, never dropped.
  Three skips in a row: raised with ______________ (manager).

PAIR 1   System: _______________   Expert: ________   Learner: ________
Week  Outcome (one line, specific)                       Done/Moved/Skipped
 1    _______________________________________________    ______
 2    _______________________________________________    ______
 3    _______________________________________________    ______
 4    _______________________________________________    ______
 5    SWAP STARTS: next ___ tickets to learner          ______
 6    _______________________________________________    ______
 7    _______________________________________________    ______
 8    _______________________________________________    ______
 9    SWAP ENDS: review tickets together                 ______
10    _______________________________________________    ______
11    TEACH-BACK at the huddle                            ______
12    Grid cell review                                    ______
Shadow day booked for: ________   Direction: [ ] forwards  [ ] reverse

PAIR 2   System: _______________   Expert: ________   Learner: ________
Week  Outcome (one line, specific)                       Done/Moved/Skipped
 1    _______________________________________________    ______
 2    _______________________________________________    ______
 3    _______________________________________________    ______
 4    _______________________________________________    ______
 5    SWAP STARTS: next ___ tickets to learner          ______
 6    _______________________________________________    ______
 7    _______________________________________________    ______
 8    _______________________________________________    ______
 9    SWAP ENDS: review tickets together                 ______
10    _______________________________________________    ______
11    TEACH-BACK at the huddle                            ______
12    Grid cell review                                    ______
Shadow day booked for: ________   Direction: [ ] forwards  [ ] reverse

MONTHLY REVIEW
  Month 1: done ___  moved ___  skipped ___   Swap paused? ____ reason: ________
  Month 2: done ___  moved ___  skipped ___   Swap paused? ____ reason: ________
  Month 3: done ___  moved ___  skipped ___   Swap paused? ____ reason: ________

EVIDENCE FOR THE GRID
  System: ___________  Learner: ________  solo ticket: ________  teach-back on: ________
  Cell changed to "alone" on: ________   Next pair: ________ with ________

Frequently Asked Questions