Learning how to run IT from the US CIO: Ride the Wave

Learning how to run IT from the US CIO: Ride the Wave

IT is a cost center. We have to divert money from critical business functions to keep it alive. We need more cost controls so that more of our spend can go towards core activities. We need to control our own destiny, so we can’t have dependencies with IT. If only IT would hire smarter engineers, we could actually get things done. We should just hire a Shadow IT team.

If you have heard any of these things, you probably work at a company where IT is not a strategic partner in the company’s success. And while people perceive that technology is probably the answer to common pain points, sometimes it’s more of a mindset shift that is required to make change. I learned that listening to the US government’s federal CIO a few years back.

Riding the Wave

A few years ago, I was fortunate to get to hear Tony Scott, then CIO for the US government, speak in a small-room setting. Prior to his public service, Tony had worked as CIO at both VMware and Microsoft. When he stood up to speak, he was addressing the most positive change he had made in his tenure at Microsoft.

He described his change as Riding the Wave. Prior to the change, individual lines of business and functional units controlled their own IT spend. This meant that if they needed additional capacity, they were responsible for budgeting for that capacity, and then IT would deploy and maintain it as necessary.

This kind of autonomy feels good for functional teams. It means they have a measure of control, especially working with teams that have historically been bottlenecks. But this breeds very specific build-out and maintenance behaviors.

Managing IT spend

In companies where IT is primarily a services organization treated as a cost center, groups will tend to undervalue IT’s contribution to the company’s bottom line. So when they allocate their budget dollars, they will fund first the initiatives for which they are responsible.

This is actually common psychology. As humans, we tend to overstate our own individual contributions and underestimate the effects of everything around us. When this plays out within an organization, it means that teams will favor their own efforts over supporting functions.

To hear Tony Scott tell it, when this played out at Microsoft, it meant that lines of business would sweat their assets for years. Rather than allocate dollars evenly across some time horizon, they would fund things in a boom-or-bust model, where spend was allocated for major buildouts or refreshes.

Insidious side effects

The insidious side effects of this type of funding model are that infrastructure will tend to age. And unlike fine wines, things like servers and switches do not age particularly well.

You see, there is never a good year to fund supporting infrastructure. In the lean years, you can’t possibly divert resources from more critical business activities. And in the boom years, you have to feed the engine that is driving the company. This leaves IT perpetually underfunded, despite its critical role at the foundation of all things digital.

Minimally, this means that when the boom years come, there are painful sacrifices to be made within the business. You are essentially funding several years of spend in one budget, so the spike will be particularly painful.

And when you are trying to get the most from your spend, you will run things into the ground before you will replace them. The operational toll this takes on IT can be devastating. Forced to support multiple generations of equipment, teams will tend to spend more of their time simply keeping the lights on, which only further feeds the perception that IT is a bottleneck.

The vicious cycle that follows leaves IT spread thin across antique infrastructure with very little leverage and virtually no control.

What did Tony do?

At Microsoft, Tony Scott basically pooled IT spend. But this was not a power play. Instead, what he did was ensure that investment was constant, avoiding the typical peaks and valleys.

With a constant stream of funding, Microsoft was able to continuously upgrade its infrastructure. And because each generation of infrastructure was more capable and efficient, it meant that the constant influx of new gear actually met the growing demands of a growing company. Essentially, he was riding Moore’s Law to success. And while Moore’s Law appears to be coming to an end, the idea that future generations will outperform previous generations should not be particularly controversial in most settings.

In short, Tony was able to hold spending overall flat, ride the way of IT innovation, and meet continuously growing demands by simply leveraging the innovation that his company was, in part, helping to drive. Not only did this keep infrastructure current, it helped reduce the overall technology drift within the company, which meant that more of IT’s top resources could be spent working on difference-making things rather than merely keeping the ship afloat.

The bottom line

The days when IT was merely an enabler are largely over for most companies. You might scoff at trends like Digital Transformation, but any company not planning to thrive in a digital era is basically just hoping to survive. And hope isn’t a strategy.

This means that IT simply must be treated as a top-tier contributor to corporate success. And that implies that some of the more antiquated models for sustaining IT have to evolve.

If you hear people at your company talking about the IT tax, stop them. If you walk through a datacenter and you spot equipment older than your teenage daughter, say something. If you find yourself bantering about Shadow IT, go find an IT engineer and ask them about the diversity of infrastructure they have to support.

The broader the range of ages of things that IT has to support, the less efficient IT will be. And if any team has to spend most of their time simply keeping the lights on, there is really no hope to take advantage of the very technology that is driving our need to change in the first place.


 By Michael Bushong

Published with permission from forums.juniper.net/t5/Blogs/ct-p/blogs