Home › Topics › One-Person IT › The Second Person

When to Hire the Second Person

"We need another person in IT." "Show me." It is the budget meeting, the one that happens once a year in a room with a projector only one person can connect to. That person is you. You have just said the sentence you have been rehearsing since the spring. The finance director is not being unkind. "Show me" is a reasonable thing to say about a salary. The trouble is that what you have is a feeling. The feeling is correct. And a correct feeling has never once appeared as a line in a budget.

This is the sixth and last article in our One-Person IT Department series. The earlier ones were about running the desk alone and staying well while doing it. This one is about the moment when alone stops being the right answer, and about turning that moment into a case a budget meeting can say yes to. It is written for the solo administrator and, in places, for the manager who will carry the case upstairs.

It covers the five thresholds that say the job has outgrown one person, then the business case built from ticket data. That includes the cost of waiting in hours rather than currency and a risk register of one-person dependencies. Next come what to ask for, and the trade-offs between a generalist, a junior technician and a contractor. What to hand off first and what to keep, then the first ninety days with two, follow. A worked example and a war story, then the one-page headcount case to copy, come last.

Why the Feeling Loses

The feeling loses in a budget meeting because it is in the wrong format, not because it is wrong. A budget meeting compares numbers with numbers. "We need another person" is a sentence, and across the table from it is a salary, which is a number. The number wins every time the sentence shows up alone. The administrator leaves the room with a vague commitment to revisit it next year. And the queue, which was not invited, carries on as before.

The case that wins is the same feeling translated into the three things a budget meeting can weigh. Those are how much work there is, what it costs to leave it undone, and what breaks if the one person is not there. All three come out of the ticket system, provided it has been fed. That is the quiet reason the first article in this series insisted that everything is a ticket, including the walk-up and the thirty-second fix. The headcount case is built from evidence collected by someone who did not yet know they were collecting it.

Start the case a year before you need it. That sounds long. It is one afternoon a quarter writing down three numbers and a list of systems. The version you bring to the meeting is the fourth edition with a trend line. A case with a trend beats a case with a snapshot, and a snapshot beats a sentence, and a sentence beats silence, but only just.

The Five Thresholds

Five thresholds say the job has outgrown one person, and any two of them together is a case. None of them is a magic number. They are the places where, in my experience and that of the solo administrators I have compared notes with, the job stops fitting. Measure yours against them and write down which ones you cross.

ThresholdWhere it tends to sitHow to measure it
Ticket volume per weekAbove about sixty a week for one person, with walk-ups and calls loggedThe volume report, weekly, over the last two quarters
Interrupt hours per dayMore than half the day spent handling interruptions and recovering from themA two-week one-line log: time, who, what, minutes
The project backlog that never movesThe same items on the list for two quarters; dates moved more than twiceThe project list with the date each item was added
Leave that never happensNo two consecutive weeks off in the last year; days carried overThe leave record, which the organization already holds
Single points of failureMore than three systems where only one person can log in or knows howThe estate page, filtered to lines with one name

The thresholds carry different weight with different readers. A finance director hears volume and backlog, because they are cost. A managing director hears single points of failure, because that is risk, and risk gets a decision made in one meeting instead of three. Leave that never happens puts the human resources lead on your side, and headcount requests pass through that office. Know which threshold your reader will hear and lead with it.

The Case Built From Ticket Data

The business case is four pieces of evidence, each a page or less, each drawn from the ticket system. The first is the volume trend: tickets per week, by month, over at least two quarters, with walk-ups and calls included because they were logged. The second is time by category: where the hours went, which shows the reader what a second person would do all day. The third is the cost of waiting, which has its own section below because it is where cases are won. The fourth is the risk register of one-person dependencies, which is the estate page with a column added.

The volume trend answers "is it getting worse", and the answer is almost always yes. That is because organizations grow, systems multiply, and the queue is the only part of IT that scales on its own. Draw it as a line, with the headcount as a second, flat line underneath. Nobody needs that chart explained. If the trend is flat, say so; a case that admits its weak points is believed on its strong ones.

