More Voltron, Less Froggytron
Or, how to keep overlapping data projects from catching you off guard
Early in my career, I was included on a large-audience email from Marketing one day. They were announcing the completion of their market segmentation and customer profiles, and they gearing up to share the results in an upcoming roadshow.
I remember being excited to learn about the work that had been done, but also curious. I was a junior UX Researcher at the time, and my team had a well-established set of personas, or characters that represent different types of users for a product. I remember wondering: How will our personas connect with Marketing's work to tell a cohesive story about our customers?
It turns out, I wasn't the only one with this question, and it quickly became an action item for both teams to figure out how these two models connected. After multiple meetings of mostly spinning wheels, it became clear that the task would be impossible without more data: Neither model included data that could connect to the other. They had fundamentally set out to answer different types of questions. While we had some hand-wavey hypotheses, nothing was solid enough enough to build upon.
In the end, neither team was keen to take on more work, so usage of both models became dependent upon inertia, influence, and politics. Probably not the outcome either data leader was hoping for.
The desire to wrangle the complexity of "all customers" or "all users" is a common one, and so different data disciplines have an approach to do just that. Data Science will turn to clustering, or a similar unsupervised learning approach. Marketing, market segmentation. UX Research, personas or user profiles. And so it goes for many common business questions: Each data discipline will have their own specialty hammer to bring to a common set of nails.
While it's fair to say that each data team is approaching their problem from a different angle, that doesn't absolve teams from needing to worry about reconciliation. At some point, the desire for a single, cohesive story will emerge, and it's certainly not ideal to leave it for our business stakeholders to deal with. It's down to data leaders to figure out a way to get this done.
In a perfect world, each data discipline would fluidly build on, and extend, work from others. Data Science extending work from UX Research, extending work from Marketing, and so on. Each team contributing to a single point of view about the business that is greater than the sum of the parts.
In short, we want Voltron:
But we don't live in that perfect world. Each team leader is already stretched thin managing their team, advocating for their work, priming their backlogs, and keeping their space running smoothly. So overlapping work may catch us by surprise, leaving us to play catch up and hopefully reconcile the projects. But since reconciliation is nobody's job, you do what little you can before you need to move on.
The single point of view falls by the wayside. And you're left with Froggytron:
The more specialized your organization’s data disciplines, the greater the likelihood for project overlap between the teams. It's not a matter of if, but when — and whether you'll be aware that the overlapping project is coming. As Melvin Conway says:1
Once scopes of activity are defined, a coordination problem is created. Coordination among task groups, although it appears to lower the productivity of the individual in the small group, provides the only possibility that the separate task groups will be able to consolidate their efforts into a unified system design.
So how do we counter the coordination problem created by data team specialization in our organizations? It's not a simple task, but it begins by opening dialog. Read on for my four tips on opening this dialog, designed to help data leaders catch overlapping projects before they show up unexpectedly.
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.
Tip 1: Build Awareness
Overlapping projects are a struggle when they're a surprise. They leave folks on both data teams scrambling to reconcile the work. So the first tip focuses on getting ahead of the issue by building broader awareness of data work across the organization.
First, cast a wide net, considering data disciplines of all stripes. Market Research, Revenue Ops, Data Science, UX Research, any Analytics team (this includes People Analytics!) — all of them are exploring data around a particular aspect of the business. Whether or not their work is immediately relevant to your team, all of it is relevant to how the business functions. Understanding their focus can cue you in to potential areas of collaboration.
Once you've connected with your data leader counterparts, strive to be their biggest fan. Sign up for their distribution lists. Engage with the content they send out. Be aware of their biggest priorities each quarter. Apart from growing your awareness of the broader business, it also builds a strong foundation for a mutually supportive relationship.
Tip 2: Embrace the Lit Review
Having published a few times in academia, one of my favorite aspects of writing was the literature review. Reading through past work and making connections was exciting: It helped me understand where my contribution would fit in, and inspired other work that I hadn't even been considering prior.
For insights-oriented data teams, I often find the lit review to be missing. Sure, you may seek out best practices for how to do the work, like the latest method or technology. You may also reference your team's past work. But your team is not the sole contributor to the business's landscape of knowledge.
While I'm not proposing a formal, lengthy lit review for each project, I do think it's incumbent upon a data team to know about — and account for — their planned project overlapping prior work from another team.
Tip 3: Check In During Planning
Trying to reconcile two teams' projects when both are completed is a recipe for frustration. I've yet to see it happen successfully. On the flip side, when two teams connect during the planning of an overlapping project, some nominal extra planning can help that project be even more impactful than it otherwise would have been standing alone.
The rationale should be one that any data leader recognizes. We often tell our teams not to get bogged down in the details of their projects before stepping back and understanding the business question at hand. That gives us time to understand why we're doing the work we're doing, and pivot if needed.
The same goes for collaboration between data teams. Understanding how business questions connect and overlap allows for much greater flexibility in designing projects to answer them, compared to trying to merge finished work together after the fact.
Tip 4: Avoid Limiting Assumptions
In order for any of the above tips to work, it’s critical to meet your data leader counterparts where they are. The first step is to avoid the limiting assumptions that you may have ingrained about the other discipline.
As someone who has transitioned from UX Research to Data Science, I hear a fair few of these statements from both camps, and there's some sayings I've had to unlearn. Data Science referring to UX Research as "small data" work. UX Research saying that Data Science can only tell you "the what," and UX Research tells you "the why."
I understand the value of the short-hand these sayings provide within each discipline. But they also put your partner data teams in a box from the start. Rather than leading with your interpretation of another team's limitations, lead with curiosity instead. What strengths does the data leader see in their team? What opportunities do they see? You may be inspired for joint work that would never come to mind with rigid assumptions guiding your interaction.
While I used to look at the prospect of overlapping projects with anxiety, these days I've flipped the script. I've seen how electric it can be when two strong data teams have a unified point of view: It brings a level of clarity to the business that I've rarely seen with teams acting individually.
This outcome isn’t hard to achieve, but it is rarely incentivized by senior leadership. It’s down to data leaders to prioritize connections with their counterparts across the organization. Hopefully this post has given you the inspiration to kick off that initial conversation.
While Conway may be best known for Conway’s Law that advises us against shipping the org chart, the article that gave rise to the law is full of insightful quotes, including this one.