Home › Topics › Training & Developing Technicians › Shadowing

Shadowing That Actually Teaches a New Technician

Tuesday, 10:15, at Ashgrove Housing. Leah has been shadowing Marcus since yesterday morning, and Marcus has just fixed a tenant portal login in about four minutes without saying a word. He opened the ticket, opened two other windows, and typed something. He closed one window, typed something else, wrote "cleared the stale session, user confirmed" and moved on. Leah, who has a notebook open and a pen in her hand, has written down "cleared stale session". She has no idea what a stale session is, or which of the two windows was the one that mattered. She does not know how Marcus knew to look there rather than resetting the password, which is what she would have done. She asks. Marcus thinks about it and says, honestly, "I don't know, you just sort of know." He has been doing this for six years. That answer is the whole problem with shadowing.

Shadowing is a new technician sitting beside an experienced one while real tickets are worked. Its stated purpose is moving judgement from one head to the other, and it fails by default because judgement is silent. The expert does not know what they know; they see a symptom and a cause arrives, and the steps between were compressed into nothing years ago. Shadowing that teaches is shadowing that forces the steps back out into the open, in words, in order, where the trainee can hear them and write them down. This article is part of our Training & Developing Technicians series. It is about the four steps that do that: watch, do with, do alone, teach back.

It covers why watching alone teaches nothing, then the four steps and what the trainer does at each. Next come narrating the diagnosis aloud, doing with and the "what next?" question, doing alone with help on call, and teaching back. Then come the reverse shadow, where the trainer watches, and the mistakes a trainee is allowed to make. A short war story and the shadow log to copy finish the article, in that order.

Why Watching Alone Teaches Nothing

Watching an expert work shows the trainee what the expert's hands did and hides everything the expert's head did. The head is the part the desk is trying to copy. Marcus looked at the ticket and saw "can log in on my phone but not on the desktop". He knew in half a second that the password was fine and the desktop's session was the suspect. Leah saw him open two windows. The half-second was the lesson, and it happened in silence. A week of silent shadowing produces a trainee who can describe the screen and cannot reproduce the thinking. The first ticket that differs slightly from one they watched will stop them cold.

The second thing silent shadowing teaches is the wrong lesson about pace. An expert on a busy queue works fast, skips the checks they have learned they can skip, and types from memory. A trainee who copies that pace without the memory behind it will skip the checks that were holding the fix together. I have watched a new technician reproduce, exactly, a senior colleague's habit of not reading the second paragraph of a ticket. The senior colleague could usually guess it and the trainee had never seen them read it. The senior colleague guessed right most of the time. The trainee did not.

The fix is not more watching. It is making the expert talk, making the trainee write, and then swapping the chairs so the trainee works and the expert talks less each day. That is the ladder, and the rest of this article walks up it.

The Four Steps and What the Trainer Does at Each

The four steps are watch, do with, do alone and teach back. The trainee does more at each one while the trainer does less, which is the whole design. At step one the trainer drives and narrates; the trainee watches, asks and writes the log. At step two the trainee drives and the trainer sits beside them asking "what next?" before each click. At step three the trainee works alone inside an agreed list of ticket types, with the trainer reading their notes the same day. At step four the trainee explains a fix to a colleague, and the trainer listens and corrects only what is wrong. The picture below draws the ladder, with the trainer's and the trainee's job at each step and the gate that moves the trainee to the next one.

The shadow ladder drawn as four rising steps: watch, do with, do alone, teach back, each taller than the last to show the trainee doing more. A grid beneath gives three rows. The trainee watches, asks and writes the shadow log; drives the keyboard with the trainer beside; owns easy tickets and asks early when stuck; walks a colleague through a fix. The trainer narrates every step and the reason; asks what next before each click; reads the notes the same day; listens and corrects only what is wrong. The move-on row gives each gate: the log shows why and not only what; the trainee picks the next step first; easy tickets close cleanly with no reopens; a peer can follow the explanation.
Four steps; the trainee does more at each, and a step is passed at its gate, not after a set number of days.

The steps map onto the weeks of the first thirty days loosely, not exactly. A trainee can be at step three on password tickets and step one on hardware faults in the same afternoon. Shadowing is done per kind of work, not per person. The log, described later, keeps track of which step the trainee has reached on which kind of ticket, and that record is the only honest answer to "is she ready for printers yet?".

Step One: Narrating the Diagnosis Aloud

Narrating means the trainer says, before each action, what they see, what they suspect, what they are about to check and what they expect to find. Afterwards, they say whether they found it. "The user can sign in on the phone, so the password is fine. I suspect the desktop has a stale session. I'm going to look at the active sessions for the account, and if I'm right there will be one for the desktop that is hours old. There it is." That is four sentences and about fifteen seconds, and it contains the entire lesson that Marcus's silent four minutes hid.

