The LeanScale Podcast · Episode 118

Convert Your Entire CRM to Apex

Steve Dinner on why the two-week sprint is finished, the three tracks and two gates replacing it, the 29:1 RevOps ratio he had to right-size, and why an LLM should manage your CRM like a code base

Steve Dinner · VP of Revenue Operations, Owner.com · Owner.com Hosted by Anthony Enrico
Published Updated 00:53:13 41 min read 8169 words
Revenue Operations AI in GTM GTM Strategy Sales Leadership
▸ Listen on Spotify Watch on YouTube Apple Podcasts
SummaryTakeawaysFrameworksQuotesAdviceAIEntitiesMetricsFAQTimelineTranscript
Executive Summary

The one-paragraph brief, extended

Why this conversation matters — and who should spend the hour.

Steve Dinner, VP of Revenue Operations at Owner.com, returns to argue against himself. The install he was proudest of on his first appearance was agile. Now he tells Anthony Enrico the two-week sprint no longer works and he is pulling some of those wires back out, blaming a collapsing of skill and technical knowledge on the AI front. He still believes strong process creates a strong team — he just wants to be anti-dogmatic about what to keep, modify and throw away, and is telling the teammates who love agile most that somebody is going to write the book on whatever comes next.

The economics drive it. The build is now cheap: set up correctly, a first pass — if not the whole thing — can be done by AI deploying to a sandbox. That moves the cost, and the importance, to scoping, planning and the unglamorous work of testing. The two-week bucket stops making sense when everything short of a business-continuity P0 is treated the same and work finished on day three waits for the deployment date. So triage moves to the front and becomes a risk question — can this hurt anything or cause permanent damage? — assessed agentically, routing each request down one of three tracks.

What forced the change was his users. Walking Owner.com's sales floor, Steve sees a BDR director who screenshotted a custom interface, told Claude what he wanted, hit the Salesforce MCP and now has something shockingly like the app Steve deployed; an SDR on Cursor asking for an API key he will not hand over; custom spiff trackers on the TVs. After years of telling sellers to adapt or end up jobless, RevOps cannot insist the systems are still its systems. His answer: stay rigid about business logic, democratize the experience layer, and host what people build internally, Vercel-style, because shadow-IT sprawl arrives anyway. The target architecture is one custom app per role, plus two gates — an agent modelled on the teammate who tears briefs apart, then the architect on solution design.

Does AI let RevOps run leaner? No. There was no AI jobs apocalypse; people captured more territory, and more delivered work means more maintenance, refactoring and testing. What changes is allocation. On investment he anchors on a baseline ratio, which gets heavier further down market: an enterprise startup can reach its first 30 or 40 reps on one talented technical operator, while a fixed-price, low-ACV business needs excellence at every point of a high-denominator funnel — roughly 15:1 to start, 25:1 with scale. He once measured 29:1 and right-sized it. On budget his advice is behavioural: make your first dollars-and-cents conversation with finance one where you protect it.

The heresy comes last. Steve first floated converting an entire CRM to Apex as a deliberately inflammatory interview question, to see whether a candidate wanted to create the future or wait for someone else to cross the chasm. The belief underneath is real: an LLM manages a CRM better as a code base. He calls the visibility objection uninspired — an SOP or a generated Mermaid diagram replaces what a flow drew for you. Handed his nastiest activity flow with free range to rebuild it in Apex, a model got through much of the testing in hours and surfaced two bugs. This is not drop everything and convert; it is why wouldn't you start.

Key Takeaways

14 things worth stealing

The load-bearing ideas, each with the business implication and who should care.

01

The two-week sprint stopped serving the business

For the majority of requests and deployments, Steve argues the sprint no longer fits the way things move, and holding onto it paints RevOps in the wrong light. Under a sprint, everything that is not a business-continuity P0 falls into the same two-week bucket, and work finished on day three sits there until the deployment date.

Why it matters: You can patch it — add a second deployment date, keep more of what you like — but that does not address the fact that everything gets treated the same unless it is a four-alarm fire, and it does not address what has changed in your stakeholders' heads.

RevOps LeadersRevenue Executives
02

The build got cheap, so planning and testing became the expensive work

With everything set up correctly, a first pass — if not the whole thing — can be done by AI deploying to a sandbox, with more complexity once managed packages and additional systems are in the mix. AI is built to do software development in the first place, so you do not have to invest as much time teaching it, beyond the quirks of developing in Salesforce.

Why it matters: Scoping and planning were always supposed to be the most important part; now the not-fun part, all the different types of testing, gets more important too. Steve's conclusion is that the value of your planning system and your testing system just went up and has to be funded accordingly.

RevOps LeadersRevenue Executives
03

Triage moves to the front and becomes a risk question

Triaging has always existed inside agile. Steve wants it happening out front and by a different mechanism: what is the likelihood that this can hurt anything or cause any permanent damage? He runs that risk assessment agentically, and the result decides which of three tracks the request goes down.

Why it matters: Deploying on the basis of complexity and risk rather than a calendar bucket is what lets low-risk work ship on the day it is ready without loosening control over anything that could break the business.

RevOps Leaders
04

Three tracks replace one sprint: skin, metadata, project

Track one is a skin update to a custom app that cannot hurt performance, touch metadata, flows or business logic, or create a security issue — it hits the board overnight, someone develops it, someone looks at it, it goes out. Track two is a small metadata change that still needs a human in the loop but is quicker and on demand. Track three is project work that looks much like the agile process his team runs today.

Why it matters: Steve describes it as regular agile with one or two more models stacked on top, and says the first two categories are where the real difference is. The big projects no longer eat the middle of the process, which affords more time to do the rest better.

RevOps LeadersRevenue Executives
05

Two gates stand in front of every request

Steve has one person on his team who is very good at beating the crap out of a brief — why does the business actually want this, no, why do they actually want this, get to the why, get to the value. He wants an agent version of that person, trained on that person's comments and transcripts of them ripping briefs apart, as gate number one. Gate number two is the architect on the solution design.

Why it matters: Done well, the first agent stops someone in their tracks and says you have asked for this but what you actually want is that — so a meaningfully better thing gets deployed without consuming the team's time the way that argument normally would.

RevOps Leaders
06

One custom app per role creates a surface that is safe to change

SDR, BDR, account executive, launch specialist, integration specialist, strategic CSM — each gets a fully custom experience layer that can be modified without touching much metadata or business logic. Steve calls it creating a reality where there is something to modify that does not touch the things you cannot let go of.

Why it matters: That architecture is what makes the happy path possible: a request that only changes the skin, passes the two gates and carries no risk can go straight to development and out the door.

RevOps Leaders
07

Be rigid about business logic, democratize the experience layer — and host the sprawl yourself

Steve's dividing line is that business logic and plumbing stay tightly controlled while the experience and application layer gets opened up. He points at Vercel as the inspiration — any user, any little use case, host something — and says his team has an internally built version that does exactly that.

Why it matters: If you do not give people a way to host what they build, the shadow-IT sprawl gets huge anyway. Bringing it into the fold also lets you browse what people made and promote the one that is genuinely special.

RevOps LeadersRevenue Executives
08

Your users' expectations changed, and RevOps cannot be hypocritical about it

Walking the sales floor, Steve sees a BDR director who screenshotted a custom interface, told Claude what he wanted, hit the Salesforce MCP and now has an interface shockingly like the one Steve deployed. He sees an SDR on Cursor asking for an API key he will not give, and custom incentive trackers for spiffs on the TVs.

Why it matters: After years of telling sellers that if they did not learn this technology they would end up jobless, you cannot then insist the systems are still your systems. Ignore that psychology and you become the shop nobody asks anymore because they do not expect help.

RevOps LeadersSales LeadersRevenue Executives
09

AI does not shrink the RevOps team — it moves where the allocation goes

Steve's read is that there was no real AI jobs apocalypse; everyone worked longer and harder and saw they could capture more territory. More available headcount is just more territory you can capture. He has seen no opportunity to reduce the team and still produce the output he wants.

Why it matters: What changes is allocation: he would probably not continue hiring offshore devs, because the ones he has can be supercharged. And when more work is delivered you need more people on maintenance, refactoring and testing.

RevOps LeadersRevenue ExecutivesFounders
10

The RevOps ratio gets heavier the further down market you are

An enterprise startup can do a lot with one really talented technical RevOps person with a strategic mind — Steve bets you could reach your first 30 or 40 reps that way with AI, because the number of deals needed to hit target is low and one deal can make the quarter. The inverse is a fixed subscription price with a take rate and little ACV variation, where every customer needs the same treatment and the denominators in every conversion rate are high.

Why it matters: That second environment demands technical excellence at many points in the funnel, so the ratio has to be much tighter — around 15:1 or 20:1 to start, expanding toward 25:1 as you get bigger. Steve remembers running the exercise, finding they had reached 29:1, feeling it, and right-sizing.

RevOps LeadersRevenue ExecutivesFounders
11

Make your first dollars conversation with finance a defense, not an ask

RevOps has a natural alliance with finance because of the sheer number of dollars that run through it or that it can affect. Steve starts building that long before any request: heads up, I am swapping this software spend for a cheaper one, expect two contracts instead of this big one.

Why it matters: It is a challenging position to have your first serious dollars-and-cents conversation be the ask. Everyone knows to tie spend to ROI and speak finance's language; Steve's addition is behavioural — be a good steward first, and establish yourself as credible rather than another person with their hand out.

