The Data Business Partnership

There are as many different ways to structure data teams within organizations as there are BI tools in the marketplace to choose from. If you’re a data leader thinking about how to structure your team for maximum impact, it’s critical to build solid relationships between data practitioners and the people they work with. The data business partner approach enables data practitioners to proactively and strategically collaborate with other team leaders.

When data practitioners work with business teams, it is often framed as providing data to help teams make better decisions. That’s absolutely correct and all, but commonly the relationship defaults to providing data = providing a service. When you’re providing a service, you’re not among the decision-makers, and that means your data work has less impact on the team and on the overall business. And data practitioners stuck in service roles burn out quickly, not only due to infinite workload, but because it’s incredibly unsatisfying work.  

Introducing the Data Business Partnership

Instead, consider being a data business partner to the team. This flips the script from data practitioners being in a reactive, supporting role informing a team’s direction towards being in a proactive, even product manager-like role. Data business partners (DBPs) leverage their extensive analytics, business intelligence, and data curation experiences in order to design and implement effective data strategies and projects within the team, all in collaboration with other team leaders. That, in turn, boosts the team’s capabilities to hit its goals. 

The DBP should share accountability for that team’s objectives and results, becoming a stakeholder in that team’s success. That is how impact is driven. It’s much harder to drive impact if you’re dispassionate and neutral (or even worse, temporary) by serving numbers, building requested metrics, and completing “pull this dataset please” tickets.

A data business partner (DBP) is not a job title. Any role on a data team can be a data business partner! Rather, it’s a work function or even a mindset. To be a DBP, you don’t need to be already specializing in that team’s function (i.e., if you’re partnering with a marketing team, the data function would be marketing analytics) but it helps. What’s more important is a willingness to jump into the fray, drive decisions, and own the team’s successes and failures.

The HR Business Partner

Let’s take inspiration from another business function often perceived as “serving” the needs of the organization: human resources. You may have heard of HRBPs (HR Business Partners). It’s a relationship paradigm that’s worked very well and is replicated across countless companies. A HRBP “is a senior professional focused on using human resources to help a business unit succeed.” (NEU)

Sounds like what data practitioners aspire to do, right? 

[HRBPs] work with teams, managers and key stakeholders to help build organization and people capability, and shape and implement effective people strategies and activities within the organization. They need to have an excellent understanding of the organization, its strategy and customers, and a very good understanding of the people challenges faced by the organization.

CIPD

Success as an HRBP means knowing the ins and outs of how a business works and what it needs to hit its financial and operational goals. At the same time, these professionals must immerse themselves in the principles of recruiting, managing, and supporting employees.

NEU

It’s a role that leans towards strategy and providing domain-specific leadership in domain-general contexts. For example, if the engineering organization’s goal is to hire more engineers, a HRBP will work with engineering leaders to develop hiring plans. They will analyze talent requirements, identify which skill sets to focus on, and rally the team behind executing those hiring plans. The HRBP weaves HR processes and HR thinking throughout the engineering organization through project work such as interviewer training, establishing scheduling processes, data reporting, facilitating team syncs and retrospectives, and regular check-ins with key stakeholders. They become an active, involved stakeholder in the engineering organization’s success–as opposed to dispassionately advising from the sidelines.  

What DBPs Do

Find-and-replace all of the above HR terms with data terms, and you’ve got a data business partner. 

Elaborating on this further: a DBP is somebody on the data team who works primarily with, and even becomes integrated in a business team (i.e., finance, product, growth, sales). The DBP works closely with that team’s managers (i.e. product manager, engineering manager, finance manager) and helps the team make better strategic and tactical decisions by bringing the data perspective to the table. To create impact, the DBP will consider team objectives and priorities, which of the five JTBDs need the most attention, plan their projects and execute, all working within a primary continuous feedback cycle with their business team (local prioritization) and a secondary asynchronous feedback loop with their data team. 

Partnerships are relationships, and effective DBPs spend a lot of time on building that relationship itself. There’s many aspects to establishing a culture of partnership, including identifying and sharing team values, having humility as you step into new contexts, and being helpful. Being helpful doesn’t mean you’re in a service role; it means you’re mindful and empathetic of your team’s challenges and want to make their lives easier in small, incremental ways (i.e., automating a problematic workflow).

Are You Already a DBP?

Maybe you’re reading this and thinking, “Hey, am I already a DBP?” A good benchmark is how long it takes for you to learn about new projects coming down the chute. 

Are you reacting to the fleshed-out requirements of a project that already has a timeline and success criteria, and now you’re fretting about how to make room on your already-full plate to support this project? 

Or did you know about this project as soon as folks started talking about it? And that enabled you to advise straightaway on which success criteria to use, plan new data pipelining and modeling work to support these metrics, and anticipate upcoming data team capacity to execute on the new work?

Maybe you’ve even already changed the project scope and objectives based on your input and consideration of your own capacity in the next few sprints (this is galaxy brain-level partnership). Partners are there at the beginning; service people are there at the end or even in the middle, but not at the beginning when it really counts. 

Let’s work through a common example of cross-functional data work: user telemetry/event tracking. 

