That memo has been in my head for two years, because it names the tension every operator is living through right now. You can have the best product in your category and still have nothing that protects you. And you can have a mediocre product sitting on top of something that competitors cannot touch, and print money for a decade.

The best tool I know for telling those two situations apart is Hamilton Helmer’s 7 Powers. So let me run it through the two worlds I actually work in: the go-to-market software stack, and healthcare software and services. Because when you do, the same answer falls out of both. The moat was never the product. It’s the system and the data around it. And AI is about to make that the only thing that matters.

Power = Benefit + Barrier

Helmer defines Power as the potential for persistent differential returns. Plain version: the ability to stay more profitable than your competitors for a long time, without them competing it away.

Every Power has two parts. A Benefit to you (lower cost, higher price, more value) and a Barrier that stops competitors from arbitraging that benefit away. The benefit is the easy part. Everybody can get a benefit. The barrier is the rare part, and the barrier is the whole game. If a rival can copy your advantage next quarter, you never had a moat. You had a good feature.

He also draws a line most people blur. Operational Excellence is table stakes, the stuff everyone in your category is grinding on to stay in the fight. Power is the durable condition underneath. Being good is not a moat. Being good in a way that others structurally cannot copy is.

The 7 Powers, fast:

1. Scale Economies. Cost per unit drops as you get bigger. Barrier: a challenger would have to match your share to match your cost, and that is prohibitively expensive.

2. Network Economies. The product gets more valuable as more people use it. Barrier: a new entrant faces the chicken-and-egg problem of an empty network.

3. Counter-Positioning. A newcomer adopts a superior business model that the incumbent won’t copy, because copying it would blow up the incumbent’s existing business. Barrier: the incumbent’s own collateral damage. The innovator’s dilemma, weaponized.

4. Switching Costs. Customers are locked in. Barrier: what a rival would have to spend to compensate a customer for the pain of leaving.

5. Branding. You charge more because people trust the name. Barrier: the long, uncertain years it takes to build that trust.

6. Cornered Resource. Preferential access to something coveted: talent, a patent, a dataset, a credential. Barrier: you own it and they don’t.

7. Process Power. Embedded organizational processes that deliver lower cost or a better product. Barrier: a long, opaque sequence nobody can shortcut, only live through.

Helmer even sequences them. Counter-Positioning and Cornered Resource tend to show up at a company’s origin. Scale, Network, and Switching Costs during the takeoff. Process Power and Branding at maturity. Hold onto that. It matters for who gets attacked next.

The GTM stack: only two moats, and neither is the workflow

Look at the modern revenue stack. CRM (Salesforce, HubSpot). Sales engagement (Outreach, Salesloft). Conversation intelligence (Gong). Data (ZoomInfo, Apollo). Forecasting and RevOps (Clari). Enablement (Highspot). Six neat categories, all describing themselves as mission-critical.

Run 7 Powers across them and the field separates fast.

The strongest Power belongs to the system of record, and only the system of record. That is Switching Costs, and it is enormous. Your CRM has data gravity, every workflow is wired through it, your whole team is trained on it, and a web of integrations hangs off it. Ripping it out is a year of pain nobody volunteers for. That is why Salesforce prints money. Not because the software is beloved. Because leaving is a project no one wants to sponsor.

The second real moat sits with the data players, and it looks like Cornered Resource plus Network. ZoomInfo and Apollo run contributory data co-ops, which is a genuine network effect: every customer makes the dataset better for the next one. And Gong’s actual moat was never the workflow app the reps click around in. It is the largest proprietary corpus of recorded sales conversations on earth. In an AI world, that corpus stops being a feature and becomes a cornered training-data resource.

Then there’s everything in the middle. Sales engagement. Enablement. The point solutions. Thin switching costs, no network effect, no cornered resource. Good products. Real benefit. No barrier. They are features sitting in the open, waiting to be absorbed.

Here is the AI wrinkle, and it is live right now, not a 2030 forecast. AI compresses this stack. Agents can rebuild a workflow cheaply, which means workflow-only tools are the most exposed things in all of B2B SaaS. If your entire company is “we move data from A to B and make it pretty,” an agent does that now. What survives the compression is the system of record and whoever sits on proprietary data. Everything in between gets squeezed.

Healthcare: the gravity well

Now the world I spend most of my time in. Healthcare software has a sun, and everything else is a planet.

The sun is the EMR. Epic, Oracle Health, athenahealth, the vertical urgent care EMRs. This is the deepest moat in all of software, and it is not close. Switching costs here are not “a hard project.” They are data migration plus clinician retraining plus recertification plus rebuilding every integration, all while carrying patient-safety risk at the moment of cutover. Nobody rips out the EMR on a Tuesday to try something they saw in a demo. And that switching-cost wall is reinforced on every side: regulatory certification (ONC), Network Economies as aggregated clinical data flows across the install base, Scale, and a cornered clinical dataset that is quietly becoming the training substrate for clinical AI. There is no soft flank.

Now watch what orbits it. Patient engagement, the scheduling and intake and communication layer (Phreesia, Weave, Luma), is the most exposed category in the well. Moderate-to-low switching costs. Usually a bolt-on. And its real problem is not internal, it is positional. It sits right next to a fortress that keeps expanding outward. The day the EMR ships native scheduling and intake, the standalone vendor doesn’t lose on features. It loses on the bundle. Its entire market can get absorbed by the thing it was orbiting, and no amount of product polish changes the physics.

Revenue cycle management (R1, Waystar, athenahealth’s RCM) is more defensible than people assume, and it’s where the Powers that looked weak in the GTM stack turn strong. Scale Economies from payer connections, clearinghouse relationships, labor pools, and automation spread across enormous claim volume. Switching Costs tied directly to cash flow, which is the one thing no health system will gamble on. And, rarest of all, real Process Power: the opaque, payer-specific machinery of actually getting a claim paid, built and tuned over years. You cannot buy that. You have to have lived it.

Teleradiology (vRad, Radiology Partners) runs on Cornered Resource. The asset is a network of radiologists licensed across many states and credentialed at many hospitals. Licensure times privileges is a combinatorial credentialing barrier that takes years and armies of administrators to assemble. Add Scale from follow-the-sun 24/7 coverage, subspecialty depth, and load balancing, and you get a moat that is genuinely hard to storm.

The two through-lines

Line one. In healthcare, the moat is proximity to two things: the system of record, and cash. The EMR owns the record, which is why it has the deepest switching costs in software and why it keeps eating adjacent categories for breakfast. RCM owns the cash, which buys it deep switching costs and real process power. Any layer that owns neither, patient engagement being the clearest case, is structurally weak no matter how good the product is. Position beats polish. It just does.

Line two, and this is the one to sit with. AI does not erase moats evenly. It erases labor.

Look at what’s actually under attack right now and the pattern is not random. RCM back offices. Radiology reads. GTM workflow execution. Every one of them is a category where the moat leans on human labor, and every one of them is getting counter-positioned by AI-native entrants whose whole pitch is “we do the labor with software.” That is textbook Counter-Positioning, the incumbents can’t fully follow because their P&L, their headcount, and their pricing are all built on the labor they’d have to cannibalize. For now, regulation, liability, and credentialing are holding parts of the line, especially in radiology. For now.

But flip it over. Every category that leans on data gravity, credentialing, regulation, and system-of-record lock-in doesn’t just survive AI. It gets stronger. Because AI turns accumulated proprietary data into the next moat. The EMR’s clinical dataset becomes the training substrate. Gong’s conversation corpus becomes the model. The data that took twenty years to accumulate compounds into an advantage that a well-funded challenger with a better UI cannot buy.

The one question

So the strategic question is the same one the AI labs are fighting about, and it’s the same one whether you run a healthcare software company, a GTM tool, or a services business:

Are you defending labor, or defending the system and the data?

One is a melting moat. You can feel good about it for a few more quarters while the water rises. The other compounds, quietly, while everyone stares at the model.

Pull up your own P&L this week and answer it honestly. Draw the line between the revenue you earn because a task is hard and expensive for a human to do, and the revenue you earn because you sit on data, a record, or a lock-in that a competitor structurally cannot replicate. That ratio is your real valuation. Not your ARR. Not your growth rate. That ratio.

Because the model was never the moat. The system was.

Harvard Business Review Analytic Services published a new report, “Agentic AI: Expectations, Readiness, Results,” sponsored by AWS.

It’s built on a July 2025 survey of 623 decision-makers from the HBR audience. They featured six expert voices in it. I’m one of them, quoted as Jonathan Moss, EVP of Revenue Growth and Operations at Experity, alongside people from Syngenta, Vanguard, and McAfee.

I’m proud of it. Getting a full-page pull quote in an HBR report is a milestone, and I’m not going to pretend it isn’t.

But I want to use this post to talk about the thing in the report that actually keeps me up at night, because it’s the part most people will skim right past.

Here’s the headline everyone will quote: 84% of respondents agree agentic AI will transform their business. 90% expect most organizations in their industry to be using it. Big numbers. The kind of numbers that make a board meeting feel exciting.

Now here’s the number nobody’s putting on a slide. Only 5% say their organization has well-defined success metrics for agentic AI. Five.

Sit with that gap for a second. Eighty-four percent are certain it’ll change everything. Five percent can tell you whether it’s working.

That’s not an AI problem. That’s a system problem. And it’s the difference between a company that’s actually building something and a company that bought a collection of apps with a budget line and called it a strategy.

The messy-data excuse, and why it’s an excuse

The most common thing I hear from executives is some version of “we can’t really do agentic AI yet, our data is a mess.” And look, they’re right that the data’s a mess. Everyone’s data is a mess. If we’re all honest about it, there isn’t a company on earth sitting on pristine, perfectly governed data waiting for the robots to show up.

But here’s where the logic breaks. People treat “fix all the data” as a prerequisite, a multiyear cleanup project that has to finish before the real work can start. So the project gets scoped, gets funded, gets a steering committee, and three years later you’ve got a slightly cleaner data warehouse and zero agents in production.

Here’s what I told HBR, and it’s the thing I’d put on the wall: you don’t have to embark on a multiyear project to get data right before you adopt agentic AI. Align on which data you actually need for the specific workflow the agent is doing. Find where that data lives. Make sure it’s good and consistent. Just start there.

That reframe is the whole game. The workflow tells you which data has to be good. Not all of it. The slice the agent touches.

This is why I think of agentic AI as a forcing mechanism. It’s the thing that finally makes you get serious about data quality, because now there’s a job on the line that depends on it. For years “good data” was a virtue nobody could schedule. Agentic AI gives it a deadline and a reason. You don’t boil the ocean. You clean the one cup of water the agent is about to drink from, and you go.

Directed autonomy, because the stakes are real

The other thing the report surfaces is readiness, and it’s brutal. Only 5% say their workforce is very prepared. The top barriers are a lack of talent and skills (48%) and no clear roadmap or strategy (46%). Everyone wants the outcome. Almost nobody has built the system that produces it.

In healthcare, where I spend my days, you can’t hand-wave this. The cost of an agent getting it wrong isn’t a bad email. So the governance question isn’t optional, it’s the design.

The model I use is what I call directed autonomy. It’s three tiers, and you place every workflow into one of them.

For routine workflows, agents run fully autonomous. Let them go.

For context-dependent workflows, it’s shared control. The agent and the human work the problem together.

For high-impact workflows, there’s always a human in the loop, with explicit escalation pathways built in.

A concrete one: we would never let agentic AI produce a medical diagnosis on its own. That’s not the job. The job is to put every relevant piece of patient information in front of the clinician so they make the correct diagnosis faster. The agent does the gathering. The human does the deciding. That’s the line, and it doesn’t move.

There’s a quieter payoff to all of this that I love. One of the oldest complaints in medicine is that people who trained to practice medicine have become typists,burning their time and energy on notes and admin. Orchestrate the workflows between the provider, the front desk, the biller, and the patient inside an agentic ecosystem, and you give that time back. The point of removing the admin burden was never the admin. It’s letting the human be fully present for the work that needs ahuman. Make the delivery of care more human, not less.

What I’d actually do Monday morning

If you read the report and feel the 84%-versus-5% gap in your own org, don’t start with a tool. Start with one question: which single workflow, if an agent ran it, would create value you could measure this quarter?

Pick that one. Define what good looks like before you build anything, so you’re not the 95% who can’t tell if it’s working. Clean only the data that workflow needs. Slot it into the right autonomy tier. Ship it. Measure it.

That’s the whole thing. Not a transformation. A workflow with a number attached to it. Do that three times and you’ve got a system. Skip it and you’ve got a press release.

The report is worth your time. I’d read it for the gap, not the hype.

Read the full HBR Analytic Services report here.

If you want the longer version of how I’d build this out layer by layer, the Revenue Nervous System breakdown, that’s what Sunday’s Under the Hood is for. See you there.

— J

WHAT YOU’LL LEARN IN THIS ARTICLE

• That GTM is a system, not a set of functions.

• AI amplifies whatever already exists, both the good and the bad.

• There is a right sequence for deploying AI. Most companies are doing it backward.

• Revenue Operations is a system discipline, not a departmental one.

• GTM ownership is a CEO decision.

Every CEO has an AI strategy. Almost none of them have answered the question of who actually owns the system it creates. Not who picks the vendor. Not who runs the pilot. Who owns the architecture: the data, the workflows, the agent layer, the feedback loops that increasingly determine whether your go-to-market actually works. AI will either absorb Revenue Operations (RevOps), automating away reporting, process documentation, and tool administration, or elevate it to the chief architect of the entire go-to-market system. There is no middle path.