RevOps LeadersRevenue Executives
12

Convert the CRM to Apex so an LLM can manage it like a code base

Steve had the thought early in the year building his first custom Salesforce MCP with an external app: lightning layouts did not go well, UI work and large flow edits were weak, but Apex — creating and modifying metadata — crushed it. Flows and FlexiPages are long, verbose XML underneath and not quite code, so a model struggles to verify it got them right and leaves you a tail of fiddly UI steps.

Why it matters: He first used the claim as an interview filter to see whether an architect candidate wanted to create the future or wait for someone else to cross the chasm. The real position is softer than the headline: not drop everything and convert, but why wouldn't you start.

RevOps LeadersRevenue Executives
13

The visibility objection is uninspired — and an LLM found two bugs in his worst flow

Almost every candidate objected that you lose the visual documentation a flow provides, or that a human can no longer make a quick fix. Steve's answer is to build an SOP, or have the automation generate a Mermaid diagram stored wherever you keep documentation, and make that part of your principles for managing LLM builds. The most interesting answer he got was that you may not run toward Apex but you start solving new problems there anyway, once a large enough flow hits race conditions and timeouts.

Why it matters: He tested it: he found his nastiest activity flow, gave a model free range to wipe it out and rebuild it in Apex, and it got through a significant amount of the testing and surfaced two bugs it could not replicate because it did not believe the behaviour was intended — in a matter of hours.

RevOps Leaders
14

Headless or not is the wrong question; do not automate away the rep's understanding

A year out, Steve says it can run headless or as a custom app inside Salesforce and it does not really matter. The real question is whether you can put the data people need in front of them — and whether the outcome improves. He cites a RevOps leader he could not place who filled MEDDIC fields from transcripts and then turned it off, because reps stopped knowing their deals once they no longer had to do the work.

Why it matters: Steve's line is that if he could autopilot sales he would, but there is something special about salespeople, implementation and CSM teams. Make the interface as cognitively light as possible — even a phone app where you swipe deals in and out of forecast — but where he needs their attention he still needs their attention.

RevOps LeadersSales LeadersRevenue Executives
Frameworks Discussed

8 named models

Every framework Jimmy names, defined and time-stamped.

Risk-Based Triage at the Front Door

05:45

Replacing the sprint bucket with a triage question asked before anything is scheduled: what is the likelihood that this can hurt anything or cause any permanent damage? The assessment is done agentically and its output routes the request to one of three delivery tracks.

Steve's objection to the sprint is that everything is treated the same unless it is a four-alarm fire. Deploying on the basis of complexity and risk instead lets safe work go out when it is ready while anything that could cause permanent damage keeps its gates.

Three Tracks: Skin, Metadata, Project

14:55

Track one is an experience-layer skin change on a custom app that touches no metadata, flows or business logic, creates no security or performance issue, and can go straight to development and out. Track two is a small metadata update that still needs a human in the loop but runs on demand. Track three is project work that resembles the agile process the team already runs.

Steve describes it as regular agile with one or two more models stacked on top. Keeping the first two tracks out of the sprint stops big projects from consuming the middle of the process and frees time to do planning, testing, rollout and communication better on the third.

Two Gates Before Anything Gets Built

13:51

Gate one is an agent modelled on the teammate who is best at interrogating a brief — trained on that person's comments and transcripts of them ripping briefs apart — which forces a request back to the underlying why and the value. Gate two is the architect reviewing the solution design.

Steve pairs the gates with a classic agile intake shape: as a, I want to, so that I can. Done well, gate one stops a requester and reframes what they actually want, so the argument that improves the request no longer has to consume his team's time.

One Custom App Per Role

14:18

Giving each role — SDR, BDR, account executive, launch specialist, integration specialist, strategic CSM — a fully custom experience layer that can be modified without touching metadata or business logic.

The architecture exists to create something safe to change. It is the precondition for the fast track: a request that only alters the skin carries no risk, so it can pass the gates and ship overnight with a single human confirmation.

Rigid Business Logic, Democratized Experience Layer

10:11

Holding business logic, automations and plumbing under tight control while deliberately experimenting with ways to open up the experience and application layer — including hosting internally built user creations the way Vercel hosts small projects.

Steve's reasoning is that shadow-IT sprawl arrives whether or not you sanction it, so giving people a place to host what they build brings it into the fold, lets you find the one that is genuinely special, and keeps the reins on the parts you cannot let go of.

The RevOps Ratio

25:59

A baseline ratio of go-to-market headcount to RevOps headcount used as the starting point for an investment conversation, with any deviation from it tied to particular metrics.

Steve's version inverts the intuition: enterprise startups can run light — one talented technical RevOps person through the first 30 or 40 reps — while fixed-price, low-variance businesses need a much tighter ratio because excellence is required at many points in a funnel with very high denominators. He puts that at roughly 15:1 or 20:1 at the start, expanding toward 25:1 with scale, and calls the 29:1 he once measured a big problem.

Bank Goodwill With Finance Before the Ask

31:30

Deliberately making your first dollars-and-cents conversation with finance one where you protect budget — flagging a cheaper software swap, consolidating contracts — so the relationship is established long before any request for resource.

RevOps has a natural alliance with finance given the dollars that run through it. Steve's point is behavioural rather than analytical: tying spend to ROI is table stakes, but credibility as a steward of the company's finances is what makes the ask land.

CRM as a Code Base

36:22

Converting declarative Salesforce configuration to Apex on the belief that it is easier for an LLM to manage the whole system the way it would a code base, replacing flow diagrams with SOPs and generated Mermaid diagrams as the documentation layer.

Steve found that models create and modify metadata in Apex extremely well while struggling with lightning layouts, UI work and large flow edits, because flows and FlexiPages are verbose XML that is not quite code and cannot be verifiably checked. Managing the backend this way is what frees the resources to build the democratized front end.

Best Quotes

20 lines worth clipping

Pulled verbatim. Copy or share any of them.

“Okay, we need to be anti-dogmatic here about what we're going to hold on to and what we're going to throw away.”
Steve Dinner 02:30
“So I'm really at the point where I'm looking at it and I'm saying the build is super cheap now.”
Steve Dinner 04:20
“But in general, I think the value of your planning system and the value of your testing system just went up and you have to now invest a lot more heavily in your effort there.”
Steve Dinner 05:30
“What is the likelihood that this can hurt anything or cause any permanent damage?”
Steve Dinner 05:57
“I'll look over and I'll see a BDR director who's got a Claude artifact that looks just like something that I deployed that's custom for a different use case.”
Steve Dinner 07:55
“And we've just spent years telling them that if they didn't adapt and learn to use this technology, they were going to end up jobless.”
Steve Dinner 08:41
“The concept should be that you want to be really rigid about your business logic and any of the plumbing, and you want to be really experimenting with ways to democratize your experience layer.”
Steve Dinner 10:11
“We always say the ad hoc is where you win hearts and minds.”
Anthony Enrico 18:45
“There was no real AI jobs apocalypse. Everybody just works longer, harder, saw that they could capture more territory.”
Steve Dinner 21:20
“I remember doing this exercise and seeing that we had gotten to 29 to one and being like, 'Oh, that is a big problem.'”
Steve Dinner 28:31
“I do everything I can to make the first dollars and cents conversation I have being me protecting the budget.”
Steve Dinner 32:05
“If I want to change the whole CRM to Apex, because I believe this, that it's easier for an LLM to actually then just manage the whole thing like you would a code base.”
Steve Dinner 36:22
“If you want the visual documentation that a flow provides, build an SOP.”
Steve Dinner 36:52
“It got through a significant amount of the testing and was able to actually find two bugs in the flow.”
Steve Dinner 39:09
“So it's not a drop everything and convert all your stuff to Apex. It's more of a, 'Why wouldn't you start?'”
Steve Dinner 40:56
“Why would you be stuck to this Windows XP looking thing? I don't think you would.”
Steve Dinner 41:30
“And it's so ironic that Flow is what made everything so easy compared to what you were doing before. And now it's like running through molasses when you're trying to build things.”
Anthony Enrico 41:38
“They actually turned it off because they found that the reps didn't know their deals because they didn't have to do that.”
Steve Dinner 43:25
“If I could get better outcomes with a pen and paper than I could with Salesforce, then I would use it.”
Steve Dinner 44:23
“If you want a CRM that you can unleash AI on, you should go to Salesforce. It's the most AI-friendly CRM there is.”
Anthony Enrico 49:34
Practical Advice

What should you actually do?

The playbook, split by the seat you sit in.

RevOps Leaders

  • Audit your process component by component and ask what value each one brings, what you keep, what you modify and what you throw away — rather than defending the methodology as a whole.
  • Move triage to the front door and make it a risk question: can this hurt anything or cause permanent damage? Route the answer to a track instead of a two-week bucket.
  • Run three delivery tracks — experience-layer skin changes, small metadata updates, and projects — and accept that only the third still looks like a sprint.
  • Build the architecture that makes a safe track possible: one fully custom app per role, modifiable without touching metadata or business logic.
  • Put two gates in front of every request — an agent that interrogates the brief back to the underlying value, then the architect on solution design.
  • Reinvest the time the cheap build gives you into scoping, planning and every type of testing; that is where the value moved.
  • Give people a sanctioned place to host what they build, or the shadow-IT sprawl happens without you — then promote the ones worth standardising.
  • Replace the documentation a flow used to provide with SOPs and generated diagrams, and write that into your principles for how LLM builds are managed.
  • Pick your gnarliest flow, give a model free range to rebuild it in Apex, and treat the exercise as a test of both the approach and the flow's hidden bugs.
  • Establish a baseline RevOps ratio and tie every deviation from it to a metric, rather than negotiating headcount in the abstract.

