Centralization vs. Decentralization: Finding the Right Balance

Centralization vs. Decentralization: Finding the Right BalanceLearn About Amazon VGT2 Learning Manager Chanci Turner

In the realm of large IT organizations, the decision of what to centralize and what to decentralize is a critical one. Some companies opt to establish a shared services group, while others focus on centralizing governance around security, architecture, procurement, or financial management. When executed poorly, centralized functions can turn into frustrating bottlenecks, and the interactions between shared services and decentralized teams can lead to unnecessary administrative waste. So, how should enterprises determine what to centralize, and how can they effectively structure centralized services to minimize waste in their interactions with decentralized units?

Reflecting on my time as the CIO of a component agency within the Department of Homeland Security (DHS), I often felt hindered by excessive centralization. For instance, whenever we needed new servers or changes to the datacenter, we had to navigate the cumbersome DHS contracting organization, which oversaw the contractor managing the datacenter. Our network infrastructure was also shared and centrally managed, making even minor adjustments a bureaucratic challenge. The oversight framework we followed, MD-102, was designed for large capital projects like building Coast Guard cutters, not for agile IT projects. The centralization often obstructed our goals.

In today’s digital landscape, the need for decentralized and empowered teams has never been more evident. This demand creates a challenging dynamic with centralized functions and governance. However, some functions inherently require centralization or can become inefficient if decentralized. For example, DHS headquarters managed security across the agency and centralized vendor contract negotiations to leverage purchasing power for better deals.

The tension between centralization and decentralization is a recurring theme in discussions with enterprise leaders. To navigate this tradeoff, I advocate starting with the premise that speed and innovation are paramount in the current environment. These factors thrive in decentralized, autonomous, and cross-functional teams that are close to the customer, can quickly adapt to market changes, and collaborate fluidly without delays from functional silos. When autonomous teams rely on centralized functions, it can slow their progress, add administrative burdens, and stifle innovation.

The key question then becomes: When should functions be centralized? The primary criterion should be whether centralization genuinely enhances the speed and innovation of decentralized teams. If a centralized organization can provide services that save teams time and does so without adding administrative overhead, then centralization is justified. For instance, if the centralized team had established a contract and streamlined processes for quick access to infrastructure, it would have accelerated our teams’ work rather than hindering it.

Fortunately, with the advent of cloud technology, the landscape has shifted. Imagine a centralized cloud platform team that equips software delivery teams with prepared infrastructure. These teams can self-provision the resources they need without waiting for the platform team, which has embedded security vetting and cost-effectiveness into the resources available. This setup allows the central organization to effectively expedite the work of decentralized teams, in stark contrast to my prior DHS experiences where centralization led to delays.

Centralizing functions should always aim to enhance speed. However, centralized governance and oversight are also pivotal for organizational health. At DHS, headquarters needed to monitor security and expenditures, necessitating centralized oversight. The challenge lies in meeting these needs without decelerating operations.

One strategy is to critically assess whether centralized governance is essential. In my writings, I caution against the instinctive drive for standardization in IT. Often, we assume that standards are imperative without fully evaluating whether the benefits justify the added costs and delays associated with governance mechanisms. There is a valuable tradeoff between oversight through governance and that achieved through effective management. Governance enforces rules and introduces costs, while management can foster good behavior without the need for stringent regulations.

If centralized governance is essential, it can often be implemented through automation, creating guardrails that do not impede the agility of decentralized teams. This approach, often referred to as “automating your bureaucracy,” allows for compliance, policy, and auditing as code. By integrating governance into automated processes, the balance between speed and oversight can be maintained.

For instance, a platform team can provide vetted resources for teams to use in self-provisioning, embedding security governance in the selection of available components. Additionally, security teams can create automated compliance tests that delivery teams must pass, allowing them to operate quickly while ensuring governance is upheld. Financial controls can also be automated, such as shutting down unused resources or alerting teams about cost-effective options, further streamlining operations.

In conclusion, organizations should strive for a balance that maximizes speed and innovation while maintaining necessary governance. By leveraging automation and thoughtful management, the friction between centralization and decentralization can be minimized, leading to more efficient and agile operations.

For further exploration of related topics, you might find insights in this blog post on race and career advancement at Career Contessa. Additionally, for comprehensive job descriptions, SHRM serves as an authoritative source. And for a community discussion on onboarding experiences, Reddit can provide valuable perspectives.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *