Learnings from managing an embedded data team
This blog is based on my experience with managing a team of product analysts and data scientists for three years at ResearchGate. We went from an integrated model, with product analysts reporting to a product manager, via a centralized data function with all analysts working in one team, and finally landed at an embedded model — a mix of both approaches. ResearchGate is a platform for scientists that helps them to increase their productivity by connecting them with the research, people, and resources they need to advance their work.
This post addresses analytics managers and analysts or data scientists who work in an embedded model or are interested in introducing such a model. My learnings about managing an embedded team refer to both product analysts and data scientists, but for simplicity, I’ll refer to them as “analysts” in this post.
Why work in an embedded team structure?
Imagine you work as a product analyst on a really exciting project: your business colleagues asked you to segment the user base into behavioral clusters. After several alignment meetings, you start digging into the data, spend days on cleaning it and making sense of it. You build a clustering model, analyse the results, and write a detailed report about the segmentation. You present your report and get a lot of praise from your business colleagues. Three months later: nobody ever used your model, your report is buried in the graveyard of “nice to have” documents.
Situations like this often result from a broken organizational setup — analytics is considered a supporting function and is too far removed from where important decisions are made in the company. How can the organizational design of a product analytics function help to overcome these problems?
One way to improve collaboration between analytics and product is the so-called integrated model. It is the opposite of a centralized analytics team, where all analysts report to an analytics manager and work together in one team. In an integrated model, the analysts report to a product manager and are fully integrated into the product team. This model creates some new challenges. For example, who makes sure that the product analysts have opportunities to develop their technical skills? Who takes care of the analysts’ infrastructure needs?
The embedded model provides an answer to these questions as it intends to balance out the challenges that arise from both the fully centralized and the fully integrated model in a hybrid organizational form. In this blog post, I summarize my learning from establishing an embedded model for the data team at ResearchGate.
Integrated vs. centralized data teams
What integrated and centralized means
In a centralized model, the data team works together on analytics problems. The analysts report to an analytics manager.
In an integrated model, the analysts work in a (typically cross-functional) product team. The product analysts report to the lead of the product team (usually product manager or engineering manager).
Which model is better?
I won’t go into a detailed discussion about the pros and cons of a centralized vs. an integrated model but just provide a high-level overview (there are other good resources on that, e.g. here or here). Which model is better depends on the size, structure and data maturity of the organization, e.g.:
- Are executives aware of the business value of data analytics and data science?
- How strongly is evidence-based decision making promoted by other leaders?
- How senior are the analysts, and which level of support do they need from a functional manager?
- How data-savvy are other colleagues from other functions?
The benefits of the centralized model are more or less equivalent to the challenges of the integrated model, and vice versa. Very small companies and companies just starting to build a data team are likely better off with a centralized data team.
Building an embedded data team
Hybrid organizational design: The embedded model
The embedded model is based on a hybrid organizational design. The core idea is a strong partnership between product analyst and product manager working together on the same domain. This means that the product analyst takes care of all data needs in the team and helps to shape product strategy and product delivery with insights and models. At the same time, the reporting line for product analytics is centralized so that all analysts report to an analytics manager.
Distribution of leadership responsibilities
On a high level, responsibilities are distributed as follows:
In our specific embedded model at ResearchGate, we distribute leadership responsibilities as follows:
Where the data team sits
The product analysts belong to two teams at the same time — where should they sit? At ResearchGate, we have a team room for the data team, and all new members stay there full time during their onboarding. This makes it much easier to introduce them to our toolchain and give them timely guidance and feedback. It also helps the new analysts to build a strong network with their functional peers which is important for their motivation and further development.
Once they completed their onboarding, we expect the more experienced product analysts to sit with their product team full time. This allows them to build up knowledge about the domain they are working with. Sitting with the product teams makes it easier for product analysts to understand the context in which they are working which in turn helps them to have a stronger impact on the team. It also helps them to build strong relationships with engineers and product managers. Still, the product analysts are always welcome to sit at a flexible hot desk in the data team room every once in a while.
Junior product analysts have a hot desk with the product team they are embedded in; they usually sit there at least two days per week to be more close to the product team and familiarize themselves with the situation of being mostly independent there.
What we own and share as a team
To work more effectively as a team, we share a functional strategy. This enables us for example to tackle longer-term infrastructure challenges together with our data engineering teams, or to work on processes to improve insights sharing throughout the company. We also own our tooling and workflows e.g. for exploratory data analysis (based on the principles of Opinionated Analysis Development), as well as a peer-review process. We have a training schedule with at least three training sessions for the data team per quarter, and we share best practices like code style guides and cheat sheets. To maintain a strong identity as a team, we have set our mission, vision, and principles.
We run weekly team meetings where we do deep dives into analyses and models, and we have quarterly retrospectives to provide a safe space to all team members to voice concerns and discuss challenges. Our team also established a mentoring system between more junior and more experienced team members to encourage peer feedback and knowledge sharing. And of course, we do social team events like cooking or playing board games together.
Challenges with an embedded data team and how to address them
The embedded data analyst’s perspective
I interviewed my team to get a better perspective on the challenges of an embedded organizational model from the team members’ view.
Stakeholder rodeo. One of the biggest challenges for product analysts under an embedded structure is that they have twice as many stakeholders — the members from their product team, and the members of their functional team. Therefore, the product manager might have different opinions or expectations on certain topics than the analytics managers. To address this challenge, we have created a responsibility matrix (similar to the one referring to the distribution of leadership responsibilities above), where we specify who is responsible and accountable for different workflows, e.g. in the experimentation process (based on the RACI framework). For the product analysts, it’s really important to make all their stakeholders aware of all their projects and tasks — over-communication is king here. It’s also important for analysts in an embedded structure to learn to say “no” in a friendly and productive way and to explicitly manage expectations with all their stakeholders.
Dealing with a lot of needs. There is always more work than a product analyst in an embedded team can actually handle, so it is crucial for the analyst to become very good in prioritization. The embedded model works best when the product analyst anticipates the needs of the team they are working with and actively shapes the data, models an insights agenda in their area of responsibility, rather than working reactively upon requests of a product manager.
Keeping the social balance of belonging to two teams. Embedded product analysts have to build and maintain strong relationships with both of the teams they belong to. They are the only person with their functional background in their product team, therefore they should always make sure their opinion is heard and understood. It can help to educate other team members on the basics of the approach of a specific analysis or model. From our experience, many engineers are quite excited to learn a bit more about data science.
Defining development goals in accordance with product needs. Since the analytics manager who is responsible for the analysts’ functional development does not know the details of the context in which the product analyst is operating, it is crucial for the analyst to own their development and think about how they want to make progress in their role. The analyst should actively think about projects that contribute to their product team’s success and discuss with their manager how those fit into their overall development plan.
Analytics Manager’s perspective
Not enough product analysts. An embedded model is expensive, and you might not have enough analysts for each product team. In this case, you can create clusters of similar product teams and assign each product analyst to a cluster. This is only feasible for product analysts who have strong leadership and prioritization skills, since they will be challenged quite a lot by balancing the needs of two product teams plus their functional team. Another option is to have several embedded product analysts and a small centralized team that can support the teams that do not have a product analyst embedded.
Confusion of responsibilities. As the embedded model is complex, a typical risk is that responsibilities get mixed up. Writing down a responsibility matrix and discussing it with the product analyst and the product manager helps to clarify these questions.
Getting lost in alignment. Particularly when starting a new collaboration between a data analyst and a product manager, there is a lot to align on. I found it helpful to invest in a good relationship with the PM early on. This can happen e.g. via regular check-ins between a product manager and analytics manager. As a manager, it is your duty to resolve any issues or conflicts in opinions as soon as they arise — they are blockers for the product analyst’s work and might make them feel uncomfortable. I also see regular 1:1s between data analysts and product managers as a best practice to ensure they have a space for feedback and discussion. Whenever a product team works with a data analyst for the first time, it is important to properly introduce the analyst’s role to the entire team.
Risks for the product analysts’ motivation. An embedded model is challenging for product analysts, particularly regarding their leadership skills. A centralized team might feel like the more “comfortable” model for some analysts since they can focus more on the technical aspects of their role. This means that for some analysts, working in an embedded model can be demotivating since they have to take on quite a bit of stakeholder management. The first step to mitigating this risk is to hire people who are primarily excited about having an impact. To ensure data analysts stay motivated in an embedded model, It is also important to coach them early on regarding communication, stakeholder alignment, and prioritization. Without basic leadership skills, they will easily get frustrated in an embedded model. At ResearchGate, we established buddy/mentor relationships and do peer reviews and deep-dive sessions in our team meeting to make sure that there is enough exchange among peers. Both mentors and mentees report regularly that the mentorship relation is a big driver of their motivation. We also usually reserve some time for bottom-up projects that help us to work more efficiently by e.g. improving our tooling together or also just by doing some bigger refactoring of our reporting code base together as a team to ensure we have enough touchpoints on a technical level.
When embedded was not the best solution for us
When we transitioned from an integrated to an embedded model first at ResearchGate three years ago, we faced several challenges. Requests from the product manager to the analyst still remained the major process for communicating data needs. It proved harder than expected for the analysts to move into a pro-active mode of setting the data agenda in the product teams. This was on one hand because most of the analysts were still at the beginning of their careers, while the PMs were more experienced — many of them also with an analytical background. Also, the former reporting line between PMs and analysts still influenced the collaboration dynamics.
Therefore, we fully centralized the data team as an intermediate solution for about 6 months and heavily invested in training. We also worked on several strategic projects like building a new model to predict the career level of scientists and a behavioral segmentation of our user base which helped to demonstrate the value we can provide to the organization.
When we eventually moved back into an embedded model, it was much easier to establish a strong partnership between the analysts and the product managers than before.
Best of both worlds vs. balancing trade-offs
The question of which specific manifestation of the embedded model is best suited for a certain company depends on its size, its structure, and its data maturity. The specific dynamics of the embedded model always vary according to the seniority levels of each individual involved. A senior product analyst and a junior product manager will work together very differently than a junior analyst and a senior PM.
When I started to manage an embedded team, I assumed it would be less “effort” compared to managing a centralized team. Actually it turned out that it was more effort to be a people manager in an embedded model since it requires so much alignment. The rewarding part about it is that the embedded model creates healthy friction from the cross-functional collaboration from which all involved parties can learn.