Time by category is the second person's job description in disguise. If password resets, new starters, folder access and printer problems account for forty percent of the hours, a junior technician can take that forty percent in the first month. Then the case can say so with the number attached. If the hours are in projects and vendor management, the second person is a generalist and the case says that instead. The category report decides what to ask for before you ask for it.

The Cost of Waiting, in Hours

State the cost of waiting in hours, never in currency, because hours can be measured and currency would have to be estimated. An estimated number in a budget meeting gets argued about until the meeting ends. The cost of waiting is the time between a ticket arriving and someone starting on it, multiplied by the number of people waiting, summed over a month. It is the organization's time, not IT's, and that is the point: it shows what a desk of one costs everyone else.

The ticket system gives you most of it. First-response time by priority, backlog by age, and the number of tickets waiting at the end of each day are standard reports. Multiply the waiting time on each ticket by the number of people affected (one for most tickets, a department for an outage) and add it up for a month. The result is a number like "four hundred and ten person-hours of waiting". That is a fact the finance director can convert into currency in their own head at their own rates. Let them. They will believe the arithmetic more if they did it.

Put the cost of your own time next to it, also in hours: the evening hours worked, the leave not taken, the interrupt hours from the log. The two numbers together say what the organization is paying for a desk of one. It is paying in waiting and it is paying in you. The second person reduces both, and the case says by how much, from the category report.

The Risk Register of One-Person Dependencies

The risk register is the estate page with a column headed "who else can do this", and on a solo desk the column is mostly blank. List every system where only one person can log in, knows the vendor, holds the keys, or understands the monthly job. For each, write what happens if that person is unavailable for a month. For example, the payroll run does not go, the firewall cannot be changed, or the backup cannot be restored. That list is the part the managing director reads twice. Everything else is cost. This is the building.

Be plain about it and do not dramatize. The register is not a threat and it is not a resignation letter. It is a list of facts the organization would want to know even if headcount were not the question. Framing it that way keeps the conversation about the job rather than about you. The list also has a second use: it is the second person's first month of work.

Remember: the case asks for a decision about a job, not a judgment about a person. Every number in it should still be true if someone else were doing your job.

What to Ask For

There are three shapes the second person can take, and the category report has already told you which one. A second generalist is another you: any ticket, any project, any leave, at the price of being harder to find and slower to start. A junior technician for the first-line lane takes the ten tickets and the walk-ups on day one, frees your hours fastest, and needs training and a career path you will have to provide. A contractor for cover and overflow costs nothing when idle, arrives when needed, and never learns the estate well enough to run it alone.

Ask forTakes over firstStrengthTrade-off
A second generalistHalf the queue in alternate weeks; all leave coverReal resilience; every single point of failure can be fixedHarder to recruit; three months before they can be left alone
A junior technicianThe ten tickets, the sponge hour, deskside visitsFrees the most of your hours soonest; easiest to recruitCannot cover your leave in year one; needs your time to train
A contractor on retainerLeave cover, project overflow, out-of-hours changesNo idle cost; starts within daysNever owns anything; the single points of failure remain

Ask for the shape the data supports, and say what you are not asking for. A case that says "a junior technician for the first-line lane, because forty percent of hours are in four categories a trained junior can own in a month" is a case about a job. A case that says "another person" is a case about a wish. If the organization cannot fund a role this year, the contractor is the honest fallback. Then the case should name it as the second option with its trade-off: the leave becomes possible, the single points of failure do not move.

What to Hand Off First, and What to Keep

Hand off the interrupt load first and keep the decisions. The ten tickets go first, because they are written down and they are most of the volume. The sponge hour goes next: the second person sits in it, and the hallway learns a new face. The deskside visits go third, because they are the walk-ups that became tickets and they are most of the walking. What you keep is identity (who gets an account and what it can reach). You also keep security decisions (what is allowed through, what is patched when), and vendors (who is called and what is said). Those three are where a mistake is expensive, and they stay with the person who knows the history until it is written down.

