Data Ticket Takers or Decision Makers?

Fundamentally, there are two different types of data teams in this world. There are those who are reactive to the wants of the organization, and then there are those who proactively lead the organization towards its needs.

The first is helpful, but a cost center. The second is a value generator. In these economic conditions, which would you rather be?

This isn’t to say data teams should never resolve a ticket or field an ad-hoc request. We are all accountable to one another and healthy organizations require give and take. 

But, for all of its faults, the modern data stack with its speed and scale has given data teams an unprecedented opportunity to set the agenda and shape their organization’s destiny. 

Here are four ways I’ve seen data leaders seize that opportunity and make the transition from back office to front. 

Squeaky wheels vs. organizational priorities

I have yet to meet a data team that has more capacity than they do stakeholder demand. The nature of the job demands ruthless prioritization. 

Some data leaders will fall into the trap of focusing their time and resources based on who is loudest or which domains are making the most requests. While this is a slight step away from literally taking tickets, there is a defensible rationale of letting the “market decide.” 

After all, the reasoning goes, aren’t the people who are making the most frequent and intensive data requests those who will actually put it to good use and derive the most value from the time spent by the data team?

Nope.

For one thing, this approach abdicates all data value creation responsibilities to those who are not experts in data. For another, the most important constituency, your organization’s customers, don’t have the ability to directly Slack your analysts “to quickly pull some data.” 

Them: Can you just quickly pull this data for me?

Me: Sure, let me just:

SELECT * FROM some_ideal_clean_and_pristine.table_that_you_think_exists

— Seth Rosen (@sethrosen) April 20, 2020

In an ideal world, data teams will have assessed and measured the value of each of their main data use cases. They would make purely rational decisions on where to invest their time based on the ROI of the task at hand.

In the real world, such black and white math breaks down pretty quickly somewhere between trying to calculate the value of a dashboard and a data literacy initiative. My recommendation for data leaders is to stay close to revenue, customers, and organizational goals.

This is what Lior Solomon did in both his former data leadership role at Vimeo as well as in his current role at hypergrowth startup Drata.

At Vimeo, he was able to prioritize data resources and justify budgets by closely tracking and ensuring the quality of business metrics data. As Vimeo was on the verge of going public, accurately monitoring the business metrics was of utmost importance for the company’s growth and success. 

The requirements at Drata were different. He was building a modern data stack from the ground up and data wasn’t as customer facing as it was at Vimeo. In this case, he focused his attention on quick, tangible wins like partnering with marketing to improve campaign performance. He also stayed close to Drata’s mission of helping customers reach full compliance readiness as quickly as possible by building systems to analyze and monitor which controls were holding back different segments of customers from achieving full readiness.

Tracking metrics vs. setting metrics

Data ticket takers are told what the key metrics are by their consumers. They are asked to develop reports tracking this metric movement. Teams are built to create and maintain dashboards and views. 

Data decision makers view dashboard creation and maintenance as a necessary bar to clear, and then set aside, to create space for value generating activities. 

“My mantra is I don’t want to be valued by how many reports I generate because then I become an extension of IT,” said Lior. 

“Our data mission statement is aligned with the Drata mission: ‘Our Mission is to Build Trust Across the Web’,” he emphasized. “We are committed to utilizing data as a powerful tool to cultivate trust and reliability in our organization and throughout the digital landscape. By harnessing the potential of data, we strive to foster transparency, security, and accountability, ultimately establishing a trusted environment for our customers and partners.”

To do this, data leaders like Alex Tverdohleb, vice president of data services at Fox Networks, prioritize building data self-service infrastructure. 

“If you think about a centralized data reporting structure, where you used to come in, open a ticket, and wait for your turn, by the time you get an answer, it’s often too late,” Alex said. “We give you the source of the data and guarantee it’s trustworthy….so just go ahead and use it how you want.

Instead of building teams to report metrics, proactive data leaders build teams to discover and experiment with new growth drivers (metrics) for the business. They move from what happened? To why did it happen? And what do we think will happen if we do this?

One way data leaders can begin to help their team make this transition is to make every ad-hoc request an opportunity to add value.

“I also give my team a mandate: Don’t ever give stakeholders what they ask for. Always give them more,” said John Steinmetz, VP of data and analytics, Shiftkey. “I tell my team that when they receive an ad-hoc request, don’t just give your stakeholders what they ask for—find out why they need the data, give them what they asked for, and give them one additional piece of information that you think could solve their problem better. Over time they will see you as more than just a giver of lists.”

Alerted to issues vs. alerting stakeholders

