The New Technician's First Thirty Days on the Desk

Monday, 08:50, at Tollgate Foods. Omar starts today. There is a laptop on the spare desk, still in its box, and a chair. There is a note from Carol, the desk lead, that says "shadow Jess for a bit, back at eleven". Jess has thirty-one open tickets, a printer that has been down at the depot since Friday, and a phone that started ringing at 08:31. She says hello, means it, and then takes a call about a locked account. Omar sits beside her and watches a screen he cannot read yet. By eleven he has seen nine tickets, understood two, and written nothing down, because nobody said he should. Carol comes back and asks how it is going. "Great," says Omar, who is twenty-three and polite. That answer will be the only measurement of his training for the next four weeks.

The first thirty days are the stretch between a technician's first morning and the day the desk calls them independent. This article treats that stretch as a plan with four weeks and four gates rather than a chair beside someone busy. The plan has a shape that repeats on every desk I have seen do it well. There is a week of watching, then a week of doing with someone beside you. Next comes a week alone on the easy work. A week of review follows, widening the work. It ends with someone saying, out loud and on purpose, "you are on your own now". This article is part of our Training & Developing Technicians series. The series covers how a desk turns a new hire into a technician and a technician into something more.

This article covers what the thirty days are for, then what must be ready before day one, including the buddy. Next come week one, shadowing, and the first ticket, chosen on purpose. Then come week two, doing with; week three, alone on the easy categories; and week four, review and widening. It covers what "independent" means and who gets to say it, then what to do when the plan slips. A short war story follows, then the thirty-day plan to copy.

What the Thirty Days Are For

The thirty days exist to get the new technician to a defined finishing line. And the finishing line is not "has been here a month". It is a short list of things the technician can now do without anyone beside them. They can take a ticket in a known category and work it to a clean close with notes a stranger could follow. They know when they are out of their depth. They ask for help before the requester has to. A technician who can do those four things is independent. One who cannot is still training, however many weeks have passed. And a plan that measures weeks instead of gates will declare people ready on a date they have never met.

The weeks are a rhythm, not a rule. A hire who has run a desk before may pass through the first week in two days. A hire from a non-technical background may need the second week twice. The plan sets the order and the gate for each stage and lets the calendar bend. What it does not allow is the thing that happens by default. The new technician drifts from watching to working with no moment anyone can point to. Months later, they are judged by a standard nobody ever stated. The desk owes its new hire a stated standard. It is cheaper to write it down than to argue about it in a probation review.

The plan also protects the desk. A new technician let loose on the queue in week one will take tickets they cannot finish. They will write replies the desk would not have sent and close things that come straight back. Every one of those costs a colleague more time than the training would have. I have seen a desk lose a fortnight of a senior technician's time cleaning up after a new hire's first week of enthusiasm. Nobody was at fault. The queue had simply been allowed to train him, and the queue is not a patient teacher.

Before Day One: Kit, Accounts and the Buddy

Three things must exist before the new technician sits down: a working computer, working accounts, and a named buddy. The buddy's own workload must have been cut to make room. The first two are an ordinary employee onboarding. And the desk should run its own new starter through the same process it runs for everyone else. The checklist, the role profile and the before-the-start-date request are all in The Day-One Checklist. And this article will not redo them. A desk that cannot onboard its own technician on time has a story it does not want to tell at the next management meeting. Treat the new hire's ticket as the dress rehearsal it is.

The technician's accounts are longer than an ordinary starter's. They need an agent login to the ticketing tool, with the same permissions as a junior colleague and no more. They need access to the knowledge base, including the articles visible to agents only. They need the shared mailboxes the desk watches. They need the remote support tool, with their own named account rather than a shared one. They need the password vault, with access to the low-risk entries only until the lead widens it. Write that list down once, as the role profile for "help desk technician". Then the next hire's accounts take an hour instead of a week of "oh, you'll need that too". The handover from hiring to training, the start date and the first morning, is covered in The Offer, the Start and the First Week. This article takes over from the moment the chair is occupied.

The buddy is the one person who owns the new technician's training for thirty days. And the choice matters more than any other decision in this article. Choose a technician who is good at the work and patient about explaining it. Those are two different qualities and not always found together. Do not choose the lead, who will be interrupted. Do not choose the most senior person, who has forgotten what it is like not to know. Do not choose whoever happens to sit at the spare desk. Choose someone a year or two in, who remembers their own first month and still has opinions about it. Then cut their ticket load for the month, visibly, on the queue. That makes the time spent narrating time the desk gave them and not time they stole from the backlog. A buddy with a full queue trains nobody. They just have company.

