How to Structure a Research & Data Science Team

The core role of any leader — regardless of discipline or domain — is to create, lead and evolve a happy, healthy, high performing team within their organisation.

There are many factors that contribute to a happy, healthy, high performing team, one of which is how the team is organised or structured. There is no one right way to structure a team. What works best will be highly dependent on each company and team, their unique goals, and growth stage.

The Research, Analytics & Data Science team (a.k.a. RAD) in Intercom exists to build, enable and share a deep, holistic understanding of our customers, their needs, and their product behaviours using Research and Data Science. We’re in a high growth phase as a company and need an org structure that’s flexible while fostering collaboration and partnerships across Research and Data Science. A structure that brings these disciplines together in meaningful ways while at the same time ensures we’re driving the right level of partnership and impact across Intercom. In this post, I share how we structure RAD in Intercom and our learnings so far.

How we structure RAD in Intercom

In Intercom we operate a hybrid model which we refer to as a centralised-dedicated partnership model.

Firstly, we are a centralised research and data science team, where all researchers and data scientists report up through a single point of leadership. This enables us to:

• Support and standardise career paths and career development
• Leverage best practices, common tools, standard infrastructure and streamlined processes to help us effectively drive and scale evidence-based decision making.
• Collaborate with RAD peers to improve our skills, give/receive feedback and guidance on core work, and foster synergies across research and data science.
• Build, prioritise and execute on strategic RAD programs around data foundations, self-serve research and analytics, and advancing target customer understanding.
• Prioritise and execute on critical business priorities as and when they arise.

Secondly, we apply a dedicated partnership model where data scientists and researchers align to key groups/areas in R&D for a prolonged period of time. This enables us to:

• Foster strong relationships across RAD pairs and core product groups/areas
• Build deep knowledge and context within a specific product group/area
• Influence and inform product strategies, initiatives and decisions using evidence for specific product groups/areas.
• Provide clarity to our product partners with whom to engage and when

How this works in practice

Each individual contributor (IC) on the team — Researchers and Data Scientists — align to 1 core product group/area and associated company program. Product groups are made up of multiple product teams. And we use company programs to execute our company and product strategy.

• Each IC partners with that product group for a prolonged period (multiple quarters or longer).
• They build strong partnerships primarily with the Group leads (PM, Engineering & Design) across that group. They work with the Group PM and Product directors to prioritise the most impactful initiatives within the group.
• The IC builds strong partnerships with their RAD peer (the researcher or data scientist also aligned to that group).
• The IC shares in the outcomes and success for that group.
• The IC fosters strong relationships with cross-functional stakeholders associated with that product group and program, e.g. program management, product marketing, Sales, Biz Ops and Finance.

Each Researcher (R) and Data Scientist (DS) in RAD aligns to a Product Group. A Product Group is made up of multiple product teams and led by a triad — Group Product Manager (GPM), Group Design Manager (GDM) and Group Engineering Manager (GEM). Each Product Team in Intercom is typically made up of a Product Manager (PM), Designer (D), Engineering Manager (EM) and multiple Engineers (E).

Each IC also drives or contributes to 1 or more RAD program or Company priority.

• The IC works with 2–3 other RAD team members to make progress on a specific RAD program or company priority.
• RAD programs include areas like our data foundations, improving self-serve evidence-based decisions making, scaling research, as well as team specific initiatives around hiring, onboarding and evolving team processes.
• Company priorities include areas like company and product strategy insights, building and delivering a centralised customer feedback & insights tool, research that informs company-level goals, etc.
• Sometimes these programs are research specific, other times they are data science specific but often they require collaboration across research and data science and in turn outside of RAD, e.g. partnership with data engineering or with product peers.

Small teams of Researchers (R) and/or Data Scientists (DS) within RAD execute on RAD programs or company level priorities.

What have we learned?

We are about ~10 months into this org structure and while it’s early days we’ve experienced a host of benefits, plenty of challenges and learned a lot!

Benefits

By partnering Researchers and Data Scientists with product groups for a prolonged period of time, we develop deep context and expertise in a given product area. This enables us to:

• Co-ideate on research questions and research approaches, resulting in higher quality framing of problems.
• Get close to the product decisions, influence those decisions at every stage, and guide product teams to be more evidence driven. It helps us shape product strategy and direction.
• Develop strong cross functional relationships with decision makers beyond just the PM.
• Spot product changes that will impact data pipelines and core metrics in advance so we can be ready as well as partner with engineers to ensure the right event tracking is in place.