Revenue Executives

  • Expect your RevOps team to ship small, safe improvements continuously; being slow on quality-of-life changes is now a credibility problem, not just a throughput one.
  • Do not assume AI lets you shrink RevOps — more delivered work creates more maintenance, refactoring and testing, and the leverage shows up as more territory covered.
  • Look at allocation rather than count: capacity that used to go to outsourced development can move to people who can diagnose, design and scope.
  • Set the RevOps ratio against your motion, not your peers — low-ACV, high-denominator funnels need a tighter ratio than enterprise ones.
  • Do not let the first budget conversation with finance be the ask; the credibility is built during the periods when nobody needs anything.

Founders

  • Early on, one talented technical RevOps person with a strategic mind can carry an enterprise motion a long way — Steve's bet is the first 30 or 40 reps with AI.
  • If your business runs on a fixed subscription price and a take rate with little ACV variation, staff ops far more tightly, because every customer needs the same treatment.
  • Getting RevOps development right in step with sales scaling is what creates repeatability, playbooks and the ability to onboard reps reliably.
  • Treat enablement as the twin of RevOps in that scaling sequence rather than a later hire.
AI Takeaways

How AI actually changes GTM

LeanScale's signature read on the AI-in-GTM question this episode wrestles with.

The thesis

Steve's argument is that agentic tooling has collapsed the cost of building, and that this breaks the process rather than just speeding it up. When a first pass can be generated into a sandbox, the scarce work becomes scoping, planning, testing and — above all — deciding what risk a change carries. That makes triage an agentic risk assessment rather than a calendar exercise, turns the brief interrogation and the architectural review into gates an agent can hold, and makes the CRM itself worth converting to Apex so an LLM can manage it like a code base. The second half of the argument is social: end users have already seen what they can build, so RevOps has to open the experience layer or become the shop nobody asks.

Agent & automation ideas

  • A risk-assessment agent at intake that scores each request for potential permanent damage, security exposure and performance impact, then routes it to the skin, metadata or project track.
  • A brief-interrogation agent trained on the comments and meeting transcripts of the teammate who is best at pushing a requester back to the underlying value, run as the first mandatory gate.
  • A solution-design gate modelled on the architect, applied after the brief passes and before anything is built.
  • An overnight development agent for experience-layer-only changes that hits the board, builds the change and leaves a single human confirmation before release.
  • A flow-to-Apex conversion agent that rewrites a nominated flow, runs the test suite, and reports behaviours it cannot replicate as suspected bugs rather than silently preserving them.
  • A documentation agent that emits an SOP and a Mermaid diagram for every automation it builds, so visual documentation survives the move off Flow Builder.
  • An internally hosted, Vercel-style platform where any employee's small app is deployed, reviewed and — when it is genuinely good — promoted to everyone.
  • A cognitively light mobile forecast app where a rep swipes deals in and out of forecast instead of editing fields in a CRM.
Operations Takeaways

By function

The same conversation, filtered for RevOps, pipeline/marketing ops, and customer ops.

Revenue Operations

  • .
  • .
  • .
  • .
  • .
  • .
  • .
Metrics Mentioned

The numbers, with context

2 weeks
Sprint length being retired

The bucket everything that is not a business-continuity P0 used to fall into, including work that was finished on day three and then sat until the deployment date.

3
Delivery tracks replacing the sprint

Experience-layer skin changes that can ship straight through, small metadata updates with a human in the loop, and projects that still resemble the agile process.

2
Gates every request must pass

An agent modelled on the teammate who interrogates briefs, then the architect on solution design.

1 per role
Custom apps in the target architecture

SDR, BDR, account executive, launch specialist, integration specialist, strategic CSM — each with an experience layer that can be modified without touching metadata or business logic.

37
User stories in the enabling epic

Written by Steve's solution architect. The first 30 are routine security, governance and tech-debt work; the last 7 are where the ability to democratize the experience layer gets unlocked.

15:1, or 20:1
RevOps ratio Steve considers the ideal start

Go-to-market headcount per RevOps person in a business where ACVs do not vary much and every customer needs the same treatment.

About 25:1
RevOps ratio at greater scale

Where Steve says the ratio can expand to as the company gets bigger, before specialization and scale flatten it out.

29:1
The ratio that signalled a problem

What Steve found when he ran the exercise. He describes it as a big problem they were already feeling, and right-sized it.

First 30–40 reps
Reps one technical RevOps person can support in an enterprise motion

Steve's bet for an enterprise startup with AI, where deal counts to target are low and one deal can make the quarter or the year.

Three months to a day
Project timeline collapse

Anthony's example of analyses and models he used to disqualify on effort alone and can now complete in a day, which is why he sees more investment in RevOps rather than less.

A matter of hours; 2 bugs found
Apex rewrite of the gnarliest flow

A model given free range to wipe out and rebuild one of Steve's activity flows in Apex got through a significant amount of the testing and surfaced two behaviours it could not replicate because it did not believe they were intended.

10
Design iterations before deploying

Steve's contrast with clicking through Flow Builder or a FlexiPage: design whatever you want, get ten iterations of it, hit deploy.

10 minutes
Ad hoc turnaround that wins hearts and minds

Anthony's example of the response time that changes how a stakeholder feels about ops, against a request they assumed would be a multi-week job.

Entities

Companies, people & tools mentioned

Auto-extracted and linked into the knowledge graph.

Companies

Owner.comRestaurant Technology / SaaS

Steve's employer, where he is VP of Revenue Operations. In the episode it is the large sales office he walks — BDR directors building their own Claude artifacts, SDRs on Cursor, spiff trackers on the TVs — and the fixed-subscription-plus-take-rate business whose low ACV variation drives the tighter RevOps ratio he describes.

00:02 · 07:48 · 27:45Company →
LeanScaleGTM Operations

Anthony's firm. He offers LeanScale's delivery model as the parallel to Steve's tracks: an architect as point person, a project engineer on the big needle movers and an ad hoc engineer on the simple stuff — with ad hoc as where you win hearts and minds.

18:33Company →
OracleEnterprise Software

Steve's analogy for what happens to Salesforce. Ten years ago you might have assumed Salesforce would make Oracle less valuable; instead Oracle is more valuable than it has ever been, which is how he expects incumbency, legacy customers and regulated industries to play out.

47:08Company →

People

Steve Dinnerguest

VP of RevOps at Owner.com; an ex-BDR leader who runs a high-output RevOps function on structure and agile — zero in-house admin/dev FTEs — and is an aggressive adopter of AI for RevOps.

VP of Revenue Operations, Owner.comProfile →
Anthony Enricohost

Co-founder of LeanScale and host of The LeanScale Podcast.

Co-FounderProfile →

Tools & software

SalesforceCRM

The CRM at the centre of the episode. Steve argues lightning layouts, UI work and large flow edits go badly for an LLM while Apex metadata work crushes it, and credits Salesforce for embracing MCP and the CLI and for an acquisition strategy aimed at specialized agentic use cases — possibly letting it shed legacy interface code entirely.

Website ↗
Model Context Protocol (MCP)AI Integration Protocol

Steve built his first custom Salesforce MCP with an external app early in the year, which is where the Apex conviction started. On the sales floor, a BDR director hits the Salesforce MCP from a Claude artifact to reproduce an interface Steve had deployed.

Website ↗
ClaudeAI Assistant

The tool the BDR director uses to turn a screenshot into a working custom interface, and the model Steve was talking to when he first noticed that flows and FlexiPages are verbose XML an LLM cannot verifiably check while Apex metadata work goes well. Transcribed by whisper as 'cloud'.

Website ↗
CodexAI Dev Tool

Named alongside Claude as the coding agents you can get more out of by teaching them the quirks of developing in Salesforce. Transcribed by whisper as 'a codex'.

Website ↗
CursorAI Dev Tool

What an SDR on the sales floor is running while asking Steve for an API key he is not going to hand over — one of his examples of end users already building without RevOps.

Website ↗
FableAI Model

The model Steve put on when he handed over his nastiest activity flow with free range to wipe it out and rebuild it in Apex; it got through a significant amount of the testing and surfaced two bugs in a matter of hours.

Website ↗
VercelDeployment / Hosting

Steve's reference point for democratizing the experience layer — a platform designed so any user with any little use case can host something. His team has an internally built version that does exactly this, to keep shadow-IT sprawl inside the fold.

Website ↗
MermaidDiagramming / Documentation

Steve's replacement for the visual documentation a flow provides once automations move to Apex: have the automation produce a Mermaid diagram and store it wherever documentation lives, as part of the principles governing LLM builds.

Website ↗
SlackTeam Messaging

Named as Salesforce's own bet on the front end of a headless CRM — a view Steve says he held himself for some time, though he now thinks fully headless is one way rather than the only way.

Website ↗
Google SheetsProductivity / Spreadsheet

