Development Beyond the Desk for Help Desk Technicians

Wednesday, 09:10, at Kestrel Media. Jonah has been on the desk for eighteen months. He closes more tickets than anyone and writes the best notes in the team. He has just handed Mei, the desk lead, a letter. She reads it twice. He has a job at a bigger company, a step up, more money, and he is sorry. Mei asks the question leads ask at this point: was there anything she could have done? Jonah thinks about it honestly and says: "I didn't know there was anywhere to go here. Nobody ever said." Mei had, in fact, been meaning to have that conversation. She had been meaning to have it for about a year. And the queue had never quite allowed it. Now the conversation is happening anyway, with a letter in it.

Development beyond the desk is the deliberate growth of a technician past the tickets they can already close. It includes work chosen because it stretches them and a project with an end. It includes the first time they fix a cause rather than a symptom. There is learning with a certificate at the end if that helps. And there is a conversation every quarter about where all of it is going. Development is the desk's job, not the technician's alone, because the desk is the only party that can hand out the work. A technician who is not developed on purpose develops anyway, usually in the direction of someone else's job advert. This article is part of our Training & Developing Technicians series. It is about doing on purpose what Mei meant to do.

It covers why development is the desk's job, then stretch tickets, the small project and the first problem record. Next come certifications, described generically, and the quarterly development conversation. Then come the two paths, towards infrastructure and towards the senior technician's chair. It covers keeping development alive when the queue is busy. A short war story follows, then the development plan to copy.

Why Development Is the Desk's Job

A help desk teaches whether or not it means to. The work is varied, and the systems are all visible from the desk. A curious person will learn the organisation's whole estate in two years from the tickets alone. The only question a lead controls is whether that learning is pointed anywhere. A desk that points it produces a senior technician or a junior administrator who knows the place. A desk that does not produces a well-trained person with a notice letter. That desk then spends three months and a great deal of senior time replacing them with someone who knows nothing. Development is cheaper than recruitment by any accounting I have seen, and it is also kinder.

The lead's reluctance is understandable and worth naming. A technician who is developed will, eventually, leave the desk, either upward within the organisation or outward to another. And the lead has just spent two years on them. This is true and it is the wrong way round. The technician who is developed stays two or three years and leaves well, often to a role next door that still answers the desk's questions. The one who is not leaves in eighteen months, like Jonah, and leaves badly. The lead cannot keep either forever. They can choose which departure they get.

Development is also how the desk gets its hardest work done. There is the printer fleet audit nobody has time for. There is the knowledge base section that has been wrong for a year. There is the known error that has been waiting for someone to chase the fix. Each is a piece of work the desk needs and a lesson the technician needs. Giving one to the other solves both. The queue will not offer this trade on its own. The lead has to make it, by hand, about once a quarter.

Stretch Tickets

A stretch ticket is a ticket one ring outside what the technician can currently do alone. The lead chooses it. The technician works it with a named person to ask. Afterwards, it is reviewed for what it taught. The ring matters. A technician who is independent on password and printer tickets has access requests with an approval step as the next ring. That ring also includes the hardware fault that needs a part ordered. It includes the e-mail problem that is on the server side rather than the user's. Two rings out is the firewall rule or the directory change. A two-ring stretch is not a stretch. It is a stranger holding a tool they do not understand. One ring, one at a time, with a name to ask.

The lead chooses the stretch ticket because the queue will not. The choice takes a minute at the morning look through the queue. "This access request has an approval and a group change. Jonah, take it. Ask Mei about the group, and we will look at it on Friday". The technician claims it under their own name and works it as they would any ticket. The named person is available and not hovering. And the fifteen-minute rule from the first month still applies: stuck for fifteen minutes, write what was tried, then ask. The requester is told nothing special. A stretch ticket is still a ticket. And the requester is owed the same service as always. That is why the safety net is a named person and not hope.

The review afterwards is the point. It is the same review the weekly ticket review gives every ticket. There is one extra question: what did this one teach that the ordinary ones do not? Usually the answer is a piece of the estate the technician had not touched, or a process they had only seen from the outside. Either way, the answer is written down, because the development plan at the end of this article has a line for it. A stretch ticket a fortnight, reviewed, moves a technician one ring outward every quarter or so. That is fast. It is also the pace at which the moving is safe.

The Small Project

