Time Management and Prioritization

Getting the right work done in an environment full of interruptions: prioritizing tickets and tasks, limiting work in progress, protecting focus time, and saying no or not yet.

Why time is hard in IT work

Most office jobs have a plan for the day. IT support and operations have a plan and a queue, and the queue wins. A VPN outage at 09:10 does not care that you blocked the morning for documentation. A developer's day has fewer outages but just as many pings: a question in chat, a review request, a "quick look" at a failing build.

Time management in this setting is not about squeezing more into the day. It is about three decisions you make over and over:

  • What comes first? Prioritization: choosing the order, and accepting that some things will wait.
  • How much at once? Limiting work in progress, so work gets finished instead of started.
  • When do I protect focus? Some work (an analysis, a change plan, a script) needs an uninterrupted hour, and that hour has to be arranged.

Teams face the same problem at a larger scale. A team that plans all its capacity and then loses a third of it to incidents fails every plan; the fix there is an interrupt buffer. This page is about the individual version of the same idea.

Ticket priority comes first

In a service desk or NOC (network operations center) you rarely decide on your own which incident matters most. The ticket already has a priority, derived from impact (how many people or how much business is affected) and urgency (how fast the damage grows). A P1 for a whole office beats a P4 for one person, however friendly that person is. Service level targets attach a clock to each priority, which is why the order of the queue is not a matter of taste.

Within that frame you still decide a lot:

  • Which of five P3 tickets to take first. Oldest first is a fair default; a ticket close to its target time goes before one that has days left.
  • When a ticket's priority looks wrong. Raise it (or lower it) with a reason in the ticket, or ask the shift lead. Silently working on something else is how a "low" ticket that is really a security incident sits for two days.
  • Everything that is not a ticket: documentation, learning, the change you prepare for Thursday, the script that would remove an hour of manual work each week.

Urgent and important: the Eisenhower matrix

The Eisenhower matrix sorts tasks on two separate questions: is it urgent (does it lose value soon if nobody acts), and is it important (does it matter for your goals, your team or your users)? The four combinations suggest four ways to handle a task.

The Eisenhower matrix as a two by two grid. Columns: urgent and not urgent. Rows: important and not important. Important and urgent: do now, for example a P1 outage. Important, not urgent: schedule, for example runbooks, learning and automation. Urgent, not important: delegate or batch, for example most interruptions and same-day requests from others. Neither: drop or park. Urgent Not urgent Important Not important 1 · Do now P1 outage, a change window that starts now 2 · Schedule Runbooks, learning, automation, change prep Gets squeezed out 3 · Delegate or batch Most pings, surveys, others' deadlines 4 · Drop or park Nice-to-haves, reading every digest
The four quadrants, with typical IT examples. The second quadrant is where most long-term improvement lives.

The matrix is useful mostly for one insight: the second quadrant. Writing the runbook, automating a weekly manual job, studying for a certification, cleaning up monitoring: none of it is ever urgent, so in a reactive job it loses every day to something that is. The fix is to treat it like an appointment: put it in your calendar, tell your lead, and protect it.

Tomasz, a network engineer in the NOC (network operations center), sorts his open work on a Monday morning. He answers the two questions per task; the code only groups them. 

# Tomasz's open work on Monday morning, with two yes/no judgments each.
tasks = [
    ("INC-20731 VPN down for the Zwolle office", True, True),
    ("CHG-3104 firewall rule review, CAB on Thursday", False, True),
    ("Update the switch replacement runbook", False, True),
    ("REQ-4517 meeting room network port, needed next month", False, True),
    ("Vendor survey about support quality, closes today", True, False),
    ("Rename old lab VMs to the new naming scheme", False, False),
    ("Study for the Network+ exam", False, True),
    ("Colleague asks for help with a cable label", True, False),
    ("Read every post in the vendor forum digest", False, False),
]

QUADRANTS = {
    (True, True): "1 Do now",
    (False, True): "2 Schedule",
    (True, False): "3 Delegate or batch",
    (False, False): "4 Drop or park",
}