Trainers find narration uncomfortable, and the discomfort is the proof that it is working. Saying the reasoning aloud exposes the places where there was no reasoning, only habit. The trainer discovers they check a thing they cannot justify or skip a thing they should not. Marcus, narrating on day three, caught himself saying "and I don't check the account lockout status because, hm, actually I should", and the trainee learned two things from one sentence: the check, and that experts have blind spots. (Trainers also discover that they say "basically" a great deal. This is fine.) The narration will be clumsy for a day and fluent by the third. Push through the clumsy day.

Narration slows the trainer by about half, and the desk pays for it by cutting their load. That is a decision the lead makes before shadowing starts rather than a thing the trainer absorbs. The trainer also writes a short version of the narration into the ticket, so that the reasoning survives the conversation. If you run QuerySolv, the internal note on the ticket is the natural place. The requester never sees it and the trainee can reread it that evening alongside the shadow log. Most tools have an internal note or a private comment that does the same. A ticket that carries the reasoning as well as the fix is a training article the desk did not have to schedule.

Step Two: Doing With and the "What Next?" Question

At step two the trainee has the keyboard and the trainer has one question, which is "what next?", asked before each click and answered before anything is touched. The trainee says what they are about to do and why. The trainer says "go on" or "why that?" The trainer only intervenes when the proposed step would cause harm or when the trainee is stuck for longer than a minute. The point is to move the narration from the trainer's mouth to the trainee's, so that the reasoning is tested before it drives the mouse. A trainee who can say "I'll check the sessions first because the phone works" has learned the thing. One who clicks and then explains is still guessing and tidying up afterwards.

The trainer's hardest job at this step is not touching the keyboard. Every trainer has reached across to "just do this bit", and every time they do, the trainee learns that the bit is beyond them, which is usually untrue. Sit on your hands. Let the trainee take three minutes over a thing you would do in twenty seconds. The twenty seconds were paid for by six years; the trainee has had two weeks, and the three minutes are how they get the years. The exception is harm. A step that would lock an account, delete a mailbox rule the user made, or send a reply that should not go out is stopped with a word. The word is "wait", not a hand on the mouse.

Doing with also covers the replies. Every message the trainee writes to a requester at this step is read by the trainer before it goes. The trainer says what they would change, in one or two sentences, and why. Tone is caught here or not at all; a trainee who sends forty unread replies in their first fortnight has set their tone for the year. By the end of this step the trainer should be approving replies without changes most of the time. That, together with the trainee picking the next step unprompted, is the gate to working alone.

Step Three: Doing Alone With Help on Call

At step three the trainee works a listed set of ticket types without anyone beside them. The two rules are that they ask early and that the trainer reads their notes the same day. "Early" needs a number, and the number I give is fifteen minutes. If the trainee has been stuck on one thing for fifteen minutes, they write a note in the ticket saying what they have tried and ask. Not forty-five minutes, because the requester is waiting and the trainee is now guessing. Not two minutes, because the first flash of not knowing is not the same as being stuck, and the trainee has to learn to sit in it for a while. Fifteen minutes of trying, then a note, then a question. The note is the price of the question, and it is also how the trainer sees what the trainee tried.

The same-day note read is the trainer's whole job at this step and it takes twenty minutes at the end of the afternoon. They open each ticket the trainee closed and read the notes and the resolving reply. They leave one line for the trainee: what was good, and what a stranger picking the ticket up in a year could not follow. The standard the notes are read against is in The Working Note Habit. The trainer applies it, kindly, every day. The trainee's notes improve faster than any other skill on the desk, because the feedback arrives hours after the writing and not weeks.

The listed ticket types are the boundary, and the trainee needs to know that stepping outside it is handled by escalation rather than by courage. A ticket off the list is claimed by someone else or handed over with a note saying why, and that handover is a correct outcome, not a failure. Trainees who are praised for escalating in their first month escalate properly for the rest of their careers. Trainees who are teased for it learn to go quiet instead, and a quiet trainee with a hard ticket is the most expensive thing on a help desk.

Step Four: Teaching Back

Teaching back is the trainee explaining a fix to someone else, start to finish, with the reasoning. It is the only test of understanding that cannot be passed by memory. The audience is a colleague who did not see the ticket, or the trainer pretending not to have. The format is the narration from step one with the chairs swapped: what I saw, what I suspected, what I checked, what I expected, what I found. The trainer listens for the places where the explanation jumps, because a jump is where the trainee is reproducing a path rather than understanding it. "And then I cleared the session" is a jump if the trainee cannot say how they knew it was a session.

