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

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

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

And it still screws up the 10-step process your team uses to qualify enterprise deals.

Not because it’s dumb. Because nobody taught it how your team actually works.

This is the gap that’s quietly killing agentic AI deployments across B2B — and it’s the same gap I kept hitting when I built out 60+ agents across our own GTM operation. The agents were powerful. They had tools. They had models. They had access. And they kept doing things wrong in ways that were expensive to debug and embarrassing to explain.

The fix wasn’t better models. It was a concept most teams haven’t encountered yet: Skills.

The Distinction That Changes Everything

Here’s the cleanest way I can frame it, borrowed from Christopher Penn: agents are like employees in departments — HR, Finance, Sales. They’re vertical. Domain-specific. They own a function.

Skills are like apps those employees use — Excel, Salesforce, your internal wiki. Horizontal. Reusable across departments. Any employee can pick them up.

Another way to think about it: tools let agents act. Skills provide the knowledge of how and when to act — including the company-specific, team-specific, and user-specific context that separates a capable AI from a competent one.

That last sentence is the whole game.

What Agents Actually Are

An agent is a full decision-making entity. It has a system prompt (its identity and instructions), tool access (what it can do), a backing model (Claude, GPT, etc.), and an agentic loop that lets it orchestrate workflows and manage state.

Think of it as an autonomous AI pre-prompted to handle a specific kind of task — debugging code, acting as the voice of the customer, running a competitive analysis, being a virtual CMO. Agents are vertical. They do one specific kind of work within a domain.

In systems like Claude Code (which I use daily), agents even have their own working memory — a little sandbox where they maintain context about what they’re doing and why.

In our system, agents are the parallel workers. Standalone files that execute work concurrently. They invoke skills and workflows as needed. But the agent itself? It’s the who. It owns the decision-making.

What Skills Actually Are

Skills are something different entirely. They’re modular, declarative bundles of expertise — organized procedural knowledge packaged into reusable units that agents load as needed.

Practically? A skill is a folder containing a SKILL.md file (the playbook), optional scripts, templates, and reference docs. It’s a standardized format that packages procedural knowledge and context for agents to load on demand.

The critical word there is “on demand.”

Because here’s where the architecture gets interesting.

Below I will share how to build them, when to use them, and give you a comprehensive step by step guide.

Read more

According to 6sense’s 2025 Buyer Experience Report, 94% of B2B buyers are now using LLMs during their buying process. Not “experimenting with.” Not “curious about.” Using. Actively. Right now. While your reps are still manually updating Salesforce fields and searching for that one case study th…

Read more

The tech press called it “an agent management platform.” Fortune called it OpenAI’s bid to become “the operating system of the enterprise.” Gartner called agent management platforms “the most valuable real estate in AI.”

…

Read more

You still need to find the right customers. Communicate value. Build relationships. Close deals. Deliver outcomes. Expand accounts.

None of that is different.

What’s changing—rapidly—is how we solve for those fundamentals.

For decades, we’ve thrown people and process at every GTM problem. Pipeline weak? Hire…

Read more

The gap between belief and execu…

Read more

Five percent.

Meanwhile, 60% are achieving no material value at all—despite pou…

Read more

None of it mattered.

Netflix won because they understood something Blockbuster couldn’t see: the value wasn’t in physical distribution. It was in knowing what you wanted to watch before you knew it yourself.

That same moment is happening right now in go-to-market.

But instead of physical vs. streami…

Read more