for (urgent, important), name in sorted(QUADRANTS.items(), key=lambda q: q[1]):
    print(name)
    for title, u, i in tasks:
        if (u, i) == (urgent, important):
            print("  -", title)
1 Do now
  - INC-20731 VPN down for the Zwolle office
2 Schedule
  - CHG-3104 firewall rule review, CAB on Thursday
  - Update the switch replacement runbook
  - REQ-4517 meeting room network port, needed next month
  - Study for the Network+ exam
3 Delegate or batch
  - Vendor survey about support quality, closes today
  - Colleague asks for help with a cable label
4 Drop or park
  - Rename old lab VMs to the new naming scheme
  - Read every post in the vendor forum digest

The hard part is the judgment, not the sorting. "Urgent" is easy to confuse with "someone is waiting for me right now", and "important" with "the person asking is senior". Quadrant 3 is also not "unimportant to everyone": helping a colleague with a cable label matters to them. It means the task does not need your full attention right now, so you can batch it, hand it to someone better placed, or do it quickly at a natural break.

Limit work in progress

Seven tickets "in progress" usually means seven tickets nobody is progressing. Each one sits half-done, the users have heard nothing, and you spend part of every hour remembering where you left each of them. Kanban teams make this visible with a WIP limit: a maximum number of items in a column. The same idea works for one person: decide how many things you actively work on at once (often two or three, one of them the interruption you are handling), and finish or park one before you start another.

Waiting is normal in IT: for a user to test, for a supplier, for a change window. Waiting work is not in progress. Move it to a status such as "waiting for user" or "waiting for supplier", note what you are waiting for and when you will chase it, and take it off your mind.

When you must park work in the middle, leave a note that lets you, or a colleague, continue without starting over. Thirty seconds of writing saves the ten minutes of rediscovery that would otherwise follow. 

INC-20718  looked at this, will continue later
INC-20718  parked 10:42 for P1 INC-20731
Done:     user's laptop gets an IP (192.0.2.144), DNS resolves, the portal
          loads in Edge but not in Firefox.
Theory:   Firefox uses its own certificate store; the new proxy CA is
          missing there. Not yet tested.
Next:     check Firefox certificate settings on the laptop (user is in
          the office until 16:00, ext. 4417).

Interruptions and task switching

Task switching is moving your attention from one task to another and back. It always has a cost: you have to put the first task aside, load the context of the second, and later reload the first. In the operating system the same idea is called a context switch; in people it is slower and more error-prone.

What research actually found:

  • In an experimental study, Rubinstein, Meyer and Evans (2001) found that switching between tasks costs time, and that the cost grows with the complexity of the task rules. It is smaller when people get a clear cue about which task comes next.
  • Gloria Mark and colleagues at UC Irvine observed information workers in their offices (CHI 2005). In their study 57% of "working spheres" (units of work) were interrupted. 77.2% of interrupted work was resumed the same day, and when it was, it took on average 25 minutes 26 seconds before people returned to it, with about two other tasks done in between.
  • In a later experiment (CHI 2008), Mark's group found that people compensated for interruptions by working faster, with no loss of quality, but at a price: more stress, frustration, time pressure and effort.

For you, the practical conclusion is not "never be interrupted". Answering colleagues and users is the job. It is to make interruptions cheaper and fewer:

  • Leave a cue before you switch. One line on where you were and what the next step is (the parking note above). This is in the spirit of the Rubinstein finding that cues about the next task reduce switching costs.
  • Separate the queue from the deep work. Many teams rotate one person as the "shield" or queue owner per day or half day, who takes walk-ups, chat questions and new tickets, so the others can focus. Next day, someone else takes it.
  • Make channels match urgency. Agree as a team that a real emergency is a phone call or a page, not a chat message. Then you can mute chat for an hour without missing an outage.

Protecting focus time

Deep work