The work RevOps does today is the work AI is best at eliminating.

The only version of the role that survives is one that fundamentally transforms. That transformation, and the ownership question it creates, is what this piece is about.

RevOps didn’t start as a strategic function. It started as CRM administration. Someone had to keep Salesforce from catching fire, so a team formed around data hygiene, report building, and making sure the dashboards said something useful before the Monday meeting. Then go-to-market got more complex. Marketing automation, multi-touch attribution, product-led growth signals, expansion revenue models, customer health scoring.

Each layer of complexity created a new process that needed an owner, and RevOps absorbed it. The CRM administrator became the process owner. The process owner became the system owner. The scope kept expanding as the go-to-market model became harder to operate. This is the pattern, not the exception. RevOps grows because go-to-market complexity grows. AI is the largest complexity jump yet. Which means RevOps is either about to have its biggest expansion, or its last.

The System No Longer Runs on People

Most executive teams have not fully internalized what their go-to-market has become. It is no longer a people-and-process operation. It is a system. And it is becoming a system that humans can no longer operate by hand. A modern go-to-market motion requires real-time signal detection across hundreds of accounts. Dynamic lead scoring that adapts to behavioral patterns. Automated workflow routing based on segment, intent, lifecycle stage, and deal velocity. Cross-functional handoffs that need to happen in hours, not days. Customer health models that synthesize product usage, support tickets, NPS data, and billing patterns into a single score that triggers the right action at the right time.

The problem is not the number of tools. It is the number of potential connections between them. The average company runs 106 SaaS applications as of 2024. In a stack that size, the number of possible pairwise integration points grows quadratically. Add one tool, and you do not add one unit of complexity. You add 106 potential interconnections. The management infrastructure most companies have built is linear. That gap is where go-to-market systems break. Not just at the tool level. At the interaction layer between them.

Figure 1. Number of tools vs. integration complexity

With the advent of AI, most executives believe they are on a path to consolidation. What we experience in practice suggests otherwise. Two things are happening simultaneously in most companies. RevOps is using AI to consolidate in one department, while another department adopts eight new AI tools without telling anyone. The result is complexity that quietly grows at the interaction layer as AI tools are added outside any governance structure. No single team has visibility. No dashboard tracks the whole. That is the gap where RevOps lives. Not in the tools. In the system that governs their interactions.

No human team, regardless of talent, can manage that interaction layer manually and keep pace with it. Most signals get missed. Most handoffs happen late. Most health scores trigger action after the moment has passed. AI is not enabling this transition. It is forcing it. The companies adopting AI-driven go-to-market motions are setting a pace that manually operated teams cannot match. This is not a theoretical future state. It is a competitive reality already playing out in pipeline generation, deal velocity, and retention economics. Someone has to architect and orchestrate this system. Someone has to be the translation layer between business objectives and machine execution. The question is who.

AI Does Not Fix What Is Broken. It Scales It.

AI is a multiplier, not a corrector. It amplifies whatever it touches. Clean processes, agreed-upon definitions, and healthy data become dramatically faster and more effective. Broken processes, inconsistent definitions, and messy data become dramatically worse, at scale.

An AI layer dropped onto a broken foundation produces outputs that look authoritative and say nothing accurate. The AI is not malfunctioning. It is doing exactly what it was designed to do: synthesizing the inputs it receives. When those inputs are garbage, the outputs are confident garbage.

I watch companies make this mistake over and over. They skip straight to the application because it has a compelling demo and a visible ROI story. What they are actually doing is betting on the short term — starting at the end of a sequence that has to be earned from the beginning.

Four stages have to be in place to enable AI to deliver its best work: data, process, system, and application. The companies playing the long game move through that sequence deliberately. They do not perfect each stage before connecting to the next. They get each stage connected quickly enough that the system can start teaching them what needs to improve. Learning happens across connections, not in any single stage.

Figure 2. The sequence AI requires to deliver its best work

The companies betting on the short term do the opposite. They skip to the application, patch backward when it fails, and wonder why the gains never compound. A disconnected system cannot learn. A system built right-to-left will always need fixing left-to-right. Playing the long game means building in the right order. AI scales what works. Betting on the short term means skipping the sequence and counting on AI to figure out what it needs to scale. It usually scales the wrong thing.

The Role That Has to Exist

Every major platform shift creates a new executive role. Not an upgraded version of what existed before. Something genuinely new. The CTO emerged when technology became a competitive differentiator. The CMO emerged when marketing became a system. The CRO emerged when go-to-market became too complex for sales leadership alone. Each time, a function that had been treated as operational suddenly became strategic. The market created a new seat at the table to reflect that.

AI is creating a new executive role that most do not yet have a name for.

We have started calling it the VP of Growth. Not a rebranded Head of Demand Generation. Not a marketing leader with a new title. A dedicated revenue operations role, someone who owns the growth model, the data architecture, the system, and the AI layer that connects functional teams around shared outcomes. This is the role Revenue Operations must grow into. Not exclusively, but the function that has spent a decade sitting across acquisition, conversion, and expansion is well-positioned to leap.

The market is already pricing it accordingly. LinkedIn shows 6,000 openings as of April 2026, with a base compensation range of $250,000–$350,000 and total compensation packages up to $550,000. That is not a coincidence. That is a market recognizing a function for the first time at its actual strategic value. Here is the provocative part. The Chief Customer Officer was created to unify customer-facing functions under one executive.

But that unification was organizational, not architectural. It connected reporting lines, not systems. The VP of Growth does what the CCO was supposed to do, but with actual system authority. A new executive has entered the room.

Go-to-Market as a Product

Once go-to-market is understood as a system, the organizational implications follow directly. A system needs a product organization, not a support function.

The best RevOps teams are already moving in this direction. Not by design. By necessity. They form cross-functional pods: a data engineer, a workflow automation specialist, and a go-to-market operator with deep domain knowledge. They run sprint cycles. They maintain backlogs. They do release management. They have arrived at product development vocabulary because the work demands it.

The team that owns the GTM system as a product is the team that owns growth.

The shift is to formalize what is already emerging. RevOps stops being a centralized service desk that takes tickets from Sales and Marketing. It becomes an embedded systems organization that builds and maintains the go-to-market architecture. The same transition product engineering made, from building what the business asks for to owning the product, is the transition RevOps is now positioned to make.

Figure 3. Revenue Operations as a system — responsibility by ring

The CEO sits at the center, not because they operate the system but because they make the ownership decision that gives everyone else the authority to do their job. The VP of Growth owns the architecture. The Data Architect and GTM Engineer own the infrastructure. The AI Agent Layer is the interface of the go-to-market product. It sits at the edge of the infrastructure, serving as the translation layer that protects the functional teams from the underlying complexity of the stack. The functional teams operate in the outer ring. They are not subordinate to Revenue Operations. They are the generators the system is built to serve.

The ownership question is not about reporting lines. It is about the gap between responsibility and governance. Revenue Operations carries the responsibility. They feel it when the system breaks. But without governance authority, agreed-upon rules, shared definitions, and system-level accountability, they can diagnose the problem but cannot fix the structure that keeps producing it. That gap belongs on the CEO’s desk.

The Capability Gap Is Real

This transition will not happen by reorganizing an org chart. It requires a genuine capability upgrade and an honest assessment of who can make the leap. The divide is real. If not uniform. Some RevOps professionals are already trending toward systems thinking and AI fluency. They are building automations, experimenting with AI tooling, and thinking in terms of architecture rather than administration. They will evolve into the systems architects this moment demands. Others are deeply skilled at the current jobs, reporting, tool management, and process documentation, but have not yet built the capabilities required for what comes next. The gap is not about intelligence or work ethic. It is about capability. And capability cannot be changed by motivation alone.

The RevOps role is not being eliminated. It is being elevated.

Elevation has a talent requirement that most companies have not yet considered. For the CEO, this resolves into three decisions. First, assess honestly which RevOps people are trending toward the system architect role, and what investment accelerates that trajectory. Second, build specific capabilities, data architecture, workflow design, and AI literacy, not generic AI awareness training. Third, accept that some of this capability will have to come from outside the company and cannot be developed from within.

The GTM Ownership Decision

Everything in this argument leads back to the question it opened with: “Who owns the GTM system?” And in most companies, the honest answer remains: nobody owns it. Pieces are owned by Marketing. Pieces by Sales. Pieces by IT. Pieces by nobody. The system as a whole is an orphan. You can feel it in the broken handoffs, the conflicting metrics, the tools that don’t talk to each other, the AI pilot that worked in the demo but failed in production.

The solution is not talent. It is governance.

If AI is going to become the execution layer of your go-to-market, and the pace of change makes that a question of when, not if, then system ownership becomes an executive-level decision. It determines org design, talent strategy, competitive positioning, and whether AI investments compound into structural advantage or scatter into point solutions that nobody maintains. This is not a tooling decision. It is not a department decision. It is the gap between having AI capabilities and having someone accountable for the system in which those capabilities live. That problem belongs on the CEO’s desk. So, who owns it?

A team burns a quarter running a demand gen program that produces pipeline the sales org cannot close. Another team spends six months building an expansion motion on top of a renewal base that is leaking. A third team doubles SDR capacity to fix a number that was never a capacity problem to begin with. The spend is real. The activity is real. The compounding is zero, because the organization was optimizing against the wrong binding constraint.

I have watched this at multiple companies now, and the pattern is the same every time. Leadership can name a handful of things that feel broken. Leadership cannot name the one thing that is actually binding the system. And in the absence of a named binding constraint, every function optimizes locally, the plans look reasonable on their own, and the quarter gets spent chasing whichever symptom made the loudest noise in the last board prep.

Pillar 5 named the seat that owns this. Deep Dive #5 is about what the person in that seat actually does every week. Forever.

The answer is not strategy. It is not planning. It is not forecasting. It is constraint diagnosis as a continuous practice. At every point in a growing company, the growth system is bottlenecked somewhere, and that somewhere moves quarter over quarter as the business grows out of one bottleneck into the next. The VP of Growth’s job is to continuously diagnose where the constraint is, name it precisely, and align the organization around resolving it. That is the operating loop of the role. It is the closest thing to a superpower a scaling company has, because most companies are still guessing, and the guesses compound.

The three places a growth system gets stuck

The reference job description Growth Institute has been circulating is uncommonly specific on this point. At any given moment, a B2B growth system is constrained in one of three places.

Capacity. Not enough pipeline to hit the number. The motion that creates qualified demand, whether outbound, inbound, partner, or product-led, is producing under what the downstream close rate and cycle time would require. The sales team has the skill to close what they see. They are not seeing enough of it. Capacity constraints look like reps with open calendars, AEs covering too many accounts to run a decent process on any of them, and a forecast where the math only works if conversion rates improve to levels the historical data has never touched. On a Monday, the symptom is a pipeline coverage ratio sliding below 3x while nobody wants to say it out loud.

Conversion. Enough pipeline arrives. The pipeline does not close at the rate it should. Something about how the team qualifies, runs discovery, handles proof, or structures the deal is broken. The cycle is getting longer, the win rate is sliding, and every no-decision post-mortem identifies a different root cause. Conversion constraints look like pipeline that looks healthy in the CRM and decays through the funnel in ways the forecasting model did not predict. On a Monday, the symptom is a sales leader walking into the forecast call with the same stalled opportunities they brought last week, re-categorized under different probability weights.

Retention. The logos land. The logos do not stay, or they stay and do not expand. Gross retention is below plan, net retention is not compounding, and the cohorts behind the current quarter’s headline revenue are quietly eroding. Retention constraints look like a renewal forecast that came in at 88% when the plan was 94%, an expansion pipeline that depends on three marquee accounts closing in Q4, and a product usage curve that peaks at day 45 and never reaccelerates. On a Monday, the symptom is a CS leader flagging the same five at-risk accounts they flagged last quarter, with the same intervention plan, and the same outcome.

Three places. One of them is binding, at any given point, and the diagnosis matters because the response is completely different.

Here is the mistake I have watched in every room where the diagnosis has not been done. The team says “we need more pipeline” when the actual constraint is conversion. They are not lying. They are reasoning locally. Marketing sees their pipeline number and takes it as a directive to build more. Sales sees their miss and assumes the top of the funnel was the issue. Nobody looks at the throughput from stage to stage and asks whether the problem is volume or efficiency. A capacity investment on a conversion problem is the most expensive kind of wrong answer, because it produces motion, the motion produces more pipeline, the pipeline compounds the conversion drag, and two quarters later the system is worse, not better. With a confident tone. With a clean deck. I have seen it happen four times in the last three years.

The first job of the VP of Growth is to stop that.

The constraint moves. That is not failure.

This is the part most companies miss.

Solve a capacity constraint and conversion becomes the new bottleneck. Solve conversion and retention becomes the bottleneck. Solve retention and you are probably back at capacity for the next segment you are trying to enter. The constraint does not sit still. The system does not stabilize at one binding constraint that you optimize forever.

This is not a sign that the work was unsuccessful. It is the nature of scaling systems. Removing a binding constraint reveals the next one, which was not binding yesterday because the first one was absorbing all the visible pain. Companies that do not understand this spend a year optimizing the Q2 constraint into Q3 and Q4, missing the fact that the constraint moved in July and they are now grinding on something that used to be broken and no longer is.

