Centralize or Decentralize?

Most large IT organizations, at some point, have to make decisions about what to centralize and what to decentralize. Some organizations decide to create a shared services group; others look to centralize governance over security and architecture, or to centralize procurement and financial management. When done poorly, the centralized functions can become frustrating bottlenecks, and the interactions between shared services and decentralized teams can lead to administrative waste. How should enterprises decide what to centralize, and how can they best organize the centralized services and their interactions with decentralized units to reduce waste?

As the CIO of one of the component agencies of the Department of Homeland Security (DHS), I considered myself the victim of burdensome centralization. Whenever we wanted new servers or changes in the datacenter, we had to appeal to the DHS contracting organization, which oversaw the contractor that managed the datacenter. Our network infrastructure was shared with other DHS components and managed centrally, so making even small network changes required paperwork, reviews, and long timeframes. For IT projects, we had to follow the onerous requirements of DHS’s oversight framework MD-102 (yes, that’s the one I make fun of frequently in my books and speeches), which was designed to oversee the building of Coast Guard cutters (the Coast Guard is also part of DHS). It also governed the delivery of software systems and was consequently oriented around huge capital investments and physical objects. Centralization seemed to get in the way of everything we wanted to accomplish.

Today’s digital ways of working call for decentralized, empowered, autonomous teams. This is difficult to reconcile with centralized functions and governance! On the other hand, there are some functions that just cannot be decentralized or that introduce inefficiencies when they are. In our case, DHS headquarters was responsible for security across the entire enterprise, and negotiating vendor contracts centrally allowed us to leverage our purchasing volume for better discounts.

The tension between centralizing and decentralizing is at the core of today’s digital IT environment. Unsurprisingly, it comes up in one form or another in most conversations I have with enterprise leaders.

To get a handle on how to manage the tradeoff, I like to start from the principle that speed and innovation are critical in today’s environment. They are best facilitated by decentralizing authority, by working in those autonomous, empowered, cross-functional teams. The teams can remain close to the customer, easily sense changes in the market, incubate ideas with cross-functional participation, and execute work with no handoffs between functional silos—that is to say, quickly. When an autonomous team depends on a centralized function, it slows them down, adds administrative overhead, and imposes bureaucracy that tends to limit innovation.

That’s my starting point, but the question demands a more nuanced treatment. In what cases should you centralize functions? My first answer is: Only when it actually speeds up those decentralized teams and supports their innovation. If the centralized organization provides services that would otherwise take the teams time to provide themselves, and does so without administrative overhead that would slow the teams down, then it is good. For example, take DHS’s oversight of the contract for managing the datacenter. As it was set up, it slowed our teams down when they needed infrastructure. If, however, the centralized team had set up the contract, pre-negotiated, with fast processes for teams to get their own infrastructure when they needed it, then it would have saved time for the teams and would therefore have been beneficial.

Of course, we don’t have to worry about datacenters anymore because we have the cloud. Imagine, now, a centralized cloud platform team that provides software delivery teams with a prepared infrastructure on which they can work. The teams can self-provision any infrastructure they need, without waiting for the platform team to do it. Instead, the platform team has set up the platform in such a way that when the teams self-provision their infrastructure, they automatically use cloud resources that the security team has vetted and configured and that the finance team has approved for cost-effectiveness. Now the central platform organization is actually making things faster for the delivery teams, because they don’t have to assess the security of those resources, don’t have to do any supplemental security engineering, and don’t have to justify the cost-effectiveness of the resources they are using. And there’s no additional administrative overhead, because they can still provision their own infrastructure.

In this case, the centralized function has actually sped up the decentralized teams—a big win! Notice the contrast with my earlier DHS examples where the centralized functions caused delays and frustration because they involved gatekeeping and an actual handoff to another team.

So, you should certainly centralize functions when doing so adds speed. But that’s still not the whole story. Another reason why organizations centralize is to provide governance and oversight for the entire enterprise. At DHS, headquarters needed to oversee security and spending, and therefore had centralized organizations attending to these things. How can those needs be met without slowing things down?

First, we should ask whether that central governance is really necessary. In my books, I advise caution about the knee-jerk standardization impulse in IT—we often assume that standards are needed, when careful analysis would show that the business value of that standardization might not justify the additional cost or slowness of the governance mechanisms that ensure standards are followed. I also like to point out the tradeoff between oversight through governance and oversight through management. Governance makes rules and introduces enforcement mechanisms, with consequent costs. But often you can achieve the same or better results simply through good management. Governance, for example, might force teams to use the standardized software delivery platform. Management, on the other hand, might ask a team that didn’t use a standard platform why they did so. Were they really keeping the company’s best interests at heart when they decided not to? You don’t necessarily need rules and enforcement to get good behavior; often, competent management solves the problem.

But let’s say that you do need centralized governance. The good news is that today, it can often be accomplished with automation, through guardrails that don’t slow down the decentralized teams or add overhead for them. I sometimes talk about “automating your bureaucracy.” Today we can do “compliance as code,” “policy as code,” or “auditing as code.” Your bureaucracy doesn’t interfere with speed and creativity, it just aligns them within guardrails.

I’ve already given an example of automated bureaucracy: the platform team that provides only vetted resources for teams to use in their self-provisioning. The security team’s governance is already embedded in the selection of components that are available. They don’t need to interfere any further. Another example: We had the security team create automated tests that checked for compliance with their policies for all of the other IT teams to use. By making sure their code passed the security tests, delivery teams could move at top speed independently—but, through the tests, the security team provided governance. Similarly, you can automate financial controls, perhaps shutting down resources that aren’t being used, perhaps stopping teams from using resources that aren’t cost effective, or perhaps notifying finance if a team plans to do something potentially expensive. All of these automated mechanisms enforce centrally determined governance controls, but don’t slow down teams, interfere with their creativity, or add administrative overhead.

So here are my rules of thumb for managing the centralization/decentralization tradeoff:

• Decentralize by default
• Centralize when it will speed up the decentralized units
• Centralize when governance is necessary, but do so in an automated way that doesn’t create dependencies

—Mark

(originally posted on the AWS Enterprise Strategy blog)