Key Insight: Every operations function gravitates toward what its core systems demand. Under traditional CRMs, that meant RevOps had to fight off the identity of system admins and data cleaners. AI-native CRMs re-balance that gravitational pull so that RevOps can operate strategically as revenue architects.

How Identity Forms Around the Wrong Work

8 years ago, I found myself doing the most basic version of CRM data work inside a global company: assigning account hierarchies with manual Google searches and a spreadsheet for batch loading.

I soon expanded to tackle distributor data stewardship, then all account master data for the Americas. I did that because I could see that clean data was the foundation for an increasingly capable team - one with the ability to connect our data to decisions about territories, forecasts, and go-to-market design.

I was after a true revenue operations function.

That meant a strategic identity for that function, not just a mandate to keep the CRM clean. But keeping data from regressing consumed an inordinate proportion of my daily work. New data streamed in from every angle as we developed systematic governance to slow it down. Duplicates compounded. Hierarchies drifted from reality.

We could not outpace a system that generated bad data faster than it could be cleaned.

I found ways to push forward, iteratively transforming how the company managed distribution data, redesigning processes, tightening logic in whatever margin I could find. But that work happened in the cracks. The strategic roadmap never got dedicated capacity.

And this is where identity erosion begins: not in a single dramatic moment, but in the accumulation of days where the only work that fits is maintenance. When a function spends years doing maintenance work, the organization stops seeing it as anything else. The identity follows the work, not the charter.

Demand-Driven vs. Purpose-Driven Identity

Most organizations take a short-sighted view when measuring the impact of AI on systems admin and data maintenance work. The default is to consider how many hours can be saved, or even how much “resource efficiency” can be achieved. But in the case of RevOps, the real impact is measured by what the function becomes.

RevOps teams that spend the majority of their capacity on system and data stewardship lose more than time; they lose their organizational identity. And it’s not because the team stops caring about strategy, but because the system never stops demanding maintenance. The “data janitor” label describes a real organizational outcome: a function whose identity is heavily influenced by what its tools require of it rather than what the business needs from it.

The Moment Identity Almost Shifted

Several years went by like this, with mostly data and system admin work, before resourcing actually improved. A global initiative to standardize business systems across regions created the business case for two new FTEs. For the first time, there was a plausible path to a different identity for the team’s function. Enough hands to hold the line on data quality and begin staffing the strategic roadmap.

That is not what happened.

The FTEs were justifiably hired for ongoing data quality, not strategy. Together, we rewired the data model, cleaned the account base, and established governance that held. We succeeded.

Then came the reallocation: one FTE to the ops team, still underwater with day-to-day demands, and the other stayed in data stewardship.

A heroic effort of leadership might have forced a different allocation. But the system had spent years making the maintenance identity the overwhelmingly visible one. When the opportunity for a strategic allocation finally came, the decision instead confirmed how the team would always be perceived.

The Pattern

That tendency to default to a known identity is not unique to one company or team. Every strategic resource, when asked to also manage a system or resolve data quality, has to resist being fully absorbed into maintaining it.

Once absorbed, regaining the strategic function is a monumental task. “RevOps” becomes a catchphrase, another trend that came and went, falling off the roadmap not because it was deprioritized, but because no one can see the team doing that work anymore.

In RevOps, strategy should drive the technologies that in turn accelerate it. But that feedback loop can’t exist when the team responsible for strategy is pinned to maintenance.

True RevOps is a function that has capacity to design, not just sustain.

Without that feedback loop, over time what’s expected of the team, even internally, quietly adjusts to match the reality of the day-to-day work. The function becomes what the system made it.

The Structural Precondition for a Different Identity

This is the context that makes revenue technology, and AI-native CRMs as a tier-one example, significant to this conversation. When baseline maintenance is automated, the RevOps function is no longer defined by what the system demands.

The data transformation I spent years squeezing into the cracks finally gets real capacity. Instead of manually reconciling account hierarchies, the team can build the territory model that connects ICP scoring to pipeline velocity. They can design the feedback loop between win/loss data and GTM motion, not because someone made a heroic case for it, but because the system stopped consuming every resource the function was given.

AI-native CRMs change what the function can become despite challenging seasons like transformation initiatives, acquisitions, and platform migrations. When the maintenance layer is automated, resources can be allocated to the strategic roadmap instead of the maintenance machine.

The team’s identity forms around revenue architecture instead of around the activities that support it.

And the organization starts evaluating RevOps on what it was designed to deliver.

The Real Question

A fundamental challenge has always been the operating model: a CRM architecture that required constant human intervention to remain functional, layered on top of an organization that expected the same team to also be strategic. Those expectations were incompatible - until now.

The question was whether the systems would catch up. They have. What’s left now is the decision to stop being the team that keeps the CRM clean, and to become the team that designs how revenue works.

Key Insight: Technology is a multiplier, but the foundation it sits on determines what gets multiplied. The competitive edge in go-to-market is moving from how fast you can execute to how well you can design the system behind it. At that intersection of revenue architecture and GTM technology, a new discipline is emerging. That discipline is RevTech.

When Categories Are Born

In the late 2000s, software teams hit a wall. Developers shipped faster than IT operations could reliably deploy and support. The two sides worked in silos with different incentives.

DevOps emerged as the discipline that bridged building software and running it. It earned its own category because the problem was too costly to leave unnamed.