The VP of Growth is the person who sees the constraint shift six to eight weeks before anyone else notices and redirects the organization before it spends another quarter optimizing what was true last quarter. That is an unreasonable thing to ask of any existing functional leader, because every functional leader is compensated against their motion. The CMO is optimized for pipeline generation. The CRO is optimized for bookings. The head of CS is optimized for retention. None of them are structurally positioned to walk into a QBR and say “the binding constraint has moved from capacity to conversion, so the plan I submitted in January is now the wrong plan for the second half.” That sentence has to come from somewhere. The VP of Growth is the only seat built to say it.

Read more

Pillar 4 made the case that the GTM system in most companies is an orphan, and that the ring model fixes it. The question that comes back to me every time from RevOps leaders and CEOs who read that piece is the same question, almost word for word. Okay, what actually changes on Monday morning? Reporting lines, titles, budget authority, who does what. And what breaks first when we start.

This piece is the honest answer. Not a 90-day playbook, that is Tier 3. The strategic picture of what happens inside a real org when the ring model gets adopted, which stress points surface predictably, and which of them are evidence the transition is working versus evidence it is failing.

One thing up front. Transitions break things. That is not a warning. It is a roadmap. The things that break first are predictable, and if you know where to look you can tell whether what you are watching is the system shedding old architecture or the system rejecting the transplant. Different responses in each case.

The ring model, one paragraph

The CEO sits at the center. Not because they operate the system, but because the ownership decision lives there and nowhere else. The VP of Growth owns the architecture: the growth model, the data stack, the constraint diagnosis, the AI layer that connects functional teams. The Data Architect and GTM Engineer own the infrastructure underneath. The AI agent layer sits at the edge of the infrastructure as the interface of the GTM product, a translation layer that protects functional teams from the complexity of the stack. Marketing, Sales, and CS operate in the outer ring. They are not subordinate to the VP of Growth. They are the generators the system is built to serve. Pillar 4 walked this. This piece is about the Monday after the org chart changes.

Five stress points the transition surfaces, in order

I have watched different versions of this transition at multiple companies now, and the same five things break first, in roughly the same order. I am going to name them, because naming makes them manageable. When a stress point is named, the CEO stops reading it as a failure and starts reading it as a stage.

Stress point 1. Reporting line conflict

The new VP of Growth reports to the CEO. So does the CRO. So does the CMO. So does the CCO, if you have one. Within two weeks, usually in the first forecast review, the governance overlap surfaces. The VP of Growth looks at the system-level data and says the current constraint is retention, not acquisition. The CMO, who has just gotten budget approval to double down on demand gen, hears that as an attack on their plan. The CRO, who was told this year’s number depended on pipeline volume, hears it as a contradiction of the strategy they committed to at the QBR.

On a Tuesday, the CEO now has four people in a room disagreeing in front of them, and all four of them technically report to the CEO. This is where most transitions get stuck. The instinct is to smooth it over, to let everyone defend their piece, to adjourn until people have had time to cool off. That instinct is wrong, and it is the thing that kills the transition more often than any other.

The conflict is not a failure mode. It is exactly the conversation the new role was designed to force. Before the VP of Growth seat existed, that conversation never happened, which is why the system was an orphan. The CEO’s job in that meeting is not to resolve it back to the old equilibrium. The job is to hold the room long enough that a system-level answer, not a functional-level compromise, gets named.

If you are three months in and the reporting line tensions have disappeared, the transition is not working. The new role has been quietly defanged. The old functional leaders are still running the strategy. The VP of Growth has become another middle layer shipping reports nobody acts on.

The remaining four stress points, the layer that breaks in month three, the three-layer org model that finally makes the whole structure legible, the cross-functional pod that ships the GTM system on a release cadence, the capability divide nobody wants to name out loud, and the five questions you can run on your own org this week are the rest of this piece.

Read more

Loop Gain is not a metaphor. It is not a marketing concept. It is a ratio, and if your architecture is correct, you can calculate it on a Tuesday and recalculate it next Tuesday and watch it move. If your architecture is incorrect, you cannot calculate it at all, and what you have instead is a slide that says “we are compounding” because somebody wrote that sentence into the board deck two quarters ago and nobody has challenged it since.

Deep Dive #1 made the case that the feedback-loop moat behaves differently from every historical moat because it compounds instead of depreciating. This piece is the operator answer to the obvious next question: how do you measure compounding, as a number, on an ongoing basis, and how do you build the thing underneath it so the number actually means something.

I am going to try to make the technical content concrete. It has been over-gated long enough. Consultants have built careers on keeping this fuzzy. It is not that fuzzy.

What Loop Gain actually is

Jacco van der Kooij’s formulation is the cleanest I have seen. Loop Gain is the ratio of productive output that feeds back as input per cycle.

Break that apart.

Output is what your system produces in a cycle. A closed deal. A renewed contract. A resolved ticket. A campaign that ran. A submission approved. Something observable, with a result attached.

Input is what feeds the next cycle. Not the raw effort. The learning. The updated model, the refreshed scoring, the retrained agent, the playbook that now includes what last week taught you. Input is the part of the output that gets captured and becomes the starting condition for the next run.

A cycle is whatever the natural unit of repetition is for the workflow you are measuring. Outbound sequences run on a weekly cadence. Support tickets run on an hourly one. Pipeline reviews run on a two-week one. You do not have to normalize across the business. You do have to name the cycle for the workflow, because without a cycle there is no ratio.

Loop Gain greater than one means the system is compounding. Output exceeds input. Each cycle strengthens the next. The moat widens without defense.

Loop Gain less than one means the system is decaying. Output underperforms what the inputs would predict. You are spending more than you are getting back. No headcount addition fixes it. No budget increase fixes it. No CRO hire fixes it. The mechanics are mechanical. A decaying loop compounded by more resources is a decaying loop running at higher volume.

That last point is the one most CEOs flinch at. The instinct when growth stalls is to add. Add sellers, add marketers, add a head of demand gen. If the underlying Loop Gain is below one, you are paying linearly for output that decays geometrically. I have seen this at multiple companies. The board meeting where somebody says “we just need more pipeline” is almost always a meeting where nobody at the table can tell you the Loop Gain of the pipeline motion.

The ratio matters more than the absolute numbers. A small system with Loop Gain at 1.3 beats a large system with Loop Gain at 0.8 over any meaningful time horizon. Compounding is not about scale at t=0. It is about direction at every t thereafter.

Why most companies cannot measure it

A ratio requires three things. What feeds in. What comes out. What cycle you are measuring. Those are not abstract. Those are three pieces of infrastructure that either exist or do not.

Most companies cannot answer any of the three for their own growth system.

Feeds in: marketing counts MQLs, sales counts SQLs, CS counts NPS, product counts DAU, and nobody agrees on how the motion starts or where the boundaries are. There are four definitions of “lead” in the room, and three of them are hidden inside departmental spreadsheets that do not talk to each other.

Comes out: every team has its own output metric, tied to its own comp plan, defined at whatever granularity made it easiest to hit the number last year. The output of the sales motion is not the input to the CS motion in any automated sense. A human copies, pastes, reformats, summarizes. Signal leaks at every hand-off.

Cycle: the planning cycle is quarterly. The forecast cycle is monthly. The pipeline cycle is weekly. The agent cycle is real-time. Nobody has named which cycle Loop Gain is supposed to measure, so the number is unmeasurable by default.

That is the architecture problem showing up in the metric layer. You cannot measure what you have not built. The inability to cite Loop Gain is not a reporting failure. It is the stack revealing itself. If somebody on your team tells you they cannot calculate Loop Gain, they are not making excuses. They are diagnosing the real problem.

The five-layer stack that makes the number real, the three ways it quietly hollows out, what Loop Gain above one looks like on an actual Tuesday morning, a build I shipped one level deeper, and the five-question diagnostic you can run at your desk this week are the rest of this piece.

Read more

I will make this concrete. Pull your calendar from last week and color-code every block into four buckets. Green for Aim, the work of sharpening where the company is going. Blue for Army, the work of developing the people who will take it there. Orange for Assets, the work of deciding what gets capital, attention, and focus next. Gray for everything else. Do it honestly. Count the hours.

Most CEOs I run this exercise with spend over seventy percent of last week on gray. That gray bucket is not a time management problem. It is the architecture problem, measured in hours on a calendar. Every block of gray is work the system should be doing. The system is not doing it because the system does not exist yet, and the CEO is covering for the gap. Their reward for building a company is a full calendar of work the company should be able to run without them.

The calendar is the test. Show me where Aim, Army, and Assets live in your calendar, and I will tell you whether you are operating in Architect Mode or just talking about it.

Aim in practice

Aim work is not an offsite. It is not the annual planning ritual that eats three days in January and produces a slide deck the org ignores by March. Aim, done right, is a continuous practice that takes about four hours of real CEO time every week. Not in one block. Distributed.

Here is what Aim looks like on a Tuesday. You sit down at nine. The intelligence layer has already surfaced the five market signals from the last seven days that are most relevant to your thesis. Not a digest of fifty headlines. Five. Filtered against what you are actually trying to build. A competitor hire. A shift in customer behavior in your top segment. A pricing experiment that landed differently than the model predicted. A regulatory move. A loss you took against a specific alternative. You read each one with a specific question in mind: does this sharpen the thesis, weaken it, or tell me my thesis needs a scenario I have not run yet?

You spend the next ninety minutes on one of those. You run it against the model. You pressure-test your assumption about where the market is going against what the signal is actually saying. You get three defensible counter-arguments back. You read them. Some of them are better than the argument in your head. You either update or you do not, but you do it explicitly.

Then you make a call. That is the part that does not automate. The model will give you a rank-ordered list of options. It will size them. It will flag the risks. It will not tell you which hill is worth bleeding for. That is yours. It will always be yours.

One concrete Aim decision from this quarter, pattern version. I have seen this at multiple companies now. A CEO runs their thesis through the scenario layer and gets back a very plausible case for moving up-market into enterprise. The analysis is clean. The TAM is bigger. The ACVs are larger. The gross margin profile is better. Every number on the page says do it. The CEO does it anyway, in the other direction. They double down on mid-market, not because the enterprise analysis is wrong, but because they know something the model does not. They know the distribution motion they have actually built. They know which of their people would be energized by that move and which would quietly leave. They know what the brand can credibly carry. The analysis is input. The call is theirs.

That is four hours well spent on a Tuesday. Four hours of Aim beats a twelve-hour planning offsite, because it happens while the signal is fresh instead of two quarters later when the data has already moved.

Army in practice

Army work does not live in the quarterly review cycle. It runs continuously, and in Architect Mode it runs through the system, not through a process.

On a Thursday morning, a CEO in Architect Mode should be able to open a single view and see which of their leaders are trending up, which are stalling, which are compounding institutional knowledge into the system, and which are treating AI as a threat rather than a multiplier. Not performance scores. Behavior patterns. Did this leader ship a workflow into the system this month that will keep running after they leave for vacation? Did they build something the rest of the org is now standing on? Or did they ship another dashboard nobody opens.

The signals that matter are specific. Who is pulling work out of the gray bucket on their team’s calendar and putting it in a system. Who is pushing work back into the gray bucket by approving things that could be governed by policy. Who is prompting well and feeding corrections back into the agents they deploy. Who is typing the same email for the ninth time and calling it their job. Who is hiring in their own image because the team feels safer that way. Who is hiring missionaries who are going to stretch the bar.

The middle manager question is the sharpest one, and it is the one most CEOs skip. In Architect Mode, a middle manager is not an information relay node. If they are still operating as one, you have an architecture problem on their team specifically. The middle manager in Architect Mode is a micro-architect. Their job is to take every frontline signal, every customer friction, every pattern their people see that the system has not yet captured, and feed it back into the architecture so the rest of the org gets smarter. The best ones are actively compounding the moat at the team level. The worst ones are quietly starving it, usually because their identity was built around being the person who held the answers.

The Thursday conversation that follows from the view is the one CEOs most often avoid. It is the honest one. “You are an excellent leader by the standards that used to define the job. By the standards of the job we are running now, here is what I am watching for, and here is what has to change in the next ninety days.” That conversation, run with directness and genuine care for the person, is the single highest-compounding hour on a CEO’s week. The cost of skipping it is paid every day after in the form of a team that is quietly working around a leader who should have been given the chance to adjust.

I could be wrong about the ninety-day window. I am not wrong that the conversation has to happen. I have seen companies lose twelve to eighteen months by postponing it.

Assets in practice

The scarce resource in Architect Mode is not information. It is not capital in most venture-backed companies. It is the attention of your best people, and the focus of the organization on a small enough set of bets that any of them actually get leverage.

Friday is Assets day. It does not have to be Friday. It does have to be once a week, not once a quarter. Once a quarter is when most companies review their bets, and once a quarter is also why most companies spread their best people across eight initiatives and get compounding from none of them. A weekly Assets rhythm catches drift before it becomes debt.

Here is what a good Assets hour looks like. The analysis layer surfaces the week’s movement on every live initiative. Pipeline, adoption, Loop Gain (how fast it is learning) on the ones that have a learning loop, cost per unit of progress on the ones that do not yet. You read it through a single filter: which of these is deserving more of our best people, and which is deserving less. You are not asking whether any of them are good. Most of them are plausibly good. You are asking which three are asymmetric.

