--- title: "Why Structure (Not Headcount) Builds Great RevOps" episode: 41 podcast: "The LeanScale Podcast" publisher: "LeanScale" guest: "Steve Dinner" guest_title: "VP of Revenue Operations, Owner.com" date_published: 2025-10-29 date_modified: 2026-07-22 duration: 00:48:32 word_count: 7954 topics: ["revenue-operations", "ai-in-gtm", "gtm-strategy", "sales-leadership"] canonical_url: https://leanscale-knowledge-hub.netlify.app/podcast/steve-dinner-structure-not-headcount-revops/ source: "LeanScale Podcast Knowledge Hub — https://leanscale-knowledge-hub.netlify.app" license: "Free to quote and cite with attribution to The LeanScale Podcast." --- # Why Structure (Not Headcount) Builds Great RevOps _Steve Dinner on running a high-output RevOps team with zero in-house admins or devs — agile, structure, specialist contractors, and AI_ **Episode 41 · The LeanScale Podcast** Steve Dinner, VP of Revenue Operations, Owner.com · Hosted by Anthony Enrico Published October 29, 2025 · Updated July 22, 2026 · 00:48:32 Canonical: https://leanscale-knowledge-hub.netlify.app/podcast/steve-dinner-structure-not-headcount-revops/ **Topics:** Revenue Operations · AI in GTM · GTM Strategy · Sales Leadership ## Executive summary Steve Dinner runs Revenue Operations at Owner.com, the all-in-one growth platform for independent restaurants, through one of the fastest growth stretches of his career — and he does it with zero in-house Salesforce admins or developers on payroll. His thesis, and the spine of this conversation with LeanScale co-founder Anthony Enrico, is that structure, not headcount, is what builds a great RevOps function. Steve reframes 'lean' entirely: most scrappy early teams who call themselves lean are really just disorganized and under-structured. Real lean is intentional and agile — right-sized structure for where you are in the journey, ratcheted up deliberately as you scale. The mechanism behind a zero-FTE-admin RevOps org is a labor economy transformed by remote work and the explosion of specialized agencies and contractors. Steve argues structure is the strategic lever that lets him hire the best Salesforce talent anywhere — Upwork developers, a high-powered consultancy, individual specialists in every time zone — and get quality output fast. The unlock was agile, only eight months old on his team: a consultancy he'd hired for one specific project asked whether he'd just implement 'boilerplate' agile, and the largest value of the engagement turned out to be not the project but how his team now works. The other half of the equation is a documented onboarding 'course' so an incoming contractor is productive on day one; as Steve puts it, writing out that course's sub-headings quickly tells you where your RevOps deficiencies are. What you cannot outsource, Anthony and Steve agree, is leadership and accountability. On org design, Steve's answer to 'RevOps has no blueprint' is to borrow shamelessly: specialized-agency management from marketing, an IT-style help desk, agile from product. He staffs product owners over vertical segments of the customer journey (four categories from growth and brand marketing through onboarding, CS, and support), organized as pods of RevOps, data/analytics, and enablement — and he protects the developers' roadmap by insulating them with a dedicated help-desk-and-comp role that absorbs the daily distractions. Contractors are vetted like full-time hires against a scorecard, but with a higher risk threshold and a willingness to move on fast; a strong operating system (daily standups, definitions of done and ready) surfaces a bad fit within days, not months. The back half turns to AI, which Steve believes is still in its opening chapters for RevOps. The near-term unlock is on the development side, which he thinks is 'about to be overrun': LLMs that ingest Salesforce metadata from a GitHub repo to write better user stories, list dependencies for developers, generate stronger QA scripts, and prevent regression errors at the story stage rather than catching them late. He compresses a monthly quota-setting exercise from a day or two to a few hours by feeding attainment and quota history into an o3 chat, and describes the 'accordion effect' — tech stacks fragment around the CRM, consolidate into a few category winners, and now fracture again as AI adds a new layer. His warning, borrowing Shopify CEO Tobi Lütke's internal memo: the 10x productivity expectation already hitting product teams is coming for RevOps, so the only question is whether you're structured to absorb it. Who should listen: RevOps leaders building or scaling a team, founders optimizing revenue per FTE, and revenue executives deciding what to keep in-house. The throughline for career growth is moving RevOps from cost center to value driver — owning the company growth model and go-to-market performance-to-plan, relentlessly surfacing the top 'must-be-true' company goals, and doubling down on the leadership work that builds a function which runs without you controlling every part of it. The biggest outcome of the hour is a concrete, modern operating model for a RevOps org that is lean by design without ever being understaffed. ## Key takeaways 1. **Redefine 'lean' as intentional structure, not fewer people** — Steve argues most scrappy teams who call themselves lean are really disorganized and under-structured — 'lean' becomes an excuse for running a million miles an hour and shipping whatever they can. His new definition is intentional, agile, right-sized structure for the stage you're at, ratcheted up deliberately as you grow. _Why it matters:_ Stop wearing 'we're lean' as a badge for understaffing. Decide the structure your stage needs, install it on purpose, and treat that as the thing that lets you do more with fewer FTEs. _For:_ RevOps Leaders, Founders, Revenue Executives 2. **Structure is the lever that lets you hire the best specialist talent anywhere** — Because his team is well-documented and agile, Steve can drop in the best Salesforce developer he can find — an Upwork specialist or a high-powered consultancy — and have them produce high-quality work fast. The structure, not the headcount, is what multiplies output. _Why it matters:_ Invest in documentation and operating cadence first; it converts a fragmented bench of remote contractors into a coherent, high-output team and widens your talent pool to the whole labor market. _For:_ RevOps Leaders, Founders 3. **Adopt agile in RevOps — the biggest value is how your team works, not the project** — A consultancy Steve hired for one specific project asked him to implement 'boilerplate' agile. He submitted completely, and while the project got done, the largest value of the engagement was permanently changing how his team operates — standups, definitions of done and ready, boards, user stories, QA and UAT. _Why it matters:_ Borrow agile wholesale from product engineering rather than inventing your own process. The operating system it installs outlasts any single engagement and lets you plug specialists in and out cleanly. _For:_ RevOps Leaders 4. **Build a contractor onboarding course — its table of contents exposes your gaps** — Steve maintains a documented course (tech stack, who-owns-what personalities, the agile working agreement, definitions of done and ready, systems, roadmaps) so an incoming contractor is productive on day one. Writing the sub-headings of that course, he says, quickly tells you where your RevOps group is deficient. _Why it matters:_ Treat onboarding as a product you build once and reuse. It lops off the expensive first hours you pay specialists to learn, and the act of writing it is a free self-audit of your operation. _For:_ RevOps Leaders 5. **You can't outsource leadership or accountability — buy execution, keep the decisions** — Anthony and Steve agree that leadership, accountability, guidance, and the actual decision-making have to stay in-house. Agencies and contractors are for execution; they can't own the call. That boundary is what determines which roles get FTE dollars. _Why it matters:_ Spend scarce FTE budget on the strategic, decision-owning roles and route execution capacity to specialists — the inverse of the old model of in-housing admins, developers, and analysts. _For:_ Founders, RevOps Leaders, Revenue Executives 6. **RevOps has no blueprint — borrow your org model from other functions** — Because RevOps means something different in every company, there's no fixed template. Steve borrows deliberately: specialized-agency management from marketing, a help desk from IT, agile from product, and assembles the function his needs actually require. _Why it matters:_ Study how larger, more mature functions solve the same problems and lift their patterns. The lack of a blueprint is an opportunity to design RevOps around your business rather than a legacy chart. _For:_ RevOps Leaders, Revenue Executives 7. **Staff product owners over the customer journey, not generalists** — Steve divides the customer journey vertically into four segments — from growth and brand marketing through sales, onboarding, CS, and support — and gives each a product owner whose whole job is obsessing over making that stretch better for customers, the company, and the employees in it. Each is backed by a pod of RevOps, data/analytics, and enablement. _Why it matters:_ Ownership of a slice of the journey drives accountability to each department's real goals and moves you from generalists-who-do-everything to specialists who compound. It surfaces where handoffs (sales-to-onboarding, onboarding-to-CS) break. _For:_ RevOps Leaders, Sales Leaders 8. **Insulate your developers from the noise with a help-desk-and-comp role** — End users ask questions every day; commission cycles and quota-setting recur every period. Steve dedicates one person to help desk and comp (backed by contractors) so those inevitable distractions don't pull his developers and admins off the roadmap. _Why it matters:_ Protect your builders' focus by explicitly absorbing operational toil elsewhere. It stitches together the full RevOps charter without your head-in-the-sand about the work that always shows up. _For:_ RevOps Leaders 9. **Vet contractors like FTEs — but with a higher risk threshold and a fast exit** — Steve runs contractors through a real interview and scorecard (technical ability, ownership, willingness to speak up, communication) and brings them fully inside the team rather than leaving them on the periphery. Most 'agency horror stories,' he argues, aren't about missing skill — they're about whether the person actually invested the time and attention they promised. _Why it matters:_ Use your existing hiring scorecard at the individual level, but carry a higher risk tolerance and be ready to move on in days, not months. A strong system (daily standups, visible participation) reveals a bad fit early. _For:_ RevOps Leaders, Founders 10. **AI's near-term RevOps unlock is on the development side** — Steve thinks RevOps AI is still in its opening chapters and that the development side is 'about to be overrun.' His plays: point an LLM at Salesforce metadata stored in a GitHub repo to write better user stories and list every dependency a dev must check; generate stronger QA scripts; and prevent regression errors at the story stage instead of catching them in a heavy testing step later. _Why it matters:_ Write better stories so you avoid mistakes rather than maturing into ever-chunkier regression testing. The platforms (Anthropic, Google, OpenAI) will keep 'accidentally' creating these capabilities as their base models improve. _For:_ RevOps Leaders 11. **Use AI to compress operational chores like quota-setting** — Steve feeds a few months of ops, closed-won, attainment, and quota history into an o3 chat and is 'astounded' by what it produces — turning a monthly quota exercise that burns a day or two into a few hours of work, with human fine-tuning of objectives and desired output. _Why it matters:_ Systematically list the lower-value recurring tasks that keep your team from strategic work and connect data sources to LLMs to automate them, keeping the road clear for what an LLM can't do. _For:_ RevOps Leaders, Revenue Executives 12. **The accordion effect: stacks fragment, then consolidate — and AI is the new fracture** — Steve maps the CRM ecosystem as an accordion: point tools (Salesloft, Outreach, then Gong and Chorus, Chili Piper) spring up around the CRM, category winners emerge and go vertical, the stack consolidates into a few big players — and now AI adds a completely new fractured layer on top. He expects this cycle to run faster than the 2015 cloud cycle because everyone has 'seen this movie before.' _Why it matters:_ Anticipate both the fragmentation and the coming consolidation. Your job is to weigh the new AI layer, pick the highest-leverage pieces, and bet on the likely category winners before they're obvious. _For:_ RevOps Leaders, Revenue Executives 13. **Move RevOps from cost center to value driver by owning the growth model** — Getting to the next leadership level in RevOps is hard because you're constantly torn between saying yes too much and no too much. The way through, Steve and Anthony agree, is to treat high-quality technical work as table stakes and win on leadership: own the company growth model and go-to-market performance-to-plan, and relentlessly surface the top 'must-be-true' company goals so every initiative ties to them. _Why it matters:_ Owning the growth model earns you the room — board meetings and strategy conversations — because you hold the go-to-market data everyone needs. Champion the company's must-be-true list as one of its broadest support functions. _For:_ RevOps Leaders, Revenue Executives ## Frameworks ### Redefining Lean: Structure, Not Headcount (00:49) **Definition:** 'Lean' should mean intentional, agile, right-sized structure for your stage — not the scrappy, disorganized, under-structured state most early teams actually describe when they say they're lean. Steve reframes a term teams use as a badge of honor for running fast and shipping whatever they can. Real lean ratchets structure up deliberately as you scale, which is what lets a small team produce output far beyond its headcount. ### Agile for RevOps (04:41) **Definition:** Import product engineering's agile operating system into RevOps — standups, definitions of done and ready, boards, user stories, QA and UAT stages — as the default way the team works. A consultancy told Steve to implement 'boilerplate' agile and he submitted completely. The engagement's largest value wasn't the project but the permanent change in how his team operates, and it's what lets him plug specialists in and out cleanly. ### The Contractor Onboarding Course (07:37) **Definition:** A documented onboarding 'course' — tech stack, who-owns-what map, the agile working agreement, definitions of done and ready, systems, and roadmaps — that makes an incoming contractor or agency productive on day one. Writing the course's sub-headings doubles as a free self-audit: it quickly reveals where your RevOps group is deficient. Because you pay specialists for their ramp time anyway, lopping off those first hours is a no-brainer. ### Borrow Your Org Model From Other Functions (13:46) **Definition:** Because RevOps has no fixed blueprint and fits differently into every company, assemble your function by borrowing proven patterns from more mature functions. Steve pulls specialized-agency management from marketing, a help desk from IT, and agile from product — building the RevOps function his needs actually require rather than copying a legacy org chart. ### Product Owners Over the Customer Journey (15:22) **Definition:** Divide the customer journey vertically into segments (four, from growth/brand marketing through sales, onboarding, CS, and support) and give each a product owner who obsesses over improving that stretch for customers, the company, and employees. Each product owner is backed by a pod of RevOps, data/analytics, and enablement, creating a natural path from insight to solution design to rollout. Borders are fuzzy on purpose so owners collaborate across the handoffs that matter most. ### Insulate Developers From the Noise (17:13) **Definition:** Dedicate a help-desk-and-comp role (backed by contractors) to absorb the daily end-user questions and recurring commission/quota cycles so developers and admins stay focused on the roadmap. It stitches together the full RevOps charter without ignoring the operational toil that always shows up, and it keeps your highest-leverage builders on the strategic work you actually hired them for. ### The Accordion Effect (35:15) **Definition:** The recurring cycle where point tools proliferate around the CRM, category winners emerge and go vertical, the stack consolidates into a few big players — and then a new layer (now AI) fractures the ecosystem again. Steve traces it from Salesloft/Outreach and Gong/Chorus in the 2015 cloud era to today's AI layer, and expects it to run faster now because operators have 'seen this movie before' and are racing to adopt. ### Own the Growth Model (43:30) **Definition:** Own the company growth model and go-to-market performance-to-plan — fully segmented, every way the business can be cut — as the source of strategic leverage that earns RevOps a seat in the room. Anthony's framing: owning the growth model (a responsibility the CFO is usually happy to share because RevOps holds the go-to-market data) is what got him into board meetings and the strategy conversations that advance a RevOps career. ### The Must-Be-True List (44:42) **Definition:** A short list of the company's top 'must-be-true' initiatives that the RevOps leader relentlessly surfaces cross-functionally — in every doc, roadmap, and prioritization call — to keep the whole organization aligned. As one of the broadest support functions in the business, RevOps is uniquely positioned to be the champion of these goals, rationalizing why one thing is priority zero versus another and keeping everyone believing in the same few things. ### Cost Center to Value Driver (41:06) **Definition:** The career path out of the RevOps 'yes-too-much / no-too-much' trap: treat high-quality technical work as table stakes and win the next level on leadership — building a function that runs without you controlling every part of it. Steve calls the shift a 'leap of faith' outside most operators' comfort zone: doubling and tripling down on organizing yourself and your team, communicating the function's value, and tying every initiative to the highest-level company goals. ## Quotes _Speakers inferred from an undiarized transcript — verify before attributing._ > "There's a big difference between what a lot of us say when we're on small, scrappy RevOps teams and we say we're lean — we actually mean that we're pretty disorganized, we don't have a lot of great structure." > > — Steve Dinner, The LeanScale Podcast Ep. 41 (00:49) > "It's the structure of my team, and the way I run it, that allows me to go find the best Salesforce developer talent anywhere, and really multiply the output compared to the headcount that we have." > > — Steve Dinner, The LeanScale Podcast Ep. 41 (01:36) > "My engagement with them ended up getting the work done that needed to get done, but actually the largest amount of value was changing how my team works." > > — Steve Dinner, The LeanScale Podcast Ep. 41 (07:06) > "If you write out the sub-headings of what sections that course should have, it's going to pretty quickly tell you where your deficiencies are as a RevOps group." > > — Steve Dinner, The LeanScale Podcast Ep. 41 (09:55) > "It's really tough to outsource leadership, it's really tough to outsource accountability. You can't ask an agency to do that part for you." > > — Anthony Enrico, The LeanScale Podcast Ep. 41 (13:13) > "You literally own this piece of that map, that flowchart — that process is theirs. Obsessing over how to make that better for customers, the company, and the employees that work within it, every single day, is their job." > > — Steve Dinner, The LeanScale Podcast Ep. 41 (16:01) > "When we come to work every day, our job is not to do the work as much as it is to create systems that provide that value." > > — Steve Dinner, The LeanScale Podcast Ep. 41 (17:55) > "A lot of these horror stories are less about you got bamboozled and that person didn't have the skill — it's more about whether or not they were investing the time that they said that they were." > > — Steve Dinner, The LeanScale Podcast Ep. 41 (23:34) > "It unlocks that piece for everybody. If you know how to ask for the right stuff, I've personally become a thousand times more dangerous." > > — Steve Dinner, The LeanScale Podcast Ep. 41 (29:05) > "You don't want to implement regression testing and have it catch a bunch of things that are wrong — you want to write better stories so that you don't make those mistakes in the first place." > > — Steve Dinner, The LeanScale Podcast Ep. 41 (30:18) > "You have to imagine a world where all of this is available to everybody, and you're going to be expected to be 10 times more efficient. You can read Toby from Shopify's letter — that's coming for RevOps. So are you structured to take advantage of it?" > > — Steve Dinner, The LeanScale Podcast Ep. 41 (33:25) > "AI comes into the picture and it's almost like a new layer outside of that has come that is completely fractured — and as a RevOps person, you have to sit there and think about it." > > — Steve Dinner, The LeanScale Podcast Ep. 41 (36:21) > "Nobody went to school for RevOps. Everybody was an accidental RevOps person — myself included. I was forced into it against my will, but I'm so happy I was." > > — Anthony Enrico, The LeanScale Podcast Ep. 41 (38:02) > "In RevOps you're constantly torn between being the person who says yes too much and being the person who says no too much." > > — Steve Dinner, The LeanScale Podcast Ep. 41 (40:40) > "There's this whole other piece that takes a leap of faith — being able to organize yourself and the people on your team and really double and triple down on leadership, and things that build a function that can operate without you controlling every single aspect of it." > > — Steve Dinner, The LeanScale Podcast Ep. 41 (42:54) > "If you can own the go-to-market performance to plan, that's going to really help you get to that next level." > > — Anthony Enrico, The LeanScale Podcast Ep. 41 (43:30) > "Lean means intentional about who's doing what and structured in what you're doing, making sure the time people are spending on things is optimized. That doesn't mean understaffed. That doesn't mean under-resourced." > > — Anthony Enrico, The LeanScale Podcast Ep. 41 (46:58) ## Practical advice by role ### RevOps Leaders - Redefine lean as structure: install agile (standups, definitions of done and ready, boards, user stories, QA/UAT) so you can plug specialist contractors in and out and multiply output beyond your headcount. - Build a documented contractor onboarding course — tech stack, who-owns-what map, the agile working agreement, systems, and roadmaps — and use writing its table of contents as a free audit of your gaps. - Structure the team as product owners over segments of the customer journey, backed by pods of RevOps, data/analytics, and enablement, and insulate developers with a dedicated help-desk-and-comp role so the roadmap is protected. - Vet contractors like full-time hires against a scorecard (technical ability, ownership, willingness to speak up, communication), but keep a higher risk threshold and move on in days if participation slips. - Arm the team with LLMs on the dev side: point them at Salesforce metadata in a GitHub repo to write better user stories, list dependencies, generate QA scripts, and prevent regression errors before they happen. ### Founders - Optimize revenue per FTE: keep leadership and accountability in-house and buy specialist execution (Salesforce dev, help desk, analytics) through contractors and agencies instead of defaulting to in-housing everything. - Remote work and the rise of specialized agencies have made a global, always-on specialist team genuinely viable — take advantage of it rather than assuming tech must build every capability internally. - Fund the structure (agile, documentation, systems) that lets a lean team absorb the 10x AI productivity expectation already hitting product groups; it's coming for RevOps next. ### Revenue Executives - Give your RevOps leader ownership of the growth model and go-to-market performance-to-plan; it's the lever that earns RevOps a seat in board and strategy conversations and moves it from cost center to value driver. - Hold RevOps to tying every initiative to the company's top 'must-be-true' goals, and expect them to be the broadest internal champion of those priorities. - Use AI to compress operational chores — a monthly quota-setting exercise can go from a day or two to a few hours by feeding attainment and quota history into a reasoning model — and reinvest the time in strategy. ## AI takeaways **Thesis:** AI is still in its opening chapters for RevOps, and its biggest near-term unlock is on the development side. LLMs that ingest CRM metadata can write better user stories, dependency lists, and QA scripts and prevent regression errors, while data-to-LLM connections automate the low-value chores that keep teams off strategy. The teams that capture the coming 10x are the ones already structured — agile, documented, systems-first — to absorb it. - **Three waves of RevOps AI** — First, enterprise vendors bolted AI onto existing software; then teams acquired AI-native or AI-embedded tools; now, data-to-LLM connections (a Clay, for example) put data-engineering-grade work in reach of teams that once needed a specialist. - **Development is about to be overrun** — Point an LLM at Salesforce metadata stored in a GitHub repo to draft user stories, list every dependency a dev must check, generate stronger QA scripts, and catch regression risks at the story stage instead of a late, chunky testing step. - **Compress the chores** — Feed months of ops, closed-won, attainment, and quota data into an o3 chat and a monthly quota exercise drops from a day or two to a few hours — with human fine-tuning of objectives and desired output. - **Structure decides who wins** — The 10x productivity expectation already hitting product teams (Shopify's Tobi Lütke memo) is coming for RevOps; only teams with agile, documentation, and clean systems can actually absorb it. - **Watch the platforms and Salesforce's lag** — Anthropic, Google, and OpenAI will keep 'accidentally' creating RevOps dev capabilities as base models improve, while Salesforce has only dribbled out AI features — so look to product and dev teams for what's coming your way. **Agent & automation ideas** - A Salesforce-metadata agent that ingests fields, flows, automations, and the last release from a GitHub repo and drafts a user story plus a full dependency checklist for developers. - A QA-script generator that writes regression-safe test scripts at the story-writing stage to prevent errors before they reach a testing step. - A quota-setting agent that ingests historical ops, closed-won, attainment, and quota data and proposes monthly quotas, tuned to stated objectives. - A 'low-value task' triage agent that connects data sources to an LLM to automate the recurring toil that keeps operators off strategic work. ## Operations takeaways ### Revenue operations - **Structure over headcount.** Intentional, agile structure — not more FTEs — is what multiplies a lean team's output and lets you source the best specialist talent anywhere. - **Agile is the operating system.** Standups, definitions of done and ready, boards, user stories, and QA/UAT, borrowed wholesale from product, are what let contractors plug in and out cleanly. - **Onboarding as a product.** A documented onboarding course makes specialists productive day one; writing its sub-headings is a free audit of your RevOps deficiencies. - **Product owners over the journey.** Own vertical segments of the customer journey in pods of RevOps, data/analytics, and enablement rather than staffing generalists who do it all. - **Protect the roadmap.** A dedicated help-desk-and-comp role absorbs daily questions and commission cycles so developers stay on the roadmap. - **Own the growth model.** Owning go-to-market performance-to-plan and championing the company's 'must-be-true' list is what moves RevOps from cost center to value driver. ## Metrics mentioned | Value | Metric | Context | | --- | --- | --- | | 0 | In-house admin/dev FTEs | Owner.com's RevOps runs a high-output function with zero in-house Salesforce admins or developers on payroll — execution is sourced from specialist contractors and agencies. | | ~8 months | Agile adoption tenure | How long Steve had been running his RevOps team on 'boilerplate' agile at the time of recording, after a consultancy prompted the switch. | | 4 | Product-owner segments | Steve divides the customer journey (growth/brand marketing through sales, onboarding, CS, and support) into four vertical segments, each owned by a product owner. | | 10x | AI productivity expectation | Steve argues teams will be expected to be ten times more efficient as AI lands — the same expectation already hitting product groups per Shopify CEO Tobi Lütke's memo. | | 1–2 days → a few hours | Monthly quota-setting time | Feeding ops, closed-won, attainment, and quota history into an o3 chat compresses a monthly quota exercise from a day or two to a few hours. | | 1,000x 'more dangerous' | Steve's RevOps capability lift | Steve — who never held an IC RevOps role and isn't a strong Salesforce developer — says LLMs made him a thousand times more capable, if you know how to ask for the right things. | ## Entities mentioned - **Owner.com** (company) — Steve's employer; he is VP of Revenue Operations, running a high-output RevOps function with zero in-house admin or developer FTEs during a fast growth stretch. · https://leanscale-knowledge-hub.netlify.app/company/owner-com/ - **LeanScale** (company) — Anthony's firm; he ran RevOps at three fast-growing tech companies (with in-house admins, developers, and analysts) before founding it, and notes he could only have built LeanScale because of remote work. · https://leanscale-knowledge-hub.netlify.app/company/leanscale/ - **Upwork** (company) — Where Steve sourced a Salesforce admin/developer on demand — his example of building RevOps execution capacity through specialist contractors rather than FTEs. · https://leanscale-knowledge-hub.netlify.app/company/upwork/ - **Shopify** (company) — Cited via CEO Tobi Lütke's ('Toby from Shopify') internal AI-first memo — Steve's evidence that the 10x productivity expectation already hitting product groups is coming for RevOps. · https://leanscale-knowledge-hub.netlify.app/company/shopify/ - **Anthropic** (company) — Named with Google and OpenAI as a platform whose improving base models will 'accidentally' create RevOps development capabilities. · https://leanscale-knowledge-hub.netlify.app/company/anthropic/ - **Google** (company) — Named alongside Anthropic and OpenAI as a foundation-model platform that will keep creating RevOps dev capabilities as its base platform improves. · https://leanscale-knowledge-hub.netlify.app/company/google/ - **OpenAI** (company) — Named alongside Anthropic and Google as a platform improving base models; its o3 model is Steve's example for AI-assisted quota-setting. · https://leanscale-knowledge-hub.netlify.app/company/openai/ - **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://leanscale-knowledge-hub.netlify.app/guest/steve-dinner/ - **Anthony Enrico** (person, host) — Co-founder of LeanScale and host of The LeanScale Podcast. · https://leanscale-knowledge-hub.netlify.app/guest/anthony-enrico/ - **Salesforce** (tool, CRM) — The CRM at the core of RevOps; the talent Steve sources (SF admins/devs) and the platform he notes is slow to release AI dev features — prompt-to-flow still awaited. - **Clay** (tool, GTM Data / Enrichment) — Cited as the kind of tool that put data-engineering-grade list building, data cleaning, prioritization, and outreach within reach of teams that previously needed a strong data engineer. - **Swantide** (tool, Salesforce Automation / RevOps Tooling) — Named (transcribed 'swan tide') alongside Sweep as tooling bringing AI-assisted capabilities to Salesforce development. - **Sweep** (tool, Salesforce Automation / RevOps Tooling) — Named with Swantide as software bringing AI capabilities into Salesforce development ahead of Salesforce's own releases. - **Salesloft** (tool, Sales Engagement) — Cited in the accordion-effect narrative as a dialing/sequencing tool that popped up around the CRM in the 2015 cloud era. - **Outreach** (tool, Sales Engagement) — Named with Salesloft as an engagement tool that surrounded the CRM before category consolidation. - **Gong** (tool, Revenue Intelligence) — Cited as a conversation-intelligence category winner in the accordion narrative, likely to go vertical into forecasting and sequencing. - **Chorus** (tool, Conversation Intelligence) — Named with Gong as a conversation-intelligence tool that emerged around the CRM in the fragmentation phase of the accordion effect. - **Chili Piper** (tool, Scheduling / Demand Conversion) — Named as an example of the single-purpose, fractured tooling (meetings/scheduling) RevOps must weigh in a now AI-fractured stack. - **GitHub** (tool, Developer / Code Hosting) — Steve stores his team's most recent Salesforce releases in a GitHub repository so an LLM can ingest the metadata to write better user stories and test scripts. - **OpenAI o3** (tool, AI Reasoning Model) — OpenAI's reasoning model; Steve feeds months of ops, closed-won, attainment, and quota data into 'an o3 chat' to draft monthly quotas in hours instead of a day or two. ## FAQ **Q: What does 'lean' actually mean for a RevOps team?** A: According to Steve Dinner, lean means intentional, agile, right-sized structure for your stage of growth — not the scrappy, disorganized, under-structured state most early teams describe when they call themselves lean. Real lean is about being deliberate about who does what and optimizing where people spend time; it does not mean understaffed or under-resourced. **Q: How can a RevOps team operate with zero in-house admins or developers?** A: By making structure the strategic lever. Steve runs Owner.com's RevOps with no in-house admin or developer FTEs by adopting agile, documenting the team's systems and roadmaps, and sourcing the best specialist Salesforce talent — Upwork developers, consultancies, individual contractors across time zones — who plug into that structure and produce high-quality work fast. Remote work and the rise of specialized agencies are what make this viable. **Q: Why should a RevOps team adopt agile?** A: Agile gives RevOps a shared operating system — standups, definitions of done and ready, boards, user stories, and QA/UAT stages — that lets specialist contractors join and leave cleanly. Steve adopted 'boilerplate' agile at a consultancy's suggestion and found the biggest value wasn't the project he'd hired them for but the permanent change in how his team works, letting it operate at a higher level of maturity than its size would otherwise require. **Q: What should go into a contractor or agency onboarding course for RevOps?** A: The tech stack, a who-owns-what map of the business and its personalities, the current agile working agreement (meeting cadence, definitions of done and ready), documentation of where and how work gets done, and roadmaps. The goal is to make an incoming specialist productive on day one. Writing out the course's sub-headings doubles as a self-audit — it quickly reveals where your RevOps group is deficient. **Q: How should a RevOps team be structured around the customer journey?** A: Steve divides the customer journey vertically into segments — four categories spanning growth and brand marketing through sales, onboarding, CS, and support — and assigns a product owner to each, whose job is obsessing over improving that stretch for customers, the company, and employees. Each owner is backed by a pod of RevOps, data/analytics, and enablement, with a dedicated help-desk-and-comp role insulating developers from daily distractions so they stay on the roadmap. **Q: How do you vet RevOps contractors and agencies before bringing them on?** A: Evaluate them like any full-time hire — run a real interview against a scorecard covering technical ability, ownership, willingness to speak up, and communication — then bring them fully inside the team rather than leaving them on the periphery. Carry a higher risk threshold than for an FTE and be ready to move on within days if they aren't investing the time they promised. Most 'agency horror stories' are about attention and commitment, not missing skill, and a strong operating system surfaces a bad fit early. **Q: How is AI changing RevOps development work?** A: Steve believes the development side of RevOps is 'about to be overrun.' The plays: point an LLM at Salesforce metadata stored in a GitHub repo to write better user stories and list every dependency a developer must check; generate stronger QA scripts; and prevent regression errors at the story stage rather than catching them in a heavy testing step later. He also compresses monthly quota-setting from a day or two to a few hours by feeding attainment and quota history into a reasoning model like o3. **Q: How does a RevOps leader advance from cost center to value driver?** A: Treat high-quality technical work as table stakes and win the next level on leadership. Own the company growth model and go-to-market performance-to-plan so you hold the data leadership needs, relentlessly surface the top 'must-be-true' company goals in every doc and roadmap, and build a function that runs without you controlling every part of it. Owning the growth model is what gets a RevOps leader into board meetings and strategy conversations. ## Timeline - **00:00** — A RevOps team with zero in-house admins or devs - **00:49** — Redefining 'lean': structured, not disorganized - **02:53** — How remote work enabled a global specialist team - **04:41** — Adopting agile — the consultant who changed everything - **07:37** — The contractor onboarding course (and what it reveals) - **13:13** — What you can't outsource: leadership and accountability - **13:46** — No blueprint: borrowing org models from marketing, IT, product - **15:22** — Product owners over the customer journey - **17:13** — Insulating developers with a help-desk and comp role - **21:03** — Finding and vetting the right contractors and agencies - **25:44** — AI in RevOps: the opening chapters - **28:27** — Becoming 'a thousand times more dangerous' with LLMs - **31:29** — Setting quotas with AI and automating low-value work - **33:25** — The 10x team and Shopify's Tobi letter - **35:15** — The accordion effect: fragmentation and consolidation - **38:02** — The accidental RevOps career path - **40:40** — Cost center to value driver: advancing in RevOps - **43:30** — Owning the growth model and the 'must-be-true' list - **46:30** — Closing: lean means intentional ## Related episodes - **Ep. 95: Why AI Means More RevOps Hires, Not Fewer** (Jimmy O'Halloran) — The sibling AI-and-RevOps thesis: productivity gains should grow (or restructure) the team, and operators win on structure and trust rather than raw headcount. · https://leanscale-knowledge-hub.netlify.app/podcast/jimmy-ohalloran-new-relic-revops-consumption-revenue/ - **Ep. 85: Why AI + GTM Engineers Can't Replace RevOps** (Tessa Whittaker) — Directly on RevOps org design in the AI era — a strategist's judgment vs. execution capacity, echoing Steve's 'you can't outsource leadership' line. · https://leanscale-knowledge-hub.netlify.app/podcast/tessa-whittaker-ai-gtm-engineers-revops/ - **Ep. 88: Why AI Won't Close Your Biggest Deals** (Michael Kiernan) — A CRO embedding agentic AI without removing humans — pairs with Steve's structure-first approach to absorbing the coming 10x. · https://leanscale-knowledge-hub.netlify.app/podcast/michael-kiernan-nextdoor-ai-wont-close-deals/ - **Ep. 15: Where Should RevOps Report?** (LeanScale) — Org-design companion to Steve's product-owner pods and the cost-center-to-value-driver career arc. · https://leanscale-knowledge-hub.netlify.app/podcast/cameron-legge-where-revops-report/ - **Ep. 6: Why Your Forecast Is Broken** (LeanScale) — Foundational forecasting episode behind the 'own the growth model and go-to-market performance-to-plan' advice. · https://leanscale-knowledge-hub.netlify.app/podcast/why-your-forecast-is-broken/ ## Full transcript _Machine-transcribed and not diarized; speaker attribution is inferred._ _Transcript only, as a separate file: https://leanscale-knowledge-hub.netlify.app/podcast/steve-dinner-structure-not-headcount-revops/transcript.md_ ### 00:00 — A RevOps team with zero in-house admins or devs **[0:00]** Today we have Steve Dinner, VP of RevOps at Owner.com. Steve, really excited to have you here because you're diving deep on something we at LeanScale are really excited and passionate about, and that's building your RevOps team in the leanest way possible while still maximizing quality and output. And I think you've started this with something really interesting that you have a team of zero admins and developers that are FTEs in-house, yet you are still building a high octane revenue function at Owner.com as you guys have been scaling like crazy. ### 00:49 — Redefining 'lean': structured, not disorganized **[0:49]** Yeah, it's been an interesting 12 months, for sure, and I certainly wasn't in a position to be able to build my team in this way at this time last year. But I've definitely found that there's a big difference between what a lot of us say when we're starting out, when we're on small scrappy RevOps teams, and we say we're lean, we actually mean that we're pretty disorganized, we don't have a lot of great structure. And so the definition of lean has definitely changed for me in the past year, really adopting agile, right size for where we're at in our journey, and then just continuing to ratchet up the structure as needed. **[1:36]** And that's really what kind of opened my eyes to the fact that for the FTE hires that I need to make want to make want to ask the business for their best spent on the most high leverage strategic roles, and actually it's the structure of my team, and the way I run it, that allows me to go find the best Salesforce developer talent anywhere, and make it really easy so that you know they're having high quality stories that they can execute on and we can put out the best work possible and really like multiply the output, compared to the headcount that we have. **[2:14]** Absolutely. I think the older way, and I'll use myself as an example, before starting LeanScale, I ran RevOps at three fast growing tech companies, and I had in house admins, in house developers, the old desk, in house analysts, like, you name it, I had really really big teams. And I think at the time, I didn't really have a lot of options, at least it felt like, during then, there weren't a lot of agencies around at the time, it was a little bit more difficult for me to find like contractors that were good. ### 02:53 — How remote work enabled a global specialist team **[2:53]** So, I think things have changed a lot. I think a big proponent of that is remote work. I know it's kind of old news, but I do think we're still seeing the impact that remote work is having in the labor economy. And I think some of the acceleration and technology too, it's really really hard for one person to keep up with things. So, finding the best talent, that can change on like a quarter to quarter basis. Yeah, I mean, even believing it was possible to, you know, run a well oiled machine with people in all various time zones or all not in even in one city not coming into the office every day. **[3:36]** Like it was pretty hard to imagine at one point so, you know, I almost like have taken for granted and forgotten to some degree like the, the impact of remote work on my current situation like I have people in. Eastern Mountain Pacific, Asia Pacific like I'm all over the place and so we actually function like a, like a global company in a lot of ways and, and that it that does just have such a huge impact on it the, the belief in the possible I guess came from the rise in remote work and we're definitely taking full advantage of that. **[4:14]** No, it makes a ton of sense. And I think there are things you do have to have in place, like to have people in different time zones. You're not in the same room, communicating and talking every single day. I do think it requires a level of structure. So before someone thinks like, Oh, I can just outsource so many things or bring on this global team. What are some things that you've implemented that have enabled you to operate in this way. ### 04:41 — Adopting agile — the consultant who changed everything **[4:41]** Yeah, this is what I really get into my hardcore belief in agile which is only eight months old for for asset at owner but you know I've, I've hired one Salesforce admin developer off of Upwork, and I've brought in, you know, a like pretty high powered Salesforce consultancy, and the thing that the two of them have in common is that like the ability for them to come in and make an impact quickly. And the quality of work really depends on what I give them to start with like what documentation do I have what system do I have what process do I have how do I teach them how to communicate with us how do I teach them what's important in the business. **[5:27]** Like, there's vastly different degrees of, you know, cost to you, but it really comes back to that same thing. And I had a situation around this time last year where I was being the old kind of lean, where I was just you know, running as fast as I can pretty disorganized, some people call that just understaffed and under resourced but there's a difference right people do call it that. Yeah, no, I think there is because mentally, like if we were to, if we were to be at a conference with 100 of our peers, there'd be some people that learn to take pride **[6:05]** in that, right, that they just kind of go as fast as they can ship as much as they can. And almost just because it's hard to figure out how to deliver for the business and build these systems, like that's really hard to do to not lose a step. And to not have people have prying eyes kind of asking you hold on, you're building what and why like what's that going to do for you know the delivery schedule that you promised us and the goals of the business like that's really hard. I think a lot of people end up like falsely **[6:35]** taking pride in the fact that they just kind of run a million miles an hour and ship whatever they can, even if they are understaffed or under structured to do so right. So I think that was me like last year, and bringing in, you know, I brought in some consultants to help with some very specific work, actually like they were supposed to work on one thing very specifically. When they asked me what my project management structure was I kind of said, nothing that I'm like very proud of or like really want to share with you. And it's a long to do. **[7:06]** But like I just didn't, I just didn't like, I was like, is it even worth me telling you because like I know it's not going to be good enough for what you want to do here. And they just sort of said hey like are you willing to just implement agile and I was like yeah I'll do it. Absolutely boilerplate boilerplate like I just submitted to it completely. And that was a huge eye opener, because my engagement with them ended up getting the work done that needed to get done but actually the largest amount of value was changing how my team works. ### 07:37 — The contractor onboarding course (and what it reveals) **[7:37]** And that's how I'm kind of like obsessed with being ahead of the curve with being with being able to deliver or have my team operate at a further level of maturity, then I probably would otherwise need to but not because just for the sake of it for the bureaucracy, but actually because we find better ways to do it I kind of just try to look down the road and and find that next thing. That's really like what now has me in a position where I could structure the team in such a way where if I need to bring on to extra Salesforce devs like I have a way to do that that is a known thing that my team does. **[8:20]** You're like okay assign them that course for how you onboard RevOps at owner. Here's the home base with all the what good looks like documents. Here's the board, here's the documentation repository, take a few days get comfortable with that, you start on QA's on QA and next for it you're in. And I think that it kind of like, whether it's bringing on like a couple individual developers or like if you're going to bring on an actual agency and like go and do like a very important engagement. **[8:52]** It really starts with like how you're organized and seeing that as a strategic lever for yourself, not, and like being able to carve the time out for that versus just like really just only being able to think about the next thing that you've got to deliver for the business. Can I go back to something that you said, because, sure, since the beginning of lean scale till now, I have never had one of our engagements give us a course of how to onboard your agency internally and load us up with a bunch of organized documentation like normally we're begging **[9:24]** for those things like, hey, we know we need context, we don't want to waste a bunch of time with you guys scoping like let us do homework. Let's do homework before we even get started. That's pretty incredible that you have it organized to that level, knowing, hey, my strategy is I'm going to need to rotate in specialist and high quality contractors and agencies to keep iterating and grow to where owner.com needs to grow. But to have that level of foresight of how to onboard them in is really powerful. **[9:55]** What for somebody I'm going to send this to all of our clients, by the way, what would you recommend putting in that course like what's in that pack to get somebody up to speed on owner.com and make sure it is contractors productive day one. You know, I think like, if you go through and you write out the sub headings of what sections that course should have, it's going to pretty quickly tell you where your deficiencies are as a rev ops group. Like, if you're imagining yourself walking in day one and needing to be productive as fast as possible because they're spending your money learning otherwise. **[10:32]** It's really going to like it'll tell you, but, you know, it's, it's the basics. It's the things that are that you don't want to burn cycles with your high leverage. You know, folks that you're bringing in to help you with something very important on like, so you're going to want to be telling about tech stack, you know, all the personalities within the business who owns what who to go to for what. Even just like a copy of the most recent version of your agile working contract. When do we meet, how do we meet, what are our definitions of done and ready and everything like that. **[11:10]** As much detail as you can provide about your system, where work gets done, what your roadmaps look like. It's literally everything you can provide and if you like any, any one of your customers could start reaming off these subheadings and then it would be pretty evident which ones you needed to round out prior to bringing in the experts but I mean that's really what it's about right now, bringing in somebody to do something very specific that has a very tangible value for you and your business, you know, if you can lop off the first number of hours, getting started which you're paying for anyway, then that's like a no brainer. **[11:55]** It's kind of sense and I think a lot of companies, they're going to be built this way. And I don't know. There's a lot of under other industries where this is relevant like the whole, the company doesn't in house everything they're very used to like building strategic partnerships to build components of the company as they grow in scale tech I feel like has historically done a lot, just in house. Yeah. And I think since remote work, there have been, there's been a massive increase in how many agencies have popped up, and I'll tell you personally why, because I could not have built lean scale. **[12:33]** When I was in an office. I had to take some client calls because I did it on the side when I was, you know, working full time somewhere, and I wouldn't have, I wouldn't have even had the courage to like, go build it. If I wasn't working remotely. So I do think there's a lot of people out there who are still like, maybe thinking about doing that building an agency around really specialized skill sets. But what it also means is as a lean startup, when you're thinking about, Hey, our North Star is probably revenue per FTE, like how efficiently can we grow this company, what has to be in house, and I'm going to ask you that in a second. ### 13:13 — What you can't outsource: leadership and accountability **[13:13]** Like, what are the roles that we really want to make sure are in house, it's really tough to outsource leadership, it's really tough to outsource accountability, like, you can't ask an agency to do that part for you and give guidance and advice, but not make the decision. So, what do I do to build the other needs I have on execution. And I really like the foresight you have to say like hey this is going to be part of our strategy. We're going to be onboarding people a lot, and to have the infrastructure to do it is, is really strong. ### 13:46 — No blueprint: borrowing org models from marketing, IT, product **[13:46]** Yeah, like one thing that like kind of strikes me to about what you just said is rev ops can mean so many things in so many different places right. And anytime that I am interviewing for an FTE role, like you have to level set and say like, Okay, what is this, what, how, how did this fit into your organizational design. But that also provides like a really interesting opportunity, which is like, you have a lot of different types of organizations to learn from because there's no real blueprint for how yours is supposed to look. So if you're going to think about, you know, who's the most effective at using specialized **[14:20]** organization agencies and things like that in your typical org, it's gonna be your marketing group. Right. So go learn that from them. And then look at an IT group that's way bigger than like my company, but go look at how an IT group organizes itself, like what can I learn from that. Okay, so I'm going to pull help desk from there, I'm going to pull specialized agency for marketing. I'm going to pull agile from, you know, product, let's say, there's a lot of opportunity to just sort of like look around and make the rev ops **[14:49]** function what you think it should be based off of your needs, not necessarily like there isn't a blueprint as much because of how different it is and how it fits into every organization. Right. No, and some of those things like in marketing, they'd have a brand and style guide that they would give to somebody they're bringing like, hey, this is these are the colors, the fonts, you don't have to like have them guessing about what that type of stuff is. So as a rev ops organization, we should be organizing what that means for us. So when we onboard people, we can do it ### 15:22 — Product owners over the customer journey **[15:22]** efficiently. Steve, what type of roles do you think have to be in house? And where do you invest your FTE dollars versus bringing on agencies and contractors? Yeah, like, I would I will spend, or I will go out and fight have gone out and fought for, you know, product owner type roles in agile speak. So if I picture the customer journey of our entire business, you know, starting at growth marketing, brand marketing, all **[16:01]** the way through this customer success and support. I'm going to divide that vertically into four categories, and I want a product owner for each one, which amounts to somebody who literally owns that piece of that, that map, that flowchart, that process is theirs. And obsessing over how to make that better for customers, the company, and the employees that work within it, obsessing over that every single day is their job. And figuring out where we can get a half point of efficiency here and there to, you know, map towards **[16:41]** our company's strategic goals. That's exactly where I spend, have spent the majority of my headcount in the past eight months. And I think it's really the way to go. It seems early for a company of our size, probably, because normally I think what you'd end up doing is having somebody who's, you know, hiring more generalists, trying to find people who could sort of do it all. But I get to focus on just finding people who are excellent at this process and strategy piece. ### 17:13 — Insulating developers with a help-desk and comp role **[17:13]** And their ownership over that piece of the customer journey and partnership with the project management group and the development group is really like the biggest unlock that I've had. The other piece is not to ignore all of the other things that it takes to make a RevOps org run. Every single day, somebody's going to be asking questions, like your end users. Every quarter or every month or whatever your period is, there's going to be a commission cycle. You probably own some element of that, whether it's end to end or partnered with finance. **[17:55]** And so really what I've been working with my team and it's been really amazing to work with them and start to instill this mindset of like when we come to work every day, our job is not to like do the work as much as it is to create systems that provide that value. So I have one person who's solely focused on, you know, compensation, helping with quota setting and running an IT style help desk. And we use some contractors for that as well. **[18:30]** But it really starts to stitch together the entire charter of the RevOps group because you don't have your head in the sand about these things that are going to happen that would normally start to distract and pull away your developers admins from what you want them working on, which is the roadmap. It kind of insulates them from that while also servicing your team. So it's that help desk comp planning person. It's the project manager who's full time and in house, and then it's the product owners. **[19:12]** Are you able to share a little bit more specifically on the product owners? I think, standard ways we've seen RevOps orgs built, they kind of pick functional like, hey, you're overall the technology, you're overall the data, you're overall this, or they take department. So your sales ops, your marketing ops, your CS ops, are you saying something a little bit different, like owning a specific part of the life cycle or owning other things that may be different than those two setups? **[19:47]** Yeah, no, I think it is pretty close to the functional one that you described there. But the way that I describe it to them, because those things all need to work together, there's not really much sense in acting like the handoff from sales to onboarding isn't important, or that the onboarding to CS handoff isn't important. So there's plenty of times where they need to work hand in hand. So I, I like to think about it as like, you own this piece of that customer journey. And the borders are a little fuzzy, and some pieces you have to own with somebody else. **[20:20]** And we have basically these pods where you have a RevOps person, a data and analytics person, and a, and an enablement person for each one of those functions. And so you can kind of see the natural progression from like insight to solution design to roll out to to the team. So they're, they're pretty much in that functional structure that you described. Got it. No makes sense. I think I like that one too, because it pushes accountability for what the goals of those departments are to like, hey, marketing, they're they're trying to create pipeline and create opportunities to enhance the brand, like, how can we support their main goals. ### 21:03 — Finding and vetting the right contractors and agencies **[21:03]** Yeah, I think it drives a lot of alignment. One, one thing, especially if somebody's newer in a management role in RevOps is where to even find these relationships. I mean, I, you have great partners, you have great talent that you found and vetted out. I've also heard absolute horror stories and have been on the receiving end of bringing on agencies that were just terrible, which make it sometimes it just makes it hard for anyone to even like think about outsourcing some of this stuff. But how do you find the right agency partner, find the right contractor talent? And then how do you vet them before you bring them on? **[21:45]** That is very much a million dollar question. I think that I've been exceptionally lucky in this. Yeah, a lot of these relationships I kind of like had or or at least were introduced second hand to somebody who, who somebody I knew trusted, but I think ultimately, there is an amount there is like a risk tolerance that you need to have. And you need to be able to put people in a position to succeed and show kind of their true colors and also be ready, I think, to move on quickly if it doesn't work. **[22:21]** I can't really like, I mean, other than name dropping some, some of my folks. I don't really know exactly how to help with like finding the right types of agencies or partners or sourcing methods. But we do definitely bring on or sorry have a have a hiring guide and we've run a full interview process and I have my project manager run it and I have him use a scorecard around, you know, technical ability, ownership, willingness to speak up and **[22:58]** and just sort of like how they interact with others the communication standards so whatever, honestly, your, your existing hiring scorecard looks like is one that I would use at the individual level when I bring people on because a lot of what we do is, is find contractors and then bring them into the team, which is, in my opinion, kind of the only way it works you can't have people that are kind of on the on the periphery and not included and expect that that that type of work. So you have to create that environment, and also in that environment if you're saying, hey, stand up is every day. **[23:34]** And if you're going to miss stand up then you post in the post in the channel. It's gonna be evident to you pretty quickly like who is on board, because I'm pretty firmly believe that a lot of these horror stories are less so about, you know, you got bamboozled and that person didn't have the skill, it's more about whether or not they were investing the time that they said that they were, whether they were, you know, giving you their full attention to detail and holding up their end of the bargain. **[24:05]** And I think if your system is strong enough, you end up seeing that pretty early. So I guess I don't have a great question other than treat them like, or evaluate them like you would any other full time higher, but just have a little bit more of a higher risk threshold and an ability to not waste weeks and months before you actually know what the quality of the work and quality of their character is. No, I think that makes a ton of sense. I think that's a good framework and proxy to think about, you know, whatever you would use to interview an internal person is great. **[24:38]** I don't know if you do this for your team. We do it before we hire anyone at lean scale. We always have them do a technical assessment. So before we bring someone on that we're thinking, hey, we're going to put in front of clients at some point, we want to make sure they're legit. So we have a small project that they can do. And also before we get engaged with any companies, we always do some form of audit or something, something for free. **[25:06]** So I would just say, hey, if you're about to engage with an agency, I love that like put them through the standard questions you would ask them what their skills are, how they learned them, and then also get some type of sample work out of them, too, if you can. Yeah, for sure. Agency. Yeah, the criteria for agency would certainly be different. And, you know, the majority of what I'm doing is actually like bringing in individuals. Although I do work with agencies as well. I just have kind of the one or two relationships established already. ### 25:44 — AI in RevOps: the opening chapters **[25:44]** Awesome. I know we talked about how remote work is a macro environmental impact to being able to build RevOps organizations this way. Something else that I think is creating a lot of tailwind as well for keeping your team lean is leveraging AI. How do you see AI being leveraged in a RevOps context? And how does AI make your team more efficient and more effective? I think the story is really in the opening chapters for RevOps, even though it might seem like it's absolutely everywhere already. At least people are talking about it everywhere. Yeah, there is a tendency to certainly over-verbalize anything to do with it. **[26:37]** I think that obviously the first wave of AI for RevOps was whatever enterprise software you are using, they went and plugged it in right away and said, oh, here it is. And so there's that element to it. Then you probably started to acquire either some like AI native tools or some other tools that had AI built into them as part of your regular software acquisition process. And then now we're kind of in this third step, I think, where companies, I guess, that probably would not have been able to do as sophisticated things, **[27:20]** especially with regards to how they're building their lists and cleaning their data and prioritizing and building their outreach and sales and everything like that. The tools that something like a clay or whatever have really put that in a lot of people's reach where you would have needed somebody pretty awesome on the data engineering side probably to achieve a lot of that in the past, even though it was achievable. **[27:48]** And I think it's going to be really interesting over the next little while because even Salesforce has only really started to dribble in a few of these AI features and they're mostly customer facing or interfacing with the actual development within the software. You know, we're still waiting for that release to be able to kind of prompt to flow and things like that. And so as a RevOps org, I think you have to look outside of the enterprise software where you develop that, you know, like other software development and things like that, ### 28:27 — Becoming 'a thousand times more dangerous' with LLMs **[28:27]** like your product team, for instance, and see how they've been impacted and imagine that that's sort of coming your way. I've personally become a thousand times more dangerous because my journey into RevOps was not one where I ever had like an IC role. I inherited the department while I was running a BDR work. So I've never been as skilled as my team members at really any aspect of let's say like Salesforce development or writing sequel or any of that type of stuff, even just like basic formulas in Salesforce like that's not where I excel. **[29:05]** Now, right, like it unlocks that piece for everybody. If you know how to ask for the right stuff, where I'm looking at trying to find ways to like, by orders of magnitude increase my team's efficiency is starting to think about how can I have it, how can I have an LLM kind of ingest all of the metadata from the last release that we did, and all of the metadata from, you know, my automations my custom fields my, my flows, and just say, Hey, I'm thinking about writing a user story that does this, **[29:42]** this and this, write a list of all the dependencies that a dev would need to check into prior to creating a solution for this, as I was talking about earlier trying to be like a step ahead on the maturity ladder, relative to the size of my team. Now you start to think about, okay, we have a QA step, we have a UAT step. Are they just stages in my camp comp on board. Maybe, like, are people just kind of going through them like are their standards for how the QA script is written are their standards **[30:18]** for how the UAT script is written. Do we really have true regression testing. Well, that all might be true. So can this LLM actually write me a better QA script, and can it prevent regression testing errors at the development stage rather than, you know, maturing to the point where you're adding this like very lengthy very chunky testing step, which really, you don't want, you don't want to implement regression testing, and have it catch a bunch of things that are wrong, you want to write better stories, so that you don't make **[30:54]** those mistakes in the first place. So how can I just like avoid certain steps along the journey here is the way that I'm thinking about it from like a development standpoint. And how can I have my team, sort of start making lists of the less valuable tasks that we do every day that, you know, prevent them from executing on things that we actually think strategically help the business. And how do we automate this, because there are so many ways to connect your data sources and your LLMs together that weren't even ### 31:29 — Setting quotas with AI and automating low-value work **[31:29]** six months ago. We're really looking at trying to do as much as we can to maximize the value of using those to keep the road clear, so to speak for the most strategic tasks that we don't think that an LLM can do. But even something like, like setting quotas, like, grab a bunch of your data from the past few months on ops and close one and attainment and quotas, and throw that into an O3 chat, and you'll be astounded with what it comes up with obviously like you're going to want **[32:03]** to be able to fine tune these things and tell them what their, you know, what their objectives are and, and what the output that you want is but ultimately like those are the type of things that can take something that would burn, you know, a day or two of your company and you do monthly quotas, and reduce it down to a few hours. And as like those, those type of things compound so it's, it's impacting the customer journey anywhere you possibly can like there's AI all through our stack, there's custom AI in some of our, you know, outbound lead targeting lead targeting stuff let's keep it a little bit secret. **[32:48]** But I really see the development side of the house as something that is about to be basically overrun by this. We've just started to use a GitHub repository to store all of our most recent releases and so that's where I was playing with having an LLM be able to do that for the purposes of writing better user stories and writing better test scripts. And like, just, you know that the platforms themselves like anthropic and Google and open AI are going to essentially accidentally create these things, just by improving their base platforms. ### 33:25 — The 10x team and Shopify's Tobi letter **[33:25]** So you have to imagine a world where all of this is available to everybody, and you are going to be expected to be 10 times more, more efficient, and so your team should be reflected as such and you're the way that you asked them to operate needs to be that way. We're already seeing that in product groups like you can read Toby from Shopify's letter. That's coming for rev ops, so are you structured to be able to take advantage of it. Are you, you know, well, well educated and what can be done today because it's about to be even more front and center in all of your workflows. That's, I guess, the message. **[34:06]** I agree with you. I think it started to come in a little bit, and I think some of the platforms like swan tide and sweep and so on are like bringing some of those capabilities to Salesforce development. I do think rev ops is becoming, I'd say before is like a rev ops kind of meant 80% is like Salesforce, but the tech stack is getting so much more broad. **[34:35]** So even at at lean scale, like we're not necessarily looking for Salesforce admins or Salesforce developers. We need like proper developers because if you're going to connect that with like whatever AI or like our customers are using plus leverage clay plus leverage like everything else that they're bringing into the stack. You need to kind of have a broader systems management and systems thinking approach. Yeah, but I agree. I think a lot of the benefits that we've seen on like development will come behind the enterprise application soon. ### 35:15 — The accordion effect: fragmentation and consolidation **[35:15]** I think people should also be thinking about it similar to like if you're around in like say like 2015 and you know enough companies had adopted Salesforce and that was like using a cloud CRM was maybe not like brand new. They're over the chasm on that, but it became clear that they weren't going to create like an excellent dialing solution at that time. **[35:39]** So you see sales lofted outreach pop up and then it becomes clear that well, they're probably not going to create conversation intelligence. It's gone and chorus pop up and you start to see this kind of accordion effect where I like a million tools that are not trying to be a CRM but are firmly surrounding them or orbiting the CRMs. They all come up and then within what the last six or seven years, then the accordion starts to crash together again and the category winners or category leaders in a lot of those spaces start to go vertical still outside of the CRM and you end up with a few really huge players who do everything. **[36:21]** And then AI comes into the picture and it's almost like a new layer outside of that has come that is completely fractured and as a RevOps person, you have to sit there and think about. And, you know, if you were around back then kind of like remember what it was like to have this super fractured tech stock and, you know, you got chili Piper on meetings and you got sales loft on calls and emails and like, you know what I mean? **[36:51]** Just a million different things. You've got to contend with like this new fracturing and weigh the value of it and figure out which pieces are going to be the highest leverage ones and which ones are going to end up as category winners and which ones give you an edge against the competition, really. Great. I wholeheartedly agree. It's going to follow a similar trend. I think it'll be a little bit more accelerated because even like I don't know if it was clear that that consolidation would happen around 2015 2016 when like that started happening. **[37:25]** I don't know if it was like, okay, clearly Gong is now going to probably do forecasting and sequencing and all this other stuff. Right. But now since I think we've seen that and also I think the adoption of AI has gone a lot faster than adoption of cloud because. All right, we've seen this movie before I better get like going quickly or I'm going to get left behind and I think that's going to happen to fractured very segmented ecosystem and then absolutely there will be consolidation in the space. ### 38:02 — The accidental RevOps career path **[38:02]** Yeah, 100%. See, if I think something that's really interesting or just our audience and people who listen to these podcasts, a lot of them are in rev ops right now looking for that, you know, VP progression of their career. I always find it super interesting because nobody went to school for rev ops, you know, everybody was an accidental rev ops person myself included. I was forced into it against my will, but I'm so happy I was. But I really would love to hear history story. Even if there was some like interest in like early childhood or anything that you feel like we're tangential but how you got to where you are today. **[38:45]** I don't know what in my childhood or anything like that necessarily would have pointed my me here. My, my dad would say he's not surprised I think if he, if you were to ask him but I think, you know, I ended up in a second line leadership position prior to even having my first job in rev ops, I ended up as a br director running multiple br teams and rev ops Salesforce, I guess, in and of itself became like a way for me to be better at being a br manager and being a br director, because I just found it was so powerful that I could trust in the fact that we're **[39:30]** great people who really want to be the best and therefore if I like create this new metric and put it on a dashboard that stack ranked, people are going to look at it and be like I want to be on the top of that. And it was just such like a huge impactful thing that you could do. And I've just I guess always had a just always been sort of like drawn to that type of broad impact so yeah I get into it through the BDR world and my first rev ops job was running rev ops in addition to running the BDR org so it's a pretty interesting path. **[40:03]** It is, but you also then really are your own stakeholder for a lot of the most important things you can really get through some cycles pretty quickly. But yeah, in terms of getting into rev ops I think you do have like there is no one way. Once you're there, and I have this conversation with people all the time. Getting to the next level is definitely the challenge I think you can end up in rev ops like one of a million different ways but once you're in there and once that title is on you. ### 40:40 — Cost center to value driver: advancing in RevOps **[40:40]** Getting into like a higher level of leadership within the revenue team within the company is definitely a challenge because in rev ops you're constantly torn between being the person who says yes too much, and being the person who says no too much. Or, you know, being the person who over promises or being the person who's under promising is maybe another way to look at it. **[41:06]** And I think like to really, really see the role correctly and have others people's not see you as a cost center but actually like a value driver. It comes down to being able to build a function, not so much like, you know, a little bit of a broken record here but building a function and building a system, being able to communicate the value of your, of your team and of your function, and being able to tell you tell people exactly why it's aligned with the highest level company goals. **[41:44]** Like, at my company, and at anyone who's in this similar position, like you should be the person that is pointing to, and most often bringing up the company's annual goals that are trying to be hit, and being able to tie every single thing that you're doing and having these conversations out in the open. I think that that's like the clearest way to advance your career and rev ops is, you know, with if you consider the high, high value and high quality work being table stakes, like that's the piece of it that I think is, is really **[42:21]** hard to grasp because it's so far outside of a lot of people's comfort zone if, and it's so far outside of the other pieces of the job that you think make you great, which would be like being great technically, or, you know, being able to deliver a lot of work in a short amount of time with probably less resources than you want. There is this whole other piece that takes a leap of faith, which is being able to organize yourself and the people on your team and really double and triple down on leadership, leadership **[42:54]** and things that build a function that can operate, you know, without you controlling every single aspect of it, that's like, what's going to move you forward. I think it makes a ton of sense systems thinking outcome driven. And I think what you were describing we coin as the growth model of the company. I found when I was owning the growth model and read ops, when I was reporting to the targets in the growth model, fully segmented, knowing the scoreboard of every single way you could cut the business up. ### 43:30 — Owning the growth model and the 'must-be-true' list **[43:30]** That was when I gained an incredible amount of strategic leverage to be in the room, be in those conversations, I got brought to the board meetings, because they're like, hey, if a number comes up that the board wants to know about Anthony's going to know it. So we better have him in there and owning the owning that growth model in rev ops, which you should it's between you or the CFO and normally the CFO wouldn't mind kicking some of it down because you have all the go to market data that they're always looking for. So I think if you can own the go to market performance to plan, that's going to really help you get to that next level. **[44:09]** And if you're building, of course, in the way that you're describing systems thinking outcomes driven, you're not there to do the work but build the system that can maybe help you not need to work as much. There's always more system building to be done. So yeah, that doesn't end up working out that way. But yeah, even even like if you have, like I do a counterpart VP of data business operations and analytics like somebody who's dedicated to those numbers, there are still **[44:42]** company initiatives that we are we call our must be true. Right. So we have this list of must be true things. And I like, I consider myself to be the person, or I want myself to be the person who is most frequently bringing those things up cross functionally to say, this is why we're doing what we're doing. And also to try and kind of like, make sure that we're keeping everybody else on board, like there's an element of, you know, aspiring to really make sure that if we believe these things as a company, you know that we're continuing to believe them we're **[45:24]** keeping them in front of mind. And there's a million other people that we have to, you know, work with and have aligned roadmaps with as well. And so we should all be believing in them. So even as simple as just like knowing the top five must be true things for your company, and surfacing them anytime that you're sharing a doc or presenting your roadmap or rationalizing while you're working on one thing and that's a priority zero versus another thing that is a priority one. I think it's just even that simple. **[45:56]** It's just this relentless focus on the most important things for the company. Because, ultimately, you're going to be the one of the broadest support functions in your business. And so it's as important or more important for you to be the champion of those things than anything else. I agree. And I'm going back to something we mentioned in the beginning, you can't outsource leadership, you can't outsource accountability. And I think those are some of the ways that that those show up. ### 46:30 — Closing: lean means intentional **[46:30]** And like, you know, that's how you're going to grow. That's how you're going to win. We've all decided on it. Let's have some fun with it. Let's keep it up top of mind and show it from the rooftops. And internally, I think that has a ton of value. It does. It does. Steve, this has been super insightful. I really appreciate you bringing this I think you're doing things in a really modern way, intentional way and thoughtful way. **[46:58]** You know, the way rev ops is built and structured is going to, I believe, look a lot more like your model than what we've seen in the past couple years, where you're keeping the team lean. That doesn't mean understaffed. That doesn't mean under resourced. Lean means intentional about who's doing what and structured and what you're doing and making sure that the time people are spending on things are optimized. I love that you're building a network of specialized contractors, agencies, thinking of ways to systematically enable them and onboard them into owner.com and making sure that they can hit the ground running. **[47:37]** And I think you have the eye on the ball in a really meaningful way of how to leverage AI. And as soon as some of those capabilities come out, which we know they're coming, it sounds like you're going to have the team, the process, the systems, the resources, agile methodology to start taking that and just supercharging the efficiency and effectiveness you have of your team. Yeah, thank you very much. I'm hoping so. And it's going to be really exciting one way or another. Either way, it's going to be a good story. So I appreciate you joining. Really excited to follow everything you're doing at owner.com and follow your career. **[48:20]** And as things progress, we'd love to have you back. Of course, it's an honor to be on. Thank you so much for having me. And yeah, we'll definitely talk again soon. Thank you, Steve. --- _LeanScale Podcast Knowledge Hub. Free to quote and cite with attribution to The LeanScale Podcast (https://www.leanscale.team)._