Teach-back works best as a routine rather than an exam. Once a week, the trainee walks the desk through one ticket from the week, for five minutes, in whatever huddle the desk already has. The questions from colleagues do the testing. The rhythm is the same one a desk uses for cross-training between experienced people, which Cross-Training Rhythms That Survive a Busy Month describes. A desk that already runs a ticket of the week has the slot ready. The trainee's first teach-back is also the moment they stop being the new person and start being a colleague who knows something, which is worth more than the five minutes suggest.

The trainer's rule at step four is to correct only what is wrong. A trainee's explanation will be longer than the trainer's, in a different order, and will check a thing the trainer would skip, and none of that is wrong. The temptation to say "I'd have done it this way" is strong and should be resisted, because the trainee has found a way that works and now owns it. Correct the error, praise the check, and let the order be theirs. The gate out of step four is that a peer could follow the explanation and reproduce the fix, and the peer is the judge.

Remember: shadowing transfers judgement only when the judgement is spoken. The trainer narrates at step one, asks "what next?" at step two, reads the notes at step three and listens at step four. The trainee moves up when the gate is met, per kind of ticket, not after a number of days.

The Reverse Shadow

The reverse shadow is the trainer sitting beside the trainee for an hour, in silence, watching them work tickets at step three. It exists because the notes and the closed tickets show what the trainee did but not how they got there. The trainer watches what the trainee reads first, where they hesitate, what they open out of habit and what they never open at all. The trainer says nothing until the hour ends. Then they debrief: three things seen, in the order they were seen, with no opinions attached until the trainee has had a chance to explain. The reverse shadow finds the habits that are forming while they are still cheap to change.

What the reverse shadow finds is rarely a technical gap. It is the trainee reading the subject line and not the body, or starting to type a reply before the fix is confirmed. It is never looking at the ticket's history to see whether the requester has asked before. Or, in one case I remember fondly, it is keeping a personal list of fixes in a text file instead of searching the knowledge base. That was because the knowledge base had been slow once in week one. None of those appear in a closed ticket. All of them appear in an hour of watching, and each takes a sentence to fix once it is named. The event history on the ticket shows the order things happened in afterwards; the reverse shadow shows the order the trainee thought in, which is the thing worth correcting.

Do the reverse shadow twice in the first month and once a quarter afterwards, for everyone, and say so. A reverse shadow that is only ever done to new people is surveillance with a friendly name. One that the senior technician also submits to, with the trainee watching, is a desk habit, and the senior technician will learn something too. They will not enjoy it. That is how you know it was worth doing.

The Mistakes That Are Allowed

A trainee who does not know which mistakes are allowed will make none, which sounds safe and is the opposite. A trainee who makes no mistakes is a trainee who touches nothing and learns at the pace of watching. The trainer's job is to say, on day one, in writing, which errors are fine, which are fine with a colleague present, and which are never made alone. The list makes the trainee bold inside the safe area and careful at its edge. It saves the trainer from the anxious "is it all right if I...?" that otherwise arrives every eleven minutes.

The table below is the shape of the list. It sorts mistakes by how reversible they are, because reversibility is what makes an error a lesson rather than an incident. A wrong guess at a printer fault costs a second visit. A wrong click on a shared mailbox's permissions costs an hour and a conversation. A wrong change to the directory costs the afternoon and a report. The trainee works freely in the first row, with a colleague in the second, and never alone in the third until the lead says otherwise, in writing, with a date.

Kind of mistakeExamplesRule for the traineeWhat the trainer does
Reversible on the spotWrong first guess at a fault; a reply that is too long; a ticket put in the wrong queue; clearing a print job that was still wantedMake them freely; note what happened; move onMentions it in the same-day note read, once, without ceremony
Reversible with helpA permission granted to the wrong group; a setting changed on the wrong user; a reply sent to the wrong requesterAllowed with a colleague beside you; otherwise ask firstFixes it with the trainee watching; records it in the ticket; no blame
Not reversible without a reportChanges to the directory, the mail flow, the firewall or a shared file store; anything on a server; anything touching a person's recordNever alone until the lead widens the list in writingKeeps these off the trainee's queue; escalations carry a reason

Say the first row aloud, too, because a written list is read once and a sentence is remembered. "You are going to guess wrong about printers for a month and I will not mind." It is a kind thing to say and a true one, and a trainee who has heard it will try the second guess instead of freezing after the first. The list is not a licence to be careless. It is a description of where care is needed, and the trainee who has it knows the difference. The one who does not learns the three rows by falling into them, in order, over a year.

A Short War Story: The Silent Fortnight at Bellweather Logistics