Then you use the Pillar 2 distinction, operationally. Uncertain versus unclear. Uncertain is honest. I have a hypothesis on initiative four, I placed the bet eight weeks ago, the signal is mixed but trending right, I will update when the data says to. Unclear is an organizational tax. I am not actually sure which of these five things we are prioritizing, which means every one of my reports is guessing, which means the best people are hedging their effort across bets that will not compound, which means we are funding motion and calling it momentum.

The discipline of Assets work is saying no to plausible opportunities, not obviously bad ones. The analysis will always make three things look reasonable. Four will have credible internal champions. The Friday afternoon decision, made explicitly, with the reason attached, and transmitted clearly downstream on Monday, is the difference between a company that compounds and a company that experiments. Experimentation is not the moat. Compounding is.

I have seen this pattern at multiple companies. The best people are spread across eight initiatives, each one getting fifteen percent of their attention, each one producing fifteen percent of what they could produce. Contract it to three. Watch what fifty percent attention does to the curve. That move almost never happens in the quarterly review. It happens on a Friday when a CEO decides they can live with five disappointed VPs for the sake of the people who are actually going to build the moat.

Read more

That stopped being true about two years ago.

The moat the Architect Mode company produces is structurally different. It does not depreciate. It compounds. That is not a marketing claim. It is a mechanical property of how learning systems behave once they are wired correctly, and understanding the mechanics is the difference between CEOs who are actually building the new moat and CEOs who are funding twelve AI pilots and hoping one of them turns into a strategy.

The moat taxonomy had a half-life

Walk the history.

Coca-Cola’s brand moat took a century to build and is now policed by a marketing budget that would run a mid-sized country. It still works. It also has to be reinforced every quarter, because attention has fragmented into 400 channels and a brand that does not show up dies on a timeline measured in years, not decades. Brand depreciates with neglect. The rate has accelerated.

Walmart’s distribution moat was physical. Real estate, trucks, warehouses, a supply chain no competitor could match. Amazon did not out-Walmart Walmart. They built a different distribution model on top of the internet and routed around the whole thing. Distribution depreciates when the underlying channel shifts.

Oracle’s switching-cost moat was architectural. Once the database was installed, the business logic got written on top of it, and ripping it out meant rebuilding eight years of custom integrations. Postgres, Snowflake, and a decade of API-first tooling did not kill Oracle. They made switching tolerable enough that the moat stopped acting as one. Switching costs depreciate when the ecosystem around them standardizes.

Facebook’s network effect moat was the canonical one. More users means more value means more users. Unbreakable, until it turned out you could break it by building a network that targeted one use case, one demographic, one format, and pulled users off the mothership one thin slice at a time. Network effects depreciate when someone unbundles them.

Pharma’s patent moat expires on a legal calendar. Amazon’s scale-economy moat requires billions of dollars in capex to defend every year. Every moat in the taxonomy has a half-life, and that half-life has been shortening for two decades.

This is the part most CEOs agree with and then promptly forget. They build the next AI strategy on top of the same depreciating-moat logic they were raised on. Pick a category. Buy a tool. Lock in a vendor. Call it differentiation. That is Manager Mode with a better budget line. The moat erodes the moment somebody shows up with a marginally better tool, which in AI is about every nine weeks.

Why feedback loops are categorically different

A feedback-loop moat does not behave like the others. It does not require defense. It does not require reinforcement. It does not require capex to hold its ground. The mechanism is different in kind.

Every interaction trains the system. The system improves without human intervention. The moat widens with each transaction the company runs. The competitor landing in your market tomorrow faces the same learning curve you faced on day one, while your system has been compounding on that problem for eighteen months. That is not a metaphor. It is a property of how learning systems behave once they are connected to a data loop that actually closes.

The closing is the part most companies get wrong. A dashboard is not a feedback loop. A weekly review meeting is not a feedback loop. A churn model you rebuild quarterly is not a feedback loop. A feedback loop exists when the output of one cycle automatically becomes the input of the next without a human stopping to decide whether to carry the signal forward. When that loop is closed, the system compounds. When the loop is open, the system does not learn. It just produces more reports.

I could be wrong about how long the first-mover window lasts. I am not wrong about the mechanics. The curve is always the same shape. Flat for a while. Then inflection. Then a gap between you and everyone else that widens instead of closes.

What the loop looks like in three industries

These are not case studies. They are the same mechanism wearing three different costumes, so you can recognize it in your own business.

Picture a GovTech firm that stops treating regulatory rejections as bad news and starts treating them as training data. Every rejection, the specific language that failed, the exact clause that triggered pushback, the reviewer who rejected the submission and on what grounds, all of it feeds back into a model. Not into a spreadsheet. Not into a shared drive anyone might read. Into a system that processes every rejection and adjusts the next submission automatically. Eighteen months in, approval rates climb and cycle times compress. The system holds things about that specific regulatory environment that no single human could carry in their head. A competitor landing next quarter meets the bureaucracy this firm met a year and a half ago. The gap does not shrink. It widens every week a new rejection comes in and gets absorbed.

Take a customer support team that stops writing macros and builds a response intelligence system. Every ticket, every resolution, every satisfaction score, every escalation pattern feeds back. Ticket volume rises. The hiring curve stays flat. CSAT improves on a trend line headcount no longer explains. The institutional knowledge that used to live in the heads of the three best agents, the ones who might quit on a Tuesday and take eight years of customer context with them, now lives in the system. Churn among the senior staff stops being an existential risk. That is a structural change, not a morale initiative.

Or a marketing agency that feeds every campaign, every brief, every performance result into a central creative model. The result is not what you would expect. The senior strategists do not get displaced. The juniors get elevated. Junior account managers produce work that used to require a senior strategist to even draft, because the system does the pattern-matching the senior used to do in their head. The gap is not because the juniors got smarter. It is because they are standing on a system that got smarter, and the senior strategists now spend their time on the problems the system cannot touch yet. The agency’s win rate on new business climbs. Its cost to produce a pitch drops by half. Its competitors, still running the old senior-juniors-and-a-brief model, are pitching against a system instead of a team.

Three different industries. Three different workflows. Same mechanical property. Every interaction trains the system. The system improves without human intervention. The moat widens.

That is the diagnosis. The number that proves it, the four things that quietly kill it, the confession of the worst report my own team ever shipped, and the five-question test you can run at your desk this week are the rest of this piece.

Read more

Not 106 features. Not 106 integrations. 106 separate tools, each with its own data model, its own vendor, its own update cycle, and its own team of people who decided to adopt it without asking the person three desks over if it would play nicely with what they already had.

Now here’s where it gets uncomfortable. In a stack that size, the number of possible integration points doesn’t grow linearly. It grows quadratically. Add one tool and you don’t add one unit of complexity -- you add 106 potential new interconnections. Your management infrastructure is still linear. Your calendar still has 24 hours in it. Your RevOps team still has a headcount it can fill.

That gap -- between quadratic complexity and linear management -- is where GTM systems break. Not at the tool level. At the interaction layer between them.

And AI is not closing that gap. In most companies, it’s widening it.

GTM Is Not a People-and-Process Problem Anymore

I’ve spent 21 years building GTM systems at companies across health tech, real estate, clean energy, education, logistics. At every stage of that career, the dominant assumption was the same: if you hire the right people, define the right process, and hold people accountable to the right metrics, revenue follows.

That assumption worked -- until it didn’t.

Go-to-market today requires real-time signal detection across hundreds of accounts simultaneously. It requires dynamic lead scoring that adapts to behavioral patterns in hours, not quarters. It requires cross-functional handoffs that happen in hours, not weeks. It requires customer health models that synthesize product usage, support tickets, NPS scores, and billing data into one score, routed to the right person at the right moment.

No team of humans can run that by hand. Not because they aren’t talented -- because the problem has outgrown the operating model.

GTM is a system. Not a collection of people with aligned OKRs. Not a set of functions with shared reporting. A system -- with inputs, processes, feedback loops, and compounding outputs. And the companies treating it like a people-and-process operation are going to fall behind companies that treat it like an engineering problem. Not eventually. Already.

The harder part: most companies don’t have a system. They have a collection of functions that happen to share a CRM.

What AI Is Actually Doing to This Problem

Here’s where the complexity problem gets a second layer. While RevOps teams are consolidating tooling and trying to get governance in place, another department just adopted eight new AI tools without telling anyone. Marketing is running three different AI content workflows. Sales is using AI for prospecting, for call summarization, for follow-up sequencing. CS adopted something for churn prediction. Product has its own data pipeline.

None of it connects. No one reviewed it. No one has visibility into the interaction layer between any of it.

Agent sprawl is the new SaaS tool sprawl, at 10x the speed. A 200-person company with 3 employees each building two AI agents is suddenly running 600 disconnected systems. No procurement. No governance. No one who owns how the outputs from one agent become the inputs to another.

This is not a hypothetical scenario. It’s what’s happening inside GTM organizations right now.

And here is the thing about AI that everyone needs to understand before they deploy another one of these tools: AI is a multiplier, not a corrector. It amplifies whatever it touches. Clean processes plus AI delivers dramatically faster, dramatically more effective output. Broken processes plus AI delivers dramatically worse output, at scale.

An AI layer dropped onto a broken foundation produces outputs that look authoritative and say nothing accurate. The AI isn’t malfunctioning -- it’s doing exactly what it was designed to do: synthesizing the inputs it receives. When those inputs are garbage, the outputs are confident garbage.

Jacco van der Kooij at Winning by Design put it precisely: “A wrong answer you can catch. A hallucinated strategy looks right.”

That’s the failure mode no one is talking about clearly enough. A wrong forecast gets caught in the next pipeline review. A hallucinated growth strategy -- one that looks rigorous, cites internal data, passes the sniff test of a board presentation -- runs for quarters before anyone traces the problem to its source.

The Right Sequence (Most Companies Are Doing It Backward)

There is a right order for deploying AI in GTM. Four stages have to be in place for AI to deliver its best work:

Data -- Process -- System -- Application

Most companies start at Application. There’s a compelling demo. There’s a visible ROI story. The vendor makes it look easy. So they skip to the end and patch backward when it fails.

Here’s what patching backward costs you: a disconnected system cannot learn. Every AI initiative that lives on disconnected data stays local. It doesn’t compound. The learning from this quarter’s outbound motion doesn’t feed into next quarter’s customer success motion. The signal that close-won deals generate doesn’t improve the prospecting model upstream.

You end up with AI-assisted points of productivity -- individual efficiency gains scattered across the org -- instead of a system that gets smarter with every interaction.

Playing the long game means building in the right order. Not perfectly -- you don’t perfect each stage before connecting to the next. But you do get each stage functional enough that the system can start teaching you what to improve. The sequence is the discipline.

The Five-Layer Stack You Probably Don’t Have

Read more

The Bifurcation

RevOps has moved through three distinct eras.

From roughly 2015 to 2021, it was a service desk. CRM administration, report building, process documentation. Reactive by design. The function existed to support Sales and Marketing, not to operate alongside them. From 2021 to 2024, it became a strategic partner -- cross-functional by default, increasingly involved in tech stack decisions, revenue planning, and go-to-market design. That era produced a generation of RevOps leaders who genuinely understood the business, not just the tools.

Now it is becoming something else. The Growth Architect era. And the shift is not gradual.

AI is eliminating the service desk work. Reporting, hygiene, documentation, ticket management -- these are exactly the tasks AI handles well and handles fast. The middle of the RevOps function, where most of its headcount currently lives, is also where AI is most efficient. There is no safe version of the old job. The only path forward is the one that moves up the value chain fast enough to stay ahead of what AI absorbs below it.

There is no middle path. The middle is exactly what AI eliminates best.

The New Executive Seat

Every major platform shift creates a genuinely new executive role. Not an upgraded version of the previous one -- something new, with new scope, new authority, and new compensation to match.

The CTO emerged when technology became a competitive differentiator and needed someone who spoke both engineering and business at the executive table. The CMO emerged when marketing became too complex and too expensive to leave in the hands of a VP reporting to a generalist. The CRO emerged when go-to-market became multi-motion, multi-segment, and multi-year -- too complex for sales leadership alone. Each time, a function that had been operational became strategic. The market created a seat to reflect that.

The VP of Growth is that seat right now.

The data makes it concrete. LinkedIn showed approximately 6,000 open VP of Growth and VP of Revenue Operations roles in April 2026. Base compensation runs $250,000-$350,000, with total comp packages reaching $550,000. VP of RevOps titles grew 300% in 18 months. The GTM Engineer talent pool expanded 45% in three months. These are not coincidences. They are a market discovering, in real time, that a function it has been undervaluing has become structurally necessary at the executive level.

The Chief Customer Officer was supposed to solve this. It didn’t. The CCO unified reporting lines but not systems. Functional leaders reported up to the same person without changing how the underlying architecture worked. Handoffs still broke. Data still fragmented. The org chart changed; the system didn’t. The VP of Growth does what the CCO was supposed to do, but with actual system authority rather than organizational proximity.

A new executive has entered the room. The question is whether your company is putting someone in that seat or leaving it empty.

What It Owns and What It Doesn’t

Read more

Every CEO has an AI strategy. Almost none of them have answered the question of who actually owns the system it creates. Not who picks the vendor. Not who runs the pilot. Who owns the architecture: the data, the workflows, the agent layer, the feedback loops that increasingly determine whether your go-to-market actually works. AI will either absorb Revenue Operations (RevOps), automating away reporting, process documentation, and tool administration, or elevate it to the chief architect of the entire go-to-market system. There is no middle path.

