Home › Topics › One-Person IT › Staying Sane

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 signWhat it looks likeWhat to do this month
The project backlog does not moveThe same five projects on the list for two quarters; dates moved three timesShow your manager the list with the date each item was added, and ask which to drop
Leave does not happenDays 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 loginSystems with no second account, or where the second account is your manager's and nobody knows its passwordList them on the estate page; create one sealed emergency login per system
The sponge hour is the whole dayAs many interruptions outside the posted hour as inside itKeep the one-line interruption log for two weeks
Fixes stop being written downNo new knowledge article this quarter; you have re-solved something you remember solvingReinstate the ten-minute habit for fixes over twenty minutes
After-hours work is routinePatching, migrations and "just checking" happen in the evening because the day is full; nobody askedCount the evening hours for a month and show the total to your manager
The same ticket keeps coming backA category with twenty tickets a month that are all the same ticket; never fixed because never finishedPick that one category and spend a protected afternoon ending it
Mistakes with a patternSmall errors on easy tasks, in the afternoon, after an interrupted morningTreat 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 questionYes meansIf no
Did I keep both protected afternoons every week?The calendar shows them and they were keptFind 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 pageBook 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 monthReinstate the ten-minute habit and nothing else
Did I log every walk-up and call as a ticket?Two-minute tickets exist in the queueStart again on Monday; the count is the evidence
Were evening hours fewer than four this month?You counted, and the count was under fourShow 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 removedAsk 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 itCreate one sealed emergency login this month
Did my manager see the three numbers?Volume, oldest open ticket, interrupt hours, sent and acknowledgedSend 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?
There is no fixed number, because the cost depends on what each one pulls you out of. The useful measure is the share of the day spent handling interruptions and recovering from them, which the one-line log gives you. When that passes half the day, planned work has stopped, and that is the threshold to show your manager.
Does the interruption log have to be exact?
No. Time, who, what and a rough number of minutes, written before you deal with the interruption, is enough. Two weeks of rough lines is a better measurement than a year of accurate memory.
My manager says the desk looks fine. What do I show them?
The two-week log with the totals at the top, the three monthly numbers, and the table of signals with the rows that apply marked. Lead with the only-login row, because it is a business risk the manager owns. Ask for one decision rather than sympathy: which project to drop, or a date for the headcount conversation.
I cannot take two weeks off because there is nobody to cover. What then?
The cover person does not need to be an administrator. A calm colleague or your manager can run the desk for two weeks from the runbook's first page and the estate page, with a contractor on call. If the organization still cannot cover one person for two weeks, it has a single point of failure, and that belongs in the case for a second person.
Is this article about burnout?
It names burnout as a risk of the role and gives the operational signals that come before it, but it is not a guide to recovering from it. A later series in this library covers that in its own right. If the signals in the table describe your last six months, speak to your manager this month.
If everything in this article applies, where do I start?
The sign on the door and the one-line log, both this week, because they cost nothing. Keep the log for two weeks, then take it to your manager with the four responsibilities on one page. The rest follows from that conversation.

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.