Later, as go-to-market teams scaled, a similar pattern played out. Sales, marketing, and customer success optimized for their own metrics while the customer journey fell through the cracks. RevOps emerged to bridge that gap, bringing process discipline, cross-functional alignment, and shared accountability for the full revenue cycle.

Now we are at another inflection point. The gap this time is not between development and operations, or between GTM teams. It is between revenue architecture and the technology that is supposed to power it.

Over the past two years, the tooling landscape has become nearly impossible to track. AI-native platforms, signal-based GTM, orchestration engines, context layers. New categories within categories form every quarter. Businesses know they need to adopt. Few know how to adopt with intention.

The sheer velocity of new GTM tech has created a systemic gap. Most GTM organizations today are over-tooled and under-architected.

RevTech is the discipline that closes that gap.

The Path to RevTech

For most of the last decade, my work has lived between revenue strategy and the systems that drive its execution.

Building in the RevOps space kept pulling me deeper into the infrastructure underneath: the data model, the workflows, the tooling. The trade-offs that separate a stack that scales from one that simply accumulates more complexity.

Over time, I found myself embedded in the ecosystems of companies that are redefining how modern go-to-market systems get built.

The more rooms I was in, the clearer one pattern became: the best teams were not stitching together point solutions. They were designing revenue systems where technology amplified strategic intent instead of becoming an expensive distraction.

The only problem was that this work had no name, no category, and no shared language.

RevTech started to take shape as my answer to that gap. Not as a product, but as the practice of turning revenue strategy and process into intentional tech architecture. With technology as the multiplier, not the starting point.

Technology Is a Multiplier. The Question Is What Are You Multiplying

Here is something I have learned from years of working with revenue teams from early-stage to enterprise.

Technology accelerates whatever is already in place.

If your strategy is sound and your processes are well designed, the right technology compounds that advantage. It takes you to impact faster, with greater precision.

But if your strategy is off, or your process is broken, technology does not fix it. It accelerates you in the wrong direction. It costs you time and money while creating the illusion of progress.

Think of it as a simple equation: strategy and process are the first input, technology is the multiplier. If your foundation is a zero, it doesn’t matter how sophisticated your tools are. Zero multiplied by ten is still zero.

I have seen this play out dozens of times. A company invests heavily in an outbound stack, only to discover their ICP definition was wrong, their value proposition wasn’t relevant enough, and their messaging didn’t resonate. The technology worked perfectly. It just accelerated a flawed strategy at scale.

That is why sequence matters, and why many companies get it wrong. They jump from strategy straight to technology and skip the critical middle layer:

1. Strategy. Defines who you serve, the value you bring, where you differentiate.

2. Process. Translates that strategy into revenue architecture and operating design.

3. Technology. Adds the multiplier that accelerates what is already working.

RevTech is the discipline that understands this sequence and executes it with rigor.

The Missing Role: RevTech Architects

Five years ago, “revenue technology” usually sat inside systems teams. The role was a builder: someone who administered tools and kept the machinery running. As stacks, integrations, and data complexity grew, that builder became an engineer. The emergence of GTM engineering is the visible proof.

Now a third role is becoming necessary: the architect.

Architects are not defined by what they build. They are defined by what they design. Design, in this context, is the translation layer. It turns strategy and intent into an implementable system that engineers can build and operators can run.

They understand what is possible technically, so they can work with engineers. They also understand what must be true commercially, so the system serves the business, not the other way around.

The parallel to construction is useful here. Builders lay bricks and run plumbing. Engineers solve structural complexity. Architects hold the whole design and connect purpose to structure.

Go-to-market is heading in the same direction. As AI automates more of the builder work, the bottleneck moves upstream. The scarce advantage becomes architecture.

The Bridge the Market Needs

The market needs practitioners who can hold both sides of the equation: revenue architecture on one side, and deep fluency in the modern technology landscape on the other. People who understand how growth is designed, not just executed, and who can work across data infrastructure, GTM orchestration, and applied AI.

RevTech sits at the bridge between these two worlds. The practitioners who operate here are not implementers. They are architects designing intentional systems that determine how fast and how efficiently a company can grow.

We are building the body of knowledge for this discipline through RevTech Insights, and will keep sharing what we see as the space evolves.

The Open Question

The open question is not whether this role is needed. It is who will claim it.

Over the past years, I’ve seen many RevOps teams build real maturity in scalable systems architecture. Yet most have been slow to keep pace with the new wave of GTM technology – staying deep in internal systems while the landscape around them shifts.

That gap – between operational maturity and the pace of tech innovation – is exactly why GTM engineering emerged. Yet in many cases, GTM engineering still lacks the architecture depth that RevOps built over a decade.

Now the question has four possible answers:

• Will RevOps keep pace with the new wave of GTM technology and become agile enough to architect what comes next?

• Will GTM engineering mature from execution focus into the architecture layer impacting the bigger picture?

• Will they converge, complementing each other’s strengths to close the gap together?

• Or will RevTech emerge as its own category, the way DevOps and RevOps did before it?

Regardless of which path takes hold, the direction is clear. As AI absorbs more of the execution work, the advantage shifts to those who can design.

The organizations that win will be the ones with someone who can translate strategy into architecture – and hold both business trade-offs and technical constraints in the same frame.