Central Org, Embedded Pods
Keep analytics reporting centrally, but mirror partner-team structure with pods that share their goals
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 95%
Jessica Lachs's contrarian structure for data teams: reporting lines run centrally into one analytics org (a Center of Excellence), while the people themselves sit in pods that map 1:1 to product, engineering, ops, and marketing teams and carry those teams' goals. This captures the embedded model's camaraderie and roadmap alignment without losing the central model's talent bar, metric consistency, growth paths, and team culture. The team's mandate is business impact, not ticket-servicing.
Origin
Developed by Jessica Lachs over 10+ years building DoorDash's analytics and data science org, after DoorDash experimented with embedding analysts inside business units and found it problematic. Lachs notes Elizabeth Stone (Netflix CTO, ex-DoorDash) holds the same view.
Core principles
- 01Analytics is a business-impact-driving function, not a service function
- 02The two things leaders love about embedded teams — camaraderie and roadmap control — can be solved for inside a central org
- 03Shared goals, not shared managers, are what align incentives with partner teams
- 04A central org gives one talent bar, one metric definition, one methodology, and multiple growth paths
- 05The seat at the table is earned by bringing opportunities, not by answering questions
How to run it
- 1
Set the mandate: impact, not service
Define the team's job as finding opportunities and having a point of view on decisions — answering 'so what do we do now that we know this', not just 'why did this happen'. Reject the Jira-ticket-and-dashboard operating model explicitly.
Pro tip State this in hiring pitches and in partner-team kickoff. If analysts are graded on tickets closed, the mandate is fiction.
Watch out A central org with a service mandate becomes the silo everyone fears. Centralisation without the impact mandate is the worst of both worlds.
- 2
Draw the reporting line centrally
All analytics and data science roles report up through the head of analytics, regardless of which function they support. Marketing analytics is part of the analytics team; it does not report into marketing.
Pro tip Be explicit that 'central' is only about reporting lines — it says nothing about where people sit or what they work on.
- 3
Cut the central org into pods that mirror partner teams
Divide the analytics org into pods that map exactly onto how product, engineering, ops, and marketing are structured, so each partner team has de facto embedded data people who attend their meetings and live their problems.
Pro tip Mirror the partner org's structure precisely — a mismatch reintroduces the coordination tax you centralised to avoid.
Watch out Re-org the pods whenever partner teams re-org, or the mapping silently rots.
- 4
Give each pod its partner team's goals
Pods carry the same goals as the teams they serve, so the analyst's success is the marketing leader's success and vice versa. This is what buys the roadmap alignment embedded teams get for free.
Pro tip Shared goals also become the mechanism for prioritisation conversations and for saying no to low-value asks.
- 5
Harvest the central-only benefits deliberately
Use the central structure to run one hiring rubric and talent bar, one definition per metric, one shared model per problem (not six churn models), cross-pod mobility for growth, and a single team culture with peer review and a learning community.
Pro tip Watch for the same problem appearing in several pods — that is the signal to automate it or get ahead of it before scale makes it painful.
Watch out Without visible mobility and culture, the central org's retention advantage never materialises.
In the wild
Marketing analysts sit with the marketing team, attend its meetings, and are goaled on marketing's goals — but they report to Lachs, are hired against the analytics rubric, and use the company-wide definition of every metric. Both the marketing team and the analytics team feel like one team.
→ DoorDash built one of the largest and most respected data orgs in tech while preserving consistent metrics, a consistent talent bar, and internal mobility.
DoorDash previously experimented with putting pockets of analytics inside business units. Talent bars drifted, methodologies diverged, and the most senior data person in a function had nowhere to grow.
→ The company reverted to a central model with pods, judging the value of centralisation far greater than what it costs.
Common mistakes
Confusing 'central' with 'siloed service desk'
People hear central org and picture a ticket queue you have to lobby for help from. Lachs calls that job terrible. Central refers only to reporting lines; the work is done as an embedded thought partner.
Centralising reporting but not sharing goals
If pods have their own analytics goals rather than their partner teams' goals, incentives split, prioritisation fights start, and business partners route around the data team.
Letting pods diverge on metric definitions
The whole point of centralisation is that 'sales' means one thing. If pods define their own metrics, you have an embedded model with extra management overhead.
Is it for you?
Best for
Heads of data/analytics at 100+ person companies — especially multi-sided marketplaces — deciding whether analysts should report into business units or into one org
Not ideal for
Very small companies with one or two analysts, where a formal reporting structure is moot, or organisations whose data function is genuinely a reporting/BI service by design
From the transcript
“for me analytics is a business impact driving function and not purely a service function”
“I believe a central Model A Center of Excellence is superior”
“we have a central analytics team but we are we're divided up into pods that map perfectly”
“because the analytic shares the same”
From the episode
Building a world-class data org
Jessica Lachs (VP of Analytics and Data Science at DoorDash)