By pairing Researchers and Data Scientists:

• We build trust, empathy and respect across the two disciplines. We begin to understand the strengths and diverse perspectives each discipline brings. Working in a RAD pair with someone with a different skill set than your own, instantly brings a different perspective to questions and often brings healthy challenges to your framing! This in turn makes the work better.
• We can execute faster. Having a shared understanding of the customer, the product and product group’s focus means there’s less time spent ramping up on knowledge across RAD pairs.
• We can work together to form opinions. Even when Researchers and Data Scientists don’t work together on a specific project, the RAD pair across each group can help shape an opinion together. Context and experiences our fellow RAD partner has can be valuable in helping refine our opinions and recommendations.
• By combining quantitative and qualitative insights, our partners and our team gain a fuller, more holistic picture of our customers, their needs and product behaviours. This often leads to greater confidence in our insights, and in turn great confidence in a specific decision or product direction we’re taking off the back of our insights. This in turn improves our chances of driving impact.

By having a single, central RAD function that sits across R&D and partners across the company, the team can keep up with what’s happening across the whole company. This helps us keep the big picture in mind, ensures we have a line of sight on the broader impact of work and helps us spot opportunities for making connections across product areas. It also enables us to priorities important company level or R&D wide initiatives.

Challenges

We don’t have RAD pairings across every group right now. This means there are gaps in our partnership model today and we lack examples of successful RAD pairings in specific product groups as a result.

Partnering at the product group level can mean juggling multiple competing asks and priorities across multiple product teams and multiple PMs. It means context switching and at times, being pulled in different directions. Likewise working with a product group and on a separate RAD program can lead to challenges balancing our time and resources across these efforts.

By working with product groups so closely, we discover all of the potential ways in which data and evidence can serve their needs and naturally get dragged into helping with tactical, low leverage questions vs. the more strategic questions. This is a natural temptation and we have to work hard to avoid it.

We’re not fully embedded with product teams nor do we operate a central agency-style resource. We’re somewhere in the middle. This means setting expectations with our product partners can be challenging. At times it’s difficult to know what to prioritise, who’s in charge of prioritising and what Researchers/Data Scientists should get involved in, e.g, what meetings do you need to attend, which comms should you be included in, etc.

Being the only Data Scientist or only Researcher for a group can be lonely as you miss out on opportunities to collaborate with someone from the same discipline. Deeper partnerships with a product group and within a specific RAD pair puts us at risk of shallower collaboration and a disconnect across RAD, so we have to make a conscious effort to keep up to date with what other RAD pairs are doing and share what we are working on in return.

By pairing Researchers and Data Scientists to groups there is a tendency to think that everything needs a qualitative and quantitative perspective because the pairing exists. This isn’t the case. What matters is the problem we’re trying to solve, the question we’re trying to answer, the decision we’re trying to drive — not the approach we use.

Within RAD, having Researchers and Data Scientists partner together meaningfully isn’t easy or a given just because we sit in the same team. Thinking about how we tackle problems or questions together doesn’t always come naturally. The nature of our work and how we work is different in a host of ways. So it’s been a challenge. Like most good things in life it takes time to nurture.

Key takeaways & next steps

There is no silver bullet or one size fits all approach to structuring a Research and Data Science team. What works in one company will not work in another. What works at a specific point in time is unlikely to work in the future. This is especially true for fast-growing teams and companies.

For now, we think the pros of our centralised-dedicated partnership model outweigh the cons and we’re confident that we’ve landed on a structure that helps us foster intra-RAD collaboration while driving strategic impact. We regularly revisit our team structure and organisational model so who knows what the future holds as we continue to scale.

For now, we’re taking our concrete learnings to date and continuing to improve for the year ahead by:

• Clarifying expectations for what we work on and how we work, for our partners and our team.
• Iterating on our planning and prioritisation process to ensure we’re working on the right things, in the right ways.
• Fostering more context building, learning and collaboration across RAD and ensuring we set folks up with the right knowledge to drive impact.

If you’re a Researcher or Data Scientist and this sounds like an interesting model and set of challenges to you, we’re hiring both Researchers and Data Scientists across Dublin, London or Remote in the UK & Ireland :)

What about you? How is your Research and/or Data Science team structured and organised? Does Research and Data Science exist as a single team? We’d love to hear more from other teams and leaders on this evolving topic.

Team RAD, November 2021!

A huge thanks to all the folks across RAD team for all their input, learnings and help with this post.