The order is the order of documentation, which is not an accident. The ten tickets were scripted and documented in Automate the First Ten Tickets. The sponge hour is posted on the door; the deskside visits have a knowledge article each. The second person inherits the written parts of the job first, which is the only way a handover works. The gaps found in month one are the next things to write, and Documentation as Your Second Person has the habit for that.

Keeping the decisions is not about trust. It is about the second person needing three months of history before their judgment on identity and security has the same basis as yours. Hand the decisions over in the second quarter, one at a time, with the reasoning written down. By month six the single points of failure should be a short list. If it is still a long list at month six, the handover has stalled on the keeping side. I say that as someone who has kept things too long and called it caution.

The First Ninety Days With Two

The three-person rotation from the support tiers series adapts to two by alternating weeks. One person owns the queue for a week while the other is protected for projects, and then they swap. With two there is no cover for cover, so the protected person is still the escalation point. But the escalation is a ticket rather than a tap on the shoulder. The first ninety days build up to it in three stages.

  • Days one to thirty: the second person shadows the queue with you and takes the ten tickets by the end of week two. They sit in the sponge hour from week three. You keep the queue; they keep a list of everything they could not do without asking, which is the gap list.
  • Days thirty-one to sixty: the second person owns the queue in alternate weeks, with you as escalation. The gap list becomes knowledge articles, one a day. The first single point of failure gets a second login.
  • Days sixty-one to ninety: full alternation. The second person runs a week with you on leave, for real, as the test. The Friday handover is a list, fifteen minutes long. The risk register is reviewed and the next three single points of failure are scheduled.

Expect your own load to go up for the first month before it goes down. Training costs hours, and the hours come out of the same day the interruptions did. Say this in the case, so that month one is not the month the result is judged. Month three is when it is judged. The queue report shows two names, the oldest open ticket has a different age, and the project list has moved for the first time in a year. That is what the case promised. Make sure it is measured.

A Worked Example: Northgate Retail's Case

Marcus runs IT alone at Northgate Retail, a chain of eight stores with a head office of fifty. His case for a second person was built over three quarters and brought to the budget meeting on one page. The volume trend showed tickets per week rising from forty-four to sixty-seven, walk-ups and calls included. Time by category put password resets, new starters, folder access and the stores' label printers at forty-three percent of logged hours. The two-week interrupt log showed twenty-one interruptions a day and just over five hours a day of handling and resumption.

