The 25x Problem That's Bankrupting Your IT Budget (And the Three-Step Fix)

Something Mark Wall said stopped me in my tracks: "Most organizations are spending twenty-five times more effort maintaining their infrastructure than deploying it." That's when I realized we've been obsessing over the wrong part of the IT lifecycle.

The 25x Problem That's Bankrupting Your IT Budget (And the Three-Step Fix)
Mark Wall breaks down Automation Priority 2 for WWT's Automation Series hosted by Robb Boyd

Something Mark Wall said during our conversation made me realize we've been thinking about IT infrastructure completely backwards. We were talking about asset lifecycle management when he dropped this bombshell: "Most organizations are spending twenty-five times more effort maintaining their infrastructure than deploying it."

Twenty-five times. Let that sink in for a moment.

Here's what that means in practice: You spend weeks getting excited about deploying new infrastructure, celebrating the go-live, maybe even taking the team out for drinks. But then you spend the next several years in a constant state of firefighting - patching, updating, troubleshooting, and trying to remember what's actually running where.

Read the full research paper: Automation Priorities for 2025

Mark Wall, Managing Director of Automation Solutions at World Wide Technology, has been watching organizations struggle with this imbalance for years. What he shared with me isn't just about being more efficient - it's about fundamentally rethinking how we approach the entire IT asset journey.

And honestly? After our conversation, I'm not sure how any organization survives without automating this process.

The moment I understood the real problem

Mark has this way of describing the IT lifecycle that immediately clicked for me: "Pallet to Production to Pasture." It sounds simple, but most organizations are only thinking about the first two parts.

"There's a lot of automation to be able to provision things to get services faster," he explained, "but it's just as important in some instances to think about a decommission aspect."

That's when I realized the scope of what we're dealing with. Organizations are so focused on getting things into production that they're creating digital graveyards - legacy assets running under desks, forgotten cloud instances still burning budget, security policies attached to devices that haven't been relevant in years.

Mark painted a picture that probably sounds familiar: "Once you don't clean up your toys, you tend to just say, 'ah, it's a mess all the time. I'm not gonna worry about it.' So the security landscape is continuing to change while you're not cleaning up your toys anymore. It's also incredibly risky to the organization."

The AI connection that changes everything

Here's where the conversation took an unexpected turn. Mark mentioned something that perfectly illustrates why this matters more now than ever: "I can't tell you how many clients we're working with that are, at massive scale with the whole AI paradigm, decommissioning their legacy environments to free up power and cooling for their high performance, GPU-based AI architecture."

Think about that. Organizations are literally having to tear down old infrastructure to make room for AI workloads. If you can't efficiently decommission legacy systems, you can't efficiently deploy the future.

The three steps that actually work

What struck me about Mark's approach is how practical it is. The research outlines three action steps that avoid the typical "boil the ocean" mistake:

Quantify Business Value (Beyond Just Time Savings)

Most people start with "this will save us five hours," but Mark pushed me to think bigger. "Don't just think about it in the time that maybe the employee or that team does to implement something, but what is that something tied to? Is it tied to a new application rollout? Is it tied to a new service that's revenue generating?"

He's absolutely right. When you can say "automating this decommissioning process will save us millions in support renewals we don't need to pay," suddenly you have executive attention.

Select a Targeted Use Case

Mark walked me through the two use cases he sees most often: zero touch provisioning and test automation. What fascinated me wasn't just the technical implementation, but how these build on each other.

"When we do zero touch provisioning and we plug a device in, it phones home, and it's the right configuration level, the right code level. We'll run automated testing to ensure that things are working properly."

But here's the part that really got me: once you build that test library, you can use it for change windows. "Before I implement a change, I could run an automated series of 50 tests within a minute, make my change hopefully automated, and then run those same tests again afterwards."

Align to a Compelling Event

This is where Mark's experience really shows. "Automation should be inherently a means to drive a greater outcome that you're trying to do from a business perspective."

He gave me examples: hardware refreshes, data center migrations, regulatory changes. These aren't just opportunities to implement automation - they're natural inflection points where the organization is already expecting change.

"What if I could shrink that from six months to four months? What's that worth to the business?"

From button pusher to button builder

What keeps me thinking about this conversation is Mark's perspective on what automation really enables. "What's important about automation is it's not just for you to push the button faster, but expose that for other people to be able to push those buttons for you. So you move from a button pusher to a button builder."

This isn't just about efficiency - it's about fundamentally changing your role from reactive firefighter to proactive architect.

The reality check I needed

Mark ended our conversation with something that honestly made me feel better about the complexity of all this: "It's okay to be not doing automation or maybe feeling a little behind the times. It's important just, every day, every week, every month, think about whatever timescale it is, and you don't have to solve the problem, but know the problem you want to solve."

He referenced a scene from Any Given Sunday about the "game of inches" - getting that foundation in place and then making incremental progress. "Pretty soon all those inches add up to the entire length of the football field and you get a touchdown and you win the game."

What this means for your infrastructure strategy

The organizations that figure this out won't just save money on their infrastructure bills. They'll be the ones who can rapidly pivot when the next technology shift happens - whether it's AI, quantum computing, or something we haven't even imagined yet.

The question isn't whether you can afford to automate your asset lifecycle. It's whether you can afford to keep spending 25 times more effort maintaining yesterday's infrastructure while tomorrow's opportunities pass you by.

Cheers!

Robb


Author Bio Section

Robb Boyd spent 20 years at Cisco turning complex tech into stories people actually wanted to hear. He created TechWiseTV (two Emmy nominations, no big deal) and now runs ExplaiNerds, where he helps technology companies stop boring their audiences to death. You'll find him regularly leading Cisco Live events in the US and Europe for Cisco TV, plus other industry events where he's probably overthinking his next opening line or wondering why every vendor thinks their solution is "game-changing."