Week One: Shadowing

Week one is watching, and watching only teaches when the person being watched talks. The buddy takes tickets as normal and narrates what they read first and what they suspected. They explain why they checked the thing they checked and what they would have done if it had come back different. The new technician keeps a shadow log. That is a plain list of every ticket seen with one line on what was tried and why. The new technician reads it back to the buddy at the end of each day. The log is the week's output. A week of shadowing with no log is a week of sitting, and the technician will remember the chair and nothing else. The mechanics of narrating, the reverse shadow and the log itself belong to Shadowing That Actually Teaches; week one is where that article is applied.

Day one has two jobs beyond the chair: the knowledge base and the queue. The technician reads the knowledge base in a set order. That order is the subject of The Knowledge Base as a Training Tool. The aim is that by day two the words on the buddy's screen have meanings. Then the buddy walks them through the queue: what the statuses mean and what the priorities mean. The buddy explains who the other names are and what they hold, and where tickets go when they leave the desk. The picture below shows the four weeks as a strip, with the milestones above it. The scope in which the technician works alone widens beneath. Day one is at the far left. And the strip is the plan the rest of this article fills in.

By Wednesday the technician should be able to say what the buddy did and why, in that order. They should be able to do this for any ticket the buddy has just closed, without looking at the screen. That is the gate out of week one: the log shows the reasoning, not just the clicks. A technician who can list the clicks has memorised a path. A technician who can say why has started to learn the territory. And the difference shows the first time a ticket arrives that is not quite the one in the log.

The First Ticket, Chosen on Purpose

The first ticket the new technician works should be picked by the buddy, on about day three. And it should be chosen for what it teaches rather than for what is next in the queue. The queue will offer the technician a vague slowness complaint from the finance director with a four-year history and a reopen. That is a fine ticket for month six. The first ticket is a password reset for a cheerful requester in a department that likes the desk. Or it is a printer that needs its queue cleared, or a "how do I" that the knowledge base answers in one article. The technician works it from first reply to close, with the buddy beside them, and sees the whole life of a ticket in forty minutes.

A good first ticket has five properties, and the buddy checks them before handing it over:

• It is in a category the desk sees every day, so the second one arrives soon.
• The fix is known and written down in the knowledge base.
• The requester is patient and not senior enough to be a lesson in anything else.
• There is no deadline attached to it and no service-level target about to be missed.
• It can be closed the same day with a note the technician writes themselves.

The first ticket teaches the shape of the work, not the content. The technician learns that a ticket is claimed before it is worked. The first reply goes out before the fix is started. The fix is written down as it is done. The resolving reply says what was done in words the requester can test. The note at the close is for a stranger. Those habits are the ones the desk will live with for years. (The password reset itself takes ninety seconds and nobody remembers it.) Choose the ticket for the habits.

Week Two: Doing With

In week two the technician drives and the buddy sits beside them. The buddy's job changes from narrating to asking. "What do you want to look at first?" "Why that?" "What would you expect to see if you are right?" The questions come before each click, and the technician answers before touching anything. That way the reasoning is said aloud before it is tested. This is slower than the buddy doing it, by roughly double, and the slowness is the training. The desk has already paid for it by cutting the buddy's load. Spending the time is the return.

Every public reply in week two is read by the buddy before it is sent. This is not a lack of trust. Every word the technician sends a requester will be read by someone who can fix it before it lands. This is the only moment in a technician's career when that happens. Tone is learned by correction, and one voice across five people is only possible if the fifth person learns the voice from the first four. The buddy reads, says what they would change and why, and the technician changes it. By Thursday the buddy should be changing very little, and that is the measurement.

The technician's own tickets start in week two, claimed under their own name, with the buddy as the person they turn to. Tickets in week two are still chosen: the easy categories and the known fixes. The requesters are ones who will not mind a reply that is slightly longer than it needed to be. The gate out of week two is that the technician names the next step before the buddy asks, most of the time. This applies to the categories they have been given. When the buddy finds themselves saying "yes, that" more than "what about", the week is over, whatever the calendar says.

Week Three: Alone on the Easy Categories

