Navigating the Spectrum of Centralization vs. Decentralization in Analytics Teams (Scaling Your Data Team, Transition #2)
We explain how you may organize an Analytics function using solely the centralization vs. decentralization dimension and look at what happens when we combine this dimension with the support vs. growth dimension (explained in the previous article).
The second transition on the “Scaling Your Data Team” series focuses on the amount of centralization or embedding of your Analytics department, as well as how organizations move between the two extremes.
Deciding between centralization or decentralization is usually not a permanent choice. Instead, analytics teams (and sometimes the whole company) transitions back and forth between the two creating what Douglas McGregor, in his book The Human Side of Enterprise (1960), calls an “accordion effect”:
“First, a big movement toward decentralization takes place. A few years later, after the consequences described above have taken their toll, top management decides that things have gotten out of hand, and there is a general tightening up in the direction of centralization. The inability to control a large, complex organization centrally leads after a while to a new attempt at decentralization.”
In the next sections we will go in detail through the different ranges of the spectrum for Analytics teams, its implications, as well as the guiding principles for when you should choose each of them:
- The data organization is centralized
- Analysts are decentralized
- Hybrid model (hub and spoke)
- Hybrid model at department level
The data organization is centralized
Most Data and Analytics teams start as a central function reporting to a “Head of” or Director of Data. This function is responsible for all data-related activities across the organization and, usually, works as a support-function as explained in the first article of the series.
When a central data team grows, it usually does so by organizing themselves “by function”. This means all Data Analysts will report to a newly hired or promoted Data Analysts Manager and all Data Engineers will report to a Data Engineering Manager, for example.
This model can work at the beginning, but eventually Analysts will become a bottleneck. The model will slow down decision-making and will prevent business domains to focus on specific and advanced topics. Analysts will see the need of specializing on a business problem and focus on that for several quarters in order to make an impact.
The feeling that Data Analysts must be decentralized begins to grow.
Analysts are decentralized
The idea of decentralizing Analysts and embedding them in cross-functional teams usually comes with a more general reorganization in the company where product and tech teams stop being organized by function and start being organized by business problem, user journey, domain, etc.
This way of organizing removes the bottleneck problem as the prioritization efforts are kept in the domain. But embedding Analysts does not ensure that you will get rid of the support-function view that other disciplines may have on data people; therefore, it is crucial to remember the steps to switch towards data being a growth-oriented function within the organization.
I think it is important to avoid using the word “embedded” in this model as it creates some separation between data folks and the rest of the disciplines. Data Analysts are simply another component of the cross-functional team and they are accountable for the success of the business domain too, period.
Although the benefits of the model might outweigh the cons, it is important to signal that in this model there is a risk of fragmenting the knowledge and creating silos. Therefore it is important to keep some kind of chapter, guild or center of excellence where Data Analysts can share knowledge and uncovered insights as well as discuss best practices to ensure analyses have the necessary consistency.
Finally, it is important to note that this transition keeps Data Engineers in a central team focusing on Data Platform efforts. (If you want to read more about scaling Data Platform teams you can read the third article of the series: Scaling Data Platform Teams: A Step-by-Step Guide.)
Hybrid model (hub and spoke)
If an organization “fully opens the accordeon” by decentralizing all the Analysts, in some months time it might realize that perhaps some analytics capacity at a central level is needed. This is when the hybrid model comes to the rescue.
A hybrid model, also called hub and spoke, keeps Analysts decentralized but also creates a central analytics function responsible for:
- The overall data strategy
- Taking a proactive attitude towards solving governance issues
- Keeping the Data & Insight community together
- Making sure trainings and onboarding programs are successful
Sometimes they will also offer ad-hoc support and/or help domains that start needing analytics resources (before assessing if hiring a full time person for that domain is needed).
Hybrid model at department level
One recent trend I’ve observed is the fact of creating mini data teams at a level higher than the team entity. This means the mini-data team supports several teams (3 to 5 is usually the number of teams this mini-teams can give support to) within the same department.
Sometimes this transition is forced because the department is going through the same type of transition within the rest of disciplines (merging several teams).
This model is more cost-effective than adding analysts in every single team and it can be good for the department to break existing team silos. On the other hand, you do that at the expense of sacrificing speed since sometimes analysts will not have the priority or focus on a specific team.
One way to try if this is a good model for you is to start small and create a mini-data team in one of the departments of your organization, learn from it and decide if you want to scale this model to other departments or not.
A note on Data Engineering
The majority of Data Engineers in an organization will usually be part of a central Data Platform team. Data Engineers are introduced in cross-functional teams only when the data products in their domain start growing in complexity and use cases. This allows Data Analysts to focus on more complex data analysis and experimentation while Data Engineers are responsible for maintaining the domain data products and bridging the data gap between the operational and analytical spaces.
One of the most difficult aspects of integrating Data Engineers into cross-functional teams is avoiding the need to build parts of the data platform that are needed by the domain but not provided by the central Data Platform team yet. To prevent this you need to establish synchronization points with the central Data Platform team to identify needs and priorities.
When it comes to the Data Engineers in the central Data Platform, the transitions a Data Platform team can go through are explained in the next article of the series: Scaling Data Platform Teams: A Step-by-Step Guide.
Bringing in the support vs. growth dimension
The level of centralization or decentralization of your analytics function is independent of the model you adopt to govern your data organization (support-oriented vs. growth-oriented) so we can visualize both dimensions together and draw the following 2 by 2 matrix resulting in four different operational models:
There are pros and cons to all operating models so let’s detail them in the following sections.
Support function, fully centralized
The bottom left quadrant describes a fully centralized data organization that just works on support requests. I described this operational model in the first article of the series. As I mentioned there, it is not the model mature and data-driven organizations use.
Growth function, centralized
The bottom right quadrant describes a very rare combination: the organization tries to work as a growth-function from a central data department.
Even if this model can work for a while, central Analysts will find it is hard to work deeply and extensively on specific problems because they are not part of the team focusing on those problems. They work as internal consultants and experts (they are working in “growth-mode”) but it will be difficult to have end-to-end ownership of the analytical problem and scale the model.
The solution: decentralize the Analysts.
Support function, decentralized
On the upper left quadrant, organizations consider Data Analysts members of cross-functional teams but they keep being a support-function and only have the time to answer Product Manager and other stakeholders requests.
The amount of toil they handle and/or the lack of being metric (growth) oriented in the team prevents them from working on advanced topics, participating in discovery activities, experimentation…
Growth function, decentralized
On the upper right quadrant, data teams work with a combination of central and decentralized Analysts (part of the cross-functional teams) and have a growth mindset. Some cross-functional teams might even have dedicated Data Engineers too.
This is the model that allows for the best use of data at scale and where most data-driven companies are or are going to as we explained in these two first articles of the series.
Final words
In this article, we have shown the various ways you may organize an Analytics function using solely the centralization vs. decentralization dimension. We also looked at what happens when we combine this dimension with the support vs. growth dimension (explained in the previous article).
This resulted in a four quadrant graph that shows you should move your organization into the “growth and decentralized” quadrant (upper right) if you want to become data driven at scale.
If you’re interested in other articles in this series, make sure to read the first one about shifting data organizations from a support-oriented to a growth-oriented role, and the third and last one about scaling Data Platform teams.