Anthony's analogy for democratized building: nobody would tell a BDR they are not allowed to use Google Sheets, even though what they build is not the financial model the business runs on.

Website ↗
Google SlidesPresentation Software

Used with Google Sheets in Anthony's analogy — you do not stop a seller from building their own presentations just because the board deck is held to a different standard.

Website ↗
X (Twitter)Social Platform

Where Steve reads upstream. He follows the most serious people using AI for software development rather than RevOps commentary, which he considers lagging, and says that ecosystem tends to be Twitter.

Website ↗
Methodologies referenced Agile and the two-week sprintP0 triageAs a / I want to / so that I canOne trigger type per objectMEDDICProjects and ad hoc as two delivery lanes
Related LeanScale Services

Where this shows up in the work

Fractional RevOps

Embedded, field-facing RevOps leadership and execution — the operator model Jimmy describes, delivered as a service.

Steve's operating model for a RevOps function — risk-based intake, three delivery tracks, the ad hoc versus project split, and sizing the team against a ratio rather than a wish list.

AI for GTM

Agents and workflows that multiply operator throughput — the 'make humans superhuman' thesis, operationalized.

The agentic pieces he is building: an intake risk assessment, agent gates on briefs and solution design, and an LLM managing CRM configuration as code.

Frequently Asked Questions

Straight answers

Generated from the conversation, marked up for search and AI extraction.

Why does Steve Dinner say the two-week sprint no longer works for RevOps?

Steve Dinner, VP of Revenue Operations at Owner.com, argues that for the majority of requests the sprint no longer serves the business or paints RevOps in the right light. Under a sprint, anything that is not a business-continuity P0 falls into the same two-week bucket, so a change finished on day three sits until the deployment date. Two things broke it: AI collapsed the cost of building, so a first pass can often be generated into a sandbox, and end users have seen what they can build themselves and now expect software to appear quickly. He still believes strong process creates a strong team — his point is to be anti-dogmatic about which components to keep, modify and throw away.

What replaces the sprint in Steve Dinner's RevOps model?

Triage moves to the front door and becomes a risk question — what is the likelihood this can hurt anything or cause permanent damage? — assessed agentically. The answer routes the request down one of three tracks. Track one is an experience-layer skin change on a custom app that touches no metadata, flows or business logic and creates no security or performance issue; it can hit the board overnight, be developed, reviewed by one person and released. Track two is a small metadata update that still needs a human in the loop but runs on demand. Track three is project work that looks much like a traditional agile process. Every request also passes two gates first: an agent that interrogates the brief back to the underlying value, then the architect on solution design.

Why would anyone convert a Salesforce org to Apex?

Steve Dinner's claim is deliberately inflammatory — he first used it to test how an architect candidate would react — but the belief behind it is that an LLM can manage a CRM more effectively when it is code. Building his first custom Salesforce MCP, he found models handled creating and modifying metadata in Apex extremely well, while lightning layouts, UI work and edits to large flows went badly, because flows and FlexiPages are long, verbose XML that is not quite code and cannot be verifiably checked. Moving business logic to code means less time in setup clicking buttons, which frees the capacity to build the custom experience layer users now expect. His practical framing is not drop everything and convert, but why wouldn't you start.

What is the most common objection to putting a CRM in Apex, and what is the answer?

The objection Steve Dinner heard from almost every architect candidate was that you lose the visual documentation a flow provides, or that a human can no longer make a quick fix. He calls that an uninspired interpretation: if you want the visual documentation, build an SOP, or have the automation generate a Mermaid diagram and store it wherever your documentation lives — and make that part of your principles for how LLM builds are managed. The most interesting answer he received was that you would not run toward Apex, but you would start solving new problems there anyway, because a large enough flow eventually hits race conditions and timeouts.

Does AI reduce the size of a RevOps team?

Steve Dinner says no. His read is that there was no real AI jobs apocalypse anywhere — people worked longer and harder and saw they could capture more territory, so more available headcount simply means more that can be done. He has seen no opportunity to reduce his team and still produce the output he wants, partly because delivering more work creates more demand for maintenance, refactoring and testing. What does change is allocation: he would probably not continue hiring offshore developers, since the ones he has can be supercharged. Anthony Enrico adds that he sees more investment in RevOps, because analyses he used to disqualify as three-month projects can now be done in a day.

What is a good RevOps ratio?

Steve Dinner recommends establishing a baseline ratio of go-to-market headcount to RevOps headcount as the starting point for any investment conversation, then tying every deviation from it to particular metrics. Counter-intuitively, the ratio should be heavier the further down market you go. An enterprise startup can get a long way on one talented technical RevOps person — he would bet through the first 30 or 40 reps with AI — because the number of deals needed to hit target is low and one deal can make the year. A business with a fixed subscription price and a take rate, where ACVs do not vary much, needs technical excellence at many points in a funnel with very high denominators, which he puts at roughly 15:1 or 20:1 to start and expanding toward 25:1 with scale. He describes reaching 29:1 as a big problem they were already feeling and had to right-size.

How should a head of RevOps ask a CFO for more budget?

Steve Dinner's advice is that the work starts long before the ask. RevOps has a natural alliance with finance because of the volume of dollars that run through it or that it can influence, so be as good a partner as possible first: flag that you are swapping a software contract for a cheaper one, or consolidating two into one. Everyone knows to tie spend to ROI and speak finance's language; his addition is behavioural — do not let the first serious dollars-and-cents conversation you ever have be the ask. Make the first one you protecting budget, so you establish yourself as a credible steward of the company's finances rather than another person with their hand out. Anthony Enrico adds that a CFO also wants a clean forecast to run models on, which is something RevOps is uniquely placed to provide.

Will people still log into Salesforce, or should everything be headless?

Steve Dinner is agnostic: it can run headless or as a custom app inside Salesforce, and he does not think it really matters. The question that matters is whether you can put the data people need in front of them so they do their job better, and whether the outcome improves. He notes Salesforce's own bet appears to be Slack as the front end, a view he held himself for a while. He also flags a counterweight: a RevOps leader who auto-filled MEDDIC fields from call transcripts turned it off, because reps stopped knowing their deals once they no longer had to do the work. His conclusion is to make the interface as cognitively light as possible — even a phone app where a rep swipes deals in and out of forecast — while keeping human attention where it is genuinely needed.

Timeline

Jump through the conversation

Click any chapter to open it in the transcript.

00:00Cold open + intro 01:38Why the two-week sprint is finished 04:20The build got cheap. Planning and testing got expensive. 06:35What's left of agile, and what gets thrown away 07:48Walking the floor: a BDR director shipping his own Claude artifact 09:57Rigid business logic, democratized experience layer 12:04The new model: two gates and one custom app per role 14:55Three tracks: skin, metadata, project 21:03Does AI shrink the RevOps team? 24:32What becomes possible when three months turns into a day 25:59The RevOps ratio: 15:1, 25:1, and the 29:1 problem 30:42How to pitch a CFO for budget 33:51The Apex heresy 38:30Handing an LLM the gnarliest flow — and it finds two bugs 41:50A year out: does anyone still log into Salesforce? 46:18What is Salesforce actually worth now? 49:19The most AI-friendly CRM there is 49:46Where Steve goes to learn 51:59Wrap
Full Transcript

The whole conversation

Broken into chapters, searchable, verbatim from the audio. Speakers inferred (not diarized).

Transcript as markdown ↓ Whole episode as markdown ↓
00:00Cold open + intro

0:00 You just really run the risk of being left in the dust.

0:02 Steve Dinner is the VP of Revenue Operations at Owner.com and he's back on the show because

0:08 the operating model he walked us through last time is already being torn apart and rebuilt.

0:14 And this conversation is about what's left of the RevOps job when the cost of building collapses

0:20 and everyone in the company can build.

0:23 I'm really at the point where I'm looking at it and I'm saying the build is super cheap now.

0:28 You have this explosion of creativity and people building things on their own,

0:32 shipping things on their own.

0:33 How are you managing RevOps, managing requests that are coming in, managing rogue applications?

0:42 I walk around the floor and I'll see a BDR director who's got a cloud artifact that looks

0:47 just like something that I deployed that's, you know, custom.

0:51 You made a very bold claim that everyone should be converting their CRM to Apex.

1:01 I need to hear where that's coming from because that has gone against every bit of Salesforce

1:07 advice I've ever heard.

1:08 Why would you be stuck to this like Windows XP looking thing?

1:13 I don't think you would.

1:14 Is there any reason anyone would be logging into Salesforce,

1:18 clicking buttons, or should everything be running headless?

1:22 It can run headless or it can run as a custom app inside of Salesforce.

1:27 I don't think it really matters.

1:28 I'll be back on here being like, "I was wrong."

01:38Why the two-week sprint is finished

1:38 Steve, last time you were on the show, the install you were proudest of was Agile.

1:43 You told me the biggest value that consulting engagement wasn't the project you hired them for.

1:48 It was permanently changing how your team worked.

1:51 A few weeks ago, though, you told me the two-week sprint doesn't work anymore,

1:55 and you're pulling some of those wires back out.

1:58 What happened between the last time we talked to now?

2:01 Well, a lot.

2:02 Obviously, on the AI front, especially, there's just been like a collapsing of skill

2:10 and technical knowledge that's really changed, I think, how you need to operate as a RevOps team.

2:18 And so I would clarify and say that I still think that strong process does create a strong team.

