Bryan Needs a Title for His Home Page
The problem of not solving the source of your problems.
There’s a difference between managing a problem and solving it.
On a recent gig, I watched a support team chase the same category of ticket for weeks, drive space alerts on machines with 128–256GB system drives. The standard fix was to log in, clean temp files, move user data to network shares, and close the ticket. Rinse repeat. Daily ticket volume drove a quick resolution then move on.
At the management level where only the ticket class was seen there were comments of better education to the users on how to manage their data or to tell them not to keep so much work on their devices. There were also talks about larger drives or increased VM allocations. All of these are reasonable options to consider.
I looked at a handful of these systems myself and found an incorrect page file configuration in the standard deployment image. It was consuming up to 40% of the drive before the user even started working. On one system with a 128GB drive, the page file allocation alone was 96GB. Three quarters of the drive, before accounting for Windows, applications, or user data. Every machine deployed from that image inherited the problem.
In this case, one configuration fix addressed the source of the recurring tickets and freed up support time. No new hardware. No budget request.
The team handling this was working hard to help. Their cleanup work gave users enough room to get back to work. But every ticket treated as an isolated incident was another opportunity for the underlying problem to keep going. When the queue stays full, making room to investigate a pattern can be difficult. Yet that’s often where the biggest return is: asking why the same work keeps needing to be done.
A drive space alert that seemed like a generic user problem turned into a higher level technical problem, and when repeated across a fleet, it suddenly becomes a problem where you can calculate lost employee time, support overhead, and potentially an unnecessary hardware expense if resolved incorrectly.
That’s the connection I look for when I’m helping someone, and it’s been the pattern across my career. Get close enough to the systems (technical and human) to understand what’s actually happening, then connect the finding to what it’s costing the business and help deliver a solution to close the loop.
A career of work in infrastructure and technology leadership, and I still look under the hood.
On a recent gig, I watched a support team chase the same category of ticket for weeks, drive space alerts on machines with 128–256GB system drives. The standard fix was to log in, clean temp files, move user data to network shares, and close the ticket. Rinse repeat. Daily ticket volume drove a quick resolution then move on.
At the management level where only the ticket class was seen there were comments of better education to the users on how to manage their data or to tell them not to keep so much work on their devices. There were also talks about larger drives or increased VM allocations. All of these are reasonable options to consider.
I looked at a handful of these systems myself and found an incorrect page file configuration in the standard deployment image. It was consuming up to 40% of the drive before the user even started working. On one system with a 128GB drive, the page file allocation alone was 96GB. Three quarters of the drive, before accounting for Windows, applications, or user data. Every machine deployed from that image inherited the problem.
In this case, one configuration fix addressed the source of the recurring tickets and freed up support time. No new hardware. No budget request.
The team handling this was working hard to help. Their cleanup work gave users enough room to get back to work. But every ticket treated as an isolated incident was another opportunity for the underlying problem to keep going. When the queue stays full, making room to investigate a pattern can be difficult. Yet that’s often where the biggest return is: asking why the same work keeps needing to be done.
A drive space alert that seemed like a generic user problem turned into a higher level technical problem, and when repeated across a fleet, it suddenly becomes a problem where you can calculate lost employee time, support overhead, and potentially an unnecessary hardware expense if resolved incorrectly.
That’s the connection I look for when I’m helping someone, and it’s been the pattern across my career. Get close enough to the systems (technical and human) to understand what’s actually happening, then connect the finding to what it’s costing the business and help deliver a solution to close the loop.
A career of work in infrastructure and technology leadership, and I still look under the hood.