Deep work is a stretch of focused, uninterrupted time on a cognitively demanding task, such as designing a change, analyzing a recurring problem, writing a script or studying. The term was popularized by Cal Newport's book Deep Work (2016). Much of the work that moves a team forward is this kind of work, and it is exactly the kind that interruptions destroy.

Practical ways to get some, even in an operations job:

  • Block one or two 60–90 minute slots a week in your calendar and give them a name ("CHG-3104 plan"), so people see what the time is for.
  • Schedule them on days you are not the queue owner or on call.
  • Close the mail and chat clients, not just minimize them, and say in the team channel how to reach you for an emergency.
  • Start with a written goal for the block. "Work on the runbook" is vague; "draft steps 1–5 of the switch replacement runbook" is finished or not.

The Pomodoro Technique

The Pomodoro Technique splits work into fixed intervals, traditionally 25 minutes of focused work followed by a short break of about 5 minutes, with a longer break after four intervals. By most accounts Francesco Cirillo developed it in the late 1980s as a university student, naming it after his tomato-shaped (pomodoro) kitchen timer. It is a form of timeboxing: the fixed length makes it easier to start, and the break is a natural moment to check the queue.

Treat the 25 minutes as a starting point, not a rule. Some tasks need longer blocks, and in a support role an interval will sometimes end early because a P1 arrives. That is fine; the habit of starting with a clear goal and a timer is the useful part.

Task batching

Task batching means grouping similar small tasks and doing them together, instead of spreading them over the day. Each batch needs one switch instead of many. Common batches in IT work:

  • Email and chat that are not urgent: check them at set times (for example at the start of the day, after lunch and at 16:00).
  • Small requests of the same kind: three access requests, two password-manager vault invites, a batch of REQ tickets for new laptops.
  • Follow-ups: chase every "waiting for user" ticket in one round.

Saying no, or not yet

You will be asked to do more than fits. Agreeing to everything feels helpful, but the work you cannot do lands somewhere: missed promises, rushed changes, or evenings. A clear "not yet" with a reason and a date is more useful to the person asking than a "yes" that quietly turns into nothing.

Three moves work in most situations: say what you are doing now, offer a realistic time, and give the choice back to whoever owns the priorities. 

Sure, I'll look at it!
Hi Joost, I'm on the VPN outage (INC-20731) until at least noon,
and this afternoon is the CHG-3104 review. I can look at the billing
export issue tomorrow at 09:00. If it can't wait, my lead can move
the review: shall I ask?

"No" is the right answer when a request is not yours to take on: work outside your access or competence, work that bypasses the change process, or a favor that skips the queue for someone senior. Point to the right route instead: "Please log it as a request so it gets a priority; I'll mention it to my lead."

A simple daily system

You do not need an app or a method with a name. You need one trusted list and a few minutes at the start and end of the day.

  • One list. Tickets live in the ticket system; everything else (promises made in a meeting, "can you check…" in chat) goes on a single personal list the moment you hear it. Your memory is not a list.
  • Morning: pick. Check the queue and your calendar, then pick the one or two non-ticket things that must happen today. Plan for interruptions: in a support role, half a day of planned work is often a full day.
  • End of day: close the loops. Update the tickets you touched, write parking notes, move promises to tomorrow's list, and note what you finished. A short "done" list is good material for your next performance review, and a useful antidote to the feeling that you did nothing but answer pings. 
Queue owner: Emeka (I'm free for planned work until 13:00)
Must today:  CHG-3104 review notes ready for CAB (deep work 09:15–10:30)
             reply to Joost about the billing export (promised for 09:00)
Batch 13:00: 3x REQ access requests, chase 4 "waiting for user" tickets
Waiting:     supplier RMA for core switch (chase Thursday)
Done:        (fill in at 16:30)

If your list keeps growing faster than you can finish it, that is not a personal failure; it is information. Bring it to your lead with numbers ("12 open items, 4 of them older than two weeks"), so the work can be redistributed or dropped deliberately. Chronic overload is a health risk too: see Health and Sustainable Work.