Is conflict the default for data team collaboration?

What interview prep on ChatGPT showed me about cross-data team dynamics

A while back, I was preparing for an interview for a Data Science leadership position. I'd been informed ahead of time that the focus would be on data-driven decision making; specifically, how to best make decisions utilizing both insights from Data Science and UX Research. (One of my favorite topics!)

To prepare, I input the details of the interview into ChatGPT, and asked it to produce a list of common questions that I could start to think through. The questions it returned were reasonable — they mirrored with questions I'd previously been asked, and had asked as an interviewer, many times in my career.

But looking at a few of the questions, I noticed something interesting. See if you can spot it:

• How would you prioritize multiple research findings that are conflicting, or point to different user behaviors?

• What's your process for making high-impact decisions when you don't have all the data, or when the data conflicts with user feedback?

• Tell me about a time when UX researchers and data scientists had differing opinions about how to approach a problem. How did you resolve the conflict?

Again, these struck me as pretty standard questions. But after a year of writing on data culture, something else stood out to me: All of these questions have some variation of the word conflict in them.

I started to wonder what this says about the state of data team collaboration. Is conflict the default? And if so, why do we accept that as a given?

---

After a bit of reflection, I decided to switch it up, and pose as a senior Product leader preparing for an interview on data-driven decision making. Again, ChatGPT returned a reasonable list of questions, including these three:

• How do you balance qualitative insights from user research with quantitative data?

• How do you ensure effective collaboration between product, data science, and UX teams when defining product requirements?

• How do you manage differing interpretations of data insights between teams?

Very similar questions to the ones I was originally shown for my Data Science leadership interview, with one notable difference: The word conflict is nowhere to be seen.

Instead: Balance. Ensure effective collaboration. Manage differing interpretations.

So if the language we use is any indication, data teams tend toward conflict with each other. PMs and Product leaders mediate, seek balance, and decide the way forward.

---

I'm on a mission to improve corporate data culture for data professionals of all stripes, in Data Science, UX Research, Analytics, and beyond. If you’d like to join me, you can help by sharing this newsletter with the data culture drivers in your network.

---

This tracks with the incentive structure at most tech companies. Data teams are evaluated based on their impact: How their data products or insights drive tangible business value. So if another team's work contradicts or casts doubt on your team’s output, that undermines your impact. It's easy to see where the interaction can be contentious. Impact starts to feel like a zero-sum game between data teams.

PMs, meanwhile, are typically given full ownership over product decisions, and are expected to be data-driven in how they approach growing and evolving the product. Having data that appears to be conflicting on its face doesn't absolve them from their data-driven responsibility: They're still expected to make the best decision to move the product forward given the data they have.

Here's the issue underlying all of this: Data synthesis is a skill, and not a trivial one to master. All things being equal, the people in the mix most likely to be experienced in data synthesis are the data experts: The Data Scientists, UX Researchers, and Analysts who do some level of synthesis every single day at work. While PMs can also build proficiency in data synthesis, it’s not as central to their day-to-day work, and can be overridden by their own instinct, or an attempt at a diplomatic resolution.¹

So how do we turn this around, and empower the data experts to reclaim ownership of the synthesis step? It starts with unpacking the common assumption behind all these interview questions: Data teams work in silos, cranking away independently until their work conflicts. If you wait until multiple projects show conflicting results to think about collaboration, those collaboration efforts will be doomed to fail. Hence the need for outside mediation by PMs.

If you want to increase your ownership of data synthesis efforts, it starts by centering collaboration at all phases of work. Especially planning. By understanding where new work might merge and conflict with existing insights, you make data synthesis part of that new work. In other words, the key to avoiding conflict is simply leaning in to collaboration, early and often.

1. I'm reminded again of Marissa Mayer in her Product leadership role at Google, reconciling conflicting data from UX and Data Science by choosing a shade of blue in between both recommendations. This is data synthesis at its most superficial: Coming up with an answer anchored by conflicting data stories, but supported by neither. For more about Google's Shades of Blue experiment, check my article about synthesizing UX Research with A/B testing.