It was Q3 board prep. The kind of week where every executive needs a different number by Friday and every number needs to be defensible.
The CMO needed pipeline coverage ratios. The CRO needed stage-by-stage conversion rates. Finance needed an ARR waterfall that reconciled with bookings.
Simple enough. Except none of the numbers matched.
Marketing reported 450 SQLs that were sent to sales. Sales showed 320 SQLs in their pipeline. Finance wanted to know where the other 130 went. Customer Success was tracking renewals in a separate spreadsheet that nobody knew existed until Wednesday.
Three smart teams. Good intentions. No shared language, no unified data model, and no system for truth.
The worst part? This wasn't unusual. I'd seen the same thing at every company I'd worked at. Different names, different CRMs, same problem. The faster you grow, the wider the cracks get.
The same failure mode, everywhere
I've been working in this space since 2019. And at every stop, I kept running into the same pattern. It was never a people problem. The teams were sharp. It wasn't a tools problem. The tech stacks were fine. It was a systems problem.
RevOps teams were spending the vast majority of their time on reactive work. Cleaning data. Fielding ad-hoc report requests. Rebuilding dashboards that broke every quarter. Chasing pipeline inconsistencies. Building one-off workflows that nobody else could maintain.
It's like hiring a Formula 1 engineer and having them change oil all day. The capability is there. The leverage isn't.
And the downstream effects compound quietly. Forecasts are unpredictable because pipeline data is inconsistent. Decisions are slow because every question requires someone to build a spreadsheet. Teams are misaligned because marketing, sales, and CS are all working off different definitions of the same metrics. Eventually, leadership stops trusting the numbers — and the ops team loses its seat at the table.
What nobody says in the all-hands
Here's the thing I've come to believe: most companies don't have a revenue strategy problem. They have a revenue infrastructure problem.
The strategy is usually fine. The ICP is defined. The sales process exists. The team is executing. But the data layer underneath — the thing that tells you whether any of it is actually working — is unreliable. And when the data is unreliable, every decision built on top of it is a guess wearing a suit.
Board decks become performative. Pipeline reviews become arguments about data quality instead of deal strategy. Forecasts are built on vibes and rep confidence rather than validated stage progression and historical conversion rates.
This isn't a niche problem. It's the default state at most growth-stage companies. Not because anyone made a bad decision, but because revenue systems grow organically — stitched together over time by well-meaning people solving the problem in front of them. By the time you realize the foundation is cracked, there's a whole building sitting on top of it.
Why not just... engineer it?
At some point, I started asking a question that felt almost too obvious: why do software engineering teams operate so differently from revenue teams?
Software engineers build systems with architecture, not hacks. They instrument everything so they can measure what matters. They use version control so they can roll back when things break. They write automated tests that catch bugs before they ship. They automate repeatable tasks so humans spend time on judgment calls, not data entry.
Revenue operations has the same complexity. The same data volume. The same need for precision. A bad deal stage or a missing field can cascade into a wrong number on a slide that changes a company's hiring plan. The CRM is a production system — every revenue team depends on it, but almost nobody treats it like one.
That's what GTM engineering means to me. Not a new title. Not a rebranding of RevOps. It's the application of engineering discipline to the systems that run your revenue operation. Tested data. Version-controlled logic. Automated quality checks. Architecture before duct tape.
Why this is actually hard
I want to be honest: this shift is genuinely difficult.
Reactive work feels urgent. Proactive work feels optional. When a VP pings you asking why their pipeline report looks wrong, you drop everything to fix it — and the infrastructure project that would have prevented the bad report gets pushed another week. Multiply that across a quarter and you've spent all your time treating symptoms while the root cause grows.
There's also a cultural problem. In most companies, ops is positioned as a support function. You get a Slack message, you deliver a report, you move on. The third time someone asks for the same report is a data model waiting to be built — but that requires someone to step back and say "we need to build this differently."
Breaking out of the cycle requires investing time upfront in work that doesn't have an immediate, visible payoff. Building a tested data model doesn't feel as productive as sending the VP their report. But six months later, the report generates itself, the data is reliable, and the team is working on strategy instead of firefighting.
The hard part isn't the engineering. It's creating the space to do it.
The gap I keep seeing
Here's what I notice when I look at how most companies operate their revenue data:
The things that get engineered: outbound sequencing, lead enrichment, email automation. The top-of-funnel tooling is often well-built. This is where most of the "GTM Engineering" conversation lives right now — Clay, Apollo, the prospecting stack.
The things that don't: pipeline integrity, forecast accuracy, deal stage validation, post-sale data, conversion analysis, data quality testing. The infrastructure that tells you whether your GTM motion is actually working is almost always held together manually.
It's like instrumenting the first mile of a marathon and then guessing the rest. You know how many people started running. You have no idea how many are still on the course.
The opportunity — and the reason I started GTM Eng — is closing that gap. Not with more tools or more headcount, but with better systems. Tested, version-controlled, automated data infrastructure that covers the full revenue operation, from first touch to renewal.
The companies that figure this out will make better decisions, faster, with fewer people arguing about whether the numbers are right. The ones that don't will keep spending four days on board prep.
I know which side I want to be on.
GTM Eng is a revenue data engineering firm based in Toronto. We help companies build the revenue data infrastructure their GTM teams deserve.