2:24 It's just a matter of looking at the reality of our situation right now and saying,

2:30 "Okay, we need to be anti-dogmatic here about what we're going to hold on to

2:35 and what we're going to throw away."

2:37 And so I have team members who are so in love with the Agile system

2:46 that this has been the way that I've kind of said it is there was waterfall,

2:51 then there was Agile, and Agile was new.

2:53 And it was this thing that was different, but borrowed concepts.

2:59 And I think that it has always been morphing and changing over time anyway.

3:04 And I've kind of said to them, somebody is going to name and write the book on whatever comes next.

3:12 And particularly for a few of my team members who live and breed this stuff

3:16 and who are really, really great at it,

3:18 I don't even particularly consider it to be my personal superpower.

3:22 It's just something that I recognize and believe in.

3:25 There's a few members on my team where I'm kind of encouraging them.

3:27 I'm like, "I want you to be the one that writes the book."

3:30 So let's just take a long, hard look at these processes and ask ourselves,

3:35 "What are the value that each individual component brings?

3:39 What do we keep? What do we modify? And what do we throw away?"

3:41 And so the two-week sprint in particular is an area where I believe that,

3:47 at least for the majority of requests and deployments that you have,

3:52 the way that things are moving, it just doesn't serve the business

3:55 and it doesn't paint RevOps in the right light.

3:59 And so where I used to really rely on that for confidently rolling out really strong,

4:06 tested functional features, I think that you just really run the risk

4:14 of being left in the dust and kind of being viewed in the wrong light

4:17 if you just hold on to these things that no longer serve.

04:20The build got cheap. Planning and testing got expensive.

4:20 So I'm really at the point where I'm looking at it and I'm saying

4:24 the build is super cheap now.

4:26 If you've got everything set up correctly, a first pass,

4:30 if not the whole thing, can be done with AI deploying to a sandbox.

4:37 Obviously, more complexity when you enter managed packages

4:41 and additional systems into the mix,

4:43 but significantly reduced development time.

4:46 But that means that the areas that you typically wouldn't associate

4:53 as the most important, which would be...

4:55 I mean, you should always have considered the scoping

4:58 and the planning process to be the most important,

5:00 but the not fun part, the testing, all the different various types of testing,

5:06 those now just get more important and you have to highlight them

5:09 and you have to spend more time on it.

5:11 I think that a lot of the AI is just built to do software development

5:15 in the first place.

5:17 So you don't actually have to invest as much time in that.

5:19 There are some quirks around how you develop in Salesforce

5:23 that you can kind of get more out of a cloud or a codex by teaching it.

5:30 But in general, I think the value of your planning system

5:34 and the value of your testing system just went up

5:37 and you have to now invest a lot more heavily in your effort there.

5:41 And so it's really just about building around that.

5:45 And where I think triaging has always existed within Agile,

5:51 I want to see that triaging happening out front

5:53 and kind of by a different mechanism, which is just like,

5:57 what is the likelihood that this can hurt anything

6:00 or cause any permanent damage?

6:02 And if it doesn't, you kind of live in an environment

6:05 where software can be created out of thin air

6:08 and your users sort of expect that kind of experience.

6:12 So where possible, I think I actually want to more deploy

6:16 on the basis of complexity and risk.

6:20 And so I have a risk assessment that's done agentically.

6:22 And based off of that, it's going to go down one of three tracks.

6:26 And I think it's a necessary evolution in how we think about

6:31 RevOps and system architecture.

06:35What's left of agile, and what gets thrown away

6:35 Specifically in the Agile methodology,

6:37 what are the components that you think really aren't serving anymore?

6:40 Is it the length of time of two weeks?

6:42 Is that too slow?

6:43 Is it the grooming process?

6:45 Is it the rigidity of locking in the sprint?

6:48 Which components feel like, hey, these just don't fit anymore?

6:51 Yeah, I mean, like it used to really be,

6:55 if you're doing this well,

6:57 a P0 is like, you cannot work on anything else while this is still open.

7:02 And that is a business continuity, bug, failure type of a thing.

7:09 And everything else then just falls into this two week bucket.

7:12 Like, can you get this done in two weeks?

7:15 And if it gets done on day three, it sits there, right?

7:18 Like, and you can, sure, you can say, okay,

7:20 I'm just going to still do the sprint, but I'm going to modify it

7:23 so that I'm going to have two deployment dates or something like that.

7:26 I think that's fine.

7:28 And you can solve the problem that way and keep more of what you like.

7:33 But I don't think it addresses the fact

7:35 that everything is mostly treated the same unless it is like a four alarm fire.

7:40 And I don't think it addresses the psychology of your stakeholders and your end users.

7:46 And that is the part that's changing.

07:48Walking the floor: a BDR director shipping his own Claude artifact

7:48 I walk around the floor.

7:49 We have a huge sales office with basically just sales folks in it.

7:55 And I'll look over and I'll see a BDR director who's got a cloud artifact

8:00 that looks just like something that I deployed that's custom for a different use case.

8:06 And he's just taking a screenshot of it, told the cloud what he wants,

8:12 hit the Salesforce MCP.

8:13 And now he's got an interface that's shockingly like mine.

8:16 And I'll go to the next one and I'll see a personal tracker.

8:20 I'll have like a SDR who's like running around using cursor

8:25 and asking me for an API key for something that I'm unfortunately not going to give.

8:32 I'll see on the TVs like these custom incentive trackers for spiffs and things like that.

8:37 All of this like they know that that can be created.

8:41 And we've just spent years telling them that if they didn't adapt

8:45 and learn to use this technology, they were going to end up jobless.

8:48 So you can't then be hypocritical and sit there as RevOps and say,

8:52 you know what, that's all true.

8:55 But like these systems are still my systems and I'm not going to consider

8:59 the effect that that psychology has had on you and what your expectations are.

9:03 At the end of the day, like the systems are designed to get an outcome from people

9:08 and considering their thought process and their experience

9:12 and what's going on in the world around them is a huge part of that.

9:16 And if you ignore that, then I think that's where you just become the shop

9:19 that nobody asks anymore because they don't think that they're going to get any help.

9:23 Yeah, there's definitely a balance there.

9:25 I think what it feels like is what maybe Google Sheets and Google Slides

9:32 might have been a while ago.

9:34 Like no one would ever say, hey, you're not allowed to use Google Sheets

9:38 because you're in sales or you're a BDR.

9:40 So I don't want you using slides and building your own presentations.

9:44 Now, there might be a difference between whatever they're building

9:46 and the board deck and the financial model that you're running the business on.

9:51 But it doesn't mean you should lock the tools down or not give some access to the ability.

09:57Rigid business logic, democratized experience layer

9:57 All right.

9:57 Well, I mean, like most people don't know it, but if you're on a lightning page,

10:01 you can go edit page for yourself right now.

10:03 Like that, like it was always built that way.

10:08 Is it user friendly enough that anyone does it?

10:10 Absolutely not.

10:11 But I think like the concept should be that you want to be really rigid

10:15 about your business logic and any of the plumbing.

10:19 And you want to be really experimenting with ways to democratize your experience layer,

10:26 like your application layer and your logic and everything like that.

10:29 There's a certain degree to which you just like can't let go of the reins on that.

10:35 And your experience layer has like become something that you have to find a way to democratize.

10:41 So like even just like take inspiration from something like Vercel,

10:47 which like is designed for this, like, OK, any old user for any little use case, host something.

10:53 Like we have like an internally built version of that that does exactly this

10:57 because you know that the sprawl of shadow IT is going to get huge

11:01 if you just like don't give people a way to host things.

11:05 So if you can at least bring it into the fold and allow for that creativity to flourish,

11:09 and then you can kind of peruse through and say, oh, man, look at that.

11:12 That one's really special.

11:14 Everyone should be using that easier said than done.

11:17 And I think it kind of goes nicely into our next point,

11:21 which is like in order for that to happen, then you need to be able to address any of the,

11:28 you know, less experienced layer stuff really quickly and efficiently.

11:34 So like the not so flashy stuff, your business logic, your processes

11:41 and automations and things like that that the business actually wants.

11:45 You have to be able to do that work confidently and thoroughly on a quick timeline

11:51 so that you can also have enough time to be forward looking about some of this other stuff

11:58 because it's always going to be a constant priority battle.

12:04The new model: two gates and one custom app per role

12:04 >> So I know the book is still being written.

12:08 So there's probably some unknowns here, but knowing, hey, there's some restrictions in Agile,

12:13 some things that aren't really serving anymore.

12:16 You have this explosion of creativity and people building things on their own,

12:19 shipping things on their own.

12:22 How are you managing RevOps, managing requests that are coming in,

12:29 managing rogue applications that might be going against something else?

12:32 What's the new method that you're using to manage the function?

12:36 >> Yeah, still under construction is certainly correct.

12:41 But the concept and actually there's like an epic on our board that has,

12:46 I want to say like 27 or 37 individual user stories.

12:51 And the first, I think it's 37 and the first 30 are like pretty routine

12:58 security governance tech debt stuff. And then the last seven is where you unlock

13:04 the ability to democratize these things.

13:08 So I'm not going to sit here and pretend that there isn't a pretty substantial investment in

13:15 very traditional things.

13:17 So we have a solution architect who wrote all of those.

13:23 In terms of like what changes day to day, I think the way that we're imagining it is like,