The work RevOps does today is the work AI is best at eliminating.

The only version of the role that survives is one that fundamentally transforms. That transformation -- and the ownership question it creates -- is what this piece is about.

RevOps didn’t start as a strategic function. It started as CRM administration. Someone had to keep Salesforce from catching fire, so a team formed around data hygiene, report building, and making sure the dashboards said something useful before the Monday meeting. Then go-to-market got more complex. Marketing automation, multi-touch attribution, product-led growth signals, expansion revenue models, customer health scoring. Each layer of complexity created a new process that needed an owner, and RevOps absorbed it. The CRM administrator became the process owner. The process owner became the system owner. The scope kept expanding as the go-to-market model became harder to operate. This is the pattern, not the exception. RevOps grows because go-to-market complexity grows. AI is the largest complexity jump yet. Which means RevOps is either about to have its biggest expansion, or its last.

The System No Longer Runs on People

Most executive teams have not fully internalized what their go-to-market has become. It is no longer a people-and-process operation. It is a system. And it is becoming a system that humans can no longer operate by hand. A modern go-to-market motion requires real-time signal detection across hundreds of accounts. Dynamic lead scoring that adapts to behavioral patterns. Automated workflow routing based on segment, intent, lifecycle stage, and deal velocity. Cross-functional handoffs that need to happen in hours, not days. Customer health models that synthesize product usage, support tickets, NPS data, and billing patterns into a single score that triggers the right action at the right time.

The problem is not the number of tools. It is the number of potential connections between them. The average company runs 106 SaaS applications as of 2024. In a stack that size, the number of possible pairwise integration points grows quadratically. Add one tool, and you do not add one unit of complexity. You add 106 potential interconnections. The management infrastructure most companies have built is linear. That gap is where go-to-market systems break. Not just at the tool level. At the interaction layer between them.

With the advent of AI, most executives believe they are on a path to consolidation. What we experience in practice suggests otherwise. Two things are happening simultaneously in most companies. RevOps is using AI to consolidate in one department, while another department adopts eight new AI tools without telling anyone. The result is complexity that quietly grows at the interaction layer as AI tools are added outside any governance structure. No single team has visibility. No dashboard tracks the whole. That is the gap where RevOps lives. Not in the tools. In the system that governs their interactions.

No human team, regardless of talent, can manage that interaction layer manually and keep pace with it. Most signals get missed. Most handoffs happen late. Most health scores trigger action after the moment has passed. AI is not enabling this transition. It is forcing it. The companies adopting AI-driven go-to-market motions are setting a pace that manually operated teams cannot match. This is not a theoretical future state. It is a competitive reality already playing out in pipeline generation, deal velocity, and retention economics. Someone has to architect and orchestrate this system. Someone has to be the translation layer between business objectives and machine execution. The question is who.

AI Does Not Fix What Is Broken. It Scales It.

Read more

That’s the thing most CEOs miss when they first encounter Architect Mode. They hear “the AI handles the synthesis” and they think: less for me to do. But the analysis, the dashboards, the approval chains, the cross-functional status updates -- none of that was the real work. It was the cost of a broken information architecture. You were the synthesis layer because the org had no other way to pull signal from noise at scale. Take the broken architecture away, and what remains is sharper and harder, not easier.

This piece is about what remains.

In Pillar 1, I laid out why Architect Mode is the current operating era -- not a future state, not a strategic option, but the terrain companies are competing on right now. If you’ve accepted that frame, the natural next question is: so what does the CEO actually do? Specifically. Monday morning.

Three things. Only three. They’re not new concepts, but in Architect Mode they carry a different weight because everything else has been stripped away.

I call them Aim, Army, and Assets.

Aim: Where We’re Going

AI can map markets, model competitive scenarios, surface second-order effects, and run strategy stress-tests faster than any human team you could assemble. I mean that without qualification. The analytical firepower available to a CEO who knows how to deploy it is genuinely without precedent. You should be using it aggressively.

But strategy is not the same as vision. And vision is not just where the market is going.

Vision is where you are willing to go.

Here’s the distinction that matters: AI can tell you what is rational. It cannot tell you what is meaningful. Given any strategy question, a well-prompted model will give you a defensible answer, usually several of them. It will map the adjacencies, size the opportunity, flag the risks, and rank the options by expected return. What it will not do -- and this is the permanent gap -- is tell you which hill is worth bleeding for.

That’s yours. It will always be yours.

As intelligence becomes more abundant, conviction becomes more scarce. When every company has access to the same analytical layer, the ones that win will be the ones where someone at the top made a clear call about what mattered and held to it long enough for the system to compound. The CEO still sets the meaning. The CEO decides the hill. And in Architect Mode, that judgment doesn’t reduce. It sharpens -- because now you have better information going into the decision and less excuse for sitting in strategic ambiguity.

The most dangerous CEO pattern I see right now is what I’d call “strategy by committee plus AI.” The team gathers the data, the model synthesizes it, someone builds a slide, and the CEO nods along because the analysis looks rigorous. But rigorous analysis of a mediocre thesis is just a well-dressed mediocre thesis. The machine can sharpen the thinking. It cannot supply the conviction.

If you are uncertain about the direction, say so and use the tools to sharpen the thesis. That’s legitimate. If you are unclear about the direction -- unwilling to make the call -- that is an execution failure that no amount of AI synthesis will fix.

Army: Who We’re Going With

The talent calculus has changed in a way most hiring processes haven’t caught up with yet.

The traditional assumption was additive: more headcount equals more capacity. You needed a team of twelve to run a function because twelve humans could produce more output than six. That math held in Manager Mode. It held less cleanly in Founder Mode. In Architect Mode, it breaks down entirely.

One high-agency operator with genuine AI fluency -- someone who knows how to build systems, prompt well, automate their own process, and feed signal back into the machine -- can now outperform teams built around average performers. I’ve seen it at multiple companies: the output-per-person gap between your best system-thinker and your average contributor has widened from a factor of 2x to somewhere closer to 10x, and that gap is still expanding.

This means you are not just hiring for skill anymore. You are hiring for the multiplier.

The new talent mandate breaks into four hard shifts:

Find missionaries, not mercenaries. In a world where anyone can generate competent work with a good prompt, the differentiator is belief. Missionaries don’t need to be managed into caring. They’re already running diagnostics on the system because they want the thing to win. Mercenaries produce adequate output and wait for the next directive. In Architect Mode, mercenaries become expensive drag before you notice them.

Test for taste and agency, not credentials. Give candidates a real problem and a set of tools. See what they build. See how they think about the system, not just the output. The credentials tell you what they’ve done in the past in someone else’s architecture. The test tells you what they’ll do in yours.

Remove drift fast. Standards decay quickly when the bar is unclear. This is not about being ruthless -- it’s about being honest. Every person who is trending away from system-architect capability and staying in place is a signal to the rest of the org about what you actually tolerate. The best thing you can do for culture is be precise about what good looks like and move on problems early.

Reward the ones who already get it. Not just with compensation -- with scope. The people in your org who are actively building systems, compounding institutional knowledge, and feeding signal back into the machine are your moat builders. Give them more surface area.

The honest CEO decision that follows all of this: assess your current leadership team with clear eyes. Some of them are trending toward system-architect capability. Some of them are not. That’s a real conversation, and it’s not a comfortable one. It is, however, a necessary one. The people who made you successful in Era 1 or Era 2 are not automatically the right people for Era 3. That’s not a judgment on them. It’s a judgment on fit.

Middle management, specifically, deserves its own note here. In Architect Mode, the middle manager’s job changes completely. They are no longer information routers -- that function is gone, and if they’re still doing it, you have an architecture problem. The middle manager in Architect Mode is a micro-architect. Their job is to take everything happening at the frontline -- every customer signal, every friction point, every pattern -- and feed it back into the system so the whole organization gets smarter. The best ones are actively compounding the moat. The worst ones are quietly starving it. The question isn’t whether they’re a good manager in the old sense. It’s whether they’re feeding the machine or blocking it.

Assets: What We Deploy

Capital. Attention. Focus. Brand. Trust. How you bet them is the third non-delegable function.

The scarce resource in Architect Mode is not information. AI gives every company more data, more dashboards, more options, more machine-generated strategy documents than they can possibly act on. Most companies will drown in possibility. They will run 12 pilots simultaneously and get signal from none of them. They will spread the best people across eight initiatives and get leverage from zero. They will confuse motion with direction.

The CEO’s job -- the part that cannot be automated, no matter how good the tools get -- is to decide with conviction: what are we actually doing, and what are we not doing?

That second question is the harder one. Saying no to a plausible opportunity is more cognitively difficult than saying yes to it. The analysis will always make three options look reasonable. Four options will have credible champions. Your job is not to validate the analysis. Your job is to select the handful of asymmetric bets that deserve your best people and your best years, and to be clear enough about that selection that the org doesn’t have to guess.

This is where capital allocation gets redesigned in Architect Mode. Before Architect Mode: you reviewed an annual budget. A large team gathered information from across functions. Resource allocation decisions came from point estimates and gut feel, compressed through management layers. You were the chief approver.

In Architect Mode: you design a live system that continuously updates priorities. You get fast synthesis from the intelligence layer and spend your time on judgment, not gathering. Capital allocation means selecting the handful of bets worth amplifying and actively de-investing from the rest. You are the chief architect of the portfolio, not the chief approver of the line items.

The best CEOs in Architect Mode are allowed to be uncertain. They are not allowed to be unclear.

Uncertain means: I have a hypothesis, I’ve placed the bet, I’m watching the signal, and I’ll update when the data says to. Unclear means: I’m not sure which of these five things we’re actually prioritizing. Uncertainty is honest and functional. Unclear is a cultural tax that every team member pays every day in misaligned effort.

The Identity Shift (The Hard Part)

Read more

Check out our AI Education section, and this is where things get real. Step-by-step guides, how-to breakdowns, and hands-on training to help you build agents, build systems, and use tools like Claude Code, ChatGPT, and Perplexity at a level most people don’t even know exists. This isn’t surface-level stuff -- it’s the training that actually moves your AI capabilities forward.

Paid subscribers get access to interactive tools and guides that free subscribers don’t see.

Office hours and live events where you can bring your real questions, get them answered by people who’ve actually built this stuff, and get hands-on keyboard time with experts in the room.

Come build with us.

———————————————————————————————————————————-

Most CEOs I talk to believe they’re running a modern company. They’ve got AI tools rolling out across the org. They’ve flattened the hierarchy. They move faster than they did three years ago. And they’re right -- they probably are running a more modern company than they were in 2020.

The problem is the bar moved again.

What “modern” looked like in 2020 is not what modern looks like now. And the companies that are treating this moment like an incremental upgrade rather than an era shift are going to find out the hard way. Not five years from now. Already.

This is the argument I want to make in this piece -- and across the four pieces that follow it. There have been three distinct eras of business leadership in the last four decades. Each era had a dominant logic, a dominant bottleneck, and a dominant moat. Two of those eras are closed. The third one is where business is won or lost right now. And most companies are still operating in Era 1 or Era 2 -- convinced they’ve arrived when they’ve barely departed.

Let me walk through all three.

Era 1: Manager Mode

Manager Mode was the dominant logic of 20th-century business. It was built for one purpose: scale through hierarchy.

The structure was a pyramid. Information traveled upward through relay nodes. A customer insight started at the individual contributor level, got compressed by a team lead, reframed by a manager, summarized by a director, and reached the CEO as a filtered version of the original signal. Four hops. Signal decayed at every relay node before it reached the top. By the time the CEO saw it, it was a sanitized PowerPoint slide with three key takeaways.

This wasn’t a failure of leadership. It was a rational system design for a world where coordination required human intermediaries at every layer. You couldn’t transmit raw customer data across an org in real time. So you built relay nodes. And the relay nodes became departments. And the departments became empires. And the CEO’s value came from organizing the machine -- from figuring out which levers to pull across a system that was too complex to see whole.

The moat in Manager Mode was contracts and switching costs. You locked customers in with long-term agreements, proprietary integrations, and the sheer friction of change. Headcount was a sign of strength. A 5,000-person company felt more defensible than a 500-person company, because the size itself was a moat.

It worked. For decades. And it produced enormous companies.

But it has a fatal flaw. Every relay node compresses signal. Every compression layer adds latency. And in a market where the feedback loop between customer behavior and business response needs to run in hours, not quarters, Manager Mode’s architecture becomes its liability.

Era 2: Founder Mode

In August 2024, Paul Graham wrote an essay called “Founder Mode.” It spread through the startup and executive world faster than anything I’d seen in years.

The argument was simple: most management advice is built for professional managers, not founders. And founders who follow that advice -- who delegate, who hire professional managers, who “step back” -- often watch their companies lose the thing that made them worth building. Graham gave founders permission to stay close, go deep, break the rules. Flatter orgs. Faster decisions. More founder instinct. Closer to the end customer. Skip the relay nodes and see the signal yourself.

It resonated because it was true. The best founders ARE obsessed. They DO know things their org chart doesn’t. The six-layer management hierarchy DOES compress signal into uselessness. And the conventional wisdom about “hiring people smarter than you and getting out of the way” has killed more high-potential companies than it’s saved.

Founder Mode was a necessary correction. If you were drowning in bureaucracy, it gave you permission to break the glass and breathe again.

But Founder Mode has a ceiling. And the ceiling arrives faster than founders expect.

