[Data Culture Corner] Establishing your data team as a strategic partner
Five steps to evolve your team beyond task-taking
Today's Data Culture Corner question comes from a recent networking conversation, where Steve asked:
My Product Data Science team is inundated with small requests for root cause analysis and dashboards, and I feel like we're leaving the most compelling work undone. How can I get business support to prioritize some of this compelling work?
Steve's challenge is one that I hear about a lot, and have faced in my career regularly—both in Data Science, and UX Research. Data practitioners thrive when given the bandwidth, and the stakeholder support, to identify high-value projects that can significantly move the needle for the business.1
It follows that we're keen to improve those situations where we aren't given that bandwidth and support. In Data Science circles, we decry organizations that treat their data teams as task takers; drowning them in ad hoc, reactionary requests, and depriving them of the heads-down time they need for deeper analysis.
The solution we put forward for this problem? Education. If your stakeholders aren't giving you time to do deeper analysis, it's because they aren't aware of the full value that Data Science (or insert your data discipline here) can bring. So educate them. Share what's possible. Surely then, things will change.
The challenge with this advice is that it over simplifies. It ignores change management best practices, and assumes that the organization is (1) aware they have a problem, (2) wants to change its approach to said problem, and (3) has the bandwidth to enact that change. More often, those same stakeholders are busy with their own jobs, and may never prioritize the behavior change we're asking them to take on.
So my answer for Steve will take a different approach. Below, I walk through five steps that he can take to drive the data culture change he's seeking for his organization. Drive being the key word—each step is geared toward centering the data leader as the responsible party for evolving how his team's work fits into the overall business operation. Let's roll up our sleeves and dive in.
Step 1: Define the problem
Data leaders may latch on to "task-taking" being a problem for a few different reasons, so before we do anything else, it's important to crisp up on the problem definition.
Are you overloaded with ad hoc requests, such that your team doesn't have time to get to the deeper work you've identified—even though that work is supported by your business stakeholders? Then you have a process problem.
Do your business stakeholders insist that data projects originate with them, and push back on project ideas that originate within the data team? Then you have a collaboration problem.
Do your business stakeholders inconsistently take action on your data products and deliverables? Is follow-up action even less likely after projects that originate from the data team? Then you have a communication and influence problem.
These are very different problems, and require different approaches to manage effectively. I know from my conversation with Steve that he was facing a collaboration problem, so the rest of this answer will focus that way.2
Step 2: Assess your stakeholders' perception of your data team
So we've decided that the problem is our stakeholders prioritizing their work requests, and pushing back on project ideas that originate within the data team. The next question to ask is: Do your stakeholders see a problem with this arrangement?
A book that reshaped how I think about this challenge for data teams is The Trusted Advisor by Maister, Green & Galford.3 In particular, they offer a framework with four levels of collaboration, with the pinnacle being the "trusted advisor"—similar, I'd argue, to what most data leaders would describe as an optimal strategic partnership stance for their team. The lowest level is "service-based," which is focused on providing answers, expertise, and input through explanation. Success for a service-based collaboration is when the work is timely and high quality.
When I started thinking about my past teams with this lens, I had an aha moment. Even though I saw so much potential for my team beyond the tasks we were given, the service-based operational approach was not only common, it also had a clear definition of success. My team's work was meeting and exceeding our stakeholders’ expectations. But because I viewed those expectations as too low, I responded by insisting something was wrong. That’s not a good foundation for culture change.
So before you take action, step back and assess how your stakeholders view your data team. In particular, reflect on these two prompts:
Even though there are drawbacks to being a service-based organization, is your team successful at providing that level of support? Maister, Green & Galford repeatedly say that trusted advisors must "earn the right" to build a deeper advisory relationship, and that starts by meeting and exceeding the expectations in front of you.
If you are successful at providing service-based support, then be mindful of how you approach the issue of evolving beyond a task-taking organization. Even if you feel that this is the biggest problem your team is facing, your stakeholders don't necessarily see it that way. Insisting that there is a problem will squander the good will you've accrued with your team's success. Instead, frame your goal around seeking even greater data-driven impact.
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.
Step 3: Adopt an apprenticeship stance with stakeholders to uncover bigger projects
When I was first introduced to the foundations of user-centered design in school, my instructors talked about taking an apprenticeship stance when connecting with users. Why apprenticeship?
Once someone has built expertise on a topic, Cognitive Psychology research suggests they will have learned tens of thousands of interconnected facts, patterns, and heuristics about that topic.4
While your user may not be an expert on building software, they are an expert on how they approach whatever set of tasks your software is trying to solve. And, you are not.
An apprenticeship stance means you seek to understand all there is to know about how your user approaches that core set of tasks, so you can effectively represent that expertise in another context (i.e., building software for that user).
The same idea holds for your stakeholder relationships. No matter how data savvy they are, they have a deep mental model of all that their job entails, and how your team's work fits into their job. By taking an apprenticeship stance, your goal is to build a deeper understanding of that mental model.
What does an apprenticeship stance look like in practice? In short: It's expressing curiosity to build a stronger awareness of how your stakeholder is using data (or not!) to do their job. It focuses on understanding the biggest problems that stakeholder is facing, even if they initially seem irrelevant to your data team. It doesn't have an ulterior motive—so don't come in trying to promote an exciting new project idea! Instead, it focuses on building a shared mental model of the stakeholder's current challenges to use as the foundation for uncovering future, impactful work.
To get you started, check out my post on sourcing data projects through observation. In it, I take inspiration from a common UX Research method to give data leaders a long list of questions for these stakeholder conversations. Before you know it, you'll inevitably find a strong opportunity for data work that the stakeholder wouldn't have articulated on their own.
A last note in this step: The apprenticeship stance alone may not get you to the projects you know you ought to be doing—at least, not right away. But in an environment where your data team's project ideas are shut down, building a longer list of projects that arise jointly from stakeholders and the data team is a step in the right direction. And it primes us for Step 4.
Step 4: Amplify the successes from your jointly-articulated projects
If you see wins from Step 3—even from just one or two stakeholders—that's huge. You've proven that your stakeholders are open to ideas from your team. Culture change is possible. Now, you just need to scale that change: More wins, for more stakeholders.
Inevitably there will be some stakeholders who are very comfortable with throwing tasks over the wall to your team. Those same stakeholders may have been resistant to your efforts to engage them with an apprenticeship stance, preferring only to connect with the data team to hand off new tasks. This step involves deeper outreach to these stakeholders, building on your prior wins.
To start with, leverage the good will you accrued in Step 3 in your conversations with stakeholders who have been strong partners. Here are some conversation starters to get them supporting your scaling efforts:
Our last project really helped solve / provide helpful insight on {stakeholder problem}. I'm keeping my eyes open for similar problems, where we could be leveraging data more effectively than we are today. Are there other examples that come to mind for you?
I really appreciate being able to stay connected on what's top of mind for you; it helps to uncover the most impactful projects like the one we just completed together. I'd like to scale that awareness across the business. Do you have any feedback that can help me to make that happen?
You should be similarly proactive with the stakeholders who have been slower to connect with this effort by leveraging your prior successes. For example:
I just finished a project with {stakeholder} where we learned {findings}, and it's been helpful for them to optimize a key part of their work. I think the same opportunity is available to you and your team; can we talk more about how a similar project can drive {business outcome} for your team?
Did you hear about the project {stakeholder} and I just finished? We delivered {business impact}. We were able to identify that project because {stakeholder} and I meet regularly to discuss their most pressing problems. I'd like to do the same for your team; who would be a good point of contact for those check-ins?
While the pace of change will slowly increase as you build more credibility with these joint projects, it will still be slow. But over time, the share of projects you plan jointly with stakeholders will grow, and so too will their trust in your ability to choose projects that meaningfully impact the business. That trust will serve as the foundation to bring in the bigger projects you've been wanting to prioritize.
Step 5: Use targeted education to prioritize projects with significant business value
I started my answer by calling out education alone as an overly simplistic approach. If you've invested in the prior four steps, you likely understand this for yourself. Your initial list of dream projects for the business may not make sense anymore: Some, the business just isn't ready for, while others need to be tweaked to effectively shape the desired business outcomes. Without putting in the prior work, you don't get all of that rich context—leaving your project ideas detached from how your stakeholders think about the business.
So as you get ready to pitch the projects that you know will move the business forward, do so in a way that takes advantage of everything you've learned prior.
Keep it simple: Don't present all your project ideas in one educational presentation. Instead, choose a single project, targeted to one (or a small group) of stakeholders.
Lead with the business problem and potential value: By now, you understand how your stakeholders talk about their problems and the value they want to provide. Use that same language. Open with the problem of theirs that you want to go deeper on, and the value your project can provide for that problem.
Envision the future: Imagine your project goes exactly the way you hope. Yes, some business metric will change, but what else will change about how the business operates? Is a new data product delivered that changes how your stakeholders approach a common task? Does that change save time or energy in the long run? How big of a departure is it from the status quo? Remember: Even with the good will you've built up, change will still be disruptive. The more you can describe the shape of that change—the good, and the bad—the better your chances to get buy-in.
Explain why now: Even when a project has clear benefit to the business, you're competing against the inertia of a busy, overloaded stakeholder team. So you should be wary of a supportive response that delays action—especially if the delay is unbounded (e.g., "This is great, but now's not the right time for this change. Let's revisit this down the line."). Consider the growth your project will bring to core business metrics, and think through what that growth looks like 6 months out if you start now, vs. in 3 months. Attach a project delay to diminished growth, to make it harder to push off.
Even with this full process at your back, you won't get support for every project you pitch to the business. Don't get discouraged! Keep bringing your ideas when they're warranted, and keep the rejected ideas in your back pocket, ready for an opportune moment when they might be better appreciated. The more you pitch projects that are centered on the business needs, the more you'll be looked at as a thought leader for how to strategically leverage data across your stakeholder teams.
When facing a problem like this, it's easy to get frustrated with your stakeholders. "I could have so much more impact with stakeholders who just get it," you say to yourself. And maybe that leads you to explore other opportunities, with companies renowned for working effectively with data (and data teams).
One thing I've learned across a wide variety of business contexts is that it's never perfect. Some environments are more primed for effective use of Data Science, sure, but there's always room to improve it no matter where you land. And if you want to drive that improvement, it starts with building a track record of success.
So if you are feeling your limit of frustration with your team only being "task takers," give this process a try before you write off your stakeholders completely. You might be surprised at how willing your stakeholders are to come along in the culture change, with you leading the way.
Have a different take for Steve? Leave a comment below, and start a discussion!
If you’d like to submit your own question, send me an email at deliberatedataculture@substack.com. Email is only enabled for subscribers, so be sure to subscribe before sending in your question. It's free!
Apart from having a happier data team, which accrues business value in minimized turnover, this stance also beneficial to the business’s bottom line. In a recent article, Eric Colson describes the business value inherent in letting Data Scientists loose on the core challenges of the business, because of how they approach problems differently.
There is some fertile ground to tread for those other problems, however. I'm making a mental note to return to these topics in a future post!
I wrote a summary of my takeaways from The Trusted Advisor for data leaders, which I recommend if you're seeking to grow your data team’s role as a strategic partner for the business.
First articulated by Chase & Simon (1973) in the domain of chess, subsequent research has gone deeper in how we build expertise, how much practice is required to attain expertise, and what that means for how we think (e.g., Ericsson, Krampe & Tesch-Römer (1993))