Take a 10-person IT team at $100K each, fully loaded. That’s $1M a year. Here is a normal day for one of them. These numbers are an example, not a survey, so swap in your own.
- Four hours keeping things running. Fixing what broke overnight. Answering questions. Watching the alerts.
- Two hours in meetings. Status updates. Vendor calls. The steering committee about the project that’s stuck.
- Two hours on the work you approved. The new features. The tech debt everyone agreed to fix. The project on the slide you showed the executive team.
That’s 25%. On a good day. Then something breaks. Because it always does.
A production issue. A vendor escalation. An outage impacting users. Those two hours go first, because nobody gets yelled at for a late project while the system is down. For a week, sometimes a month, your $1M team spends 100% of its time keeping the lights on.
The math nobody runs
In the example, $750K a year buys survival, not progress. The other $250K gets raided by every fire that sparks during the day.
Leadership looks at that and thinks IT is slow. The team looks at it and thinks nobody sees them drowning. Both are right.
The fix usually isn’t more people. It’s the two or three systems causing most of the fires. Stabilize those and win back two of those reactive hours a day. Improvement time doubles. Same team. No new headcount. Here is how to go after it.
Count the hours first
You can’t fix a split you haven’t measured. For two weeks, sort the team’s hours into three buckets: keeping things running, meetings, and progress work, meaning the items on the roadmap.
- Use what you already have. Export the tickets and look at the calendars. If the tickets don’t capture it, have each person jot down a rough split at the end of the day. Rough is fine. You are looking for the general shape to establish a baseline, not a minute-by-minute play call.
- Show leadership one number. The share of team hours that went to progress work. Expect it to look worse than anyone hoped. That is the point.
Find the few systems behind most of the fires
Take the last 90 days of incidents and tag each one with the system, vendor or cause behind it. Add up hours, not tickets. A five-minute ticket and a five-hour outage are not the same size.
Then rank them. If a few systems sit at the top, you have your targets. If the fires are spread evenly, the cause is more likely process or missing documentation. Both answers are worth knowing.
Treat each of the top two or three like any other approved project:
- Name one owner.
- Set a target, such as fewer incidents a week or fewer hours lost, and a date.
- Reserve a fixed slice of the week for it, and put it on the roadmap.
After every fire, write a short note: what failed, why, and what was done. It keeps the team from fighting the same fire twice.
Be honest with leadership about the cost. The first weeks take time from the roadmap before they give any back. Asking for that patience is a change management problem, so plan for it.
Protect the time you win back
- Put one person on interrupts. Google’s SRE book is blunt about this: “If you currently assign tickets randomly to victims on your team, stop.” Make tickets a role and rotate it. It also puts a price on the alternative: a 20-minute interruption, it says, “results in a loss of a couple hours of truly productive work.” On a small team, rotate by the day. Everyone else works the roadmap unless there is an outage.
- Cut alerts nobody acts on. If an alert fires and nobody does anything, fix it or delete it. Every alert should lead to an action.
- Let an agent watch the baseline. I run an AI agent that is prompted to act as a full-time network administrator. It is read-only, with read-only credentials for the firewall, switches, access points, NAS devices and the like. It knows what is on the network and what a normal day looks like, so it can quickly give the team a heads-up when something deviates. That is the key point. It is also a great use case for a local model. Read-only means it can tell you something changed but can’t change anything, and the questions in my post on agents trusting each other too much still apply.
- Automate the top repeat requests. Look at the five most common requests in your ticket data. Password resets are the classic. Microsoft’s licensing page says basic self-service password reset is included in Microsoft 365 Business Standard and above, and that writing resets back to an on-premises Active Directory requires Business Premium or Entra ID P1 or P2.
- Make meetings earn their place. Replace the status meeting with a short written update. Give every recurring meeting a decision it exists to make, and drop the ones that have no agenda. For the steering committee on the stuck project, ask what is blocking it. Then remove the blocker, or pause the project in the open.
What to expect
Don’t aim for eight hours of roadmap work a day. Google’s SRE organization sets a goal of keeping operational work below 50% of each technician’s time and spending at least half on project work. Their buckets differ from yours, but the target is a fair one. Winning back two hours takes the example team from 25% progress work to 50%. That is a good result, and it will take longer than a month to fully realize.
But somebody has to count the hours first. If you actually counted, what would your team’s split look like?