Here’s a scenario I see all too often. Bad data makes its way to company leadership, or worse, customers. The request comes down the chain, “Why do these numbers look funny?”

Fire drill time! The team’s best data engineers and system experts are pulled from their projects to troubleshoot and analyze the root cause. After a couple of days, nothing concrete has been identified and everyone goes back to their projects to wait for next week’s fire drill.

I also hear stories from data leaders on how their inbox is routinely filled with issues from their data consumers. Essentially those consumers have stepped in to act as manual data monitors and are firing off alerts, which are now tickets, to anyone and everyone on the data team who will listen. 

This story has become increasingly common as engineering resources get spread thinner and teams have less time to spend on data testing.

Proactive data leaders not only prioritize but measure how frequently their team is the first to know of any data quality issues. They realize two things: 1) data trust is their most important currency and every unflagged issue is a withdrawal from their account, and 2) it can be the difference between the data team being perceived as the problem or as the solution. 

One data leader of a Fortune500 company described the reactive to proactive data quality transition like this:

“We send daily reports to update executives on all aspects of the business. If data was wrong in those reports, I would hear about it first thing in the morning and it was the worst way to start my day…[Recently], I got a volume alert and quickly emailed the [the business stakeholder] who owns this report to just say, ‘We have a problem right now, but we are working on it. Please don’t send your daily report yet.’ She was incredibly appreciative of our proactive initiative. It was a moment where the [the business stakeholder] knew we had her back. It felt great—I felt like I was delivering a service rather than just fixing a problem she had.”

This transition requires a few prerequisites. Data teams need to have a data quality monitoring system in place; a means for understanding how an incident will impact what and who within the organization; and a process for informing those stakeholders. Quick Slack pings can do the job, but the best in class solution I’ve seen for this is placing a notice on the BI dashboard itself either through a data observability/data catalog integration or custom built solution.

The top data teams will go a step past their ‘first to know’ rate and work with stakeholders to define ahead of time what level of reliability is needed (what actually constitutes an incident) and codify these expectations in data SLAs.

Cost vs. investment

Reactive data teams report their outputs, which are frequently framed in technical terms. Things like, “we have built X pipelines,” or “we have reduced latency by 25 percent.” They make their budget requests the same way. “We need an X so we can do Y.” 

As a result, the team is seen as a cost center and their budget requests (and these days even headcount) are seen as unnecessary line items to be minimized. After being pressed by the CFO, “if they REALLY need this,” they either abandon the initiative or turn to stitching together a bevy of piecemeal open source solutions like Frankenstein’s monster.

This can quickly become a vicious cycle as the reactive data team spends more time–literally more than 50 percent–keeping their data Frankenstein infrastructure functional than adding value. Instead of data engineers, they become data plumbers. 

“I understand the instinct to turn to open source, but I actually have a lower cost of ownership with [certain modern data stack tools] because the management burden is so low and the ecosystem works so well together,” said Adam Woods, chief executive officer of the digital advertising platform Choozle. “We are able to reinvest the time developers and database analysts would have spent worrying about updates and infrastructure into building exceptional customer experiences.”

Proactive data leaders don’t have costs; they have investments. The difference between the two is an investment is attributable and has a return. While both can be challenging to calculate for broader platform or infrastructure investments, proactive data leaders take the time to build the business case both before and after implementation.

For many companies, budget isn’t given, it’s earned. As a result, these data teams are almost always adequately resourced because the CFO understands the context of the line item to, “boost revenue 5 percent by making our customer facing machine learning models more accurate.” 

Proactive data teams also ensure these investments pay off by focusing on business value. More often than not this means monetizing data by surfacing it externally with your customers.

“One of our big value ads is giving business insights to our customers: restaurants,” said Noah Abramson, data engineering manager, Toast. “How did they do over time? How much were their sales yesterday? Who is their top customer? It’s the data platform team’s job to engage with our restaurant customers.”

Data teams should build with, not build for

Please don’t mistake these examples as a license to dictate terms to your business stakeholders. It is helpful to know when to lead and when to follow– it is even better to partner with your business teams and lead the way together.

I’ll leave you with a quote that mirrors my most frequent advice to data leaders: be obsessed with customer impact.

“It’s very easy as a team embedded in the business that’s not directly impacting or interfacing with our customers to lose sight of what our work means to our customers,” said Rob Parker, former senior director of data and analytics, Gitlab. “So we try to think about our customer’s customer. We’ve been able to move away from being the typical order taker into being a trusted business partner in the journey of building scalable and reliable solutions for the business.”

So, what road will you choose? 

Curious how data observability can help make your data team more proactive regarding data quality? Sign up for a demo using the form below.

Our promise: we will show you the product.