Organizing Data Teams Effectively: Blueprint — Tip #10
In Tip #7, I discussed how to arrange talent and create an effective setup. Then in Tip #8 and Tip #9, I described my vision for the data team. Now, I’d like to discuss how a data team should be structured within a company.
Centralized or Embedded
The first question that may come to your mind is whether to set up the data team using a centralized or embedded model. Here is a great article that walks you through the different models: How should our company structure our data team? 👍
I recall my early days at my current company when our data team was just starting. The centralized model seemed a logical choice then, but as we expanded, the embedded structure proved invaluable. Here are a few common models I have experienced or heard about from friends:
1. Centralized Data Team
- DE + DA are in the same data team and are responsible for all the data requests from other teams.
- Mostly, they’ll build a self-service BI tool or educate a data champion in other teams to reduce their workload.
- They’ll have better alignment in data models, pipelines, etc., but are less involved with other teams and, therefore, more service-oriented.
2. Centralized but Different Data Teams
- This mostly happens in global enterprises. They have a DE or a complete data team at the headquarters and DAs in local subsidiaries.
- The DA is more supportive and understands business domains, whether that is MKT or product. However, the DA usually has a hard time accessing source data or resolving issues arising from it.
3. Embedded in Important Teams
- This model seems like a transition period from centralized to embedded. Due to MKT and Finance having higher demands on data analysis, DAs are embedded to provide data services faster.
4. Embedded Data Team
- Only the data infrastructure is shared. Each team has its DA who understands the domain well, so they work like partners.
- The challenge here is how to prioritize work for DE, especially when there are new data sources or issues from different teams to be resolved.
Starting with Centralized
When the data team is first established, the initial step is to create a data pipeline. Therefore, almost every data team starts as centralized. Resources are limited. Sometimes, there’s just a one-man data team. No other model is feasible at this point 😆.
After the infrastructure is set up, the data team needs to define its vision and mission. How do they want to be valued? How do they plan to work with others? The data team should be prepared to participate in organizational discussions. That’s the time to think about structure models.
Changing for a Reason
No model is perfect 😂. Each model arises to address specific situations and solve company challenges. No model lasts forever. It evolves based on the benefits the company seeks and the challenges it wishes to overcome.
If you have a complex data stack, you need a team of data engineers to maintain it. If you handle confidential or rigorous data, for example, in a listed company, you need a centralized team or even multiple teams. If your business teams aim to make data-informed decisions or obtain reports quickly, you should lean towards embedded models.
Observing Your Data Team’s Structure 🤔
When you join a data team, observe how it’s structured. Why is your team structured this way? What are the pros and cons your company and team consider? When the disadvantages outweigh the advantages, it may be time for a change.
Coming Next
After deciding how to organize your data team and determining its vision/mission, the next step is to support your company with data. In the next article, I will discuss how to promote company-wide data literacy.
🤩 I’m happy to hear how you handle product development process? what tool do you use? Feel free to reach out to me on LinkedIn Karen Hsieh or Twitter @ijac_wei.
🙋🙋♀️ Welcome to Ask Me Anything.
