Hybrid data team models aren't a panacea
That bespoke analytics team's short-term impact won't always outweigh the added collaboration cost
I recently happened upon this article from Towards Data Science, that discusses the why and how of building a strong Analytics function for your business. Even though it's a few years old, I find it to still be a good primer for folks considering different approaches to building strong Analytics teams. They offer three different org structure strategies, and provide the tradeoffs inherent with each:
A centralized data and analytics function, which ensures building a single source of truth, but may result in the team being disconnected from the needs of the business.
Embedded data and analytics functions within each business unit, ensuring deep connection to the needs of those business units, but difficulty collaborating to build on a single source of truth.
A hybrid model with a centralized data team (Data Engineering with a small Data Science center of excellence), and embedded Data Science & Analytics resources within each business unit.
While the article is thorough in its descriptions and tradeoffs of these three models, the rosy description of the hybrid model is built on a hidden assumption: That building single source of truth, while necessary, is also sufficient to align all things data across the business. This assumption can break down in practice, for a few reasons:
Two similar teams working off a single source of truth can still arrive at different, but contextually correct, insights on the same topic given the data source(s) they prioritize and the analysis approach they take.
The assumption that the proliferated teams will be similar is rare in practice! Some business units may opt for a smaller analytics team, while others build out deep Data Science expertise.
It ignores research teams, who similarly produce insights for the business, but often do so on top of data they source themselves (e.g., interviews, surveys). Typically, this data won’t pass through the Data Engineering center of excellence.
Let’s illustrate the first point with an example: A SaaS company is trying to better understand the value that is being delivered by its product offering.
The Customer Success team wants this information as a means to prevent churn and promote upsell and cross-sell motions, so their Data Scientist leverages Salesforce and CS platform data to analyze customer feedback and satisfaction trends to tease out the value signals that are most likely to promote renewal.
The Product team, meanwhile, wants this information to get more leverage to drive active users up and to the right. Their Data Scientist (hopefully in collaboration with UX Research) analyzes key events to find those with the strongest correlation with regular usage, and operationalizes those signals as the ones that represent strong value to users that the Product team should use to prioritize their future work.
Both teams now have a customer-centric notion of what value means, on top of the single source of truth maintained by the Data Engineering center of excellence. But do they agree on what that value is? Each Data Scientist leveraged a different data source for their work; one biased more toward the business decision maker / buyer, and the other toward the day-to-day user of the product. And maybe that's by design! But you're still left with two business units, who need to partner effectively, talking past each other when conversations of customer value arise.1
I'm on a mission to improve corporate data culture for data professionals of all stripes, in Data Science, UX Research, Analytics, and beyond. If you’d like to join me, you can help by sharing this newsletter with the data culture drivers in your network.
In discussing the drawbacks of the hybrid model, the TDS article says:
This model requires an additional layer of coordination and communication... to ensure alignment between [the Center of Excellence] and business units.
While technically true, "an additional layer of communication" downplays the challenge at hand. There is a single business with a single landscape of insights to inform how it functions; each time we add a bespoke data science, analytics, or research for a business unit, we increase the coordination burden on the business to arrive at that unified point of view.
Let’s visualize what this additional layer of communication looks like in practice:
Start from the images above, and assign a value to each connection between two insights teams. You could consider time spent (e.g., 4 hours of meetings per month) or monetary cost (e.g., cost in salary for those meeting participants to spend 4 hours each month in meetings).
With 2-4 specialized insights teams, the cost per team and the overall cost to the business grow incrementally. It's fair to argue that the benefit these specialized teams bring to the business outweighs the coordination cost involved.
But as we go beyond 4 specialized teams, the cost to the business rises at a faster rate (polynomial), even as the cost to each individual team is incremental (linear). Even larger businesses will quickly hit an inflection point, where the benefit to a particular business unit isn't worth the increased coordination burden on the overall business.
This isn't to say that we should fully centralize our insights functions—that just leads us back to the centralized model with all its drawbacks.2 Rather, if you lead a business unit that's hungry for data, and you're thinking of standing up your own analytics team: Take a beat. Check in with existing data leaders at the company, and get their perspective on how they'd meet your goals. Consider the long-term costs associated with standing up your own team. And then make an informed decision. Even if you opt to establish a specialized data team, doing so with an eye on the bigger business picture will benefit everyone in the long run.
I'm again reminded of a former VP of Engineering's mission for data: "I want to confirm that what we market, is what we sell, is what users experience, is why customers renew." It's not enough for each business unit to conduct their analysis independently; the holistic story is the mission.
However! A relevant benefit to the centralized model that the TDS article doesn’t cover, is that having a single leader across insights for multiple business units makes one person responsible for building that single point of view for the business. Clear ownership can go a long way in minimizing the coordination cost to the business.
A couple tweaks on the hybrid model can reclaim some of that benefit:
Pivoting to a centralized-but-embedded model: One Data Science leader overseeing the practice, with subteams for each business unit needing support. Those subteams function as distributed teams in every way that matters, but benefit more directly from the center of excellence by reporting up through the centralized data org.
Combine the DS/Analytics embedded teams with Research teams serving the same business unit. For example, a small but growing number of companies (including Salesforce and Spotify) have seen stronger collaboration across insights teams when they combined Product Analytics / Data Science and UX Research into a single insights organization.