Founder Mode scales to about 30 people and then breaks. The bottleneck shifts. It’s not bureaucracy anymore. It’s the founder. Every decision flows through one person. Every creative call requires one brain. Every strategic judgment waits in one queue. The founder’s calendar becomes the constraint on the entire organization’s velocity. And the founder -- no matter how brilliant -- has 24 hours in a day, processing capacity that plateaus under cognitive load, and attention that degrades under scope.

The moat in Founder Mode is the founder’s taste, network, and speed. Which means the moat retires when the founder does. Or burns out. Or gets distracted. The company’s competitive advantage is entirely load-bearing on one human being.

This is why so many companies hit a ceiling between 30 and 150 employees that looks like a product problem or a market problem but is actually a leadership architecture problem. Founder Mode is a brilliant early-stage operating mode. It is a catastrophic late-stage one.

Era 3: Architect Mode

This is where we are now. And most companies haven’t arrived yet.

Architect Mode keeps the speed and conviction of Founder Mode. It keeps the founder’s closeness to the customer, the flatness, the intolerance for bureaucracy, the bias for action. But it adds something Manager Mode never had and Founder Mode can’t: AI leverage at the center of the operating system.

Here’s how it works in practice.

In Manager Mode, the intelligence lived in relay nodes -- in the heads of middle managers who synthesized information and passed it up the chain. In Founder Mode, the intelligence concentrated in the founder’s head. In Architect Mode, the intelligence lives in a system that sits at the center of the organization. Every functional unit connects to it directly. Signal from a customer churn event, a rejected contract submission, a failed sales call, a support ticket resolved -- all of it flows directly into the center and reflects back to whoever needs to act on it. No relay nodes. No compression. No decay.

And here’s what changes everything: every signal that enters the system makes it smarter for the next one.

This is not “let AI run the company.” That framing is almost always wrong when I hear it, and I hear it often. Architect Mode is not abdication. It is the discipline to work ON the system rather than IN it -- to combine human meaning, human taste, and human accountability with machine-assisted analysis, machine-assisted execution, and machine-assisted scale.

The CEO’s job in Architect Mode compresses to three things. I call them Aim, Army, and Assets.

Aim -- where we’re going. AI can map markets, model scenarios, surface patterns across competitive landscapes. But the human decides which hill is worth bleeding for. That judgment doesn’t reduce. It sharpens.

Army -- who we’re going with. AI can surface performance data, flag drift early, model org design. But the human transmits belief, creates psychological safety, and removes the dysfunction that data alone can’t diagnose. Culture doesn’t compress to a model. Leadership does.

Assets -- what we deploy. AI can stress-test capital allocation, model ROI across investment scenarios, flag opportunity costs in real time. But the human decides what deserves their best people and their best years. Strategy is not an optimization problem. It’s a values problem that benefits from better information.

Everything else -- the analysis, the synthesis, the execution, the monitoring -- that’s where the system runs.

The Framework: Three Eras, Ten Dimensions

Read more

Before we dive in -- thank you to our paid subscribers! Make sure to take full advantage of all the value you get.

Check out our AI Education section, and this is where things get real. Step-by-step guides, how-to breakdowns, and hands-on training to help you build agents, build systems, and use tools like Claude Code, ChatGPT, and Perplexity at a level most people don’t even know exists. This isn’t surface-level stuff -- it’s the training that actually moves your AI capabilities forward.

Paid subscribers get access to interactive tools and guides that free subscribers don’t see.

Office hours and live events where you can bring your real questions, get them answered by people who’ve actually built this stuff, and get hands-on keyboard time with experts in the room.

Come build with us.

Most CEOs I talk to are running a 2022 company with a 2026 tool stack and calling it transformation. The AI line in the budget doubled. A ChatGPT subscription went out to the whole team. Copilot landed in the sales org last quarter. The board deck has a slide titled “AI-native.” And the underlying system that actually produces revenue is unchanged from three years ago.

That gap is not a technology gap. It is an architecture gap. And the growth-rate spread between companies that have closed it and companies that have not is already visible in the pipeline numbers, in retention, in the hiring curve. Not a projection for 2028. Current reality.

Five shifts explain the gap. Each one compounds into the next.

1. The era has changed. Three logics of running a company, three moats, only one that compounds automatically.

2. The CEO’s job got clarified, not simplified. Aim, Army, Assets. Everything else is an architecture problem.

3. The revenue system most companies run is hollow. 106 SaaS apps, quadratic complexity, a five-layer stack that was never built.

4. The system is an orphan. Everyone owns a piece, no one owns the whole.

5. A new executive seat is emerging to own it. Reports to the CEO. Different scope, different comp, different hire.

Shift 1. The Era Has Changed

Three logics have governed how companies get built in the last forty years. Two of them are closed. One is where business is won right now.

Manager Mode was the dominant logic of the 20th century. Information climbed a pyramid. A customer insight got caught by a rep, filtered by a team lead, reframed by a director, and arrived at the CEO as a sanitized slide with three bullets. Four relay nodes, four rounds of compression. The moat was contracts, switching costs, and org chart depth. It worked for decades. It built enormous companies. Its fatal flaw is latency. Every relay compresses signal. Every compression adds delay. When the feedback loop between customer behavior and company response has to run in hours, not quarters, Manager Mode’s architecture becomes its liability.

Founder Mode was a correction. Paul Graham named it in 2024 and it landed because it was true. The best founders are obsessed. They know things the org chart does not. The six-layer management hierarchy does compress signal into uselessness. Founder Mode was permission to break the glass and breathe. But it has a hard ceiling. It scales to roughly thirty people and then the bottleneck stops being bureaucracy and starts being the founder’s calendar. Every decision runs through one person. Every creative call requires one brain. The moat is the founder’s taste, network, and velocity, which means the moat retires when the founder does.

Architect Mode is where we are now. It keeps the speed and conviction of Founder Mode. It keeps the closeness to the customer. And it adds the piece neither prior era had: an AI-native system at the center of the operating model. In Manager Mode, intelligence lived in the relay nodes. In Founder Mode, it concentrated in the founder’s head. In Architect Mode, intelligence lives in a system that sits at the center, and every function connects to it directly. A churn event, a rejected submission, a support ticket, a closed deal, signal flows into the center and reflects back to whoever needs to act on it.

Every interaction makes the system smarter.

The moat column is where this gets real. Manager Mode’s moat erodes the moment something meaningfully better shows up. That used to take decades. It now takes months. Founder Mode’s moat is non-transferable and leaves with the founder. Architect Mode’s moat is different in kind: a proprietary feedback loop that compounds automatically. The competitor landing in your market tomorrow faces the learning curve you faced on day one while your system has been compounding for eighteen months.

Three examples of what that looks like right now, none of them demo slides.

A GovTech firm stopped treating regulatory rejections as bad news and started treating them as training data. Every rejection, the specific language that failed, the clause that triggered pushback, the reviewer who rejected and on what grounds, fed back into a model. Eighteen months in, approval rates climbing, cycle times compressed. The system now holds things about that regulatory environment no individual could hold in their head. A competitor walking in next quarter meets the bureaucracy this firm met eighteen months ago. This firm’s system has been compounding on that exact problem the whole time.

A customer support team stopped writing macros and built a response intelligence system. Every ticket, every resolution, every satisfaction score fed back. Volume is up, hiring curve is flat, CSAT is improving. The institutional knowledge that used to live in the heads of people who might quit on a Tuesday now lives in the system.

A marketing agency fed every campaign, every brief, every performance result into a central creative model. Junior account managers are producing work that used to require a senior strategist. The gap is not because the juniors got smarter. It is because the system got smarter and they are standing on it.

Most companies are tourists. They visit AI. They take the photos. They use a tool, learn something, share it at the next offsite. Tourists have a great time. They learn things. They come home with stories. But they go home. They do not build a life there. They do not put down the roots the compounding requires. The tourist trip is fun. The efficiency gains are real. The budget line looks good on the board slide. The transformation is not happening.

“Are we using AI?” is the wrong question. The right question is harder. Is your AI smarter today than it was yesterday, and does that gap widen automatically without your involvement? If not, you are in Founder Mode with a better toolkit. You are not in Architect Mode.

Shift 2. The CEO’s Job Got Clarified, Not Simplified

The most common mistake a CEO makes on entering Architect Mode is assuming it makes the job easier. It does not. It makes the job sharper and more uncomfortable, because the cover stories for what was broken go away.

The dashboards, the approval chains, the cross-functional status updates, the personal synthesis between a board meeting and a Tuesday ELT, none of that was the real work. It was the cost of a broken information architecture. The CEO was the synthesis layer because the org had no other way to pull signal from noise. Take the broken architecture away and what remains is three things.

I call them Aim, Army, and Assets.

Aim. Where are we going. AI maps markets, models scenarios, surfaces second-order effects, and runs strategy stress-tests faster than any internal team. Use it aggressively. Strategy is not the same as vision. A well-prompted model will give you a defensible answer to any strategic question, usually several of them. It will size the opportunity, rank the options, and flag the risks. What it will not do, and this is the permanent gap, is tell you which hill is worth bleeding for. That is yours. It will always be yours. As intelligence becomes more abundant, conviction becomes more scarce.

Army. Who are we going with. The talent calculus shifted in a way most hiring processes have not caught up with. One high-agency operator with genuine AI fluency, someone who builds systems, prompts well, automates their own process, and feeds signal back into the machine, now outperforms teams built around average performers. The output gap between your best system-thinker and your average contributor widened from 2x to something closer to 10x, and it is still widening. The honest CEO conversation that follows is not a comfortable one. Assess your current leadership team with clear eyes. Some of them are trending toward system-architect capability. Some are not. The people who got you here in Era 1 or Era 2 are not automatically the right people for Era 3. That is not a judgment on them. It is a judgment on fit.

Assets. What do we deploy. Capital, attention, focus, brand, trust. The scarce resource in Architect Mode is not information. AI gives every company more dashboards, more data, more machine-generated strategy documents than any team can act on. Most companies will drown in possibility. They will run twelve pilots simultaneously and get signal from none. They will spread the best people across eight initiatives and get compounding from none. The CEO’s job, the part that does not automate no matter how good the tools get, is to decide with conviction: what are we doing, and what are we not doing? The second question is the harder one. Saying no to a plausible opportunity is more cognitively difficult than saying yes to it. The analysis will always make three options look reasonable. Four will have credible champions. Your job is not to validate the analysis. Your job is to pick the asymmetric bets that deserve your best people and your best years, and be clear enough about the pick that the org does not have to guess.

The best CEOs in Architect Mode are allowed to be uncertain. They are not allowed to be unclear. Uncertain means: I have a hypothesis, I placed the bet, I am watching the signal, I will update when the data says to. Unclear means: I am not sure which of these five things we are actually prioritizing. Uncertainty is honest. Unclear is a cultural tax every team member pays every day in misaligned effort.

Aim, Army, Assets sounds clean on the whiteboard. The application of it requires something leadership training does not talk about enough: an identity shift. In Founder Mode, your value came from your involvement. You knew the answers because you were closest to the problem. Your fingerprints were on everything. Architect Mode asks for a different discipline. Build the thing that runs without your constant involvement while staying deeply accountable for what it produces. You optimize for system quality over personal heroics. That takes real work to sit with.

The question I would leave here is not “am I in Architect Mode?” Most CEOs will say yes and mean something closer to “I think about AI a lot.” The real question: if you were removed from your company for sixty days, which decisions would be better because your system kept learning, and which would be worse because the system does not exist yet? The length of the second list is the honest measure of how far you have to go.

Shift 3. The System Most Companies Don’t Have

Read more

Go count the SaaS tools your GTM team pays for. Not the ones in the deck. The ones actually running. The ones someone signed up for eighteen months ago that still bill the credit card even though the champion left. Now count how many of them share data without someone manually exporting a CSV.

That gap between “tools we pay for” and “tools that actually talk to each other” is the most expensive line item nobody tracks.

The Garage Problem

Every GTM team I have worked with over the past 21 years has the same issue. It looks different at every company, but the shape is identical.

It starts with a problem. Pipeline visibility is bad. Someone buys a tool. Content production is slow. Someone buys a tool. Competitive intel is stale. Someone buys a tool. Customer health scores are unreliable. Someone buys a tool.

Each purchase made sense at the time. Each vendor demo was convincing. Each implementation had a champion who cared. And now you have 14 tools across marketing, sales, CS, and RevOps that were never designed to work together, connected by integrations that break quarterly, managed by people who spend half their time maintaining the plumbing instead of doing the work the tools were supposed to make easier.

This is not a technology problem. It is an architecture problem. And the entire GTM industry has been pretending it is normal.

I can say this with confidence because I was one of the people pretending. I signed the contracts. I championed the tools. I sat in the QBRs and told my team the new platform would fix the data problem. Three of those tools are still billing my old company’s credit card right now, and I am not sure anyone knows the login.

The Market Map Illusion

You have seen the market maps. The ones with 150 logos arranged in neat categories. CRM. Marketing Automation. Sales Engagement. Revenue Intelligence. Conversational Intelligence. Customer Success Platform. ABM. Content. SEO. Competitive Intel.

They look organized on a slide. They feel chaotic in practice.

Here is what actually happens when you run a GTM operation across those categories:

Data lives in silos. Your CRM knows about deals. Your marketing automation knows about engagement. Your CS platform knows about health scores. Your content tools know about performance. None of them know about each other. The competitive intelligence your analyst gathered last Tuesday lives in a Google Doc that three people have read.