The cost of waiting for the most recent month came to three hundred and ninety person-hours. That was a median first response of four hours on normal tickets, plus two store outages where six staff each waited ninety minutes for the registers. His own cost was nineteen evening hours in the month and no leave longer than five days in fourteen months. The risk register listed six systems with one login: the firewall, the backup server, the point-of-sale console, the domain controllers, the phone system and the vault itself. The ticket tool did most of the first two pages (QuerySolv's reports, for example, include workload per agent, backlog by age and a busiest-hours heat map over 7, 30 or 90 days). The log and the estate page supplied the rest.

He asked for a junior technician for the first-line lane, with a contractor on retainer as the second option. The case said in one line what each would change: the forty-three percent of hours in four categories, or the leave. The meeting took twenty-five minutes. The question the finance director asked was not "why" but "why not last year". The answer was that last year there had only been a feeling.

A Short War Story: Kestrel Payroll

Priya ran IT alone at Kestrel Payroll for three years, and her case for a second person was three numbers and a list. The numbers were sixty-two tickets a week, five hours a day of interrupt work from a two-week log, and nineteen months since her last full week off. The list was five systems only she could log into: the payroll engine's admin console, the bank file gateway, the firewall, the backup server and the certificate store. She put the list at the top of the page, above the numbers, because the managing director was the reader and the managing director thinks in risk. The second person, Tomas, started in the spring. The first thing they did together, before he took a single ticket, was spend a week giving each of the five systems a second login, a vault entry and a page in the runbook. By the summer the list was empty, the queue alternated weeks, and Priya took three weeks off. During that leave, the payroll ran on time twice and nobody called her. Nobody had done anything wrong in the three years before. The list had just never been written down where the person who could fix it would see it.

The One-Page Headcount Case

The template below is the case on one page, in the order a budget meeting reads: the ask first, the evidence second, the risk third, the plan last. Fill it in from the ticket system, the log and the estate page, and update it each quarter whether or not there is a meeting. That is because the quarter it is needed is never the one you expect.

THE HEADCOUNT CASE, ONE PAGE
Desk: ____________   Prepared by: ____________   Quarter: ________

THE ASK
  Role: [ ] second generalist   [ ] junior technician, first-line lane
        [ ] contractor on retainer (cover and overflow)
  Because: ___________________________________________________________
  Second option if the first is not funded: ___________________________

THE EVIDENCE (from the ticket system; walk-ups and calls logged)
  Tickets per week, by quarter:   Q-3 ____   Q-2 ____   Q-1 ____   now ____
  Hours by category, top five:    ____________ __%    ____________ __%
                                  ____________ __%    ____________ __%
                                  ____________ __%    (total ___% of hours)
  Interrupt load (two-week log):  ____ per day,  ____ hours per day
  Cost of waiting, last month:    ____ person-hours (waiting time x people)
  My own cost, last month:        ____ evening hours;  last full week off: ____
  Project backlog:                ____ items;  oldest added ____ months ago

THE RISK (one-person dependencies)
  System                     Only login / only knowledge    If unavailable a month
  ________________________   __________________________    ____________________
  ________________________   __________________________    ____________________
  ________________________   __________________________    ____________________

THE PLAN (first ninety days)
  Hand off first: the ten tickets, the sponge hour, deskside visits
  Keep: identity, security decisions, vendors (hand over in quarter two)
  Days 1-30: shadow; take the ten tickets; keep the gap list
  Days 31-60: alternate weeks on the queue; gap list becomes articles
  Days 61-90: full rotation; one week of real leave as the test
  Measured at day ninety by: oldest open ticket ____   interrupt hours ____
                             projects moved ____      single points left ____

Bring the page, not a slide deck. A budget meeting can read a page in two minutes and argue with a slide deck for an hour. The argument is never about the numbers. Leave a copy with the manager who will carry it on, because the meeting you attend is rarely the one where it is decided.

When the second person starts, hand them the page. It is the most honest description of the job they will ever get. The feeling was right all along. It just needed to be written in a format the room could count.

Frequently Asked Questions

How many tickets a week justify a second person?
There is no single number, because a week of sixty password resets and a week of sixty server problems are different jobs. Around sixty a week with walk-ups and calls logged is where most solo desks stop fitting one person. But pair volume with a second threshold, such as interrupt hours or single points of failure. Two thresholds crossed is a case; one is a trend to watch.
Should I put a currency figure on the cost of waiting?
No. State it in person-hours and let the finance reader convert it at rates they trust. A currency figure you estimated invites an argument about the estimate, while an hours figure from the ticket system invites a calculation. The person who does the calculation tends to believe the result.
Should the second person be junior or experienced?
Let the time-by-category report decide. If most of the hours are in the ten routine tickets, a junior technician for the first-line lane frees the most time soonest. If the hours are in projects, vendors and cover, a second generalist is the right ask, even though they are harder to recruit and slower to start.
What if the case is turned down?
Ask for the second option in the case, usually a contractor on retainer for leave cover and overflow. Make sure the risk register stays with management in writing. Keep updating the page every quarter so that the next meeting starts from a trend rather than from zero. A turned-down case with a dated risk register is a different thing from a request never made.
Who should present the case?
You build it and your manager carries it, because budget decisions are made in meetings the administrator is rarely in. Walk your manager through the page beforehand so they can answer the two questions that always come: why now, and what changes in ninety days.
How long before the second person pays back?
Expect your own load to rise in month one, because training comes out of the same hours the interruptions did. By month three the queue report should show two names, the oldest open ticket should be younger, and the project list should have moved. Put those measures in the case so the result is judged at ninety days rather than thirty.

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.