I Don't Want to Kill RevOps
But it's time to level up.
I got surprised in a conversation this week with a VP of RevOps. He told me he’d mentioned Gradient Works to a job candidate and their response was, “Isn’t that the company with the CEO who wants to kill RevOps?”
This was news to me since I do not, in fact, want to kill RevOps. I’ve been a RevOps leader and I work with RevOps folks every day. I love RevOps!
That said, I’ve obviously communicated something in this newsletter that would lead a reasonable person to assume I’m cheering the death of RevOps.
But what could it be?
It might be when I called out RevOps for being slow to adopt AI. Or maybe when I implied RevOps teams were bloated and AI would shrink them. Or possibly when I suggested that nobody will hire junior RevOps folks anymore. Or perhaps when I said AI is a substitute for the primary job companies hire RevOps for.
Oh. Well, ok. Maybe it could be some of that.
Clearly, I’ve written a lot about how RevOps is changing—and how practitioners need to change—thanks to AI. I assure you it comes from a place of love. Tough love, perhaps, but still love. I believe RevOps is a force for good in the GTM world and I want to see it adapt to the age of AI.
That adaptation requires embracing new levels of abstraction. The template for RevOps comes from another discipline I love: software engineering.
How software engineers learned to stop worrying and love abstraction
I wanted to build software since the moment my sister showed me how to animate a turtle walking across the screen of our Apple IIgs using the Logo programming language. In middle school, I spent hours building a text-based adventure game on my TI-83 calculator1. I went to college for computer science, became a software engineer, and continue to code as a CEO. I even named my daughter after the very first programmer.
I love writing code. I love the problem solving, the deep thinking and the flow state. Luckily that was all integral to creating software. Then, one chilly weekend in January I tried Claude Code and immediately saw that my relationship with code would never be the same again—I could create software without writing code.
That hurt a bit. I’d devoted two decades to getting good at writing code and now that skill no longer mattered. But ultimately I embraced it because I recognized it was just another step in a journey that started with the first digital computers in the 1940s.
The discipline of software engineering is, essentially, about bridging the yawning gap between the billions of electrical switches2 that computers use to compute and the way humans think. The solution to this problem—developed over the last 80 years—is to build layers of abstraction.
Software engineers use the term “abstraction” in a very specific way. That’s ironic because when we use “abstract” in regular conversation it usually means “vague”. In software engineering, an abstraction means “something that hides complexity so you don’t have to think about it”.
You use abstractions all the time. When you tap send on your “what’s for dinner?” text to your spouse, something amazing happens. Your finger changes the capacitance of a weak electrical field spanning the surface of your screen to register a tap, billions of CPU instructions execute in milliseconds, and the massive globe-spanning infrastructure of the internet is enlisted in transmitting your words as radio waves and little pulses of light. Your conversation about ordering Thai (again) is an actual miracle. You just don’t think about it—and that’s the point of an abstraction.
Software engineers have for decades layered on abstractions to make building software easier.
When Apollo landed on the moon in 1969, its “software” was encoded into a bundle of twisting wires making something called core rope memory. Updating the software meant producing a new physical rope. Building good software required working directly with bits and physical hardware.
By the ‘80s things had changed. Computers had RAM and operating systems, not wire ropes. Changes didn’t require rewiring, just rewriting some words on the screen in a language like C. The operating system hid most of the hardware details. The major problem was computers were memory constrained and slow. Building good software meant memory management tricks and finding clever speedups.
When I started college in 1999 (or “the 1900s” as my daughter would put it), we were the first class at NC State to use Java as our teaching language. Java hid the details of the OS and handled memory management for you. Building good software meant designing your own abstractions—like little code building blocks—that you or others could reuse.
And in January 2026, building good software meant writing instructions that an AI agent could turn into code.
This journey of increasing levels of abstraction—from practically moving bits by hand all the way to asking AI to build software for you—wasn’t as smooth as I make it sound. At each stage, the things that made a practitioner good at their job eventually stopped mattering as the computer took over. The people who learn to operate at the new prevailing level of abstraction do well. The people who don’t ultimately end up doing something else.
What’s fascinating about software engineering, though, is that adopting new levels of abstraction is embraced as part of the culture. Great software engineers are obsessed with it. It’s why the most AI-pilled people I know are developers even though AI’s doing the thing they’re supposed to be good at: writing code. For them, AI is just the next level of abstraction.
And that brings me back to my tough love for RevOps.
RevOps needs to level up
When I wrote about the threat to junior RevOps roles, I shared the chart below built from my analysis of jobs-to-be-done found in RevOps job postings.
These jobs are mostly concerned with managing data, analyzing it and reporting on it. Many of the other jobs RevOps owns—building workflows, managing GTM software—are also very much in the technical weeds. These are all jobs that AI is good at.
If you equate becoming personally skilled at those tasks with success in RevOps, then you’ll be like programmers in 1999 mastering the memory management practices that mattered in the 1980s. You’re operating at the wrong level of abstraction and your skills will no longer be economically useful.
To be successful, you’ll need to operate at a higher level of abstraction. I think that means focusing on four core areas:
System architecture - designing and connecting the core parts of an entire GTM system that successfully integrates data, technology, process and people. That doesn’t mean personally wiring these pieces up; it means deciding what pieces should exist in the first place.
Agent management - creating the access, skill and context foundations that enable agents to operate the systems you put in place, as well as the feedback loops that allow them to self-improve.
People management - this includes both managing direct reports as well as working with stakeholders throughout the business. This may be the most AI-proof of all the core areas.
Business strategy - working with leadership to shape strategic GTM choices like ICP, segmentation, positioning and pricing/packaging. Then building the systems to track, measure and optimize the strategy.
The good news is that, in this list, only agent management is fundamentally new. It ultimately replaces most of the hands-on technical skills that matter so much to RevOps roles today. In that way, this is very similar to the way agentic development is forcing software engineering to replace coding prowess with a new level of abstraction.
The even better news? This new level of abstraction lifts RevOps out of the technical weeds and puts it where it belongs—solving the most strategic GTM problems for the business.
Wrapping up
I don’t want to kill RevOps; I want RevOps to thrive. That won’t happen without a sense of urgency. The world is transitioning to a new level of abstraction. The only thing to do is transition along with it. Software engineers have been doing it for 80 years. You can too. It’s time to level up.
Only for my friend Heath to borrow it and accidentally delete the whole thing. In case you were wondering, there were no backups on a TI-83. I don’t really think they expected anyone to be dumb enough to write a thousand+ line program on there.
The M5 processor in your Macbook pro has around 28 billion of these little on-off switches cycling about 4.5 billion times per second.