13:29 actually I use like the personas on my team.

13:32 I have one person who is like really good at beating the crap out of a brief and saying like,

13:40 why does the business actually want this?

13:42 No, no, no, why do they actually want this?

13:45 Not that's actually just trying to tell me the answer.

13:47 No, I have to get to the Y, I have to get to the Y, I have to get to the value.

13:51 And I basically want like an agent version of that person that has seen the comments

13:59 and has the transcripts of that person ripping apart briefs.

14:04 And I want that to be gate number one that you have to pass.

14:07 I want gate number two to be the architect on the solution design.

14:12 And then overall, I think one of the directions that we're moving that is going to make it easier

14:18 to enable this is just kind of going to be one custom app per role.

14:22 So like if you're an SDR, if you're a BDR, if you're a account executive,

14:25 you're a launch specialist, integration specialist, strategic CSM, whatever,

14:31 we create an environment where there is an experience layer that is fully custom

14:36 that can be modified without touching a whole lot of like metadata or business logic.

14:42 So we create this like reality where there is something to modify that doesn't touch it.

14:49 So that allows you to then I think, focus on triaging.

14:55Three tracks: skin, metadata, project

14:55 So our triaging becomes, hey, do we just want to update the skin basically of any of these custom

15:01 maps? And you can verify that it's not going to hurt performance.

15:04 And it's not going to touch any, any metadata or flows or business logic

15:09 and doesn't create a security issue. It just like in a request that meets that criteria

15:15 and passes the two other gates can just go straight to develop, you know,

15:20 like it hits the board overnight, someone develops it, someone has a look at it, pushes it out.

15:27 Or like it passes some testing gates and it gets pushed out.

15:29 And that would be like your happiest of all happy paths.

15:32 And we had kind of create the environment for that happy path to exist.

15:35 And then the second one is like a tiny metadata update that isn't like a huge deal.

15:40 And you're still going to need some human, you know, in the loop for that one.

15:44 And but it's still gonna be much quicker and it's kind of on demand.

15:48 And then I think the third one are like, these are these would be things that contribute to like

15:52 projects. And that might more closely resemble just the normal agile process that we're doing today.

16:02 In that we're probably not racing to deploy those in piecemeal.

16:11 But I do think that from inception, there's still opportunities to actually put a lot more

16:18 emphasis on the upfront. Why are we doing this? What problem is it solving? What number does it

16:22 need to move? Okay, what is the design principle that we need to meet so that the development

16:28 process is super quick, and then we can be extremely thorough with testing and rollout

16:33 and communication. So I think that like, just like without that center part eating up your

16:39 the big projects, and a lot of the time, it like affords you more opportunity to do the other stuff

16:44 better. So these first two categories, I think are where the real difference is. So it's almost like

16:49 I kind of have like regular agile, then I have another one or two stacked on top of it is maybe

16:56 a better way to think about it. Yeah, I like that a lot. There's still going to be some big ones,

17:01 like a major quote to cash overhaul, if you're migrating CRM or something, like you're not going

17:06 to be able to ship all that out in a couple days. But some of the things that maybe used to be a

17:10 two week timeline could probably be a day. And you could set up your agent system to do the testing

17:15 really well. So I think dividing those like yeah, it's run that like a traditional project or no,

17:21 put that one in the fast lane, we can just crank that one through. Yeah, exactly. I do think like

17:26 something healing progress is important to the people that you're shipping to. And so you create

17:31 an environment where they can feel progress. I think that's what really been missing. Like it's

17:37 been challenging to like, if you have an update that you want to make for one type of user,

17:46 one little thing, it's a tiny quality of life improvement, like needing to slot it in and,

17:53 and have it stack within everything else that you have to get done, like it's so easy to get the

17:58 can kicked. But like if someone just submits the request correctly, and it's passes two gates,

18:04 and there's a place in the CRM, a custom map for it to land at the experience, and it's just the

18:08 experience layer. So like, there's no risk to this going out, basically. And an agent can develop it

18:14 and then kind of like one person just has to go, Yep, and it's out. Right? Like, what that means to

18:21 the people on the ground, I think it's like pretty meaningful. And they are the ones that are driving

18:26 the revenue in this, in your business. So it matters. It's interesting you say that because

18:33 it's really similar to how we work with customers. We have projects and then we have ad hoc. That's

18:37 how we explain it. And you have your architect, that's the main point person that you work with

18:42 here at LeanScale. And then you have a project engineer, they're working on the big stuff,

18:45 the big needle movers. And then you have an ad hoc engineer, the simple stuff. And we always say

18:50 the ad hoc is where you win hearts and minds. So it's that, oh my gosh, they turned this around in

18:58 10 minutes. Oh my gosh, they flipped it around today when I thought that was going to be a

19:01 multi-week thing. And they just were super responsive. And then the projects are where

19:06 you move the business forward and you're proactive. Yeah. And you know what, like maybe the ask is the

19:13 wrong ask, but the way that your intake works, the way that our intake works at least is like

19:18 trying to get to like, what is it that you want to see change as a, like, which is, you know,

19:25 very well handled and agile. I want to, so as a, I want to, so that I can.

19:32 And if you're doing a good enough job with that, like your first agent might stop someone in their

19:37 tracks and be like, oh, like this isn't actually, you've asked for this, but what we actually want

19:43 is this. And so you can actually have this whole like loop where something meaningfully is deployed

19:50 that has been kind of argued. But it hasn't like taken up a bunch of your team's time like it

19:56 normally would. Like a lot of the time you get an, if there's an intake process, the flaw in the

20:00 intake process, I think is like the asynchronous element of it leads to like this weird scenario

20:06 where as RevOps you're reading it and you're just being like, what? You think that is going to, no.

20:12 And so you kind of like half of that ultimately kind of, I think come together most of the time.

20:18 But yeah, no, I think like the whole point of this is like your users' expectations and

20:24 understanding of what is possible in technology has changed. They are the ones that are, you know,

20:32 pulling the rope for your business. And I always want to be focused on them and how I can make

20:41 them feel like they're well equipped and respected for the job that they do. So even though, you know,

20:50 you might say, oh, Steve, like an experience layer update, if it can go out without impacting

20:54 anything, like it's unlikely to be that big of a deal. Like I would disagree.

21:03Does AI shrink the RevOps team?

21:03 In this new era, are you seeing the need for more RevOps or is the efficiency allowing you to run

21:13 leaner in compared to your overall go to market investment as before?

21:20 I mean, I think the same is true of RevOps as it is anywhere. Like there was no real

21:27 AI jobs apocalypse. Everybody just works longer, harder, saw that they could capture more territory.

21:35 So the more that you have available to you in headcount is just more territory that you can

21:44 capture more, more that you can get done. I think that it's allowing us to think in

21:55 scales that we weren't able to before. I think it's allowing us to

22:04 put down plans to service end users in a way that like we used to kind of only wish we were

22:10 able to. And I think that it's also probably if you're going to continue to hire the same way,

22:20 give you an opportunity to like, reduce some of your software spend in very like strategic places.

22:27 I really think that you just sort of end up with more people who can

22:36 manage projects all the way through and do a significant amount of the actual work. And so

22:43 it kind of fits the principle that I had in the first place, which is like, I want people who

22:49 can be strategic thinkers, understand the technology, but I'm not actually hiring them

22:56 to be the ones to do all of the development work. That has like aged quite nicely. Like the more

23:03 people that you have that can see a problem, diagnose it, design a solution, co-design a

23:11 solution with AI, write up the scope. And then you're just kind of like, basically on the doorstep

23:18 of like, okay, prototype it, like your PO in my environment can get to a point where

23:25 any dream that they have become something that gets prototypes. And then we're storing all these

23:30 prototypes, you know, whether we use it as is or not, in our knowledge base, as something that

23:37 we can always draw on. That's like almost like a library or a recipe of services that we can

23:42 always kind of come back to. So yeah, no, I don't think the need for RevOps reduces. I think perhaps

23:52 where some of your allocation lies changes. Like I would probably not continue to hire

23:57 offshore devs, like probably good, because the ones that I have, I can similarly supercharge.

24:04 And then so any capacity increases are able to be met. You know, obviously that

24:10 reaches a scaling point as well. But yeah, and if more work is delivered, then you need more

24:18 people on maintenance. You need more people on refactoring. You need more people on testing.

24:24 So I haven't seen, I haven't seen any opportunity to like,

24:27 reduce the team and still produce the kind of output that I want to be producing.

24:32What becomes possible when three months turns into a day

24:32 Yeah, no, it makes sense. I'm not, I'm not seeing that either. In a lot of ways, I'm seeing

24:37 maybe even more investment in RevOps because before the scope of what was possible was

24:46 relatively limited. There were things that I had in my mind all the time. I would love to be able

24:49 to do. Oh, I'd love to build this. I'd love to run this analysis. I'd love to build a model for that.

24:54 But immediately I would disqualify because I'm like, well, that's going to take

24:58 three months to do and I can do it. And now I can get that done in a day. So

25:02 the possible things I could work on today have gone through the roof. And I think people are

25:09 seeing that a lot. One thing this leads to though is, and I know heads of RevOps are always

25:17 in this tension with maybe CRO or CFO, is how much you should be investing in RevOps. So I think

25:27 it's pretty clear. Like an investment in RevOps does a few things. When you get the GTM telemetry,

