Software Teams Tripled Their Output in 18 Months — Your IT Team Is Still Fixing Servers One RDP Session at a Time

InfoWorld recently ran a story that should matter to every IT manager, sysadmin, and MSP tech — even though it is nominally about software engineering. A legal software company tripled output per engineer in 18 months. Deployments went from 82 to more than 155 per quarter. Customer-reported defects dropped 65% per million lines of code. They measured all of it — DORA metrics, cycle time, pull requests per developer — against a fixed baseline.

Here is the part worth reading twice: the author is clear that the AI itself was not the breakthrough. The breakthrough was redesigning the workflow around the new capability. The team stopped asking "should we use this tool?" and started asking "what should building software look like now that this exists?"

Now compare that to what happened on your shift last week. An alert fired. You found out about it late — or a user found out before you did. You opened a monitoring console, then a remote access tool, then the helpdesk, and fixed the problem by hand. One machine, one RDP session, one tab at a time. The engineering world is compounding its output. Most IT operations teams are still running the same swivel-chair workflow they ran in 2015, just with more tools open.

The 2 A.M. Workflow Nobody Redesigned

Let's walk through the most common scenario in IT operations — the one everyone recognizes and nobody has fixed.

Saturday, 02:14. Your monitoring tool emails an alert: disk on FS01 at 81% and climbing. The on-call tech is asleep. The email sits in an inbox nobody watches overnight.

Monday, 08:47. Users start filing tickets: "Can't save to the shared drive." The helpdesk SLA clock starts now — 54 hours after your monitoring tool already knew.

09:05. A tech triages, opens the RMM or TeamViewer, hunts for FS01 in a device list that does not match the monitoring tool's naming, and finally gets a remote session.

09:20. Temp files and stale Windows Update downloads get cleared by hand, in an RDP window. The results of that cleanup — how much was reclaimed, whether it worked — live in the tech's head and nowhere else.

09:35. The tech switches back to the monitoring console to confirm the disk graph turns green, then copy-pastes a note into the ticket.

Total: about 80 minutes of hands-on time spread across three or four tools, for a problem your monitoring platform detected before the weekend started. And if the pattern repeats next month? Same manual dance, minute for minute.

Why the Gap Exists: Detection Tools That Can't Act, Action Tools That Can't Watch

This is not a people problem. It is an architecture problem, and most IT stacks have three or four versions of it running simultaneously.

Monitoring and remediation live in different products. PRTG, SolarWinds, Zabbix, and Nagios detect. ScreenConnect, TeamViewer, AnyDesk, and Action1 act. ConnectWise Manage, Zendesk, and Jira Service Management document. Each tool maintains its own asset list, its own naming conventions, its own timeline. The "integration" between them is usually an email webhook or an API sync someone configured once in 2021 and nobody has audited since.

The remediation loop never closes. Your RMM can run a script, but it does not watch the metric that script was supposed to fix. Your monitoring watches the metric but cannot run the script. So a tech cleans up disk space at 09:20 and the monitoring tool re-alerts two days later — not because the fix failed, but because nothing recorded that the fix happened.

Script results evaporate. When a tech runs PowerShell by hand inside an RDP session, the output goes to a console window that dies when the session closes. There is no record of what ran, on which device, with what result. That is painful for troubleshooting next time, and worse for compliance audits: "Who changed what on this server, and when?" has no answer.

Per-device workflows do not scale. RDP is one machine at a time. When a bad Java update or a rotated local admin credential hits 300 endpoints, your team spends days doing what a script across a device group does in minutes. MSPs feel this hardest: 20 minutes of manual work per endpoint per month, across 12 clients, is a full headcount.

The business impact is measurable: MTTR inflated by tool-switching, SLA misses that start the clock at user complaint instead of detection, on-call techs burning out because 2 a.m. pages arrive for problems a script could have fixed while everyone slept, and reporting that cannot answer basic questions because the monitoring data, the remediation data, and the ticket data live in three systems that do not agree on what a "device" is.

How AlertMonitor Closes the Loop: Alert to Resolution in One Console

AlertMonitor was built on the same insight as that engineering team: the tool is not the win — the redesigned workflow is. Monitoring, RMM, helpdesk, patching, and network topology share one data model, so a device in an alert is the same device you remote into, patch, and attach to a ticket.

Concretely:

