Staying Sane When You Are the Whole Department
It is a Tuesday in month eleven. Nothing is down. The queue is at nine, which is fine. The backups ran and the mail is flowing. Nobody is waiting on anything urgent, and you have been at your desk since 08:15 doing nothing you could name. You cannot remember the last afternoon that went the way you planned it. There is a project plan in a folder somewhere with your name on every line. The folder has not been opened since the spring.
This is the fifth article in our One-Person IT Department series, and it is the personal one. The earlier articles were about running the desk. This one is about running the person. It is written for the solo administrator in month eleven and for the manager who has one. It is an operations article rather than a wellness one. The fixes are calendars, logs, numbers and conversations, in roughly that order.
It covers why an interrupt-driven day is tiring in a way a busy day is not, then the signals that the job has outgrown one person. Next come recovery as part of the job, what your manager owes the desk, and what you can change on your own and what you cannot. Then it covers burnout, named plainly, and one day's interrupt arithmetic. A war story about a two-week log and a monthly sustainability checklist to copy finish the article.
Why an Interrupted Day Is Not a Busy Day
An interrupted day is tiring in a different way from a busy day, and the difference is the cost of coming back. A busy day is eight hours of work done in order; you finish it tired and done. An interrupted day is the same eight hours cut into forty pieces by the phone, the hallway and the quick question. Each cut costs the ten or fifteen minutes it takes to find your place again. Twenty interruptions is five hours of finding your place. The work you planned has to fit in the remaining three, which is why it does not get done, which is why the project folder has dust on it.
Interrupt load is invisible in every report the organization reads. The queue shows tickets, and tickets are a fraction of interruptions. The walk-up who needed a cable, the call from the warehouse about the scanner, the vendor who called back: none of them became a ticket. So none of them exist. At the end of the day the record says you closed six tickets and the feeling says you ran a marathon on a treadmill. Both are accurate. Only one is written down.
Name the load before trying to reduce it. The tool is the one-line log, worked through below, and the reason to bother is that an unnamed load gets explained as a personal failing. "I just couldn't get to it" is the sentence a solo administrator says in month eleven, and it is wrong in one word. You could get to it. Twenty other things got to you first.
The Signals the Job Has Outgrown One Person
A job outgrows one person quietly, and the signals all look like diligence from the outside. The table below lists the ones I have seen most often, what each looks like in an ordinary week, and the one thing to do about it this month. None of them is a verdict on the person. They are measurements of a job.
| The sign | What it looks like | What to do this month |
|---|---|---|
| The project backlog does not move | The same five projects on the list for two quarters; dates moved three times | Show your manager the list with the date each item was added, and ask which to drop |
| Leave does not happen | Days carried over; the last full week off was before the migration; "when things calm down" | Book two consecutive weeks three months out and start the cover plan the same day |
| You are the only login | Systems with no second account, or where the second account is your manager's and nobody knows its password | List them on the estate page; create one sealed emergency login per system |
| The sponge hour is the whole day | As many interruptions outside the posted hour as inside it | Keep the one-line interruption log for two weeks |
| Fixes stop being written down | No new knowledge article this quarter; you have re-solved something you remember solving | Reinstate the ten-minute habit for fixes over twenty minutes |
| After-hours work is routine | Patching, migrations and "just checking" happen in the evening because the day is full; nobody asked | Count the evening hours for a month and show the total to your manager |
| The same ticket keeps coming back | A category with twenty tickets a month that are all the same ticket; never fixed because never finished | Pick that one category and spend a protected afternoon ending it |
| Mistakes with a pattern | Small errors on easy tasks, in the afternoon, after an interrupted morning | Treat it as a load measurement; move risky work into the protected block |
Two rows deserve a second read. "You are the only login" is a business risk rather than a personal one. It gets a manager's attention fastest, because it still exists when you are on leave. The fix is a sealed emergency login per system: a second account whose password sits in an envelope someone else can open. "Mistakes with a pattern" is the row solo administrators take personally, and should not. Error rates rise with interruption; that is a property of attention, not of character. If the mistakes cluster at 15:00 after a morning of walk-ups, the fix is the morning.
Recovery Is Part of the Job
Recovery is part of the job rather than a reward for finishing it, because the job does not finish. An administrator who waits for the queue to empty before taking a day off will wait until the role is empty instead. Recovery on a solo desk takes three forms: protected time inside the week, real leave outside it, and a cover plan that makes the leave real. Each is a calendar entry, each is the first thing canceled under pressure, and each has to be defended as an operational control rather than a perk.
Protected time is two afternoons a week when the queue is looked at once, at the start, and then not again. The phone goes to voicemail with a message that names the next time you will be available. The time goes on whatever needs sustained attention. Protected time that is given up three weeks in a row is not protected. It is a story you tell about your calendar.
Real leave is two consecutive weeks, at least once a year, with no laptop. One week is not enough, because the first week is spent waiting for the phone to ring and the second is where the rest happens. The cover plan is what makes two weeks possible, and it is laid out in Documentation as Your Second Person. It includes a runbook's first page, an estate page, a cover person with limited rights, and a note from your manager saying they have authority. Book the leave first and build the plan toward it. A plan with no date has no deadline, and the queue will supply one of its own.
One rule protects the leave more than any other: no change the day before. Nothing gets patched, migrated, renamed or upgraded on the last working day before you go, however small. The day before leave is for handover and for leaving on time. A small safe change at 16:00 on the Friday is how the cover person spends Monday on the phone to you. Changes can wait two weeks. Almost all of them already have.
What Your Manager Owes the Desk
A solo desk is sustainable only if the person above it does four things, and they are the manager's job rather than yours. The first is backing the boundaries: when someone complains that IT would not drop everything for a quick question, the manager says "that is how we run it" and means it. The second is reading the numbers: volume, oldest open ticket and hours of interrupt work land on their desk monthly and get read. The third is planning cover, so that your leave is something the organization arranges rather than something you negotiate. The fourth is treating headcount as a question with evidence rather than a mood, which is the subject of the last article in this series.
Say this to your manager in those words, once, in a calm week. Most managers of a one-person IT department have never managed one before and have not been told what the job needs from them. They see a competent person who gets things done and conclude that the desk is fine, because it is, right up until the week it is not. The four responsibilities fit on a page. Hand it over. A manager with the page can act on it; a manager with only a feeling that you seem tired cannot.
If the manager will not do the four things, that is information, and it belongs in the decision about where you work. I would rather write that sentence plainly than leave it out. A solo desk with no backing above it is not a sustainable job for anyone, however good. The person doing it should know the problem is structural before concluding that it is them.
What You Can Change on Your Own
Three things reduce the load without anyone's permission, and the earlier articles in this series cover each one. The first is to automate the ten tickets that make up most of the queue, from Automate the First Ten Tickets: a reset that takes a form instead of a visit is an interruption that no longer happens. The second is to post the boundaries, from Boundaries for the Solo Admin: the sponge hour, the walk-up redirect and the written emergency definition cut interruptions without cutting service. The third is the documentation, which turns leave from a theory into a date.
The fourth thing you can change alone is what gets recorded. Log every walk-up, call and hallway request as a ticket, even the thirty-second ones. The ticket is the only evidence the organization will ever have that the interruption happened. A desk that records only the e-mails has a workload chart one third the size of the job. If your ticket tool has a busiest-hours report it will do part of the counting for you. (QuerySolv's reports include a busiest-hours heat map over 7, 30 or 90 days.) But it only counts what became a ticket. Hence the log.
Expect each to take a month to settle in. None of them needs a budget. All of them need an afternoon that does not get interrupted, which is the problem they exist to solve. Start with the sign on the door. It is the cheapest, and it works the same day.
What You Cannot Change on Your Own
Three things cannot be fixed from inside the desk, and pretending otherwise is how a structural problem gets turned into a personal one. Headcount is a budget decision. Scope, meaning what IT is and is not responsible for, is a management decision, and the scope series is written for making it. And there is a culture of walk-ups, where the whole building has learned that the fastest route to IT is the stairs. That cannot be changed by the person at the bottom of the stairs. The sign on the door works only if the manager repeats what it says.
The honest response to these three is to stop absorbing them. Absorbing is the default: the scope grows and you take it. The walk-ups continue and you handle them. The headcount stays at one and you work the evenings to make it look like two. It is generous, it is competent, and it is the mechanism by which the organization never finds out there is a problem. The queue is very good at hiding how many people are running it. Stop helping it.
Stopping looks like three sentences, said to your manager and written down: this is out of scope and here is the list; this is more than one person's load and here is the log; this cannot be done this quarter and here is what can. None of them is a threat. They are measurements, delivered to the person whose job it is to act on them. Delivering them is yours.
Burnout, Named Plainly
Burnout is what happens when the load stays above capacity for long enough that recovery stops working. It is a risk of this role, not a weakness of the person in it. It arrives slowly: the protected afternoons go first, then the leave, then the writing-down, then the evenings fill up. Then one Tuesday in month eleven nothing is wrong and you cannot remember a planned afternoon. The order is much the same on most solo desks, and the signals in the table above are its early stages.
Naming it is the operational step, and it is the one most often skipped. A solo administrator who says "the load on this role is unsustainable and here is the log" has made a statement about a job. One who says nothing and works harder has made the same statement to nobody. I have done the second one. It did not work, and it was not noble; it was just quiet. The first one is harder for about a minute and better for about a year.
This article stops there, because the subject deserves more than a section; a later series in this library is about burnout on the help desk in its own right. For now the operational point is enough: it is a risk of the role, the signals are measurable, and the measurements belong on someone else's desk as well as yours.
Remember: the log, the three numbers and the checklist measure a job, not a person. If they look bad, the job is too big, and that is a sentence to say out loud.
The Interrupt Arithmetic, Worked Through
Here is the interrupt load for one day, counted. Sam runs IT alone at Northgate Retail, a chain of eight stores with a head office of fifty. On an ordinary Wednesday he kept the one-line log: time, who, what, minutes. He wrote the line before doing anything about the interruption, which took about ten seconds each and is the whole discipline.
The day had twenty-three interruptions between 08:30 and 17:30: nine walk-ups, seven phone calls, four chat messages, two from the manager and one from a vendor. The median one took four minutes. Four of the twenty-three became tickets. The queue report for the day showed four opened and five closed, and a manager reading it would conclude that Wednesday was quiet.
The arithmetic goes like this. Twenty-three interruptions at four minutes is ninety-two minutes of handling. Add the cost of getting back to what you were doing, which Sam put at twelve minutes each. He was doing a firewall rule review, and firewall rule reviews do not resume well. Twenty-three at twelve minutes is two hundred and seventy-six. Handling plus resumption is three hundred and sixty-eight minutes, or just over six hours of a nine-hour day. The firewall review got the remaining two hours and fifty minutes, in twenty-minute pieces, and was not finished, and the log says why. Four tickets, six hours.
Over two weeks the log averaged nineteen interruptions a day, with a peak between 09:00 and 10:30 and another after lunch. Sam moved the sponge hour to 09:00 and the firewall review to a protected block on Thursday afternoon. Eleven interruptions a day still arrived outside the hour. But the review finished, and the log went to his manager as a one-page chart, which is the only form in which an interrupt load has ever been believed.
A Short War Story: Lena at Acme
Lena ran IT alone at Acme, a manufacturing firm of about a hundred and twenty people. For most of a year she told her manager she was busy, which was true and changed nothing, because busy is what everyone is. For two weeks in the spring she kept a one-line log of every interruption. It came to two hundred and six lines, forty-one of them from the same three people about the same two systems, and eleven hours of handling time plus whatever it cost to resume. She put the log on one page with the totals at the top and took it to her regular one-on-one instead of saying she was busy. The manager read it and asked two questions. By the end of the month the two systems had an owner in their own department. The three people had a form instead of a hallway, and the headcount conversation had a date. The log did in twenty minutes what a year of "I'm busy" had not, because busy is a feeling and two hundred and six lines is a measurement.
The Sustainability Checklist
The checklist below is eight questions, asked once a month, in the weekly review from the first article in this series or in your manager's one-on-one. A no is not a failure; it is the thing to work on next month. Three no's in a row on the same line is the signal to stop working on it alone and put it in front of your manager with the log attached.
| Monthly question | Yes means | If no |
|---|---|---|
| Did I keep both protected afternoons every week? | The calendar shows them and they were kept | Find which interruption took them and log it |
| Is my next two-week leave booked, with a named cover person? | A date in the calendar, a name on the runbook's first page | Book the date this week; build the plan toward it |
| Did every fix over twenty minutes get written down? | The knowledge base has articles dated this month | Reinstate the ten-minute habit and nothing else |
| Did I log every walk-up and call as a ticket? | Two-minute tickets exist in the queue | Start again on Monday; the count is the evidence |
| Were evening hours fewer than four this month? | You counted, and the count was under four | Show the count to your manager with what the hours were for |
| Did the project list change, in either direction? | Something was finished or something was removed | Ask your manager which item to drop |
| Is there a second login for every system on the estate page? | No line on the estate page has only one name against it | Create one sealed emergency login this month |
| Did my manager see the three numbers? | Volume, oldest open ticket, interrupt hours, sent and acknowledged | Send them anyway, with one sentence on what they mean |
Keep the filled-in checklist with the runbook, where your manager can see the pattern. A desk that answers yes to six of the eight is in good shape, and the person running it should take the Tuesday afternoon. A desk that answers no to six of the eight does not have a person problem, and the checklist is the first page of the case for the second one.
Month eleven is still going to have Tuesdays in it. The difference is that one of them will be the afternoon you planned, and it will go the way you planned it. That will feel strange for about an hour. Then it will feel like the job.
Frequently Asked Questions
How many interruptions a day is too many?
Does the interruption log have to be exact?
My manager says the desk looks fine. What do I show them?
I cannot take two weeks off because there is nobody to cover. What then?
Is this article about burnout?
If everything in this article applies, where do I start?
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.