Integrations are duct tape. Zapier, native connectors, custom API work. They move data from point A to point B, but they do not carry context. A lead score in your MAP tells your CRM a number. It does not tell your sales team why that number is high, what content the prospect engaged with, or what competitive alternative they were evaluating.

Signal loss is the default. Every handoff between tools loses information. Marketing qualified a lead and passed it to sales. What was the qualification signal? It is in the MAP, but the AE is in the CRM. The customer told your CSM something important on a call. It is in the conversational intelligence tool. Your product team will never see it.

Nobody owns the whole picture. Each tool has an admin. Nobody administrates the system. Because there is no system. There is a collection of tools.

What This Actually Costs

The direct costs are obvious. License fees stack. A mid-market GTM team easily spends $200K-$400K annually on SaaS subscriptions across these categories. Enterprise teams spend millions.

But the indirect costs are worse:

Time tax. Your ops team spends 30-50% of their time on integration maintenance, data hygiene, and tool administration. That is your most strategic team doing janitorial work.

Decision latency. When a signal has to travel through three tools and two manual handoffs before it reaches the person who can act on it, you are making decisions on stale information. Every time.

Context collapse. The thing that makes your business distinctive -- your market knowledge, your customer relationships, your competitive position -- gets flattened into whatever fields the tool allows. Your institutional intelligence lives in people’s heads instead of in the system.

Training drag. Every new hire learns 8-12 tools. Every tool update resets muscle memory. Every tool switch requires migration. The switching costs are so high that teams stay on bad tools because moving is worse than suffering.

The Question Nobody Asks

Here is what I kept asking myself across two decades of GTM work: why do we accept this?

Why do we accept that marketing, sales, and CS should operate in different software environments? Why do we accept that “integration” means a fragile API connector instead of shared context? Why do we accept that every department has its own version of the truth?

The answer is that we did not have an alternative. The SaaS model was the best we had. Best-of-breed tools in each category, connected by integrations, managed by ops teams. That was the architecture. It was the only architecture available.

It is not the only architecture available anymore.

What is behind the paywall: The five-step Tech Stack Audit framework I use to diagnose exactly where signal dies in a GTM stack, the thesis that ties this entire series together, and a paid subscriber resource -- a complete Tech Stack Audit Interactive Guide you can run with your ops team this week.

The diagnosis above is free. The prescription is for subscribers.

Read more

“We’re not even using AI that well yet,” he told me. “But the board read the Block announcement and now everyone’s counting heads.”

This is the moment we’re in. And I want to be honest with you about how strange and how consequential it is.

The Block Signal and What It Actually Means

Jack Dorsey didn’t dress it up. When Block cut from 10,000 to fewer than 6,000 employees this month, he said: “This is not driven by financial difficulty, but by the growing capability of AI tools to perform a wider range of tasks.”

Read that again. He’s not saying AI replaced those roles. He’s saying he believes it will.

Oracle followed the same week: 20,000–30,000 cuts to free up $8–10 billion for AI infrastructure investment.

And here’s the data that makes this stranger: 45,000 tech layoffs in March 2026. 20% explicitly attributed to AI — up from less than 8% last year. But at the same time:

• Only 14% of organizations have AI solutions ready to deploy

• Only 11% are actively running AI in production

• 76% are deploying or implementing agentic AI in theory

Companies are restructuring for a capability that hasn’t fully arrived. The expectation of AI performance is driving business decisions faster than AI performance itself.

This has never happened before. In every prior technology wave — cloud, mobile, SaaS — companies restructured after the technology proved itself at scale. This time, the restructuring precedes the proof. The expectation economy has arrived.

And if you run a GTM organization, you have a decision to make before someone makes it for you.

The 65-Point Gap Nobody Is Talking About

Here’s the number that should keep every executive up at night: the gap between intent (76% deploying agentic AI) and reality (11% in production) is 65 points.

Sixty-five percent of organizations are somewhere in between — buying tools, running pilots, writing policies, reorganizing teams, reallocating budgets — but not actually running AI-powered workflows at scale.

They’re paying for the transition without getting the performance. That’s the worst possible position. You have the cost of change without the benefit of capability.

Why does the gap exist? Three reasons, and they’re all fixable with the right architecture:

Data quality. Organizations are committing to agentic AI workflows faster than they’re addressing the data quality those workflows require. An AI agent is only as good as the signals it runs on. If your CRM is 60% accurate, your AI-powered outreach is 60% accurate — and it’ll move 10x faster than a human in the wrong direction.

Integration depth. Demandbase’s new B2B AI GTM Report found that integrating CRM, marketing automation, predictive scoring, and advertising tools into a unified stack boosts conversion rates 53%. Most companies have those tools. Almost none have them fully integrated. You’re not missing software — you’re missing connective tissue.

Governance frameworks. 76% of GTM leaders are deploying agentic AI at a faster rate than they’re establishing the governance frameworks those deployments require. No decision rules. No escalation logic. No human-in-the-loop design. Just agents running in the wild.

The companies that are winning — the ones in that 11% running AI in production — aren’t doing something heroic. They built the infrastructure first. They didn’t skip the connective tissue.

Check out the Claude Cowork and Code Guides for Go-To-Market Below

Click Here

What the AI-Native GTM Org Actually Looks Like

Read more

It’s not transformation. It’s decoration.

And the companies that figure this out—that actually restructure around AI instead of just buying AI-flavored SaaS—are going to have a competitive advantage that’s very hard to close.

The signal is always the same: the early movers don’t wait for the market to package the thing for them. They build the capability themselves, internally, before it becomes table stakes.

Right now, that capability is the Agent Builder.

The Math Changed and Nobody Updated Their Playbook

Buying AI-powered versions of the tools they already have.

New CRM? It has AI baked in. SEO tool? AI-powered. Social listening platform? AI-enhanced. Email sequencer? Copilot included.

The category names are new. The underlying model is identical: pay a vendor, get a tool, add it to your stack.

This made sense when AI was genuinely hard to implement. When you needed a team of engineers and weeks of fine-tuning just to automate a simple workflow. That era lasted maybe 18 months. It’s over.

What changed isn’t just that models got smarter. It’s that agent platforms got accessible enough that a sharp, workflow-minded generalist can build something genuinely useful in a day or two. Not a toy. Not a demo. Something that runs autonomously, handles edge cases, and generates actual output.

The AI agents market is projected to grow from $7.84 billion this year to $52.6 billion by 2030—a 46.3% CAGR. That’s not a trend. That’s a structural shift in how work gets done. And by end of 2026, 80% of B2B sales interactions are expected to be AI-powered.

The companies building this capability internally are going to capture the value. The companies buying it from vendors are going to pay a premium for someone else’s version of what they could have built themselves.

What the Agent Builder Actually Is

The Agent Builder isn’t a developer. They’re not a data scientist. They’re not an ops coordinator who learned to use ChatGPT.

The best Agent Builders live at a very specific intersection: they understand workflows deeply—what humans actually do, step by step, in a given function—and they can translate that into agents that do those same tasks autonomously.

The key word is autonomously. Not “with AI assistance.” Not “AI-augmented.” Autonomously.

Their mandate is simple: find manual workflows and SaaS subscriptions that can be replaced by agents, and build the replacements. Run discovery across teams. Understand inputs and outputs. Build, test, deploy.

But here’s what separates this from a tech project: they’re accountable for the business result. Not “the agent runs.” But “we cancelled that $2,400/month subscription” or “we eliminated 12 hours of manual data work per week from the growth team.”

This is a full-time role. It needs to be. Because the backlog of replaceable workflows and cancellable SaaS subs in your company is enormous—you just haven’t mapped it yet.

The Evidence Is Already In

This isn’t theory. The data is coming in fast and it’s unambiguous.

Owner.com ran a two-week pilot with AI agents in their BDR function. The result: 85% improvement in decision-maker connects. Their reps now operate 3-4x more efficiently than competitors. Two weeks.

Klarna achieved a 152% increase in revenue-per-employee without proportional headcount growth. They didn’t hire their way to efficiency. They built it.

The GTM Engineering talent pool—people who build at this intersection of revenue and automation—expanded 45% in just three months, with 1,570 new profiles entering the market. The role is real and the market is responding.

And here’s something I can speak to directly: I currently manage 93 specialized AI agents across 12 departments with 11 live integrations. One operator. Ninety-three agents. That’s not a future scenario. That’s my Tuesday.

Why GTM Gets Hit Hardest

Go-to-market is where this lands first and lands heaviest. And it’s where most leaders are the most behind.

Think about what your GTM stack actually looks like. Intent data. Social listening. Competitive intelligence. User feedback analysis. Email sequencing. Pipeline analytics. Content production. Prospect research.

How many of those are candidates for agents?

All of them. Every single one.

That doesn’t mean you flip a switch and cancel everything tomorrow. It means you have a strategic opportunity to systematically replace vendor dependencies with internal capabilities that are faster, cheaper, and tailored to your specific business context.

VP RevOps titles have grown 300% in the last 18 months. That’s the market telling you that companies are centralizing operational control. But the smart ones aren’t just hiring RevOps leaders to manage the existing stack—they’re hiring them to replace it.

Anthony Enrico from Leanscale said it plainly: “The Salesforce admin role is gonna die.” Nico Druelle at Revenue Architects went further: “RevOps staying at the surface—dashboards, reporting, CRM admin—AI will do most of that. That whole layer disappears.”

They’re not being dramatic. They’re describing what’s already happening.

The Compound Effect

Here’s what most people miss: it’s not one subscription or one workflow. It compounds.

Every agent you build is a fixed cost that replaces a variable or recurring cost. The agent doesn’t need a seat license. It doesn’t need a renewal negotiation. It doesn’t have a per-user pricing model that punishes you for growth.

And the Agent Builder doesn’t build one agent. They build a system of agents. A coverage map across your company where manual work and SaaS dependencies get methodically replaced.

At the end of a year, a good Agent Builder has replaced 6-12 SaaS subscriptions, automated dozens of manual workflows across multiple functions, and created a compound cost advantage that keeps widening as the company scales.

That’s not a technology project. That’s a structural change to your operating model.

Why This Changes What You Hire For

If you’re a GTM leader, this should change how you think about headcount.

The old question: “Do we need another SDR, another analyst, or another ops person?”

The new question: “Do we need an Agent Builder who can eliminate the need for three tools and two manual processes in their first quarter?”

That’s not hyperbole. That’s the ROI profile I’m seeing from early adopters.

Your SDRs shouldn’t be doing research. Your analysts shouldn’t be pulling reports. Your ops people shouldn’t be manually QA-ing data. Agents can do all of that. Your humans should be doing the things that compound over time—building relationships, making judgment calls, creating strategy, running experiments. That’s where human time has the highest leverage.

The Moat Nobody’s Talking About

Software can be copied. A workflow built on a shared SaaS platform can be replicated by anyone with the same subscription.

An internal agent system? That’s built on your specific data, your specific workflows, your specific context. It gets better the longer it runs. It compounds knowledge. It surfaces insights that a generic tool was never designed to surface.

The company that has an Agent Builder working for 12 months has a capability advantage that a competitor can’t buy off the shelf. They can buy the same agent platform. But they can’t buy your 12 months of workflow knowledge, custom tooling, and proprietary outputs.

That’s the moat. And it’s building right now, whether you’re building it or not.

How to Actually Start

If you’re thinking about this seriously, here’s where I’d begin:

Map your SaaS spend by workflow. Not by category—by the actual thing each tool does. What’s the input? What’s the output? How many hours per week does a human spend operating it?

Find your Agent Builder. They probably already exist on your team. They’re the one automating their own work, annoyed by manual processes, asking “why are we doing this by hand?” more than anyone else.

Start with one thing. Pick one workflow that’s manual, repetitive, and high-frequency. Build an agent. Let it run for 30 days. Measure against what you were doing before.

Then give them a cancellation target. Identify and replace $X in SaaS spend by end of Q3. That creates accountability and forces prioritization.

Most companies will read this, nod, and keep buying tools.

A few will actually do something different.

The question isn’t whether agents can replace manual workflows and SaaS tools. They can. The question is whether you’re building that capability or waiting for a vendor to sell it back to you.

Read more

The demo builders get attention. The infrastructure builders get leverage.

Google just made a significant infrastructure move — and based on what I’m seeing in most GTM and ops conversations, people are treating it like a developer curiosity instead of what it actually is: a signal about where AI agent adoption is heading next.

Let me explain what’s happening and why it matters if you run a team, build products, or are trying to figure out where to actually place your bets with AI.

What Google Actually Launched

Google released a set of managed, remote MCP servers — Model Context Protocol integrations that let AI agents talk directly to Google Cloud services. We’re talking BigQuery, Firestore, Cloud Logging, Google Maps, Vertex AI Search, GKE, and more.

If that sounds overly technical, here’s the version that matters:

Your AI agents can now read from your databases, query your logs, pull from your analytics warehouse, and act on that data — without you building and maintaining the plumbing yourself. Google runs the infrastructure. You configure the connections. The agent does the work.

That’s a different world than what we’ve been operating in.

Most of the AI agent implementations I see today are brittle. Someone builds a workflow that calls an API, wraps it in a custom integration, hosts it somewhere, and prays it doesn’t break. There’s no standardization. There’s no security layer baked in. It works until it doesn’t, and then you’re six layers deep in debugging.