25:31 you know exactly how things are working, what's going well, what to double down on, what's not

25:35 going well. You are increasing conversion rates, decreasing time and stage. That at scale can mean

25:44 millions, if not tens of millions. But what's the right level of investment? How do you

25:50 have that conversation with your CRO, CFO when you're asking for more resource?

25:59The RevOps ratio: 15:1, 25:1, and the 29:1 problem

25:59 I think really you have to be able to sooner or later establish some sort of a baseline ratio

26:09 as like a starting place for this conversation. And then any deviations from that end up

26:18 tying to particular metrics. Do you have any ratios that have worked well for you in the past

26:26 that you like to use or even just some general guidance?

26:34 I would say that in my experience, it's actually

26:43 heavier ratio the further down the market that you are. If you're like an enterprise startup,

26:54 you can do a lot with one really talented person. If you've got somebody who's like

27:04 like a technical RevOps person, strategic mind, you can do a ton with one person. You can get to

27:12 probably your first 30 or 40 reps, I bet, with AI. But that's an environment where

27:22 the end of deals to hit your target is quite low and you can have one deal that makes your

27:31 quarter, makes your year. The inverse scenario is one where that's impossible and basically every

27:39 customer needs the same treatment and is as important as the one before it, which is closer

27:45 to where we are at owner, like a fixed subscription price and some take rate. But ultimately the ACVs

27:54 don't vary all that much. So there's not really like, "Oh, that one deal can save the year," which

27:59 means you have to be technically excellent everywhere. And it means that the denominators

28:06 in all of your conversion rates are quite high. So there's just the degree of excellence that you need

28:13 at the number of places in the funnel, I think requires a much closer and much tighter ratio.

28:21 So it's more of a like 20 to one type situation or 15 to one even. And it can probably expand,

28:31 but I remember doing this exercise and seeing that we had gotten to 29 to one and being like,

28:39 "Oh, that is a big problem." And we were feeling it and right sizing that. So I think it like

28:45 probably starts out more ideally at like a 15 to one and then you can probably get more into like

28:51 the 25 to one when you're a little bit bigger. But again, I guess it would reach a point where

29:02 the specialization and the scale are going to have to kind of like flatten out somewhere. So this is

29:11 more like startup experience I would say. Yeah, I think that makes sense. The more between enterprise

29:17 SLG to I'll call it PLG or high velocity SLG, you would need a higher ratio of ops to overall

29:26 good market spin, sales, marketing, et cetera. And then as you scale, then that ratio should start to

29:33 go down as you get leverage out of the team that you have. Yeah, I think so. Because if you've got

29:38 good people, one of the hardest things is to get terminal velocity in a sales group. You can have

29:47 your first set of sales, who's that person who comes in, proves it out, carries a bag,

29:53 hires the first couple of people, gets maybe to a team. Eventually, you're going to hire a more

29:58 senior leader. But there are a bunch of events on that mountain that you've got to reach these

30:07 thresholds. Otherwise, you don't really get to that sales culture terminal velocity. And I think that

30:15 being able to nail the development of your RevOps team according to that scale

30:25 is really helpful in trying to reach that point because you're introducing opportunity for

30:30 repeatability and for playbooks and for reliably being able to bring on and rent new people.

30:37 I would say the same for enablement. It's kind of hand in hand.

30:42How to pitch a CFO for budget

30:42 For a head of RevOps who's putting their pitch together for more budget, more resource, they

30:48 know in their head what they need, why they need it. How do you recommend they pitch that to their

30:53 CRO or CFO or navigate that process? I mean, the only way is to speak their language.

31:05 Find that you have a natural alliance or opportunity to build goodwill with the

31:15 finance team as RevOps because of just how much the sheer number of dollars that run through you

31:21 or that you have some ability to affect. For me, I always make sure that this starts

31:30 way before the ask, which is be as good of a partner to finance as you can be. Heads up.

31:38 This technology, this software spend, I'm actually going to swap it for this one,

31:42 which is cheaper. So you can expect me to come to you with these two contracts instead of this

31:48 big one or this one instead of these two. I think it starts early. There is the relationship trust

31:55 building element of it first. I think it's a challenging position to be in to have your first

32:05 serious dollars and cents conversation be the ask. I do everything I can to make the first

32:10 dollars and cents conversation I have being me protecting the budget and then kind of establish

32:17 yourself as a serious person who's thinking about the company's goals at large rather than

32:24 simply just asking and being another person with their hand out, so to speak.

32:32 I'm sure that every RevOps person in the world would say, "Okay, you have to tie this

32:39 spend to ROI and you have to speak their language." My, I guess, more behavioral social

32:48 advice though, is don't make that the first time that they've talked to you about dollars and do

32:55 what you should do and be a good steward of the company's finances and establish yourself as

33:01 somebody credible on that basis and that'll go a long way. I think it's really, really good advice.

33:10 Then any head of RevOps that's going into a budget season or has that tension happening right now,

33:16 I think that's helpful. Yeah, don't wait until the budget meeting for it to happen.

33:20 Just imagine being the CFO and how many people are just asking, asking, asking.

33:25 But you're right, you do have an opportunity to build that relationship. They want a clean

33:29 forecast to run their models on, so if you're helping get them what they need and I think it

33:35 makes a ton of sense. Not a lot of roles actually do have that opportunity to go and make the CFO's

33:42 life a little bit easier. So take that opportunity. I love it. I'm going to transition a little bit.

33:51The Apex heresy

33:51 You made a very bold claim that everyone should be converting their CRM to Apex.

34:02 I need to hear where that's coming from because that has gone against every bit of Salesforce

34:07 advice I've ever heard. People are sharing out in the market right now, so this is a huge

34:13 turn from where people are thinking about their systems now. Why are you saying people should

34:19 move to Apex? Yeah, I mean, it's like intentionally inflammatory. I say that as an attention grabber

34:28 and actually this whole thing started, well, I mean, I guess privately I had the thought

34:33 really early in the year when I built my first custom Salesforce MCP with just an external app

34:42 and I was just sitting there being like trying stuff and noticing like a lightning layout.

34:51 It doesn't do so well. You can't do UI stuff and flows. You can make a new small flow, but if you

35:00 want to edit a huge flow, it's not super great at that, but Apex nailed just creating modifying

35:08 metadata crushed. It really did really, really well. I was talking to Claude and it was just like,

35:14 hey, look, that's XML underneath all of that stuff, the flows and the flexi pages.

35:22 It's really long. It's verbose. It's not quite code, so I really struggle to know if it done

35:27 it right. I can't really verifiably do this. You'd get it to do like really challenging stuff and

35:34 then it would be like, and then seven steps for you at the end and they're all just like silly UI

35:39 things or whatever. At the time I was hiring for a architect and I decided that after allowing some

35:49 of my other teammates on the panel to grill them about architectural principles and stuff for a

35:54 while, I would make this ridiculous claim and then just watch how they reacted. Really what I was

36:00 trying to do at the time was get a sense of whether this person wanted to create the future

36:06 or was comfortable hanging back until someone else had crossed the chasm, so to speak.

36:15 Almost to a person, they were reacting similarly to what you were saying because the question

36:22 was just like, hey, if I want to change the whole CRM to Apex, because I believe this,

36:27 that it's easier for an LLM to actually then just manage the whole thing like you would a code base.

36:34 What would you say? Most of them, the objections were, do you lose the visibility or easy things

36:44 aren't able to be quickly fixed by a human or things like that. Things that I found to be

36:52 an uninspired interpretation of this. If you want the visual documentation that a flow provides,

36:59 build an SOP. If you create an automation that you have to use mermaid and create a diagram and

37:06 store it wherever you want to store it. That's actually more in your principles for how you

37:11 manage your LLM and your builds. Eventually, I found somebody who had a really

37:21 interesting answer, which is that you wouldn't really necessarily run towards it, but you might

37:25 start solving new problems by doing this anyway. Eventually, you run into race conditions and

37:31 timeouts and things like that, that a large enough flow doesn't work. For the record, I was the same.

37:39 I would actually just force someone to really argue with me as to why I should allow any Apex

37:45 into my system, because I had had the experience and known about previous instances that I was not

37:51 in charge of, but had worked in that had been 100% Apex and had caused a nightmare.

37:58 I was the same way. I don't know. The Salesforce, we love admins days, quietly going away. I really

38:07 think that you aren't going to go in and make a super quick change in your CRM anymore anyway.

38:15 You're going to do this via CLI and an LLM is going to do it for you. I have been operating

38:23 and moving towards a system that allows my team to be operating that way for a while now.

38:30Handing an LLM the gnarliest flow — and it finds two bugs

38:30 For fun, I just actually not too long ago asked it, "What's my gnarliest flow?"

38:38 It gave me something about one of our activities, because the principle of one trigger type per

38:46 object. I just found one of my activity flows that was particularly nasty. I gave it free range to

38:53 just try and totally wipe it out and create it with Apex. I just put on Fable and said, "How about it?"

39:02 It was interesting because there are nuances and you would just hit, "Okay, sounds good," but it

39:09 got through a significant amount of the testing and was able to actually find two bugs in the

39:16 flow. It was like, "I can't replicate these because I don't think that you actually want this to

39:20 happen," but it took a matter of hours. I think that if you were able to do that and get to a point