Week three is the first week the technician works alone. "Alone" means alone on a written list of categories and nothing outside it. The list is short. On most desks it includes password and lockout tickets, the common "how do I" questions and printer queue faults. On those desks, it also includes basic software installs from the approved list and new starter kit that follows the role profile. Those categories share a shape: the fix is known, the knowledge base holds it, and the worst outcome of getting it wrong is a second visit. Anything off the list is claimed by someone else or escalated by the technician with a note saying why. Escalation in week three is a sign the plan is working, not a sign the technician is weak.

The buddy's job in week three moves to the end of the day. They read the notes on every ticket the technician closed, the same day, and say what was good and what a stranger could not follow. The notes are the week's output in the way the log was week one's. A technician who closes twelve tickets with readable notes has done more for the desk than one who closes twenty with "fixed, closed". The second technician has produced twenty tickets the desk will have to work again when they come back. The habit, and the standard the notes are read against, are in The Working Note Habit; the buddy applies it kindly and daily.

Visibility in week three comes from the queue, not from the chair. If you run QuerySolv, ownership is claim-based. That lets the lead see on the queue which tickets the new technician holds and how long each has been open, without standing behind anyone. In most tools something similar is true once every ticket has a named owner. The lead glances at the queue twice a day. The buddy reads the notes once a day. Nobody hovers. A technician who is watched all week learns to perform rather than to work, and the performance ends the day the watching does.

Week Four: Review and the Widening

Week four opens with a review of week three's tickets, done together. The review is the first time the technician sees their own month as the desk sees it. The buddy and the technician sit with the closed tickets from the previous week and read ten of them properly. They read the first reply, the notes, the resolving message, and whether it came back. The format and the kindness of that hour are the subject of Feedback and the Ticket Review. In week four the review is run for the first time. It sets the expectation that it will happen every week from now on, for everyone, not as a thing done to new people.

Then the list widens. The categories the technician may work alone grow to include the ones they handled in week two with the buddy beside them. These are access requests that follow a standard approval, hardware faults that follow the diagnostic order, and e-mail problems in the user's own mailbox. The widening is written down, in the plan, with the date. Then in two months nobody has to remember whether the technician was ever told they could take a VPN ticket. The scope grows by decision, not by drift. A technician who is never told what they may now do will either take everything or nothing, and both are the desk's fault.

Week four ends with the sign-off. The sign-off is a conversation with three people in it: the buddy, the lead and the technician. Each says whether they think the technician is independent, and why. If they disagree the plan continues on the gate that was missed. I prefer the technician to speak first. A new hire who says "I am not sure about the hardware tickets yet" has just told the desk exactly what week five should be for. Then the lead says it, out loud: "You are on your own now; here is who to ask." It takes one minute and people remember it for years.

What "Independent" Means and Who Says So

Independent means the desk can give the technician a ticket in a listed category and not think about it again until it is closed. It is a statement about the desk's trust rather than about the technician's talent. Independence has four parts, each of which is a gate in the plan. The table below names each one, who checks it and what it looks like when it has not been met. The point of the table is that each gate has a person whose job it is to say yes. And that person is never the calendar.

The person who says "independent" is the lead, on the advice of the buddy, with the technician's agreement, and all three words are needed. A buddy who declares it alone has no authority over what the queue will do next. A lead who declares it without the buddy is guessing. A technician who is declared independent while privately terrified will take the next hard ticket and go quiet rather than ask. The first the desk hears of it will be a requester. Ask the technician. The answer is better evidence than the week number.

Independence is also narrower than it sounds. It applies to the categories on the list and to nothing else, and the list keeps widening for a year. A technician independent on passwords in week four is not independent on a server fault in week six. And a desk that forgets that will discover it on a Friday afternoon. The list is the contract. Keep it where both of you can see it.

When the Plan Slips

Plans slip. The honest response is to name the gate that was not met and give it a week, rather than to extend the whole thing vaguely and hope. "We are going to spend another week on doing-with, because the replies still need rewriting, and here is what I want to see by Friday" is a sentence a new technician can act on. "Let's give it a bit longer" is not; it is a sentence that makes a nervous person more nervous and teaches them nothing about what to change. One gate, one week, one stated thing to see. Then review again.

The commonest slip is not the technician's. It is the buddy's load creeping back up in week two. The printer at the depot is still down and Jess is the only one who understands it. By Wednesday the narration has stopped and the new technician is watching a screen again. The lead's job is to notice this on the queue, which is where it shows, and to take the printer. A buddy who is rescued once in week two will finish the month. A buddy who is left to sink will train a technician in how to be too busy to explain. That is a lesson the desk did not mean to teach.

The plan is not a probation. Probation is an employment matter. How it works and what it allows vary by place and by contract. Check both, and keep probation with the people whose job it is. The thirty-day plan is the desk's own training rhythm. And a technician who takes six weeks to pass the gates has had six weeks of training, not a bad report. Say so, in the plan, in writing, so that nobody confuses the two. The one does end careers. The other starts them, and it is cruel to let the new technician wonder which they are in.

A Short War Story: The Chair Beside Priya at Meridian Parts

At Meridian Parts, a new technician called Daniel was sat beside Priya, the desk's most experienced person, for his first fortnight. Nobody told Priya what he was supposed to learn or cut her load to let her teach it. So she worked her usual forty tickets a week and he watched. In week three the lead, short-handed, gave Daniel the queue. Over the following ten days he closed sixty-two tickets. Nineteen came back, and eleven had notes that said only "sorted". One was a shared mailbox permission he had granted to the wrong department. That happened because the ticket said "the sales mailbox" and there were two. Priya spent most of the next month reworking his closes while he took the new ones. The desk's reopen count for the quarter was the worst it had recorded. The lead calculated the cost afterwards at roughly ninety hours of senior time, plus the hour with the sales director about the mailbox. The lead wrote a four-week plan with gates for the next hire. Daniel became a good technician in time. He said later that nobody had ever told him he was doing it wrong, which was true. A chair beside an expert is not a plan, and a queue is not a teacher.

The Thirty-Day Plan

The plan below is one page, filled in on day one by the buddy and the lead together. It is kept where the technician can see it. The top names the three people and the date. Each week has its purpose, its work, its gate and a line for who signed it and when. The categories list in week three is written out in full. "The easy ones" means different things to different people on the same desk. The widening in week four is written with a date, and the sign-off needs three names. A week that slips gets a line in the notes saying which gate and what to see next; nothing is crossed out.

THE THIRTY-DAY PLAN — ONE PAGE
Technician: ______________   Buddy: ______________   Lead: ______________
Start date: ____________     Buddy's ticket load reduced to: ______ per week

BEFORE DAY ONE
  [ ] Computer and accounts ready (agent login, knowledge base, shared
      mailboxes, remote tool, password vault at low-risk level)
  [ ] Buddy named and told what the month is for
  [ ] This plan filled in and shown to the technician on day one

WEEK ONE — SHADOW
  Purpose: see how the desk works and why each step is taken
  Work:    knowledge base read in the set order; the queue walked through;
           shadow log kept for every ticket seen; first ticket chosen by
           the buddy on day ____ : ticket ________ (category ____________)
  Gate:    the log shows why, not only what
  Signed:  ______________ on ________    Notes: ______________________

WEEK TWO — DO WITH
  Purpose: drive the keyboard with the buddy beside
  Work:    buddy asks "what next?" before each click; every public reply
           read before sending; own tickets claimed in these categories:
           ______________________________________________
  Gate:    picks the next step before being asked, most of the time
  Signed:  ______________ on ________    Notes: ______________________

WEEK THREE — ALONE ON THE EASY CATEGORIES
  Purpose: work alone inside a written list; escalate everything else
  May work alone:  ______________________________________________
                   ______________________________________________
  Work:    notes read by the buddy the same day; lead checks the queue
           twice a day; escalations carry a reason
  Gate:    clean closes, no pattern of reopens, readable notes
  Signed:  ______________ on ________    Notes: ______________________

WEEK FOUR — REVIEW AND WIDEN
  Review:  ten closed tickets read together on ________
  Widened to include:  ________________________________ on ________
  Sign-off conversation on ________ :
     Technician says independent:  yes / not yet, on: ______________
     Buddy says independent:       yes / not yet, on: ______________
     Lead says independent:        yes / not yet, on: ______________
  Next review of the category list: ________

IF A GATE IS MISSED
  Gate: ____________   One more week on it; what to see by ________:
  ____________________________________________________________

Carol wrote the plan for Omar on the Tuesday, a day late, after reading his shadow log and finding it empty. She cut Jess's load to fifteen tickets and took the depot printer herself. She chose Omar's first ticket on the Thursday: a locked account for a warehouse supervisor. The supervisor had been locked out twice before and was good-humoured about it. The sign-off conversation happened on day thirty-three. Omar said he was not sure about the hardware tickets. Jess agreed. Carol gave him a week on them, and said so, and then said the sentence. He still has the plan, folded, in the drawer of the desk that used to be the spare one.

Frequently Asked Questions