MCP changes that architecture. And Google hosting MCP servers on managed infrastructure — with IAM security, stateless scalability, and official documentation grounding — is the enterprise-grade shift that makes this practical at scale.

Why Most People Will Miss What This Signals

I’ve been in enough technology cycles to know how this plays out.

When something new drops, the people closest to the technology see the capability immediately. The people who actually transform their businesses with it are the ones who see the second-order effect — what this enables that wasn’t possible before.

Here’s the second-order effect nobody’s talking about:

Google didn’t just make it easier to connect AI to Google Cloud services. They built a standardized, secure, enterprise-ready interface between AI agents and live operational data. That’s the gap that’s been stalling real agentic deployment in serious organizations.

Think about the problems I hear from operators constantly:

“We built something with GPT, it worked in demos, but we can’t get it into production because security won’t approve it.”

“Our AI agent workflow is great until the data it needs lives in three different systems with no clean integration.”

“We can’t give AI agents write access to anything important because there’s no audit trail.”

Google’s architecture addresses all three. IAM Service Accounts as the security layer. Managed stateless infrastructure. Official documentation grounding via the Developer Knowledge MCP Server so agents aren’t hallucinating API syntax.

The foundation just got a lot sturdier.

What This Actually Looks Like in Practice

Read more

He mentioned he’d been using Claude Cowork and was getting a lot out of it. Great. Then I asked if he’d tried Claude Code.

“No. That’s for engineers, right?”

I paused. Not because it’s a dumb question — honestly, it’s the reasonable assumption given how Anthropic positioned it. But because it’s the same thing I hear from revenue leaders, ops executives, and founders every single week. And it’s costing them the most powerful AI unlock that exists right now.

So let me just say this directly: Claude Code is not a code editor. It is an AI operating system.

The terminal is just where you type. That’s it.

Think about it like this:

You talk to people via text messages.

You talk to AI via a terminal.

The Misconception Anthropic Created (And Why It Matters)

When Anthropic released these tools, they framed Claude Code as a developer product and Cowork as the accessible business tool. That framing stuck. Hard.

Business leaders saw “Code” and heard “not for me.” They stayed in Cowork, did their one-off projects, and told themselves they were using AI. And they are — just not the most powerful version of it.

Here’s the mental model I use when I explain the difference:

Cowork is a smart contractor you hire for a day. They show up, do the task, leave. Great work. No memory of what they did before. Next time, you re-explain everything.

Code is a full-time operator who sits at your desk every day. They remember everything. They build systems. They get better over time. And when you need something done, they already know the context without you having to catch them up.

Same model underneath. Wildly different relationship.

The Four Things That Change Everything

I’ve put together a full operator’s guide (link below) that breaks down the complete comparison — feature by feature, use case by use case, including a step-by-step setup for your first 15 minutes. But let me walk you through the four capabilities that actually move the needle.

1. CLAUDE.md Is Your Business Operating System

This is the one that blew my mind first.

In Cowork, every session is fresh. You can build a memory workaround — write things to a file, hope it loads — but it’s manual and unreliable. You re-explain your ICP. You re-explain your deal stages. You re-explain your competitive landscape. Every. Single. Time.

In Code, there’s a file called CLAUDE.md that loads automatically at the start of every session. Write your business context there once — ICP, competitors, deal stages, naming conventions, team structure, communication preferences — and every future session starts with full context. No re-explaining. No uploading. No context tax.

It’s the difference between a sticky note on your monitor and an operating manual that’s hardwired into the system.

I now have over 400 lines in mine. First session of the day, Claude already knows everything. The compound effect over months is hard to overstate.

2. Named Agents Are Your AI Team

In Cowork, sub-agents are ephemeral. They exist for one task and disappear. Which is fine for quick work. But it means you’re starting over every time you need a competitive analysis, a piece of content, or a pipeline review.

In Code, you define agent specs. You build a CMO agent — here’s how it thinks about positioning, here are the competitors it tracks, here’s the writing style it uses. You build it once. You refine it over time. It accumulates institutional knowledge.

I’m running over 80 GTM agents now. CMO, CRO, Sales Engineers, Content Writers, Competitive Intel Analysts. When I need a battlecard, I don’t start from scratch. I invoke the Competitive Intel agent that already knows our positioning and our rivals and just ask for the update. The task that used to take an hour takes 7 minutes.

That’s not efficiency. That’s a different category of leverage.

3. Your File System Is Already There

Cowork works in a sandbox. Which means uploading, copy-pasting, and re-uploading your actual files into a contained environment every time you want to work with them.

Code works with what’s already on your machine.

“Read the pipeline export in Downloads and tell me which deals are at risk.”

You type that. It reads it. No prep work. No uploading. No explaining where things are. Your actual pipeline data. Your actual competitive folder. Your actual deal notes. All of it available by just pointing at the path.

This sounds like a minor convenience until you’ve done the upload dance three times in one week. Then it feels like a superpower.

4. Automation That Actually Runs

Cowork’s scheduled tasks are in beta as of right now, and honestly — they’re unreliable. They work sometimes. They silently fail other times. You cannot build a repeatable business process on “sometimes.”

Code supports hooks (event-triggered actions), cron jobs (scheduled tasks), and full automation pipelines. Things I have running in production today:

• Daily competitive monitoring that flags pricing changes

• Automated content pipeline: trend research → draft → review

• Weekly research digests synthesized from multiple sources

• Pipeline health alerts triggered by CRM events

None of those require writing code. They require describing what I want, once, and letting Claude build it.

“But I’m Not Technical” — Let me actually address this

Read more

Let me explain.

The Three Eras (and Why Era 3 Changes Everything)

Era 1: The Service Desk (2015–2021). RevOps was the team that kept the lights on. CRM admin, report building, data hygiene. The career ceiling was “Senior Manager.” Measurement was system uptime and ticket turnaround.

Era 2: The Strategic Partner (2021–2024). The 2022 SaaS correction forced a reckoning. When “growth at all costs” became a punchline, someone had to answer harder questions — What’s our real CAC? Why are we spending $400K on a channel producing $50K in closed-won? RevOps teams that could answer those questions got promoted. Leaders moved from reporting to VP Sales into senior leadership meetings. Directors started commanding $273K total comp.

But even in this elevated state, most RevOps teams remained fundamentally reactive. Better at answering questions. Not designing the system that generates them.

Era 3: The Growth Architect (2025–). This is where we are now. And it’s genuinely disruptive.

RevOps is evolving from a service function to a technical, architectural discipline. The Vasco 2026 RevOps Trends & Predictions Report — built from interviews with fifteen GTM leaders including Jacco van der Kooij, Kyle Norton, Jen Igartua, and Jeff Ignacio — frames it bluntly:

“RevOps is shifting from a service desk to a growth architect and GTM CTO.”

Teams are moving from busywork and reporting to system design, simulation, experimentation, and orchestration.

The Bifurcation No One Is Talking About

Here’s the uncomfortable truth that most RevOps content avoids: RevOps doesn’t have a future. It has two. And they’re diverging fast.

Path 1: Automate and Absorb. The software performs the RevOps function. CRM administration, basic reporting, dashboard maintenance, data cleanup — AI handles all of it. The traditional RevOps team shrinks or disappears. Anthony Enrico of Leanscale is direct: “The Salesforce admin role is gonna die. It’s not gonna exist in an AI-driven world.”

Path 2: Orchestrate and Elevate. RevOps becomes the central node orchestrating all GTM agents — human and artificial. The function owns system architecture, data governance, workflow orchestration, and AI governance.

Guillaume Jacquet of Vasco captures the uncertainty: “Future number one: the software performs the RevOps function and the team disappears. Future number two: RevOps becomes the only function, the central node orchestrating all the GTM agents. I actually don’t know which one wins.”

What’s clear is that the middle is collapsing. RevOps as a support desk that builds dashboards and manages CRM fields — that’s dead. Nico Druelle of The Revenue Architects: “RevOps that stays at the surface — dashboards, basic reporting, CRM admin — AI will do most of that. That whole layer disappears.”

The Rise of the GTM Engineer (and Its Critical Blind Spot)

The most significant new role in the revenue org is the GTM Engineer. Between September and November 2025 alone, the GTM Engineering talent pool expanded by 45%. AI mentions in profiles rose from ~40% to ~60%. Average experience jumped from 27 to 49 months as the role professionalized.

But here’s where I push back on the prevailing narrative.

The GTM Engineer role — as currently practiced — is massively over-indexed toward the top of funnel. Look at where the talent clusters: Clay workflows, outbound sequencing, lead enrichment, prospecting automation, intent signal routing. It’s acquisition-obsessed.

This is the exact mistake that Winning by Design’s bowtie model was designed to correct: treating revenue as something that happens before the signature.

The bowtie isn’t a metaphor. It’s math. In a SaaS business with healthy unit economics, the majority of lifetime value comes from onboarding, adoption, expansion, and advocacy — the right side of the bowtie. NRR is what separates compounding businesses from leaky ones. Yet the overwhelming majority of GTM engineering energy goes into filling a funnel that’s leaking out the bottom.

A true GTM Engineer should be building across the full lifecycle:

• Acquisition systems — but also onboarding automation that cuts time-to-value from weeks to days

• Pipeline orchestration — but also adoption scoring that predicts churn before your CSM sees the signals

• Lead enrichment — but also expansion triggers that surface upsell from product usage data

• Outbound sequencing — but also advocacy loops that turn power users into referral engines

If your GTM Engineer spends 80% on acquire/convert and 20% on onboard/adopt/expand/advocate, your “revenue system” isn’t a system. It’s a funnel with a new job title attached.

The CRM Demotion

The most provocative structural shift: the CRM is no longer the system of record. The data warehouse is.

“More and more operators are pulling truth directly from the warehouse now, because the CRM just can’t describe the real state of the customer anymore.” — Guillaume Jacquet

Kyle Norton takes it further: “We’ll start seeing headless CRMs or chat interfaces built directly on top of the data layer. The UI won’t matter anymore.”

This has massive implications for RevOps talent. If the CRM becomes an interface layer rather than the source of truth, the skills that matter shift from Salesforce administration to data engineering, warehouse architecture, and semantic layer design.

Where We Actually Are on the AI Curve

The Vasco report introduces a useful framework:

• 2025 = Curiosity. Experimentation phase.

• 2026 = Faster. Speed gains at production scale.

• 2027 = Smarter. True intelligence — decision-making, simulation, relevance.

But here’s the honest reality check. Matt Volm of RevOps Co-op: “AI has actually slowed RevOps down this year. On top of our normal work, we’ve added new AI responsibilities, which stretches teams thinner rather than making them faster.”

Stuart Watson invokes the Red Queen Theory: “Finishing something faster doesn’t mean you rest — it just raises the bar. You run faster just to stay in the same place.”

We’re in a skilling phase where the investment hasn’t yet paid off in productivity. But the teams that invested in data foundations before deploying AI are starting to see results. Norton’s team saw 85% improvement in BDR decision-maker connects from a two-week pilot and claims reps are 3-4x more efficient than competitors.

The takeaway: data foundations first, AI deployment second. Always.

The Human Cost No One Talks About

RevOps professionals who built careers on CRM expertise are watching their core competency get automated. The transition to systems architect requires fundamentally different skills — and not everyone will make it.

Nico Druelle says it plainly: “There will be less analyst/admin-only roles. AI will take that over. The reality is: most won’t make the transition.”

Kyle Norton captures the urgency: “If your RevOps team has not already evolved, you’re in serious trouble. We’re over 24 months into the AI era, and if your team is operating the same way it did two years ago, that’s not the right leadership.”

This isn’t just organizational restructuring. It’s a workforce transformation that will leave some people behind.

Five Things Revenue Leaders Should Do Right Now

1. Audit your team against the bifurcation. Which path are your people on? If the majority of time goes to CRM admin, reporting, and manual data work — you’re building on a foundation AI is about to automate.

2. Invest in data foundations before AI deployment. The universal prerequisite. Every single leader I’ve talked to converges on this. If your data is fragmented, AI will amplify the mess.

3. Hire (or develop) GTM Engineers — across the full bowtie. Target RevOps managers and data engineers who can write Python, design APIs, and think in systems. But mandate that at least half their capacity touches post-sale systems.

4. Restructure RevOps as a product team. Stop running it as a service desk with a ticket queue. Organize around product ownership of the revenue system — sprint cycles, user research, dedicated engineering capacity.

5. Manage the human transition deliberately. Acknowledge the anxiety. Invest in upskilling. Create clear career paths from admin to architect. Be honest about which roles are evolving and which are disappearing.

The Bottom Line

RevOps is not dying. But the RevOps most companies have today — reactive, admin-heavy, CRM-centric — is.

What’s emerging is more ambitious, more technical, and more strategically important than anything the function has been before. The Growth Architect doesn’t just support the GTM motion. They design it.

As Jacco van der Kooij puts it: “Once you see growth as a system to be designed rather than a funnel to be staffed, you start to understand why 2026 marks a true inflection.”

The RevOps evolution isn’t about AI replacing people. It’s about AI revealing which people — and which organizational designs — were built for a world that no longer exists.

Go Deeper: The Full Interactive Research Brief

I put together a comprehensive interactive research brief that covers everything in this article and more — including the recommended org chart for the future RevOps team, the four-pillar model, compensation data, the full talent analysis, and the contrarian GTM Engineer argument in detail.

Paid subscribers can dive into the full interactive brief here

Read more