1. Not a partnership: The product team just released a new feature, and now they’re asking you to tell them how users are interacting with the feature. But the tracking wasn’t properly set up, and there’s several critical user actions that aren’t being captured. Now the product team is losing weeks of time-to-insight as you catch up on context, figure out what’s being tracked, and write up a new tracking plan that’s aligned with their success metrics. Nobody’s sure if the feature works well, and stakeholders are wondering what’s taking Data so long.
2. Also not a partnership: The product team is two weeks away from releasing a new feature. Engineers are sprinting towards the end, and the product manager is trying to control scope creep and stick to the project timeline. Then a VP asks, “how do we know if this feature is successful?” You’re looped in to define success metrics, and while catching up on context, you point out there needs to be a tracking plan implemented. Now the scope has expanded and the timeline is at risk, all “because Data needs certain things in place before we can launch.” 
3. Partnership win: The product team is thinking about a new feature. Because you’ve been a partner on this team for a while now and have been drilling home the importance of predefined success metrics and tracking plans, the PM’s already written out a proposed set of success metrics. As designers and engineers scope out the feature, you’re close to all these discussions and start writing out a tracking plan that’s aligned with the success metrics. The scope includes this and the project timeline includes time for implementation. Once the feature is launched, both PM and engineers can pull event counts and build rudimentary visualizations, because you’ve already shown them how to use the company’s event analytics tool. Insights come faster, decisions get made with confidence, and everybody wins. 

Can Your Organization Have DBPs? 

The HR domain is very concise with their job titles (which shouldn’t come as a surprise), so the HRBP role is distinctly different from other roles like HR specialists or HR managers. We don’t have that luxury in our discipline (hello, many confusing job titles). Think of DBPs as a mindset, as a working paradigm rather than an actual job title. What it involves is shifting your attitude towards how you perceive your stakeholders and their work, and shifting your messaging towards working with them, participating in their meetings and rituals, and yes, getting a seat at the table. 

Just like HRBPs still stay in HR teams and report to HR managers, data practitioners who are in DBP-type roles should continue to report to data team managers. HR does it this way because HR technology, policy, and processes must be consistent companywide. If an HR person is no longer actively on an HR team and reporting to HR managers, this consistency won’t happen. 

It’s exactly the same for DBPs. You want a solid central data team set up with a well-oiled modern data stack, processes in place for planning and defining data models and metrics, and long-term strategies for data activation and self-serve capabilities. When all that’s in place, a well-built datahouse (pun intended) will create leverage for DBPs as they both apply these centralized processes to business teams, and in the opposite direction, take learnings from those teams to improve on those centralized processes for everybody else. 

Starting Up a Data Business Partnership

Here’s a to-do list for how to initiate a new data business partnership at your work: 

1. Identify opportunities where having a DBP can create some real impact. Are you getting many tickets from a particular person? Would being a partner to them and their team be a good idea? Or is there a cross-functional team with a clear business-critical objective? A team with a clear focus probably benefits more from having a DBP than one that doesn’t, especially if you’re just starting out with the DBP mindset.
2. Talk with your data manager. A DBP means most of your workload needs to be aligned with the business team’s objectives and projects. What’s currently on your plate that may need to be taken off? Get buy-in from your manager; they have company-wide context and likely have opinions about who you should be partnering with. 
3. Identified a team and their leaders (PMs, EMs, other types of managers)? Meet them! They’ll be thrilled to have their own data person. Kick off the partnership by defining regular communication channels, and get invited to all the team’s regular syncs and meetings. Pick up all the documentation out there on the team’s objectives, roadmap, structure, and processes, read through them, and set up a follow-up meeting in 1-2 weeks once you’ve had time to read and digest. 
4. You are part of the team now! If there’s a weekly team meeting, carve out 5 minutes to discuss data things–metric updates, new processes or tools, tutorials on how to pull certain numbers. Let everyone else see how your data work is making everyone else’s work more efficient and impactful. 
5. Make sure you have 1:1s with team managers. While it’s important to talk about in-flight work, keep conversations focused on long-term team objectives (i.e., quarterly OKRs, what’s going on the roadmap in the next planning cycle). How can these objectives benefit from better data hygiene or processes? Does the team need to pick up on important data practices or learn new data tools? Write process docs, host brown bag lunches, have async AMAs. 
6. Monitor external discussions elsewhere in the company. Determine if those are tangentially related to your team. If so, either do a quick analysis and bring a data perspective to it, or pull it into your team and have a discussion there. You, as a data person, are naturally exposed to many parts of the company; leverage this to add value to yourself and your team. 
7. You may start getting more ad-hoc data requests or tickets from your team. This is normal; remember, the default mode of data teams is to be in service roles. Now is the time to start regular data prioritization with your team. At the start of each week, share out a list of 2-4 issues in priority order and share it with your team for feedback and re-ordering if needed. Help them understand that ad-hoc data asks, while they may feel important in-the-moment, often don’t add as much value as proactive, foundational projects.  
8. Consider office hours: 30 mins or 1 hour a week where anyone in the team can come to you to discuss a specific issue, think through an experiment, learn how to use a data tool better, or point out a metric anomaly. Rather than a meeting about “what each one of us will be working on this week,” this setting establishes an informal space for being curious about data and to surface common pain points about working with data. It can be incredibly fertile ground for conceiving new data projects to solve these pain points and new proactive insight work to follow up on your partners’ hunches.

Wrapping Up

Data business partnerships are challenging–you’ll work in messier contexts with multiple people and you may feel you’ll have to do more communication work between your business team & your “home” data team. It requires a healthy “saying no” muscle to other ad-hoc work as you need to protect your time and focus for your partners.

But there’s also a bonus for you and your career as a data business partner. You’ll become an expert in the business domain and understand common objectives and challenges–all very portable skills for your next job, a good argument for a promotion, or a reason to consider lateral moves into product or program management. And as you specialize further, you’re able to move faster, define the right metrics faster, find more relevant insights, and drive more impact for the team. 

In the end, you will find yourself influencing basic business processes such as how new features are planned, shipped, and measured. You will be the local point of data expertise for your team, and become a model for how other business teams can leverage data to hit their goals faster and more reliably. Having data practices and processes interwoven in a team’s ordinary business processes is what it really means to be data-driven, and it takes partnerships–not service folks–to make that happen.