- Tags:: 🗞️Articles, Data Team Topologies
- Author:: David Murray (Data lead at Snaptravel)
- Link:: How should our company structure our data team? | by David Murray | Snapcommerce | Medium
- Source date:: 2020-10-22
- Finished date:: 2021-01-01
- It is common to take the back seat when there is a need to move fast in features:
At the time, the company’s mantra was to move fast, so refined decision-making with data took the backseat to shipping new features. The structure of our data team — one software engineer who periodically had to build front-end applications when needed — was perfectly aligned with the size and needs of a young seed-funded startup.
Centralized vs Embedded trade-offs
Model evolution
Embedded model
We were evolving our analytics team at a rapid pace and lacked consistency across the organization
Centralized but divided:
Knowledge share is more technical in a centralized model because DAs are in the same stand-ups and helping each other through problems, at the expense of developing a deep understanding of the business context.
They needed to centralize the DAs to avoid their short-term thinking:
This misalignment in priorities caused lots of problems — data engineering was focused on building the data health of the company long term, while the DAs were pursuing short term revenue at the cost of the companies’ long term data integrity. Our solution was to take the best of both teams and combine them into one full-stack data team.
One potential drawback with a centralized model, taken from Bob Iger’s Ride of a Lifetime, is the morale degradation when control over data is taken from heads of business units. As a small company, it has worked because our data team are coworkers but also friends with the heads of business. At a larger company or when/if Snaptravel becomes looser-knit, this may be a much larger issue.
I wonder what happens when your DAs are more or less the PMs… How do you bring consistency to that model?
Full-Stack team
The two skill sets were already working closely together, but the new team formalized the relationship and improved knowledge sharing by being in the same meetings. DEs met with DAs and business users at the same time.The merge allowed us to prioritize the right things, **balancing long-term infrastructure health with our growth targets. **
- Also, made management more stable:
Changing our team structure so frequently disrupted manager relationships and created instability for team members, which was a big drawback.
- This is probably the right model to start: they said they chose the first model “blindly” and they would have skipped the second.
Full stack pods
- Not sure why they needed to move away from this model. They said they had “too many cooks in the kitchen”:
In some cases, there were four people on a 6-person pod all trying to make decisions, including cross-pod managers.
Full-stack team with domain leads
And contributors organizing in a flexible way from quarter to quarter.