A small project is a bounded piece of work with a start, an end and an outcome the desk can see. It is not a ticket, and the technician owns it from brief to delivery. The printer fleet audit, which walks every printer and records model, age, location and fault count, so that the lemons can be found. The rewrite of the knowledge base section on the loan laptops, which has been wrong since the laptops changed. The loan laptop process itself, which currently lives in one person's head and needs to live on a page. A script that opens a ticket when the nightly backup job reports a failure, so that nobody has to check the log. Each of those is a month of a few hours a week. Each produces something the desk keeps. And each teaches a thing the queue never would: how to finish.

The project has a one-page brief before it starts, written by the lead and the technician together. The brief says what will exist at the end and when the end is. It says how many hours a week are protected for it and who the technician asks when stuck. It also says what the project does not include, because small projects grow. A printer audit that becomes a printer replacement programme has stopped being a learning exercise. It has become a budget conversation the technician did not sign up for. One page. An end date. A thing that will exist. If the thing changes any shared system, a server, the mail flow, the directory, the project also goes through whatever the desk uses for change. In that case, The One-Page Change Record is the right amount of ceremony for the size.

The projects that teach most are the ones that join two things the desk already has. If you run QuerySolv, the REST API and webhooks make a natural first project. One example is a script that raises a ticket when a monitoring check fails. Another is a script that posts a ticket's number back into the chat channel where the request started. Either is a month's work for a technician who has never automated anything. It teaches them how the desk's data moves in a way no course does. In any tool, the project that connects the help desk to something else in the estate is the one that shows the technician the estate. Pick that one second. Pick the printer audit first, because it finishes.

The First Problem Record

A problem record is the written account of a fault that keeps producing tickets, kept separately from the tickets. It holds the cause when it is found and the permanent fix when it is done. The first one a technician raises is the moment they stop fixing symptoms and start fixing causes. The distinction between the ticket that is one occurrence and the problem that is the pattern behind many is in Problems vs Incidents. Finding the repeat tickets that deserve a record is in Finding the Repeat Tickets. This article is about the technician's first time doing it, which is a development milestone whatever the desk calls it.

The first problem record usually arrives through irritation. A technician fixes the same printer model's spooler fault for the fourth time in a month. At the desk, they say, "this is the fourth one". The developing move is for the lead to say "write it up". The technician then does the thing they have not done before. They stop, pull the four tickets together, describe the pattern, and propose a cause. The proposing is the lesson. Fixing four tickets taught them the symptom. Writing the record teaches them to ask why the symptom exists, and to put a cost on it. Four tickets a month at forty minutes each is nearly three hours, every month, until someone changes the driver or the model. Linking the tickets to the record makes the count grow visibly as more arrive. That is what eventually gets the fix approved. Most tools can link tickets to each other or to a parent for exactly this.

The technician then owns the record to its end. That may be a driver update they can do themselves, a firmware change they must schedule, or a replacement they must argue for. Each of those is development. Arguing for a replacement means putting the three hours a month into a sentence a manager will read. That sentence is the first time most technicians write for management. It should be short. It should be in hours. And the way to write it is in Explaining Technical Things to Management, which the lead hands over with the record. A technician who has closed a problem record end to end has done something closer to administration than to support. And they know it, and so does everyone who watched.

Certifications, Described Generically

A certification is an exam set by a vendor or a professional body. It says the holder knows a defined body of material. For a help desk technician the useful ones fall into three generic kinds. The first is a vendor's entry-level certification for the operating system and productivity tools the desk supports. The second is a networking fundamentals certification. It teaches the vocabulary the technician will need the day a ticket turns out to be the network. The third is a framework certification, which teaches the vocabulary of how support is organised. The names of the specific exams change every few years and this article does not use them. The kinds do not change, and the kinds are what the development plan should name.

What a certification is worth is a shared vocabulary and a signal, and the honest view is that it is not a skill. A technician who has passed a networking fundamentals exam can follow a conversation about subnets and knows what a default gateway is for. And that is valuable on the day the infrastructure team asks them to check one. The technician cannot yet diagnose a network fault, because that takes patterns, and patterns take tickets. The certification makes the technician able to learn from the next network ticket instead of being baffled by it. And that is enough to justify the study time. It is not enough to justify treating the certificate as the development. The tickets are the development. The certificate is a dictionary.

