The News Behind This Post
The Register recently reported that KPMG's Advisory arm is reshaping yet again — with cuts landing on AI, cyber, SAP, and testing teams, and severance sums that some departing staff are calling insulting. Set aside the Big Four politics for a moment. The operational takeaway is blunt, and it applies far beyond consultancies: organizations are cutting tech headcount while the infrastructure those teams support keeps growing.
If you are the sysadmin, help desk lead, or MSP technician still standing after a round of cuts like this, you know exactly what happens next. The 400 Windows endpoints still need patching. The Hyper-V cluster still needs watching. The printer on floor 3 will still jam. Tickets keep arriving. Your phone keeps going off — except now there are fewer people to answer it.
This post is not about severance packages. It is about the reality lean IT teams face every day after one: your estate did not shrink, so your tooling has to do more of the work. Most IT stacks are not built for that.
The Problem: Tool Sprawl Cannot Survive a Smaller Team
The typical mid-size IT department or MSP runs something like this: ConnectWise or Ninja for RMM, PRTG or SolarWinds or Zabbix for monitoring, Freshservice or Jira Service Management for the helpdesk, WSUS or a patch add-on for updates, and TeamViewer or AnyDesk for ad-hoc remote support. Five tools, five logins, five data silos. That stack was barely workable with a full team. With a trimmed one, it fails in four specific ways:
1. Every alert costs 15 minutes of context switching. An alert fires in the monitoring tool: FS01, C: drive at 92%. Now the technician opens the RMM console to see the device, the helpdesk to check for a related ticket, the patch console to see whether a pending update is the culprit, and a separate remote access tool to actually get onto the box. Nothing shares context. Nothing shares history. The technician burns the first quarter-hour of every incident reassembling a picture that one console should have shown them.
2. Remediations vanish into a black hole. Your tech runs a cleanup script from the RMM tool. It works. But the monitoring timeline never records it, the ticket never references it, and next month a different tech re-diagnoses the same problem from scratch. On a lean team, repeated diagnostic work is not an annoyance — it is the difference between coping and drowning.
3. Alerts go to inboxes nobody watches anymore. This is the quiet killer. When the colleague who owned the monitoring configuration leaves — and after cuts like KPMG's, someone always leaves — their alert routing, thresholds, and maintenance windows leave with them. The disk fills on Friday night, the alert lands in the mailbox of a person who no longer exists, and Monday starts with 14 users unable to save files. Time to acknowledge: half a workday. The actual fix: 90 seconds of scripted cleanup.
4. Burnout compounds. The Register story notes departing staff calling the severance insulting. Insulting severance plus heavier workloads for the people who remain is a formula for the next resignation. Every redundant manual step — every tab switch, every hand-copied note between tools — pushes the remaining team closer to the door. And when they go, the tribal knowledge in their head goes with them.
The business impact shows up in the metrics your IT manager actually tracks: longer MTTR, missed SLAs, Monday-morning ticket backlogs, and SLA reports stitched together by hand because the monitoring data and the ticket data live in systems that disagree on everything.
How AlertMonitor Collapses the Stack
AlertMonitor was built on a simple bet: monitoring, RMM, helpdesk, patching, and network topology belong in one platform, because the technician working an incident needs all five in the same window.
Here is what changes:
The alert arrives with full device context. When FS01's disk alerts, you see the device's patch state, its recent script history, its open tickets, and its position on the network map — on the same screen as the alert. No tab-switching between a monitoring console and a separate RMM tool.
Remote action is one click from the alert. AlertMonitor lets technicians remotely view and manage endpoints, run scripts across entire device groups, push software, and open remote sessions — all without leaving the platform they are already using to monitor infrastructure.
Script results feed back into monitoring data. This is what kills the black-hole problem. When your cleanup script runs across 60 endpoints, the results land in the same timeline as the alerts and the ticket updates. Automated remediations and manual technician actions are both visible, in one place, permanently. Nobody re-diagnoses a problem that was already fixed.
The SLA report writes itself. Alert fired at 21:47, script executed at 21:49, service restored, ticket auto-updated and closed at 21:52. One system, one timeline, one report. No spreadsheet archaeology merging monitoring exports with helpdesk exports that never quite line up.
For an MSP, multiply all of this by client count. One NOC dashboard, one set of scripts deployable across client device groups, one place where a technician supporting 12 clients actually lives — instead of a dozen tabs across five tools per client.
The practical outcome: the time between alert and resolution drops from the better part of an hour to minutes, and a two-person team can credibly cover an estate that used to need four.
Practical Steps: Do These Today
1. Find the disks that will page you next
Run this across your Windows servers — it lists every volume under 15% free, worst first:
$servers = "DC01","FS01","SQL01","APP01","RDS01"
Get-CimInstance Win32_LogicalDisk -Filter "DriveType=3" -ComputerName $servers |
Select-Object SystemName, DeviceID,
@{n='SizeGB';e={[math]::Round($_.Size/1GB,1)}},
@{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
@{n='FreePct';e={[math]::Round($_.FreeSpace/$_.Size*100,1)}} |
Where-Object { $_.FreePct -lt 15 } |
Sort-Object FreePct
In AlertMonitor, save this script once, attach it to your server device group, and run it on a schedule. The results flow into the monitoring timeline, and the disk alert becomes a trigger for the script instead of an email nobody reads.
2. Snapshot patch compliance before someone asks for it
$session = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$result = $searcher.Search("IsInstalled=0 and Type='Software'")
"$($env:COMPUTERNAME): $($result.Updates.Count) missing updates"
$result.Updates | Select-Object -ExpandProperty Title
Deployed across a device group in AlertMonitor, this gives you a live compliance picture per device — visible right next to that device's alerts and tickets, not buried in a separate patch console nobody opens until audit season.
3. Turn dead service checks into self-healing ones
$svc = Get-Service -Name "Spooler" -ComputerName "WKS-1042"
if ($svc.Status -ne "Running") {
Start-Service -InputObject $svc
"$($svc.Name) restarted at $(Get-Date -Format 'HH:mm:ss')"
}
Same idea on Linux:
systemctl is-active --quiet nginx || { systemctl restart nginx; echo "nginx restarted $(date +%T)"; }
df -h --output=source,pcent,target | awk '$2+0 > 85 {print "LOW DISK: "$1" "$2" "$3}'
Wire the script to the "service stopped" alert in AlertMonitor, and the platform attempts remediation the moment the alert fires — before a human is even awake to see it. The restart attempt and its result sit in the same timeline as the alert, so whoever comes in at 7am sees exactly what happened overnight, with zero re-investigation.
4. Audit your own alert routing
Open your monitoring tool and ask a hard question: who receives each critical alert, and are they still employed? After any round of cuts, re-verify routing, on-call schedules, and escalation paths. If the answer to "who gets this at 2am" is a departed colleague's mailbox, you have just found your next Monday-morning outage.
The Bigger Picture
Nobody enjoys reading a story about insulting severance packages. But the practical lesson for IT teams is not about KPMG specifically — it is that team size can change overnight, while your servers, endpoints, firewalls, switches, and printers do not change at all. The only durable answer is a tool stack that assumes fewer hands: one platform where monitoring finds the problem, RMM fixes it, patching prevents the next one, and the helpdesk records all of it in the same timeline.
That is the difference between a lean team that copes and a lean team that quietly burns out one tab-switch at a time.
Related Resources
AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.