• Act from the alert. From any alert, launch a remote session, run a script, or push software — on one device or an entire device group — without leaving the console or re-authenticating into a second product.
• Script results feed back into monitoring. When your cleanup script reclaims 14 GB on FS01, the disk metric recovers and the script output lands on the same timeline, timestamped right next to the recovery. The next person who looks at that server sees the alert, the action, and the result in one place.
• Device groups turn fixes into scale operations. Run a script across every server at Client A, or every Windows 11 workstation missing a patch, on a schedule or triggered by an alert condition.
• Known problems fix themselves. Map recurring alerts — spooler crashes, service failures, disk pressure — to automated remediations. The 2 a.m. page becomes a resolved record the tech reads at 9 a.m.
• The helpdesk shares the same data. Alerts link to tickets automatically, so SLA reporting comes from one dataset instead of a spreadsheet reconciliation between two systems.

The same disk-full incident, in AlertMonitor: the alert fires at 02:14 with device context attached. A remediation script runs automatically — or the on-call tech clicks Run Script directly from the alert. The script reclaims space, the output is logged to the device record, the metric recovers, and the ticket auto-created from the alert shows detection, action, and resolution on one timeline. Hands-on time: minutes, in one console.

Practical Steps: Start Compounding Your Team's Output This Week

Step 1: Baseline your alert-to-fix loop. Time the next five routine incidents. Count the tools touched between alert and resolution. That number is your version of the article's fixed baseline — everything you change from here gets measured against it.

Step 2: Build a remediation script library in AlertMonitor for your top five recurring alerts. Start with the classics. Pull disk usage across an entire server group from one script:

$servers = 'FS01','FS02','SQL01','DC01'
Get-CimInstance -ClassName 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)}} |
    Sort-Object FreePct | Format-Table -AutoSize

Package the classic disk-cleanup fix so it runs identically on every device, every time, with the result logged:

$paths = "$env:TEMP", 'C:\Windows\Temp', 'C:\Windows\SoftwareDistribution\Download'
$before = (Get-PSDrive C).Free
foreach ($p in $paths) {
    if (Test-Path $p) {
        Get-ChildItem $p -Recurse -Force -ErrorAction SilentlyContinue |
            Remove-Item -Recurse -Force -ErrorAction SilentlyContinue
    }
}
$after = (Get-PSDrive C).Free
'Cleaned {0:N2} GB on {1}' -f (($after - $before)/1GB), $env:COMPUTERNAME

Step 3: Automate the patterns you have seen ten times. A print spooler check-and-restart is a two-minute script that eliminates one of the most common helpdesk tickets in existence:

$svc = Get-Service -Name 'Spooler' -ErrorAction SilentlyContinue
if ($svc -and $svc.Status -ne 'Running') {
    Restart-Service -Name 'Spooler' -Force
    Write-Output ('Spooler restarted on ' + $env:COMPUTERNAME)
} else {
    Write-Output 'Spooler already running - no action needed'
}

The Linux equivalent, for mixed environments:

systemctl is-active --quiet nginx || { systemctl restart nginx && echo "nginx restarted on $(hostname)"; }

Step 4: Make patch compliance data, not a spreadsheet hunt. This script reports exactly what is pending on a device. Run it across a device group and you have a compliance report in the time it used to take just to open WSUS:

$session = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$result = $searcher.Search('IsInstalled=0 and Type=''Software''')
if ($result.Updates.Count -eq 0) {
    Write-Output ('COMPLIANT: no pending updates on ' + $env:COMPUTERNAME)
} else {
    Write-Output ('NON-COMPLIANT: ' + $result.Updates.Count + ' updates pending on ' + $env:COMPUTERNAME)
    $result.Updates | ForEach-Object { Write-Output (' - ' + $_.Title) }
}

Step 5: Measure like the engineering team did. They did not guess whether output tripled — they tracked DORA metrics against a baseline. Track your own: MTTA, MTTR per alert type, percentage of alerts auto-remediated, scripts executed per week. When MTTR on disk alerts drops 80%, you will have the number to prove it — to your manager, or to your clients.

The Bottom Line

The engineering team in that article did not triple output by working three times harder. They removed handoffs, closed the loop between detection and action, and measured everything against a fixed baseline. Those are exactly the levers IT operations has available — the difference is that AlertMonitor hands them to you in one platform instead of making you bolt them together across four.

The teams that redesign the workflow will compound. The teams that keep swivel-chairing between a monitor, an RMM, and a helpdesk will keep paying the same 80 minutes per incident, forever.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources