Stop shipping the data org chart
A strong data-driven culture requires strong data team collaboration
This post is a continuation of my Learning from Metrics Review series for data leaders, where I discuss using signal from Metrics Reviews to drive your organization's data culture and data-driven decision-making forward.
The first post is here, and will be updated with links out to all other posts as they are published. Be sure to subscribe to stay up to date with future installments!
While most of my team's data projects come and go as part of the regular flow of work, occasionally there's a request or business question that just sticks with me. One such example came from a business leader, who was trying to get a more holistic grasp on the health of the business:
How can I verify that what we market is what we sell is what users experience is why customers renew?
Most businesses, including this one, set a strategic direction that all teams then take and execute. And once each team is engaged, they each have standard approaches for measuring, validating, and refining their approach.
What made this prompt stand out was the focus on verification across functions, not just within. In other words:
How had each business unit operationalized the business's strategic direction via success metrics? And did each business unit’s success metrics consistently reflect the strategic direction?
How had each business unit evolved their understanding of success metrics over time based on what they'd learned? And could other business units benefit from that same learning?
These questions can be challenging given the specialization of data insights functions. Each has their own jargon, methodology, and definition of rigor. Marketing will have Market Research and/or Marketing Analytics. Finance, Revenue Ops. Product may turn to UX Research to understand how users are experiencing their products. Data Science may have one or more Analytics-focused team(s) partnering with some, all, or none of these business units. So how do we look across these teams to deliver that single point of view about the business?
After you've been in a product-facing role for a release cycle or two, you'll probably be exposed to the phrase, "Don't ship your org chart." Commonly credited with Steven Sinofsky during his time at Microsoft, it refers to the idea that the teams you set up to enable focused work might become too insulated from one another. The result? Duplicate features, or missing connective tissue to tie the work of multiple teams together into a cohesive, usable product.
This framing is often tied back to Conway's Law, which says: "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." Dr. Conway's original paper1 goes into more depth, and one passage in particular resonates with me:
[T]he very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise. Given any design team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization, because the necessary communication paths do not exist. Therefore, there is no such thing as a design group which is both organized and unbiased.
What if we, as data leaders, step back from our usual notion of deliverables as dashboards, presentations, forecasts, reports, models, and frameworks? What if, instead, we framed our deliverable as a shared, single body of knowledge for the business? With this framing, each data team would be contributing to the same deliverable. But are each team's contributions compatible with the others?
Or are we just shipping our org chart?
I'm not suggesting the org chart itself is the problem.2 Per Dr. Conway, every organizational decision we make will have implications on what's in bounds and out of bounds for our data work. The only way to keep innovation pathways open is by keeping communication channels open.
So data leaders can take action by identifying other data teams in their orbit, and opening a line of communication. When you do, you might just find a new way of working that takes both teams' work to new heights.
Communication post photo by Hugo Jehanne on Unsplash
Dr. Melvin Conway first wrote the text that would come to be known as Conway's Law in the paper How Do Committees Invent? for Datamation in 1968. It was first referenced as Conway's Law in the book The Mythical Man-Month by Frederick Brooks.
That being said, there are an increasing number of teams that combine UX Research, Data Science (esp. Product Analytics), and Market Research in a single team to strong effect. Spotify is one case in point that has been open in sharing the benefits of this model.