--- title: "Convert Your Entire CRM to Apex" episode: 118 podcast: "The LeanScale Podcast" publisher: "LeanScale" guest: "Steve Dinner" guest_title: "VP of Revenue Operations, Owner.com" date_published: 2026-09-15 date_modified: 2026-09-21 duration: 00:53:13 word_count: 8169 topics: ["revenue-operations", "ai-in-gtm", "gtm-strategy", "sales-leadership"] canonical_url: https://www.leanscale.team/knowledge/podcast/steve-dinner-owner-com-the-two-week-sprint-is-dead/ source: "LeanScale Knowledge Hub — https://www.leanscale.team/knowledge" license: "Free to quote and cite with attribution to The LeanScale Podcast." --- # 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_ **Episode 118 · The LeanScale Podcast** Steve Dinner, VP of Revenue Operations, Owner.com · Hosted by Anthony Enrico Published September 15, 2026 · Updated September 21, 2026 · 00:53:13 Canonical: https://www.leanscale.team/knowledge/podcast/steve-dinner-owner-com-the-two-week-sprint-is-dead/ **Topics:** Revenue Operations · AI in GTM · GTM Strategy · Sales Leadership ## Executive summary 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 1. **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. _For:_ RevOps Leaders, Revenue Executives 2. **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. _For:_ RevOps Leaders, Revenue Executives 3. **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. _For:_ RevOps Leaders 4. **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. _For:_ RevOps Leaders, Revenue Executives 5. **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. _For:_ RevOps Leaders 6. **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. _For:_ RevOps Leaders 7. **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. _For:_ RevOps Leaders, Revenue Executives 8. **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. _For:_ RevOps Leaders, Sales Leaders, Revenue Executives 9. **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. _For:_ RevOps Leaders, Revenue Executives, Founders 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. _For:_ RevOps Leaders, Revenue Executives, Founders 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. _For:_ RevOps Leaders, Revenue 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. _For:_ RevOps Leaders, Revenue 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. _For:_ 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. _For:_ RevOps Leaders, Sales Leaders, Revenue Executives ## Frameworks ### Risk-Based Triage at the Front Door (05:45) **Definition:** 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) **Definition:** 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) **Definition:** 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) **Definition:** 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) **Definition:** 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) **Definition:** 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) **Definition:** 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) **Definition:** 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. ## Quotes _Speakers inferred from an undiarized transcript — verify before attributing._ > "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, The LeanScale Podcast Ep. 118 (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, The LeanScale Podcast Ep. 118 (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, The LeanScale Podcast Ep. 118 (05:30) > "What is the likelihood that this can hurt anything or cause any permanent damage?" > > — Steve Dinner, The LeanScale Podcast Ep. 118 (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, The LeanScale Podcast Ep. 118 (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, The LeanScale Podcast Ep. 118 (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, The LeanScale Podcast Ep. 118 (10:11) > "We always say the ad hoc is where you win hearts and minds." > > — Anthony Enrico, The LeanScale Podcast Ep. 118 (18:45) > "There was no real AI jobs apocalypse. Everybody just works longer, harder, saw that they could capture more territory." > > — Steve Dinner, The LeanScale Podcast Ep. 118 (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, The LeanScale Podcast Ep. 118 (28:31) > "I do everything I can to make the first dollars and cents conversation I have being me protecting the budget." > > — Steve Dinner, The LeanScale Podcast Ep. 118 (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, The LeanScale Podcast Ep. 118 (36:22) > "If you want the visual documentation that a flow provides, build an SOP." > > — Steve Dinner, The LeanScale Podcast Ep. 118 (36:52) > "It got through a significant amount of the testing and was able to actually find two bugs in the flow." > > — Steve Dinner, The LeanScale Podcast Ep. 118 (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, The LeanScale Podcast Ep. 118 (40:56) > "Why would you be stuck to this Windows XP looking thing? I don't think you would." > > — Steve Dinner, The LeanScale Podcast Ep. 118 (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, The LeanScale Podcast Ep. 118 (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, The LeanScale Podcast Ep. 118 (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, The LeanScale Podcast Ep. 118 (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, The LeanScale Podcast Ep. 118 (49:34) ## Practical advice by role ### 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 **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 ### Revenue operations - **.** - **.** - **.** - **.** - **.** - **.** - **.** ## Metrics mentioned | Value | Metric | 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 mentioned - **Owner.com** (company) — 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. · https://www.leanscale.team/knowledge/company/owner-com/ - **LeanScale** (company) — 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. · https://www.leanscale.team/knowledge/company/leanscale/ - **Oracle** (company) — 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. · https://www.leanscale.team/knowledge/company/oracle/ - **Steve Dinner** (person, guest) — 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. · https://www.leanscale.team/knowledge/guest/steve-dinner/ - **Anthony Enrico** (person, host) — Co-founder of LeanScale and host of The LeanScale Podcast. · https://www.leanscale.team/knowledge/guest/anthony-enrico/ - **Salesforce** (tool, CRM) — 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. - **Model Context Protocol (MCP)** (tool, 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. - **Claude** (tool, AI 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'. - **Codex** (tool, AI 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'. - **Cursor** (tool, AI 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. - **Fable** (tool, AI 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. - **Vercel** (tool, Deployment / 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. - **Mermaid** (tool, Diagramming / 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. - **Slack** (tool, Team 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. - **Google Sheets** (tool, Productivity / 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. - **Google Slides** (tool, Presentation 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. - **X (Twitter)** (tool, 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. ## FAQ **Q: Why does Steve Dinner say the two-week sprint no longer works for RevOps?** A: 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. **Q: What replaces the sprint in Steve Dinner's RevOps model?** A: 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. **Q: Why would anyone convert a Salesforce org to Apex?** A: 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. **Q: What is the most common objection to putting a CRM in Apex, and what is the answer?** A: 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. **Q: Does AI reduce the size of a RevOps team?** A: 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. **Q: What is a good RevOps ratio?** A: 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. **Q: How should a head of RevOps ask a CFO for more budget?** A: 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. **Q: Will people still log into Salesforce, or should everything be headless?** A: 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 - **00:00** — Cold open + intro - **01:38** — Why the two-week sprint is finished - **04:20** — The build got cheap. Planning and testing got expensive. - **06:35** — What's left of agile, and what gets thrown away - **07:48** — Walking the floor: a BDR director shipping his own Claude artifact - **09:57** — Rigid business logic, democratized experience layer - **12:04** — The new model: two gates and one custom app per role - **14:55** — Three tracks: skin, metadata, project - **21:03** — Does AI shrink the RevOps team? - **24:32** — What becomes possible when three months turns into a day - **25:59** — The RevOps ratio: 15:1, 25:1, and the 29:1 problem - **30:42** — How to pitch a CFO for budget - **33:51** — The Apex heresy - **38:30** — Handing an LLM the gnarliest flow — and it finds two bugs - **41:50** — A year out: does anyone still log into Salesforce? - **46:18** — What is Salesforce actually worth now? - **49:19** — The most AI-friendly CRM there is - **49:46** — Where Steve goes to learn - **51:59** — Wrap ## Related episodes - **Ep. 41: Why Structure (Not Headcount) Builds Great RevOps** (Steve Dinner (Owner.com)) — Steve's first appearance, where agile was the install he was proudest of — the operating model he spends this episode pulling apart. · https://www.leanscale.team/knowledge/podcast/steve-dinner-structure-not-headcount-revops/ - **Ep. 106: How She Runs All of RevOps From the Terminal** (Sarah Madden (FERMÀT)) — The day-to-day mechanics of the agentic practice Steve is describing at a design level — skills, context management, MCP connections and where the human stays in the loop. - **Ep. 108: He Built a $60K CPQ Inside HubSpot in 2 Days** (Derek Mogar (LeanScale)) — The build-cost collapse Steve builds his whole argument on, with the counterweight he agrees with: the discovery and design work in front of the build did not get cheaper. - **Ep. 103: Why Your Reps Should Never Open the CRM Again** (Justin Lee (Superblocks)) — The headless-Salesforce end of the question Steve deliberately leaves open — headless or a custom app inside Salesforce, and what a rep should still be asked to do by hand. - **Ep. 95: Why AI Means More RevOps Hires, Not Fewer** (Jimmy O'Halloran (New Relic)) — The same answer Steve gives on whether AI shrinks the function, reached from a different operating environment. · https://www.leanscale.team/knowledge/podcast/jimmy-ohalloran-new-relic-revops-consumption-revenue/ - **Ep. 115: What RevOps Should Look Like at Every Stage** (Hassan Irshad (Unify)) — The staged build order behind Steve's ratio argument — what to staff and when as a company moves from a few reps to a full funnel. - **Ep. 85: Why AI + GTM Engineers Can't Replace RevOps** (Tessa Whittaker (ZoomInfo)) — The strategic layer that survives when execution gets cheap — the judgment Steve is protecting with his two gates. · https://www.leanscale.team/knowledge/podcast/tessa-whittaker-ai-gtm-engineers-revops/ ## Full transcript _Machine-transcribed and not diarized; speaker attribution is inferred._ _Transcript only, as a separate file: https://www.leanscale.team/knowledge/podcast/steve-dinner-owner-com-the-two-week-sprint-is-dead/transcript.md_ ### 00:00 — Cold 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:38 — Why 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:20 — The 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:35 — What'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:48 — Walking 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:57 — Rigid 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:04 — The 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:55 — Three 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:03 — Does 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:32 — What 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:59 — The 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:42 — How 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:51 — The 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:30 — Handing 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:50 — A 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:18 — What 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:19 — The 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:46 — Where 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:59 — Wrap **[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." --- _LeanScale Knowledge Hub. Free to quote and cite with attribution to The LeanScale Podcast (https://www.leanscale.team)._