At Bellweather Logistics, a new technician called Sam shadowed Dev, the desk's senior, for a fortnight in which Dev worked his normal queue, said very little, and was, by every account, pleasant about it. Sam watched Dev reset the depot's dispatch terminals eleven times in those two weeks and wrote "reset terminal" eleven times in a notebook. On the Tuesday after Dev went on leave the terminals at the Eastfield depot stopped. Sam reset the one he could reach, which was not the one that mattered, and the depot loaded by hand until two in the afternoon. The desk lead later worked out that the fix was two clicks. Dev could have narrated it in twenty seconds any of the eleven times. The morning had cost the depot something like thirty staff hours plus a conversation with a customer who had been promised a lorry by nine. Dev was mortified, which was unfair, since nobody had told him to talk. Shadowing without narration transfers presence, not knowledge, and the desk had paid for a fortnight of presence.

The Shadow Log

The log below is kept by the trainee from the first morning, one row per ticket seen or worked. It is read with the trainer for ten minutes at the end of each day. The columns are deliberately few: what the ticket was, which step the trainee was at, what was tried and why, and what the trainee would not have thought of. The last column is the one that matters, because it is where the expert's hidden step gets written down. A log with that column full is a knowledge base entry waiting to be tidied. Keep one page per day. By the end of the month the stack shows which kinds of ticket the trainee has climbed the ladder on and which they are still watching. That stack is the answer to "ready yet?".

THE SHADOW LOG — ONE PAGE PER DAY
Trainee: ______________   Trainer: ______________   Date: ____________

Step reached today, by kind of ticket (W = watch, D = do with, A = alone, T = teach back)
  Passwords and lockouts: ___   Printers: ___   How-do-I: ___
  Software installs: ___        Access requests: ___   Hardware: ___
  Other: ______________ ___

Ticket    Kind of ticket     Step   What was tried and why
________  ________________   ___    ___________________________________
________  ________________   ___    ___________________________________
________  ________________   ___    ___________________________________
________  ________________   ___    ___________________________________
________  ________________   ___    ___________________________________
________  ________________   ___    ___________________________________
________  ________________   ___    ___________________________________
________  ________________   ___    ___________________________________

The thing I would not have thought of today:
  ______________________________________________________________
  ______________________________________________________________

The thing I was stuck on for more than fifteen minutes, and what I asked:
  ______________________________________________________________

Reply read by the trainer before sending:  ____ of ____   Changed: ____

Read together at ______ (time).   Trainer's one line for tomorrow:
  ______________________________________________________________

Leah's log for the Tuesday has one line in the last-but-one box: "Phone works, desktop doesn't: it's the session, not the password. M. didn't know he knew this." Marcus read it that evening and laughed, and then narrated every ticket for the rest of the week, badly at first and then not. By the second Friday Leah was doing the portal logins with Marcus asking "what next?" By the third she was doing them alone and he was reading her notes at four o'clock with a coffee. She taught the session fix back to the desk in the Friday huddle in week four. Marcus sat at the back and corrected nothing.

Frequently Asked Questions

Our best technician is a poor explainer. Should they still be the trainer?
Not necessarily. The trainer needs to be competent and willing to narrate, and the second quality matters more than being the best on the desk. Choose someone a year or two in who remembers not knowing, and let the best technician be the person the trainer escalates to. If the best technician is the only option, give them the narration script in this article and expect a clumsy first week; most people get fluent by day three.
How long should the trainee stay at the watching step?
Until the shadow log shows reasoning rather than clicks, per kind of ticket. On common categories that is usually a few days and on rare ones it may be months, because the trainee has to see enough examples. Do not set a number of days for the whole step. Move the trainee to doing-with on the kinds of ticket they can explain, and keep them watching on the ones they cannot.
The queue is on fire and the trainer has no time to narrate. What then?
The lead takes tickets off the trainer, visibly, on the queue, before the shadowing starts, and takes more if the week turns bad. Narration roughly halves the trainer's pace, and a trainer with a full queue stops narrating by Wednesday without meaning to. If the fire is genuine, pause shadowing for the day and say so, rather than letting it quietly become silent watching.
What if the trainee asks for help constantly instead of trying?
Give them the fifteen-minute rule and the note. They try for fifteen minutes, write what they tried in the ticket, and then ask. The trainer answers questions that arrive with a note and gently sends back the ones that do not. The note is the price of the question. Most constant askers are trainees who were never told how long they were allowed to be stuck, and a number fixes it.
Can shadowing work when the desk is remote and nobody sits beside anyone?
Yes, with a shared screen and the microphone open; narration works as well over a call as across a desk, and some trainers find it easier. Keep the sessions to an hour or two with breaks, because listening to a shared screen is tiring. The shadow log, the same-day note read and the teach-back are all unchanged, and the reverse shadow is simply the trainee sharing their screen instead.
Should experienced technicians shadow each other too?
Yes, and it is the best cross-training a small desk has. A day a quarter in which one technician narrates their specialty to another, with a log, spreads the knowledge that otherwise lives in one head. The teach-back in the weekly huddle keeps it spread. The mechanics are the same as for a new starter; only the step they start at is different.

From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.