The Reluctant Data Engineer

If you’ve been on a RevOps team, there’s a good chance you’ve been involved in one of the de-facto functions of RevOps: Analytics. 

RevOps isn’t always running analytics for the whole organization but you can bet that when it comes to the sales, marketing, and CS metrics, RevOps is on the hook to deliver. 

And often, that means delivering not only a fully baked suite of reporting solutions, but also building and maintaining robust data transformation processes. This is often done without additional resources, limited technical skills and leads to cobbled together solutions that fall apart with the slightest schema alteration.

Let’s be honest, RevOps doesn’t get the recognition it deserves for the complexity it delivers, and adding data engineering to the mix just adds one more thing that can go awry. 

How did we get here? 

In the era of consolidation, we often hear the phrase “do more with less”. The other phrase we hear is “I need a dashboard that displays X, Y, and Z”. 

“But wait!” your RevOps leader cries, "we have a dashboard that displays X, Y and Z!” 

“But does it break it down by rep by weekday only, adjusting for current weather forecasts by region?”

“Well, no, but….” 

“Just build it” 

And here we are. 

What do we call this? YADB. Yet Another DashBoard. Yes, I made this up. Yes, it's a terrible acronym. But can every RevOps analyst turned reluctant data engineer relate? Absolutely. 

It’s not just the need to split data in different ways that led us here. The explosion of the GTM tech stack, the need to aggregate data across systems, and the inherent complexity of reconciling schemas that don’t play nice all contributed.

The job of RevOps is to work cross-functionally to align business units around the common goal of hitting targets. It isn’t to be the plumber of data pipelines and the sole custodian of hundreds of dashboards. 

I don’t say “hundreds” lightly, I’ve seen analytics environments with thousands of dashboards and even more subpages. Once you go down that road, it’s extremely hard to get off that train. It’s not just building and maintaining, it’s documenting and handoffs when a key person exits, and time spent on upkeep that would be better served elsewhere. Like figuring out how that 30% growth target the CFO just handed down fits into last year’s 5% decline.

What are we really solving for? 

When we break it down, what revenue leaders really want from data, reporting and ultimately analysis is truth. Truth as in “what dashboard can I look to as the source of truth”. 

If I had a dollar for every time I’d heard that in RevOps, I wouldn’t be working in RevOps, I’ll tell you that much. 

If the source of truth is a pipe dream, then how do we close the truth gap, the space between data and action?

It starts by reframing the problem. It’s not another dashboard. What leaders really want is confidence.

They want to know that what they’re looking for is signed off, correct, and defensible. They want to keep tabs on the business with the metrics that matter, that they can explain clearly. What they don’t want is to have to dig, interpret or wait. 

Here’s the kicker: that kind of clarity doesn’t come cheap. It requires human hours, tech spend, and miles of consensus. 

The only sustainable way to get there? Good data at the source, directly accessible without the transformation layers. 

It’s a hot take, but I’ll say it: traditional ETL or ELT processes will be gone in the next couple of years and the technologies powering them will have to evolve or die. 

The Way Forward

So what replaces traditional data transformation, storage, and dashboards?

The answer: business context derived from data that already lives in your source systems. There’s no longer a need to extract, transform and stitch together semi-normalized schemas from 10+ sales tools. 

MCP (Model Context Protocol) technology is already doing this with a high degree of fidelity, even generating relationships between datasets when none exist natively. 

That represents a fundamental shift not just for RevOps but for data teams too. 

Clean data at the source removes the layers between data and insight, then leverage emerging technologies to go directly to the source. 

The source of truth already exists, and it can be leveraged.

Imagine the time savings for RevOps to be freed up from the gravity well of data engineering. I won’t throw dashboards completely under the bus, they still have their place. But they aren’t great for speed to insight. They don’t provide recommendations and they certainly don’t take action on behalf of the user. 

The future is real-time insights powered by source level data. 

So what next? 

Most organizations are into Q4 or on the cusp of it. As part of the end of year tech consolidation planning, teams need to be asking one question: “Do our data processes support the speed of our business?” 

If the answer is no, it's time to re-evaluate the tech stack. Look into the future and decide:

Do you want your RevOps team to be your de facto data engineering team?

The answer is no. 

You don’t.