A working playbook for a two-person IT function

It is Monday, and there are two of you. One is on a call with a new hire whose laptop will not enroll. The other is staring at a sign-in alert from a country nobody on the team has visited, while a sales rep waits on a security questionnaire that was due Friday. Somewhere in the queue is a contractor who left in March and may still have access to a shared drive.

This is the shape of a two-person IT function. The work is not hard. It is endless, and it arrives all at once, and no version of the calendar lets two people get through it by being heroic. The instinct is to ask for a third person, or a tool that promises to shrink the pile. Most of the time the pile is not the problem. The way the pile is sorted is.

A two-person team can cover a surprising amount of ground. What it cannot do is cover all of it the same way. The trick is deciding, on purpose, which work you own, which you hand to a specialist, and which you never touch with human hands again. Here is how to draw that map.

Before you assign anything, name the three buckets. Every task your team faces belongs in exactly one of them.

• Own. Work that needs context only you have: who the people are, how the business runs, what is urgent this week. This is judgment work, and it does not transfer well.
• Route. Work that needs depth you cannot keep current at two people: threat monitoring, audit evidence, identity architecture. This goes to a specialist who does it all day.
• Automate. Work that is the same every time: provisioning, deprovisioning, alerting, reminders. Anything a human does the same way twice is a candidate.

Most two-person teams try to own all three buckets at once. That is the source of the Monday. When the same two people are the help desk, the security operations center, and the audit team, every bucket gets the leftover attention of the other two. The point of sorting is not to do less. It is to stop doing the wrong work with the wrong attention.

Own the work that depends on knowing your own company. Triage is yours: deciding what is urgent, what can wait, and who is truly blocked. Vendor and license decisions are yours, because you know what the team uses and what it only pretends to use. Internal communication is yours, because trust lives in the relationship, not in a queue.

Own the first response, too. When a person cannot log in, they want a human who knows their name, not a ticket number that disappears. That immediacy is something a two-person team is genuinely good at, and it is worth protecting. The mistake is letting the small, human work expand to fill space that deep work needs. You own the front door. You do not have to own the whole building.

Some work punishes generalists. Security monitoring is the clearest case: tools like Amazon GuardDuty and Microsoft Defender will happily generate findings around the clock, and findings nobody reads are not a security program. Reading them well takes someone who sees the patterns every day. Identity architecture is similar. Setting up Conditional Access in Microsoft Entra ID correctly is a different skill from supporting the people who live inside it.

Audit evidence is the third. Frameworks like SOC 2 expect proof that controls operate over a period of months, not a screenshot taken the week before the assessment, a structure described in the AICPA Trust Services Criteria. Gathering that proof by hand is a job by itself. The honest move at two people is to route these to a partner who runs them as their daily work, so your two stay focused on the work only you can do.

Security is an operational problem before it is a tool problem. The tools are mostly already in your cloud. What a small team lacks is the time and the depth to run them well, and that is a staffing question, not a shopping question.

The last bucket is the one that gives you your week back. Anything that happens the same way every time should happen without you. When a new hire starts, their accounts, groups, and device enrollment should provision from the role, not from your memory. When someone leaves, access should revoke on the effective date, automatically, not whenever you next remember to check. Routine alerts should escalate on their own, and access reviews should arrive on a schedule, not as a panic the week before an audit.

Done well, automation also produces its own paper trail. The record of who got access, when, and why is not extra work; it falls out of running the process properly, and it is exactly what an auditor asks for later. Automate the repeatable, and the repeatable stops interrupting the judgment work that needed you all along.

Go back to that Monday. The laptop enrollment was an automate problem solved before it started. The sign-in alert was a route problem, already in front of someone who reads them all day. The questionnaire pulled from evidence that existed because the environment was run that way. The contractor's access revoked itself in March. Two people did not work harder. The work was sorted so that only the parts needing a human reached one.

That is the whole playbook: own the judgment, route the depth, automate the repeatable. A two-person team is not small because it has two people. It is small when all the work lands on those two the same way. So before next Monday, ask yourself the honest question: of everything on your plate this week, how much of it truly needs you?