How one IT lead covers the work of a team of five

It is 8:40 in the morning and you have already lost the thread. A new hire starts today and nobody set up the accounts. The finance lead is locked out of a shared mailbox again. Someone forwarded a "quick question" that is, on a second read, a request to grant a contractor access to a system you would rather not open up. Your phone buzzes with a calendar reminder for the standup you are about to miss, and the laptop you ordered for next week is sitting in a box because you have not had 10 minutes to image it.

You are the whole IT function. Every one of those problems lands on you, and most of them landed in the last 20 minutes. So you triage by volume alone: loudest gets answered, quietest waits, and the important-but-quiet work (the access review, the offboarding you never finished, the policy that is six months stale) slides one more day.

Here is the uncomfortable part. The person doing the work of five is not five times faster. They are running a different operating model: they treat IT as a system, not an endless pile of tickets. The difference is not effort. It is structure.

When you are solo, the default is to meet each request where it lands. The mailbox lockout shows up in email, so you answer it in email. The access request shows up in chat, so you handle it in chat. The new hire setup shows up as a sticky note in your own head, so it lives there until it does not.

The cost is invisible until you add it up. Every channel switch is a context switch, and context switching is where the hours go. There is solid research showing how expensive that reset is; one widely cited study from the University of California, Irvine found it takes an average of about 23 minutes to refocus after an interruption (unverified as to whether it generalizes to IT work specifically, but the direction holds). For a solo lead, the interruptions are the job. The work between them is what never gets done.

A team of five does not escape interruptions. It absorbs them, because the work lives somewhere other than one person's inbox and one person's memory.

The leads who run like five have quietly stripped out the small decisions that eat a solo person alive. They are not making fewer choices because they are smarter. They made the choices once, wrote them down, and stopped re-deciding.

A few decisions worth making exactly once:

• Where requests live. One intake, one queue, one place where a request becomes a tracked item with an owner and a status, so nothing depends on you remembering it.
• What the common jobs look like. Onboarding a new hire, granting access, offboarding someone leaving: each one a defined sequence you run the same way every time, not a fresh puzzle at 8:40 in the morning.
• What you handle and what you route. Solo does not mean alone. The work that needs a specialist (a security concern, an identity change in Entra, a finding from GuardDuty) goes to the specialist; it does not wait for the one generalist to find a spare hour.

None of that is a tool purchase. It is an operating decision. The tools to enforce it are almost certainly already in your stack.

The work that quietly buries a solo lead is the security and access work, because it is important, invisible, and never urgent until it is. The offboarding you half-finished leaves a credential live. The contractor's access outlasts the contract. The Conditional Access policy you meant to tighten stays loose. Nobody pages you about any of it, so it waits.

This is why we say security is an operational problem before it is a tool problem. You can own every license Microsoft and Amazon Web Services (AWS) sell and still carry real exposure, because the gap is not a missing product. The gap is that the access review, the device check, and the policy update are tasks with no owner and no system to surface them. A bigger team does not fix that by being bigger. It fixes it by running those tasks on a schedule; adrenaline stops being the trigger.

A solo lead does not get safer by working later. They get safer when the quiet, important work runs whether or not anyone remembers it that morning.

Picture the same 8:40, run on a system. The new hire setup is a defined sequence that started yesterday when the request came in, so the accounts are ready. The mailbox lockout is a tracked request with a status, not a thread you have to reconstruct. The contractor access request follows a known path: file it, route it, approve it, log it, with a record that it happened. The stale policy is on a review cadence, so it is not stale.

You are still one person. You are not doing five people's typing. You are running an environment where the work has a place to live, the common jobs run themselves, and the quiet security tasks surface before they become incidents. That is the leverage. The win comes from structure, not from heroics.

If you want a concrete starting point, the submit a request guide shows how a single intake turns scattered messages into one accountable queue, and the getting started guide walks the rest of the operating surface.

The solo lead who covers a team's worth of work is not grinding harder than you. They stopped meeting every request where it landed and built a system that catches the work for them, so their attention goes to the hard problems; the routing takes care of itself. The interruptions still come. The difference is that the important-but-quiet work no longer depends on a good memory and a quiet morning.

You already have most of the pieces: the identity platform, the cloud controls, the licenses. What is usually missing is not another product. It is the operating model that connects them and the people to run it.

So the question for your week is not how to move faster. It is this: which decisions are you re-making every morning that you could make once and never touch again?