Creating a powerful data team is no easy task, it requires leaders to decide what data team structure best suits their organization.
I was faced with this decision at my company, BombBomb, and learned firsthand the pros and cons of embedded (“distributed”) and centralized team structures. An embedded team structure, is a data team in which each data professional is fully embedded as part of a business team, like marketing. While a centralized data team is a data team that works centrally on all the requests from all business units.
Evaluating the data team’s mission and outlining what exactly your business needs from a data team can help you decide how to structure that team.
For example, if you only have a single data person at your organization, an embedded model will likely not work. If there is only one person to field all requests, a centralized method would work best, so that a one-person data team can partner with multiple departments to drive insights.
My organization was utilizing an embedded model. While this model has advantages, our business was suffering from poor prioritization, and projects were falling far behind due to the company’s lack of data maturity, a measurement that demonstrated a company’s use and access to embedded data.
I felt challenged to explore different team structures, in the hopes of getting our data professionals on the same page, increasing our organization’s data maturity, and creating a strong environment for peer-to-peer skill sharing. While exploring models, I came up with this pros and cons list:
Advantages of a centralized model
- The team can easily prioritize projects across all the departments they support;
- The data team can establish their own team mission and work on their own outcomes while also supporting the organization;
- The head of data has a broader view of the overall company’s strategy and can easily offer data support throughout the organizatio;
- Having data engineers, data analysts, and data scientists on the same team encourages peer-to-peer learning and creates opportunities for skill set development;
- Holistic data strategy is shared and maintained within the team;
Some cons of a centralized model you must consider
- Instead of being an active partner with different departments, the team can become more of a ticket crusher;
- The head of data must maintain an excellent understanding of company strategy to prioritize work accurately. Even still, some departments might be favored, leaving other departments feeling unsupported;
- While knowledge sharing can be high within the team, data engineers and data scientists may be too far removed from stakeholders, causing business context to be missed;
While a centralized team structure is often the stepping stone into an embedded team structure, this will not be the case for all businesses.
Advantages of an embedded model
- Strong relationships are built within the department, removing the barriers between technical team members and business partners, decreasing confusion around data and business requirements;
- Less context switching between different topics and departments can lead to increased productivity;
- Prioritization is clear and aligned within the team – highly directional. Team members can become subject matter experts in their respective departments;
The embedded model promotes better alignment between data members and business units.
Cons you should consider ensuring your embedded model is effective
- Data engineers, data analysts, and data scientists can become misaligned, due to having different leaders with their own missions;
- Without one person to make a final decision on the direction of a project, conflict when prioritizing projects can increase;
- This team structure can feel isolating, as you are surrounded by those who don’t have the same skill set, and your ability to problem solve together isn’t always there;
- Career growth can differ between departments;
My aim was to create a shared understanding of business goals and objectives across a team of engineers and analysts, while also creating clear direction and an environment of skill-sharing within members with similar technical skill sets.
Knowing we had a low data maturity as an organization, I leaned heavily towards a centralized model – as our organization needed a strong team that could lean on each other and easily prioritize based on the company goals as a whole – instead of separately. Since implementing a centralized model, I can confidently say we have increased access to data for the whole organization, increased data quality, created data team goals aligned to the companies goals, and created a positive team culture focused on trust and working together towards common goals.
So, when you’re challenged to determine the best team structure for your organization, remember there is not a “how-to” model for building a data team, and instead focus on understanding your company’s data maturity level so you can build a team that is well aligned with your organization needs and strategy.
Finally, remember your structure can and will likely change, and embrace that change.