The Invisible Infrastructure Work: Counting Unmanaged Hours in IT Teams

An engineer gives notice on a Tuesday. By Friday the team has a list of six things only she knew how to do: the certificate that gets renewed by hand every spring, the backup job that needs a nudge after month-end, the firmware process that keeps one storage array from throwing errors.

None of it was written down. None of it was on a roadmap. All of it was getting done.

That list is the subject of this post. Most midsize IT teams have one. Very few have counted it.

What does "unmanaged" infrastructure actually mean?

It rarely means neglected. In a company with 20 to 200 servers, "unmanaged" usually means the servers are managed by your own team, in the gaps between everything else, with no line item attached.

The work is real. It has no owner on paper, no ticket and no place in the budget. That is why it stays invisible until someone leaves or something breaks.

The work that never gets a line item

Here is what it can look like for a three-person team. The hours are an example, not a benchmark. Your own number is the only one that matters.

Forty hours is one engineer-week every month. On a three-person team, that is a quarter of one person, spent on work nobody planned and nobody reports.

Why does this work stay invisible?

Three reasons, and none of them is anyone's fault.

It sits inside salaries. Nobody raises a purchase order for a Thursday night patch window. Finance sees a headcount cost and has no way to see what the headcount is doing.

It arrives as interruptions. Planned work gets a ticket. A disk alert at 3am gets handled and forgotten. The hours are spent and no record exists.

The people doing it don't complain. The engineer who quietly tests restores is usually the last person to ask for credit, or for help.

The real exposure is concentration, not cost

Forty hours a month is a cost, and a manageable one. The bigger problem is where those hours live.

In most small teams the repeatable work has collected around one or two people. They know which server needs its updates in a certain order. They know which vendor contact answers. When one of them takes a week off, the team copes. When one of them resigns, the company finds out how much of its infrastructure ran on memory.

That makes this a continuity question as much as a scheduling one. It is also the version of the argument that lands with whoever approves the budget.

How do you count infrastructure hours without a time-tracking rollout?

You do not need new software. You need a shared note and thirty days.

1. List the seven kinds of work above. Add anything specific to your server room.
2. Tally as you go. Each time someone does one of them, they add the time, rounded to the nearest half hour, and their initials.
3. Include the interruptions. The after-hours alert counts even if it turned out to be nothing. Especially if it turned out to be nothing.
4. Add it up at the end of the month. Total hours, and how many of them belong to one person.

It will not be precise, and it does not have to be. A rough number you measured beats a confident guess.

What the number is for

It is not an argument for handing everything to someone else. Some of this work should stay with your team, and some systems are better left exactly where they are.

The number is a baseline. Without it, every hardware quote and every provider quote gets compared to zero, because the way things run today looks free. With it, you can ask any vendor a plain question: which of these hours stop being ours, and where is that written down?

We get asked that from both sides of the table. Dynascale is a Dell partner and a cloud provider, so we can quote the hardware or the service, and the recommendation follows the workload. Sometimes the right answer is to keep what you have and get the hours counted.

So what is your number? If you ran this for one month, what would the total be, and how much of it would sit with one person?

Next week: why the list got longer when the team did not.

‍