Scaling Technicians, Not Just Tooling

RMM lets a small team manage a large estate. The limit people hit is not tool capacity but how much a technician can know about the clients they serve.

The recommendations in “Scaling Technicians, Not Just Tooling” become sustainable only when the recurring work has visible owners and enough capacity. A team assessing time tracker for projects can use time and project records to see where operational effort accumulates, without treating activity data as a substitute for technical evidence or direct discussion with technicians.

For an independent operational benchmark, compare the local practice with NIST Cybersecurity Framework; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

What automation scales

Repetitive actions.

Monitoring coverage.

Patch deployment.

Reporting.

These scale almost without limit, which is why the tooling pays for itself.

What it does not

Judgement about a specific client's environment.

Knowing that this server cannot reboot and why.

The relationship that makes a difficult conversation easy.

Understanding what the client's business actually does, which determines what severity means.

These are per-client and they scale with people.

The knowledge ceiling

A technician can hold working knowledge of a limited number of clients — the number varies and it is not large.

Beyond that they are working from documentation, which is slower and more error-prone.

Which is an argument both for documentation and for client assignment, and most providers rely on the first without the second.

Assignment versus pooling

Assigned technicians know their clients and create a dependency on individuals.

Pooled technicians scale and know nobody well.

The usual answer is a primary and a secondary per client, with the pool behind them — which preserves knowledge and survives absence.

Tiering the work

First line: triage, known fixes, following documented procedure.

Second line: diagnosis, anything not documented.

Third: the small number who know the estates deeply.

The structure works when the escalation path is clear and the documentation lets first line resolve more over time.

What breaks it

Escalating everything, because first line lacks documentation or authority.

Third line doing first line work because they are quicker.

And no feedback loop: things escalated repeatedly should become documented procedures, and usually do not.

Hiring ahead of the ceiling

The signs: escalation rate rising, response times slipping, the same two people appearing on every difficult ticket.

These precede the client complaints by months.

Watching them is how you hire before the service degrades, rather than after.

What to check

How many clients does each technician actually know?

Is there a primary and secondary per client?

What proportion of tickets escalate, and is it rising?

And do repeatedly escalated issues become documented procedures?

The point

Automation scales repetitive action.

It does not scale knowing that this server cannot reboot and why, which is per client and scales with people.

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.