The team decentralization dilemma
Today, practically every business unit has a significant technology footprint. From HR to finance, a mountain of technology must be managed and enhanced over time. Consequently, IT leaders are often confronted with the dilemma of consolidating technical functions, or instead, decentralizing said functions. Each approach has its respective tradeoffs, and keeping those factors top-of-mind may enable faster decision making for IT executives.
Decentralized teams versus shadow IT
It’s worth noting that “shadow IT” differs from decentralized technical teams. Shadow IT operates in secrecy; intentionally shrouded away from the purview of IT or even other business units for that matter.
Conversely, decentralized teams operate in the open. They are transparent in nature and are willing to share information and abide by enterprise standards.
5 team decentralization consideration factors
From data teams to software developers, there are a variety of factors to consider when analyzing consolidation and decentralization. Here are the top five I routinely use for evaluation:
- Speed – will decentralization increase team velocity and productivity?
- Scope – are the customers of this team departmental or cross functional?
- Specialization – Are team skills specific to a functional area (e.g. finance) or more general in nature?
- Cost – Is controlled redundancy a manageable expense, or is it cost prohibitive?
- User experience – will internal customers be confused or otherwise dissatisfied with decentralized team services?
Rather than examining each factor individually, a better understanding may be achieved through a couple simple use cases outlined in the next sections.
Team centralization use case: campus WiFi
An exemplary case for centralized IT services would be campus WiFi. Imagine the confusion and inefficiencies that would ensue if each department created their own WiFi network. First of which would be different authentication standards. One network requires a password, the other requires Active Directory credentials, another requires a certificate, etc. This would lead to poor user experience and significant cost increases as different network equipment would require different contracts, different administrative skills to recruit for and so on.
In this scenario, a table stakes IT service such as WiFi has broad scope, is not specialized to departmental needs, and can actually be deployed faster when there are global / enterprise standards.
Team decentralization use case: revenue analytics
In the prior section I explained how speed, scope, specialization, cost, and UX are optimized with a centralization approach. However, those same factors may point IT leaders in the direction of decentralization when the inputs are inverted. Let’s look at a common example: a revenue analytic team.
In this scenario, the scope of customers are focused within finance. Specialization is high, as revenue analysts need advanced mathematics skills and must possess an expert-level command of data query languages. The cost difference between centralized and decentralized revenue analytics teams is marginal, as the same number of people must be hired regardless of where they reside. Yet the user experience of the customer (finance) and the speed of achieving productivity is high because the finance team can prioritize this team’s staffing and tooling capabilities, whereas IT would likely need to juggle this capability development with many other competing priorities.
Team decentralization patterns over time
It’s natural to observe centralization ebb and flow over time; especially as a company grows.
I’ve personally seen many data teams start off completely decentralized, then consolidate into enterprise business intelligence teams, only to later fork off into factions that remain aligned to the centralized / core BI team.
Over time, decentralized functions should increase cooperation and coordination with centralized teams. The centralized teams may function like a center of excellence; focusing on broader macro-level standards and processes. The decentralized teams remain focused on their business unit or area of specialization yet they must operate within the confines of enterprise guardrails.
Summary
When to consolidate versus decentralize a team depends on numerous factors. Moreover, the structure of the team (consolidated or decentralized) may change over time. The idea is to optimize for the present and near-term horizon, while remaining flexible for the future.