The framework certification deserves a sentence of caution. The question "is it worth it for a small desk?" has its own article, Is ITIL Certification Worth It?. The answer there is more nuanced than either the vendor or the sceptic will tell you. For a technician's development the summary is: it is useful as a vocabulary if the organisation uses that vocabulary. It is useful as a signal if the technician is heading for a larger desk. Without either use, it is a week of study the small project would have used better. Who pays for exams and study time, and whether study happens in work hours, vary by place and by contract. Check both, and write what was agreed into the plan so that nobody remembers it differently later. The longer view of which certifications matter on the path off the desk is in Certifications and What They Are Worth. And this article leaves that to it.

The Quarterly Development Conversation

The development conversation is forty-five minutes, once a quarter, between the technician and the lead, about the technician's direction. It is not the performance review. That belongs to the organisation's own people process and has different rules in different places. The development conversation has three questions and a plan. What have you learned this quarter? What do you want to learn next? What is in the way? The answers go on the plan. The plan is one page, and the next conversation opens by reading the last one. That is the whole structure, and the structure is deliberately small so that the conversation can be about the person.

The first question is answered from the evidence: the stretch tickets, the project, the problem record and the certificate if there was one. There are also the weekly review's one-line notes. By the end of a quarter, those are a dozen lines that show what changed. Most technicians underestimate what they learned. Learning on a help desk arrives one ticket at a time and does not feel like anything. The lead's job is to read the quarter back to them so that they can see it. "In January you had never touched an access request with an approval; you closed eleven this month and wrote the runbook" is a sentence that changes how someone sees their year.

The second and third questions are where the two paths, described next, come in. And the lead's job is to listen rather than to steer. A technician who says "I want to learn the network" has told the lead what the next stretch tickets should be. One who says "I like the desk and I want to be better at it" has told the lead something equally useful and often less welcome. Leads tend to assume everyone wants out. (Some people like the desk. This is allowed.) The third question, what is in the way, is usually answered "the queue". The honest response is the protected hours in the plan, said aloud and written down. The lead's name goes next to them as the person who defends them.

The Two Paths

There are two directions a developing technician can go, and both are careers. And the desk has to say so out loud because the industry only talks about one of them. The first is the ladder towards infrastructure. The technician takes more of the tickets that touch servers, the directory and the network. They pick up the small projects that join systems together. In two or three years they become a junior administrator who still knows what the desk's tickets look like. That is a rarer and more valuable thing than it sounds. What that path looks like step by step, and what to build while still on the desk, is the subject of What the Ladder Looks Like. This article points at it rather than redrawing it.

The second path is the senior technician's chair: staying on the desk, by choice, and becoming the person the desk cannot run without. The senior technician trains the new starters and owns the knowledge base's hardest sections. They raise and chase the problem records. They are the first escalation for everything the first line cannot finish. They know the organisation's people and its history in a way no administrator does. That is a career. A desk that treats it as a failure to leave will lose exactly the people it most needs to keep. Why a technician might choose it is in Staying on the Desk by Choice. That article also covers how to make the choice a real one with a real title and real recognition. The table below puts the two side by side, not to rank them. It shows that each has first steps the desk can hand out this quarter.

Both paths start with the same stretch tickets for the first six months. That is convenient. Most technicians do not know which path they want until they have tried the work on both. The lead should not ask them to choose in the first conversation. Ask in the third or fourth, when the stretch tickets have shown the technician what each kind of work feels like. Accept that the answer may change. A technician who heads for infrastructure and comes back to the desk by choice has learned something the desk should be glad to have.

Keeping Development Alive When the Queue Is Busy

Development dies in busy weeks unless it has protected hours. Protected means visible on the queue as a block of time with the technician's name on it that the lead defends. Two hours a week is the number that survives on most small desks; four is better and rarer; one is a gesture. The block is for the small project and the study, not the stretch tickets, which are ordinary tickets and happen in ordinary time. When the week is genuinely on fire the block moves, and the lead says so. In that case, it is made up the following week. A block that is quietly skipped three times is a block that no longer exists. Jonah's development had two hours a week on paper and none in practice for a year. The paper did not keep him.

The trade-off is said aloud to the desk and to management. Two hours a week of one technician's time is roughly a day a month. And the backlog will be a day a month longer for it. And the return is a technician who stays and a printer audit that gets done. Most managers accept this when it is put as a trade and resist it when it is discovered as a gap. Put it as a trade. The alternative is to explain, in eighteen months, why the desk's best technician has left and the printer audit still has not been done. And that conversation is longer than this one.