39:30 where your CRM was all code, so therefore you didn't spend a whole bunch of time in setup

39:37 going through and doing things manually and clicking buttons and typing stuff in,

39:44 then I believe that you would be able to manage your business logic and manage your

39:51 critical pieces of the CRM backend more effectively, which is what gives you the time to do some of

40:01 that front end stuff that we started the podcast with. I think that those two things need to happen

40:07 together because if they don't, you're asking for blood from a stone. If you want to be managing

40:14 this super progressive experience layer that's democratized and things like that and super custom,

40:22 it's easier to do that than it's ever been, but it doesn't hide the fact that you still got all of

40:28 these tech debt and/or less flashy things that you have to do and things that are

40:38 needing adjustment all the time. So I think in order to free up the resources to do things that

40:48 will drive impact because they will improve and change behavior, this is probably a necessary

40:56 step. So it's not a drop everything and convert all your stuff to Apex. It's more of a, "Why wouldn't

41:02 you start?" Because on a long enough timeline, can you really imagine yourself going through

41:10 clicking through Flow Builder or can you really imagine yourself

41:15 going through and using a Flexi page? That's so obviously not the thing. You can just design

41:22 whatever you want, get 10 iterations of it, hit deploy. Why would you not do that? Why would you

41:30 be stuck to this Windows XP looking thing? I don't think you would. I don't think so either.

41:38 And it's so ironic that Flow is what made everything so easy compared to what you were

41:43 doing before. And now it's like running through molasses when you're trying to build things.

41:50A year out: does anyone still log into Salesforce?

41:50 I'm curious, fast forward, extend it a little bit, maybe go a year out from now.

41:57 Is there any reason anyone would be logging into Salesforce, clicking buttons, manually logging in

42:03 opportunities and notes, or should everything be running headless?

42:10 It can run headless or it can run as custom app inside of Salesforce. I don't think it really

42:16 matters. I think that obviously their thought is that Slack would be the front end, which is

42:24 something I thought for some time as well. I think, yeah, to me going fully headless is less

42:36 the only way as it is one of the ways. This is really just about like, can you put the data in

42:43 front of people, the data that they need to do their job better? Can you put it in front of them?

42:48 If you can put it in front of them inside of Salesforce, great. I don't know, maybe you don't

42:52 need to go headless. If you can't, maybe you want to put it into some sort of a headless format.

42:59 It's really just all about the outcome. Will they log in? I think it depends. There's also this

43:06 interesting, it's not really a phenomenon, but it's a behavioral thing again that I believe I heard.

43:20 It was a different RevOps leader, I can't exactly place it, who was having all the

43:25 medic fields filled out from transcripts. They actually turned it off because they found that

43:34 the reps didn't know their deals because they didn't have to do that.

43:38 Now, I think there's a balance there. Do I really want to force field entry

43:45 just as a deep thought exercise, or is there another way for me to do that?

43:55 I'm unsure. I do, however, think that if you could autopilot sales, then you would.

44:05 There is something special about the salespeople, and there is something special about your

44:10 implementation team and your CSM team, and people want that. The question is not necessarily for me,

44:18 how do you make all of it go away? How do you maximize your outcomes? It's always actually

44:23 about that. If I could get better outcomes with a pen and paper than I could with Salesforce,

44:31 then I would use it. I totally understand. I just leave room for the fact that I still need

44:52 my people to be doing what they do best, and I still need to be considering what workflow creates

45:01 that environment. I don't necessarily think—because I think what I'm getting hung up on is what you

45:12 asked was managing opportunities. I'm like, "Yeah, kind of, right?" Now, should it be easier than

45:18 before? Should maybe I have a custom app on their phone where they can do a Tinder swipe and put

45:27 things in and out of forecast? Sure, maybe. Can I make this as cognitively light as possible? Sure,

45:33 but where I need their attention, I think I still very much need their attention.

45:39 That's really the concept, and it's always been the concept. We always call them revenue-generating

45:45 activities. If there's a revenue-generating activity, that's what I want to rev doing,

45:50 and anything else, I don't. But sometimes, I think that there's a need for

45:56 the deep understanding of the situation to still be left with the rep as opposed to auto-filled

46:07 or auto-managed. It's a fine line. I leave the door open a little bit there.

46:13 Yeah, tailoring it to the team and the things you need them to do. I'm just wondering,

46:18What is Salesforce actually worth now?

46:18 I think a big part of the value that Salesforce originally brought was an easy way to manage your

46:28 pipeline, an easy way to manage your forecast, a UI that helps people operate well, a data model

46:34 that organizes and structures things well. I'm just wondering what the value is. I'm not

46:39 recommending anybody rip out Salesforce today. I'm just trying to forecast a couple years out.

46:45 What is the value of having something like Salesforce versus maybe, I mean,

46:52 is it essentially just turning into a data warehouse or is there more to it?

46:59 I have been thinking about that for a while now. I'm kind of wavered here and there.

47:08 If you kind of look at Oracle as a predecessor to Salesforce and you could have maybe thought,

47:18 maybe Oracle gets, maybe if you were 10 years ago, you'd be like, "Oh, Salesforce is going to make

47:23 that company less valuable." Well, no, Oracle is more valuable than it's ever been. I think

47:27 it survives in a way. It's just sort of a matter of how do cutting edge startups continue to use it,

47:35 do larger legacy customers, regulated industries, things like that. They still

47:41 tend to continue to use it almost certainly. At the same time, what they're doing right now,

47:52 I don't know if I would do anything. I commend it. I think it's pretty bold for them and pretty

47:58 brilliant. They're not holding you back from they're embracing MCP and CLI. Their acquisition

48:10 strategy this year has certainly been around specialized agentic use cases. I think more than

48:18 ever, the platform and the tools and the way that they're investing is very open. There's a decent

48:27 likelihood that to your earlier question about headless, that move in particular kind of just

48:33 maybe allows them to shed some of the legacy code that they would have had to build something

48:39 beautiful on top of and say, "Hey, don't worry about all that. You guys handle that,

48:44 this interface piece. Here's all this agent infrastructure that we have available."

48:52 I don't know. As far as this goes, it feels like they're handling it so well.

48:58 Yeah. I'm not asking because I have an answer. I'm asking because I'm genuinely curious what

49:03 other people are thinking. Not that it matters. People like us will just pivot and ride whatever

49:11 wave is happening, but I was just curious. At the core, what's the value of it?

49:19The most AI-friendly CRM there is

49:19 At the same time, I agree. I do think they're handling it really, really well, but before,

49:22 I would have said it's for an early stage company. There's a certain threshold where I say, "Hey,

49:27 you should always be on Salesforce." The early stage company, this is a bit of a coin flip.

49:31 Like, "Yeah, you could go up spot. You go to Salesforce. It won't matter that much."

49:34 Now, even for an early stage company, we say, "Well, if you want a CRM that you can unleash AI on,

49:40 you should go to Salesforce. It's the most AI-friendly CRM there is."

49:46Where Steve goes to learn

49:46 Steve, this has been awesome. One last thing. I'm just curious. There's so much happening. I mean,

49:56 I'm deep in this, and we work across multiple companies, and it still feels like it's hard

50:01 to keep up with everything that's going on. Where do you tend to lean in to learn,

50:06 get your information from, and get a perspective on what people in RevOps should be doing?

50:14 Yeah. It's certainly a mix. A lot of my algorithms are obviously tuned to this,

50:22 so it serves up to me quite a bit. I definitely have a small group of people that I respect and

50:31 make a point of trading ideas with, and so they come back to me in kind.

50:41 There's a flourishing community of these RevOps substacks, podcasts, things like that,

50:48 as well as around certain technologies. Anyone who's a clay person by design,

50:55 I'll peek over the fence and see what they do. As much as anything, to be quite honest,

51:07 I feel like if I am actively looking at the most serious people in terms of folks who use

51:19 AI for software development, and then I'm trying to read the tea leaves on how I can apply it,

51:25 because it's not quite designed for us, but also someone talking about what they're doing

51:33 in RevOps is kind of typically lagging because they've had to see something, figure out how to

51:39 use it, prove that it works, and then tell you. I'm always actually trying to look a little bit

51:44 upstream, and so that ecosystem tends to be Twitter, to be honest.

51:53 I love it. I love it. Yeah, it's hard for me to shed the Twitter brand, too.

51:59Wrap

51:59 Well, Steve, thank you so much. It's always a pleasure having you and just picking your brain,

52:03 and I love how forward-thinking you are, how proactive you are, and just really setting the

52:09 standard of what modern RevOps looks like. Everything you shared today, I think, is

52:15 really, really helpful for anybody listening. Moving away from Agile or at least shedding the

52:21 parts that aren't serving anymore, and I think the way you're prioritizing things between

52:26 projects and smaller requests and having a different execution cycle for both of those,

52:30 I think, is really, really impactful. Then following the trend of, "Hey, LLMs are

52:35 really good with code, so why hold it back from building code in your CRM?" I think it's really

52:41 thought-provoking, and I'm actually pretty confident it's the right move. Thank you for

52:46 sharing everything. I'm really, really excited to follow everything that you do, and also just can't

52:52 wait to see what you do next. Thank you so much. It's a pleasure being here. I'll hopefully do it

52:57 again soon. I'm sure there will be new things to talk about in the next couple months, at the very

53:03 least. I'll be back on here being like, "I was wrong."