Nothing in this article needs a feature. QuerySolv, like most small-team help desks, has no training or development module. The plan below is a page kept where the technician and the lead can both see it. The tool's part is the tickets. There are the stretch tickets claimed under the technician's name and the linked tickets behind the first problem record. There are the reports read for the quarterly evidence. The development is in what the lead chooses to hand over, and no tool has ever chosen that.

A Short War Story: The Letter at Marlow Freight

At Marlow Freight, a technician called Noor spent two years on a three-person desk. She became the only person who understood the depot handheld scanners. She taught herself enough about the network to diagnose the warehouse wireless faults that the infrastructure contractor billed a day to look at. She never once had a conversation with her lead, Patrick, about where any of it was going. Patrick had the queue and meant to get to it. She left for a junior administrator role at a logistics company across town, giving the month's notice her contract required. In that month the desk discovered that the scanner knowledge existed nowhere but in her head. The desk also discovered that the wireless diagnosis would now cost a contractor day each time. Recruiting her replacement would take a quarter and training them another. Patrick costed it afterwards, roughly. There were three months of agency cover. There were four contractor days in the first two months for faults Noor would have fixed in an hour. Training the replacement to the point Noor had reached unaided took about two hundred hours of his own and the senior technician's time. Noor, asked at her leaving drinks, said she would have stayed for the junior administrator path if anyone had said it existed. It had, in the infrastructure team, with a vacancy that spring. A technician who is not developed on purpose develops anyway, and the development was pointed at somebody else's door.

The Development Plan

The plan below is one page per technician, written together in the first development conversation. It is reread at the start of every one after it. The previous quarter's lines are kept rather than erased so that the page becomes a record over a year or two. The top states the protected hours and who defends them. The quarter section holds the stretch tickets with what each taught and the small project with its brief in a line. It holds the problem record if there was one. It also holds any certification agreed, with who pays and when study happens written down. The conversation section holds the three questions and their answers in the technician's words. The direction line is filled in only when the technician is ready to fill it, and may be changed at any conversation without comment.

THE DEVELOPMENT PLAN — ONE PAGE, ONE TECHNICIAN
Technician: ______________   Lead: ______________   Started on the desk: ________
Protected development time: ____ hours a week, on ____________ (day/time)
Defended by: ______________   Made up when moved?  yes / no, last missed: ________

THIS QUARTER (quarter beginning ________)
  Stretch tickets (one ring out, one at a time, with a name to ask)
    Ticket ________  Category ______________  Asked ______________  Taught: ______________
    Ticket ________  Category ______________  Asked ______________  Taught: ______________
    Ticket ________  Category ______________  Asked ______________  Taught: ______________
  Small project
    What will exist at the end: ______________________________________
    End date: ________   Hours a week: ____   Ask when stuck: ______________
    Does NOT include: ______________________________________
    Changes a shared system?  yes / no   If yes, change record: ________
  Problem record
    Pattern noticed: ______________________   Tickets linked: ____
    Record raised on: ________   Owned to: cause found / fix proposed / fix done
  Certification (kind, not brand)
    [ ] vendor entry-level   [ ] networking fundamentals   [ ] framework   [ ] none this quarter
    Exam by: ________   Study time: in work hours / own time / mixed (as agreed)
    Costs met by: ______________ (as agreed; varies by place and contract)

THE CONVERSATION (45 minutes, once a quarter; not the performance review)
  Date: ________
  What have you learned this quarter? (read back from the evidence above)
    ______________________________________________________________
  What do you want to learn next?
    ______________________________________________________________
  What is in the way?
    ______________________________________________________________

DIRECTION (fill in when ready; may change at any conversation)
  [ ] towards infrastructure   [ ] the senior technician's chair   [ ] not yet decided
  What the desk will provide for it: ______________________________________
  Next conversation on: ________

PREVIOUS QUARTERS (kept, not erased)
  Quarter ________ : learned ______________________  project ______________________
  Quarter ________ : learned ______________________  project ______________________

Mei could not keep Jonah, who had already said yes to the other job. She asked him to spend his last month writing the plan for the other three technicians with her. He knew better than she did what nobody had said. The first conversations happened the week after he left. One technician wanted the network and got the next three server-side e-mail tickets and a brief for a backup-failure script. One wanted the desk and got the title the desk had never had a reason to invent, and the reading list to own. The third did not know, and said so, and that went on the plan too, in her words, under "not yet decided". Mei has the block in her own calendar now, two hours on Thursday afternoons. There is a note that says "the queue can wait two hours; it waited a year".

Frequently Asked Questions