---
title: "Stop Hiring GTM Engineers. They Already Work For You."
episode: 123
podcast: "The LeanScale Podcast"
publisher: "LeanScale"
guest: "Ryan Vanshur"
guest_title: "VP of GTM Intelligence and AI Solutions, Handle"
date_published: 2026-09-22
date_modified: 2026-09-28
duration: 00:58:19
word_count: 11244
topics: ["ai-in-gtm", "revenue-operations", "sales-enablement", "gtm-strategy"]
canonical_url: https://www.leanscale.team/knowledge/podcast/ryan-vanshur-handle-gtm-engineers-already-work-for-you/
source: "LeanScale Knowledge Hub — https://www.leanscale.team/knowledge"
license: "Free to quote and cite with attribution to The LeanScale Podcast."
---

# Stop Hiring GTM Engineers. They Already Work For You.

_Ryan Vanshur on finding one builder inside each department, why the context graph matters more than the model, the content audit that threw out 75% of what he had, the wave theory of AI adoption, and going from 12 account executives to 8 without a backfill_

**Episode 123 · The LeanScale Podcast**  
Ryan Vanshur, VP of GTM Intelligence and AI Solutions, Handle · Hosted by Anthony Enrico  
Published September 22, 2026 · Updated September 28, 2026 · 00:58:19  
Canonical: https://www.leanscale.team/knowledge/podcast/ryan-vanshur-handle-gtm-engineers-already-work-for-you/

**Topics:** AI in GTM · Revenue Operations · Sales Enablement · GTM Strategy


## Executive summary

Ryan Vanshur is VP of GTM Intelligence and AI Solutions at Handle, a title that did not exist until he built the job that needed it. He owns Handle's go-to-market tech stack and BDR team and has led an AI rollout that reaches every department. Before that he spent nearly a decade as a co-founder at CourseKey. His opening claim is that the go-to-market engineer companies are trying to hire is already sitting inside the org. While he was away for about three weeks, three colleagues from different departments each came back with a fleshed-out, clickable prototype after one or two hour-long sessions with him. His conclusion: maybe it isn't one full-time hire with the right title but a tiger team of people who live with the problems every day.

How he picks those people matters as much as the tools. He asks department leaders who leans into problems, watches webinars and shares new practices, not who has used AI longest or built the most apps. Then he gives them what they have never been trained on: a playbook for capturing a problem, turning it into possible solutions, scoping it and defining what done looks like. He is candid about the tech debt that comes with vibe coding. Six months into his own tinkering, a project stalled because data has a shelf life. The fix was engineering discipline taught in plain terms: GitHub for version control, no customer data in models that train on it, a bridge to the CTO, and guardrails that protect a SOC 2 posture in a compliance-heavy market.

The center of the episode is the context graph. Ryan's view is that the model race is not the story; what matters is the context, or ground truth, the model works from. His graph grew out of a year and a half of saving and organizing go-to-market work, and he shares his screen to walk through a demo graph built for a fictitious death-care software company: 35 nodes and 123 connections. The build steps are plain. Audit the content, find out what is still true (about 75% of his wasn't), organize it in markdown, then have Claude turn it into a knowledge graph. After that, keep it healthy with a weekly and monthly maintenance routine. He combined it with Endgame, which covers accounts, opportunities and contacts, and hosts it as a custom connector the whole team plugs into.

He attaches numbers to it. From the first half of last year to the second, Handle went from 12 account executives to about 8 without backfilling and still had a record year. Sales cycles for big marquee accounts fell from 12–18 months to 6–9, win rates rose 9% and ACV grew 70%. Anthony Enrico stops to make the point for listeners: a couple of points of conversion can mean millions in bookings, and cutting the cycle by a third speeds up pipeline turnover and the growth rate with it. Ryan's explanation for why adoption held is his wave theory. Start with account intelligence people can verify, then move to deal acceleration, pipeline monitoring and post-sales, not email copy that can't be checked against anything.

The back half is for RevOps leaders. Ryan thinks many future go-to-market engineers are already in RevOps, and that Salesforce-admin types need enablement skills and curiosity more than extra technical depth. He builds micro-SaaS that only fits Handle's stack and refuses to rebuild the CRM, mostly for compliance reasons. He sells resourcing internally the way reps sell deals, and argued for three BDRs instead of four new AEs.


## Key takeaways

1. **The GTM engineer you're recruiting for is probably already on payroll** — Ryan had been the only builder of production AI solutions. Before a three-week vacation he tested a theory with a few people in different departments. After one- or two-hour sessions with three of them, he came back to three fleshed-out prototypes built to solve problems the company deals with every day.
   _Why it matters:_ The role may not be one FTE with a title at all. A tiger team of people who live with the problems daily, given the right tools, guidance and resources, can build solutions an outside builder never would.
   _For:_ RevOps Leaders, Revenue Executives, Founders

2. **Pick builders for curiosity, not AI experience** — Handle deliberately did not hand licenses to everyone. Ryan picked departments, worked with their leaders, and asked who leans into problems, who watches webinars, and who keeps sharing new practices with the team. It wasn't about who had used AI longest or built the most apps.
   _Why it matters:_ These people are not builders at first. What turns curious people into builders is a playbook: capture the problem, convert it into possible solutions, scope the project and define what done looks like and doesn't look like.
   _For:_ RevOps Leaders, Revenue Executives, Sales Leaders

3. **Vibe-coding tech debt is real because data has a shelf life** — Ryan describes himself as a kid in a sandbox, building constantly, until six months later a project slammed to a standstill. He had been building very complex HTML artifacts with nothing hooked up to any database.
   _Why it matters:_ The unlock was pulling basic engineering discipline out and teaching it to non-engineers. That means why to back work up in a GitHub repo and why never to put customer data in a model that trains on it. Do that dirty work first, before letting people innovate.
   _For:_ RevOps Leaders, Founders

4. **Build a bridge to engineering before the tech debt piles up** — Ryan used to pride himself on never pulling an engineering hour off the product. Once he wanted usage and product data alongside go-to-market data, he had to go to the CTO and let himself be vulnerable. He needed guidance on compliance posture and on sanitizing files before any model ingests them.
   _Why it matters:_ Engineering teams have lived with these problems forever, and go-to-market is new to the game. He says doing this earlier would have spared him a wall of tech debt when it came time to scale and automate.
   _For:_ RevOps Leaders, Revenue Executives

5. **Guardrails beat faster emails in a compliance-heavy business** — Ryan's cross-department job is to make sure each department's standards (messaging, positioning, email format, branding) are met in every AI interaction a rep has. To the rep it feels like a $20 ChatGPT license. Underneath are connectors, context graphs, guardrails, rules and non-training model environments.
   _Why it matters:_ Losing a marquee account or putting SOC 2 status at risk because someone fed contracts and customer data into a model isn't worth faster copy. He wouldn't make that trade for what most people are using AI for right now.
   _For:_ RevOps Leaders, Revenue Executives

6. **The model isn't the problem; the context is** — Asked whether deep AI expertise or deep business context matters more, Ryan answers context immediately. The battle between frontier and open models is not the story; what matters is the context, or ground truth, the model is working from.
   _Why it matters:_ Most of Handle's effort went into backend systems so that everyone gets the same plugins, skills and frameworks. People can then have good conversations with an AI that already has the toolkit, compliance, guardrails and skills to one-shot high-quality artifacts.
   _For:_ Revenue Executives, RevOps Leaders, Founders

7. **A context graph starts as a content audit, not a project** — Ryan never set out to scope a context graph. He spent a year and a half saving and organizing go-to-market work so he could pick sessions back up where he left off, and it turned out that is what a context graph is. His build order: audit what the teams have, work out what's true today, organize it in markdown files, then have Claude turn it into a healthy knowledge graph with keywords and relationships.
   _Why it matters:_ The hard part is gathering, not structuring. Pull tribal knowledge out of teammates, including recorded sessions where a long-tenured head of sales talks through what he knows, and get to a ground truth before you build anything on top of it.
   _For:_ RevOps Leaders, Sales Leaders

8. **Expect most of your existing content to be wrong** — When Ryan got to ground truth, about 75% of the intelligence he had was either outdated or no longer relevant. He scrapped it and built the first graph only from what was still true.
   _Why it matters:_ He calls this the dirty work of controlled-burning content. It's unglamorous, but the sooner you do it the sooner you bottle up competitive advantage: tribal knowledge, industry expertise and what you know about your customers.
   _For:_ RevOps Leaders, Sales Leaders, Marketing Leaders

9. **No graph stays accurate without a maintenance schedule** — Much of Ryan's graph upkeep is automated through ingest skills and a graph-health skill that checks every node, with a dashboard showing how healthy the graph is. He still spends Friday afternoons cleaning up nodes and does a bigger monthly pass to make sure what's in there is still true.
   _Why it matters:_ It is never 100%, and a human stays in the loop. But he argues that maintenance is what gives the rest of the team grounded intelligence, and that 20 rounds of frustrated prompting is really a context problem.
   _For:_ RevOps Leaders

10. **Start AI adoption where answers can be checked** — Ryan's wave theory runs from account intelligence to deal acceleration, then pipeline monitoring, then post-sales. Most teams instead start with content (write my emails, build my sequences) because that's what vendors sell. But an email either sounds good or it doesn't, and with no ground truth a new rep can't tell when it is hallucinating.
   _Why it matters:_ When outputs can't be verified, people get burned, stop trusting the tool and stop using it, and it becomes shelfware. Context is the bottleneck, not content.
   _For:_ Revenue Executives, Sales Leaders, RevOps Leaders

11. **The results showed up in cycle time, win rate and deal size** — From the first half of last year to the second, Handle went from 12 account executives to about 8 without backfilling and without a BDR team until October. Big-account sales cycles still fell from 12–18 months to 6–9, win rates rose about 9%, and ACV grew 70%. Ryan ties the win-rate gain to sharper business cases and the shorter cycles to go-to-market teams working accounts together.
   _Why it matters:_ Anthony's point is that these are not incremental gains. A couple of points of conversion can mean millions or tens of millions in bookings at scale. Cutting the cycle by a third speeds up pipeline turnover, and the gap between 80% growth and doubling can mean multiples on your multiple.
   _For:_ Revenue Executives, Sales Leaders, Founders

12. **From tech vendor to consultative seller** — Handle competes as a scrappy startup against much bigger incumbents. Ryan credits the graph with making the sales process itself the differentiator: business cases tailored from the actual conversations, with no copy-paste, no generic artifacts and no blanket proposal.
   _Why it matters:_ Because the graph carries intelligence through the handoff, the client-success kickoff and onboarding, teams stop losing intelligence between departments. That separates them from vendors bolting AI on and copy-pasting blindly.
   _For:_ Sales Leaders, Revenue Executives, Customer Success

13. **Build micro-SaaS; don't rebuild the CRM** — Ryan builds what he calls micro-SaaS: purpose-built tools that only work with Handle's stack and would never make a vendor's roadmap. He has zero interest in replacing Salesforce. It's already SOC 2-compliant, has an integration economy around it and connects to marketing's and success's tools, and he doesn't have the skills to guarantee SOC 2 compliance for a rebuild.
   _Why it matters:_ He still keeps reps out of Salesforce's clicks where he can by giving them other tools on the same data. The question is whether you're buying or building compliance. Where vendors expose APIs and MCP servers, that's all he needs.
   _For:_ RevOps Leaders, Revenue Executives

14. **Salesforce admins should add enablement and curiosity, not more technical depth** — Ryan thinks RevOps holds many of the people who will fill go-to-market engineer seats, since his Salesforce-certified counterparts matter more to what gets built on the core stack than he does. His advice to them is to develop a knack for enablement: improving teammates' work, not LMS decks. That means taking design-thinking courses, getting in front of the people they serve, and starting with a small wedge product inside one department.
   _Why it matters:_ He sees technical and enablement skills merging in the go-to-market engineer role. His example: an AI hooked up to vendors' MCP connectors and logs traced a long-running Salesforce address-change bug in about an hour, after a consultant and a full-time resource hadn't found it.
   _For:_ RevOps Leaders

15. **Sell resourcing internally, and ask whether it's the right FTE** — Ryan runs the same sales process internally that he teaches reps: multi-thread across department leads, look for cross-department value and overlap with the current stack, and build the ROI story before presenting. His first dialer purchase solved the CEO's problem of calls not getting logged, and also added notes, dispositions and efficiency for reps.
   _Why it matters:_ On headcount, his first answer is never more headcount. When Handle dropped from 12 to 8 AEs, leadership wanted backfills. He argued for three BDRs instead of four AEs so the reps already performing would get more pipeline rather than more competition for territory. Leadership had believed for three to four years that outbound didn't work for them.
   _For:_ RevOps Leaders, Revenue Executives, Sales Leaders


## Frameworks

### One Builder Inside Each Department (01:36)

**Definition:** Rather than hiring a single go-to-market engineer, find a naturally curious problem-solver in each department and give them the tools, a shared context layer and a builder's playbook. Together they form a tiger team that builds from inside the problems.

Department leaders nominate the people who lean into problems, watch webinars and share new practices. They get the same plugins, skills and frameworks Ryan uses, plus a playbook for capturing a problem, turning it into possible solutions, scoping the project and defining done. His proof point was three clickable prototypes from three people after one or two short sessions each.

### Context Before Artifacts (17:24)

**Definition:** An AI-native go-to-market approach: build and validate the context layer (the ground truth) before generating any artifacts from it. Model quality is not the constraint; the context the model operates from is.

Ryan argues the frontier-versus-open model race is not the story. When the underlying graph is grounded and maintained, people can one-shot high-quality artifacts. When it isn't, they fall into 20 rounds of frustrated prompting, which he calls a context problem. He demonstrated it with a graph for a fictitious death-care software company built from real market research: 35 nodes and 123 connections.

### Build Your Own Go-to-Market Context Graph (20:37)

**Definition:** A step-by-step build for teams with little AI or engineering background. Audit the content, determine what is true today, organize what survives into markdown files, have an AI restructure it into a knowledge graph with keywords and relationships, then host it as a custom connector the team can plug into.

Ryan's own version grew out of a year and a half of saving go-to-market work so he could resume sessions where he left off. About 75% of it turned out to be outdated or irrelevant. He used Claude to ingest documents, transcripts, one-pagers and white papers and fill the graph. He then combined it with Endgame's account, opportunity and contact graph, and used a hosted service (he names Pinecone as one option) to turn it into a self-hosted connector. He describes the progression as crawl, walk, run.

### Graph Health Maintenance Cadence (15:57)

**Definition:** An operating rhythm that keeps a context graph accurate: ingest skills that stage new material as nodes, a graph-health skill that checks every node, a health dashboard, a weekly Friday cleanup and a bigger monthly truth pass.

Ryan is explicit that there is no automated way to keep a graph 100% accurate. A human stays in the loop. The maintenance is what gives the rest of the team grounded intelligence back instead of stale product files and slides nobody looked at again.

### The Wave Theory of AI Adoption (27:03)

**Definition:** AI adoption should follow the customer lifecycle in waves: account intelligence first, then deal acceleration, then pipeline monitoring, then post-sales. It should not start with content generation.

Most teams start with emails and sequences because that's what vendors sell. But generated copy can't be verified: it sounds good or it doesn't, and with no ground truth a new rep can't spot a hallucination. People get burned, trust never builds and the tool becomes shelfware. Starting with intelligence that can be checked builds the trust later waves depend on.

### Micro-SaaS vs. Systems of Record (36:31)

**Definition:** Build the small, purpose-built tools that only work with your own stack and that no vendor would ever put on a roadmap. Buy, and keep, the compliant systems of record the rest of the stack integrates with.

Ryan has zero interest in rebuilding the CRM. Salesforce is already compliant, has an integration economy and connects marketing's and success's tools. Replacing it means rethinking the whole stack's connections, and he can't guarantee SOC 2 compliance for a rebuild. His test is whether you're buying or building compliance. Where a vendor exposes APIs and MCP servers, that access is all he needs to build around it.

### Run a Sales Process Inside Your Own Company (51:38)

**Definition:** Make the case for tools or headcount the way a rep sells a deal: multi-thread across department leads, find cross-department value and overlap with the current stack, and build the business case and ROI story before presenting.

Ryan's example is the CEO's first problem for him: reps were making dials that never got logged in the CRM. Instead of training people to log calls manually, he bought an inexpensive dialer on top of the outreach platform. It analyzed transcripts, added notes and dispositions and logged calls to Salesforce, which solved the CEO's problem and made reps more efficient. He also makes vendors help him build his business cases.

### Is It the Right FTE? (Coverage and Activation Test) (53:49)

**Definition:** Before backfilling a seat, ask whether you have adequate coverage and activation across a finite market. If you do, invest in enablement and pipeline for the people already performing instead of adding more of the same role.

When Handle went from 12 AEs to 8, leadership wanted backfills. Ryan argued for three BDRs instead of four AEs so proven reps would get more pipeline without watered-down territories. The broader questions he now asks are what the business needs to be in 12 months, whether this team can get it there, and if not, who else is needed. He notes an SMB or mid-market business with thousands of accounts may need a different approach.


## Quotes

_Speakers inferred from an undiarized transcript — verify before attributing._

> "The battle of models in frontier versus open, that's actually not the story. The story is what sort of context or ground truth is your model operating from."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (03:08)

> "Maybe it's not a one FTE hire, right, that's out there with a title that you're looking for. It might be a team, like a tiger team, of builders that live and breathe the problems every day."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (02:20)

> "It wasn't necessarily who has been using AI the longest or who has the most AI apps built, as much as who's always looking for ways to solve problems."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (05:41)

> "All of a sudden, six months later, I had a project that just slammed to a standstill because data has a shelf life."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (08:04)

> "I wouldn't trade that for faster emails, or quicker copy, or whatever most people are doing with AI right now."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (14:12)

> "The part a lot of people don't want to hear is there's no automated way to keep it 100% accurate."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (15:57)

> "It was like 75% of all the intelligence that I had was either outdated or no longer relevant."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (22:53)

> "Most people are used to 20 iterations of conversations. If you're getting to the point of frustration, I promise you, you have a context problem."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (23:52)

> "You have to go through that dirty work of controlled burning content, figuring out what matters, what doesn't."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (26:09)

> "You can't check an email, it either sounds good or it doesn't. And there's no right answer to verify if there's no ground truth to work from."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (27:29)

> "Context is the bottleneck. It has nothing to do with your content."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (27:55)

> "The context is really, it's the premium fuel for the system."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (29:18)

> "Only a couple points on conversion rate can increase your bookings by millions, tens of millions at scale."
>
> — Anthony Enrico, The LeanScale Podcast Ep. 123 (30:45)

> "It makes you go from tech vendor to pure consultative seller."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (33:58)

> "You don't need to double your sales team. Sometimes you just need to let them do a little bit more with less."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (35:46)

> "A lot of people, the reason why they want to leave them is because they're garbage cans, right? They've never been able to turn it into a goldmine."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (38:12)

> "The technical part is not the most important thing, it's the curiosity that I look for, because that's not teachable."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (43:22)

> "You have to sell the business case internally. Like, I literally run the same sales process I teach my reps internally."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (51:38)

> "Because you guys want us to get four new account executives. I think we can bring on three BDRs and actually supercharge pipeline for the people who have already been performing and are still here."
>
> — Ryan Vanshur, The LeanScale Podcast Ep. 123 (53:49)

> "The AI strategy is a data model problem. It's not an LLM problem."
>
> — Anthony Enrico, The LeanScale Podcast Ep. 123 (57:25)


## Practical advice by role

### RevOps Leaders

- Ask department leaders to name their most naturally curious problem-solvers, and make them the builders instead of opening a GTM-engineer req.
- Give new builders a playbook for capturing a problem, turning it into possible solutions, scoping it and defining done, not just a license.
- Teach basic engineering discipline in plain terms early: version control in GitHub, and never put customer data in a model that trains on it.
- Open a line to your CTO before you start pulling in product or usage data, and agree on compliance posture and file sanitization.
- Start a context graph with a content audit, and expect most of what you find to be outdated.
- Put graph maintenance on the calendar: a weekly cleanup, a monthly truth pass, and automated health checks where you can.
- Build micro-SaaS for the gaps only your stack has; keep the compliant system of record the rest of the stack integrates with.
- If you came up as a Salesforce admin, invest in enablement and design thinking, and prove yourself with one small wedge product inside a single department.

### Revenue Executives

- Measure AI by cycle time, win rate and deal size, not adoption or question volume.
- Treat a few points of conversion and a shorter sales cycle as major levers on bookings and growth rate.
- Before backfilling a seat, ask whether it's the right FTE and whether you have coverage and activation across the market.
- Don't trade compliance for faster copy; one data incident can cost a marquee account and your SOC 2 status.

### Sales Leaders

- Record sessions with long-tenured sellers and add their tribal knowledge to the shared context so every rep's AI answers include it.
- Roll out AI starting with account intelligence reps can verify, before email and sequence generation.
- Use grounded intelligence to build business cases tailored to each conversation, with no generic proposals.
- Consider BDRs that feed proven AEs instead of hiring more AEs to split territories.

### Founders

- Look inside the company for the builder before hiring one; context about the business beats AI technique.
- Invest in the backend (shared skills, plugins, guardrails, a maintained context layer) before handing tools to everyone.
- Don't let reps rebuild the CRM on a whim; ask whether you're buying or building compliance.


## AI takeaways

**Thesis:** Ryan's thesis is that AI in go-to-market is a context problem, not a model problem. The leverage comes from a maintained graph of what is true about your market, customers and playbooks, used by curious people inside each department with guardrails in place, and rolled out in an order where outputs can be verified.

- **** — 
- **** — 
- **** — 
- **** — 
- **** — 

**Agent & automation ideas**

- An ingest skill that turns documents, call transcripts and interview recordings into graph nodes with keywords and relationships.
- A graph-health agent that checks every node on a schedule, flags stale or orphaned content, and feeds a health dashboard.
- A debugging agent connected to each vendor's MCP server and logs that traces which automation last changed a CRM field.
- A business-case builder that drafts tailored recommendations from the context graph plus the account's conversation history.


## Operations takeaways

### Revenue operations

- **.** 
- **.** 
- **.** 
- **.** 
- **.** 

### Pipeline & marketing ops

- **.** 
- **.** 
- **.** 
- **.** 
- **.** 


## Metrics mentioned

| Value | Metric | Context |
| --- | --- | --- |
| 12 → about 8 | Account executives | Handle started last year with 12 AEs and was down to about eight a little before mid-year. It never backfilled and still had a record-breaking year. |
| 12–18 months → 6–9 months | Sales cycle for big marquee accounts | From the first half of last year to the second, which Ryan attributes to go-to-market teams working accounts together on shared intelligence. |
| 9% | Win-rate improvement | Tied to more intelligent business cases and recommendations built from the context graph. |
| 70% | ACV increase | Ryan's figure when he returns to the results. Earlier in the same answer he also describes a 40% increase in average ARR per deal. |
| 75% | Content found outdated in the audit | Share of the intelligence Ryan had gathered that was either outdated or no longer relevant when he established ground truth. |
| 35 nodes, 123 connections | Demo context graph size | The graph Ryan shared on screen, built from real market research for a fictitious death-care vertical software company. |
| About 18 months | Organic go-to-market work behind the graph | A year and a half of saving and organizing work while supporting go-to-market teams, before he knew it was called a context graph. |
| 3 | Prototypes from department builders | Three fleshed-out prototypes from three people after one or two hour-long sessions each, while Ryan was out for about three weeks. |
| 3 BDRs instead of 4 AEs | Headcount proposal | Ryan's counter to leadership's request to backfill AEs. The BDR team started in October of last year, after three to four years of believing outbound didn't work for the company. |
| About 1 hour | Time for AI to trace a persistent Salesforce bug | After a consultant, a full-time resource and Ryan had all failed to find the automation changing account addresses. |


## Entities mentioned

- **Handle** (company) — Ryan's employer, where he is VP of GTM Intelligence and AI Solutions and owns the go-to-market tech stack and BDR team. A SOC 2-certified vertical software company in a compliance-heavy industry with a finite market to sell into. It competes as a scrappy startup against bigger incumbents and went from 12 AEs to 8 while cutting sales cycles and lifting win rate and ACV. · https://www.leanscale.team/knowledge/company/handle/
- **CourseKey** (company) — The startup Ryan co-founded and was running about ten years ago, before Handle. He contrasts it with today: back then, losing a couple of reps meant a scramble to make up the pipeline, not an enablement-led plan. · https://www.leanscale.team/knowledge/company/coursekey/
- **MIT** (company) — Where Handle sent Ryan for a certificate last year. The coursework is where he learned that the knowledge he had been organizing in markdown was a knowledge graph. · https://www.leanscale.team/knowledge/company/mit/
- **OpenAI** (company) — Named by Anthony alongside Claude as offering good desktop apps that have removed the early barrier of running agents in a terminal or VS Code. · https://www.leanscale.team/knowledge/company/openai/
- **Netlify** (company) — Anthony's team's deployment platform. Getting people hooked up to it so they could push and share what they built was one of the big adoption unlocks at their December hackathon. · https://www.leanscale.team/knowledge/company/netlify/
- **Ryan Vanshur** (person, guest) —  · https://www.leanscale.team/knowledge/guest/ryan-vanshur/
- **Anthony Enrico** (person, host) — Co-founder of LeanScale and host of The LeanScale Podcast. · https://www.leanscale.team/knowledge/guest/anthony-enrico/
- **Claude** (tool, AI Assistant) — The AI environment Handle's context graph is connected to. Ryan used Claude to ingest documents, transcripts and other content into the graph and later to restructure his markdown into a healthy knowledge graph. Anyone at Handle talking to Claude gets the captured tribal knowledge in its answers.
- **Endgame** (tool, Account Intelligence / Context Graph) — The partner Handle uses for a graph of its accounts, opportunities and contact intelligence from the CRM and other systems. Ryan combined it with his own go-to-market graph, and chose to buy it rather than build because it was already SOC 2-certified and integrated with everything they needed.
- **Pinecone** (tool, Vector Database) — Named by Ryan as one of a few services that let you upload your graph and turn it into a custom connector you host yourself for the team to plug into.
- **GitHub** (tool, Developer / Code Hosting) — The version-control habit Ryan teaches non-engineers to avoid vibe-coding tech debt. One colleague came back with her own fully built-out repo after a single conversation.
- **Salesforce** (tool, CRM) — Handle's CRM, which Ryan won't rebuild because it is compliant, has an integration economy and connects the whole stack. He keeps reps out of its clicks where he can. An AI given MCP connectors and logs traced a long-running Salesforce address-change bug in about an hour.
- **Model Context Protocol (MCP)** (tool, AI Integration Protocol) — MCP servers and connectors are what Ryan needs from vendors to build around them. They are also how an AI traced the Salesforce address bug across providers' systems and logs.
- **ChatGPT** (tool, AI Assistant) — Ryan's shorthand for how Handle's AI feels to reps, like a $20 ChatGPT license, while it carries connectors, context graphs, guardrails and non-training environments underneath. Anthony uses 'ChatGPTing' to describe a beginner AI user.
- **Vercel** (tool, Deployment / Hosting) — Mentioned by Anthony as an alternative to Netlify for letting people deploy and share what they build.
- **Outreach** (tool, Sales Engagement) — Handle's outreach platform. The dialer Ryan bought runs as an overlay on it, and he uses it as an example of a vendor connector.
- **Gong** (tool, Revenue Intelligence) — Cited alongside Outreach as the kind of vendor connector a self-hosted context-graph connector works like.
- **Clay** (tool, GTM Data / Enrichment) — Ryan's example of a tool he has always wanted but won't request just to see what he can do with it, because it's expensive and he has no business case.


## FAQ

**Q: Should you hire a go-to-market engineer or find one internally?**

A: Ryan Vanshur, VP of GTM Intelligence and AI Solutions at Handle, argues the go-to-market engineer many companies are recruiting for is often already on payroll. While he was away for about three weeks, three colleagues from different departments each produced a fleshed-out, clickable prototype after one or two short sessions with him. He picks these builders by asking department leaders who is naturally curious and always trying to solve problems, not who has used AI longest. He then gives them the same tools, context layer and a playbook for scoping problems and defining done. The result is less one full-time hire and more a tiger team of people who live with the problems every day.

**Q: What is a go-to-market context graph and why does it matter?**

A: A go-to-market context graph is a connected, maintained body of what is true about a company's market: playbooks, strategies, coaching, product, positioning and winning zones, stored as linked nodes an AI can traverse. Handle's Ryan Vanshur argues it matters more than which model you use. The race between frontier and open models is not the story; what counts is the context, or ground truth, the model works from. With a grounded graph, people can produce high-quality artifacts in one shot. Without one, they fall into 20 rounds of frustrated prompting, which he says is a context problem, not a model problem.

**Q: How do you build a context graph with little AI or engineering experience?**

A: Ryan Vanshur's sequence starts with a content audit: collect what the teams have and work out what is still true. About 75% of his own material was outdated or irrelevant. Organize what survives in markdown files, use an AI such as Claude to ingest documents, transcripts, one-pagers and white papers, then ask it to restructure everything into a knowledge graph with the right keywords and relationships. Capture tribal knowledge by recording sessions with long-tenured experts. Finally, host the graph as a custom connector the whole team can plug into. Handle combined its graph with a vendor graph of accounts, opportunities and contacts. Then maintain it with weekly and monthly health checks, because it is never automatically 100% accurate.

**Q: Where should a sales team start with AI adoption?**

A: Not with email and sequence generation, according to Ryan Vanshur's wave theory. Adoption works best following the customer lifecycle: account intelligence first, then deal acceleration, then pipeline monitoring, then post-sales. Generated copy is hard to verify. It either sounds good or it doesn't, and a new rep without tribal knowledge can't tell when it is hallucinating. Once people get burned they stop trusting the tool and it becomes shelfware. Starting with intelligence that can be checked against ground truth builds the trust the later waves need.

**Q: What results did Handle see from its AI and context-graph work?**

A: From the first half of last year to the second, Handle went from 12 account executives to about 8 without backfilling and still had a record year. Ryan Vanshur reports that sales cycles for big marquee accounts fell from 12–18 months to 6–9, win rates rose about 9%, and ACV grew 70%. He attributes the win-rate gain to sharper, more tailored business cases and the shorter cycles to go-to-market teams working accounts together on shared intelligence. Handle has published a case study on the work.

**Q: Should a RevOps team build its own CRM with AI?**

A: Ryan Vanshur has zero interest in it. His rule is to build micro-SaaS, meaning purpose-built tools that only work with your own stack and that no vendor would ever put on a roadmap, and to keep the systems of record. At Handle, Salesforce is already SOC 2-compliant, has an integration economy around it and connects marketing's and success's tools, so leaving it would mean rethinking the whole stack. He also says he lacks the skills to guarantee a rebuilt CRM would stay SOC 2-compliant. The question he asks is whether you are buying or building compliance. Where vendors expose APIs and MCP servers, he has everything he needs to build around them.

**Q: What skills should a Salesforce admin learn to stay relevant in RevOps?**

A: Ryan Vanshur says RevOps and Salesforce admins already have the technical skills. What they need to develop is a knack for enablement: helping teammates do their jobs better, not producing LMS decks and PowerPoints. He recommends design-thinking courses, getting in front of the people you serve to find problems, and proving value with a small wedge product inside one department before attempting anything enterprise-wide. He looks for curiosity above technical depth because it can't be taught, and he expects technical and enablement skills to merge in the go-to-market engineer role.

**Q: How do you make the case to executives for more RevOps tools or headcount?**

A: Run a sales process inside your own company. Ryan Vanshur multi-threads across department leads, looks for cross-department value and overlap with the current stack, and builds the ROI story before presenting. He even asks vendors to help write the business case. His first win solved a CEO problem, calls not being logged in the CRM, with an inexpensive dialer that also added notes and dispositions for reps. On headcount, his first answer is never more headcount. When Handle dropped from 12 to 8 AEs, he argued for three BDRs instead of four AEs, so proven reps would get more pipeline instead of more competition for territory.


## Timeline

- **00:00** — Cold open and intro
- **01:17** — The GTM engineer you're hiring already works for you
- **04:43** — How to find the one builder inside each department
- **07:46** — Vibe-coding tech debt: data has a shelf life
- **14:35** — Why the context graph is the layer that matters
- **16:47** — Screen share: inside a live go-to-market context graph
- **20:15** — Build your own graph, step by step
- **22:53** — 75% of it was outdated: the content audit
- **27:03** — The wave theory of AI adoption
- **30:12** — The numbers: cycle time, win rate, and ACV
- **34:09** — Where RevOps is going
- **35:55** — Build vs. buy: micro-SaaS and why he won't rebuild the CRM
- **41:04** — What the Salesforce-admin generation needs to learn now
- **47:39** — Making the resourcing case to your exec team
- **52:21** — Headcount: three BDRs instead of four AEs
- **57:00** — Wrap


## Related episodes

- **Ep. 119: The Agent Was Never the Hard Part** (Kushal Sharma (Circle)) — Same conclusion from another operator: the model and agent are easy, and the context layer underneath is what decides whether AI works.
- **Ep. 85: Why AI + GTM Engineers Can't Replace RevOps** (Tessa Whittaker) — The counterpart to Ryan's claim that the GTM engineer already works in your org, and that RevOps is where many of them come from. · https://www.leanscale.team/knowledge/podcast/tessa-whittaker-ai-gtm-engineers-revops/
- **Ep. 105: You Built a Brilliant AI Agent — Now Get 300 People to Use It** (Christopher O'Donnell (Day AI)) — Adoption as the real problem, in line with Ryan's view that trust has to be built or the tool becomes shelfware.
- **Ep. 106: How She Runs All of RevOps From the Terminal** (Sarah Madden (FERMÀT)) — A RevOps leader building her own AI tooling, the same builder's path Ryan recommends to Salesforce-admin-era operators.
- **Ep. 95: Why AI Means More RevOps Hires, Not Fewer** (Jimmy O'Halloran (New Relic)) — Takes on the resourcing question Anthony puts to Ryan: AI raises the ceiling on RevOps work instead of shrinking the team. · https://www.leanscale.team/knowledge/podcast/jimmy-ohalloran-new-relic-revops-consumption-revenue/
- **Ep. 108: He Built a $60K CPQ Inside HubSpot in 2 Days** (Derek Mogar (LeanScale)) — A worked example of Ryan's micro-SaaS line: build the purpose-fit tool around the system of record instead of replacing it.
- **Ep. 112: Why Enablement Fails Before It Starts** (Cheyenne Griffith (Deepgram)) — Enablement from the other side, relevant to Ryan's argument that the go-to-market engineer role is merging with enablement.


## Full transcript

_Machine-transcribed and not diarized; speaker attribution is inferred._  
_Transcript only, as a separate file: https://www.leanscale.team/knowledge/podcast/ryan-vanshur-handle-gtm-engineers-already-work-for-you/transcript.md_

### 00:00 — Cold open and intro

**[0:00]** They're growing all-cost stuff, I think, at this point. It's pretty much wore itself out.

**[0:03]** Like, I think those days are over.

**[0:05]** My guest today is Ryan Vantret, VP of GTM Intelligence and AI Solutions at Handel,

**[0:11]** a title that did not exist until he built the job that needed it.

**[0:15]** In HR, finance, or sales, or wherever,

**[0:18]** how do you pick the person that you're like, "Okay, this is going to be my AI person"?

**[0:22]** It wasn't necessarily who, you know, has been using AI the longest or who has the most AI apps built,

**[0:27]** as much as who's always looking for ways to solve problems and constantly looking

**[0:31]** for ways to improve the team and the customer experience.

**[0:35]** What do you think is more important?

**[0:36]** Do you think it's strong, deep technical expertise on how to leverage AI,

**[0:42]** or having strong, deep context of the business and what you need to solve for?

**[0:49]** Definitely the context.

**[0:50]** I think there's a growing conversation that people are realizing,

**[0:53]** like, you know, the battle of models in Frontier versus Open and, you know,

**[0:57]** the fables versus others, like, that's actually not the story.

**[1:02]** Like, the story is what sort of context or ground truth is your model operating from.

### 01:17 — The GTM engineer you're hiring already works for you

**[1:17]** Ryan, you said something at the end of our prep call really stuck with me.

**[1:21]** The go-to-market engineer companies are trying to hire is already sitting inside their org.

**[1:26]** They just don't know it yet.

**[1:28]** What makes you so sure?

**[1:29]** And what does that person look like before anyone ends up giving them the title?

**[1:36]** Yeah, so I think that was coming off the back of, like, you know,

**[1:39]** I was on vacation for a few weeks.

**[1:41]** And prior to leaving, it was about three weeks I was out.

**[1:45]** Historically, I've had to be the builder when it comes to, like, actual,

**[1:48]** you know, production-level AI solutions.

**[1:50]** And I had a few different folks in different departments where I was kind of testing this

**[1:54]** theory that if I can kill a few folks in each department that actually live and

**[1:58]** breathe the go-to-market problems, that they would actually come up with better

**[2:01]** solutions that I could going in and trying to understand them from the outside looking in.

**[2:07]** And when I came back, you know, after literally one or two-hour sessions with three different folks,

**[2:12]** I was looking at three different pretty fleshed-out prototypes purpose-built to solve problems that

**[2:18]** we deal with every day.

**[2:20]** And so that's where I started thinking, like, you know, maybe it's not a one FTE hire, right,

**[2:25]** that's out there with a title that you're looking for.

**[2:28]** It might be, you know, a team, like a Tiger team, you know, if you want to put it that way,

**[2:32]** of builders that live and breathe the problems every day, have that knack for innovation,

**[2:38]** lean into technology and with the right tools, you know, the right guidance, the right resources,

**[2:43]** you know, they can go out and build solutions that I would never be able to without, you know,

**[2:47]** living, you know, the day-to-day jobs that they have to do.

**[2:51]** What do you think is more important?

**[2:52]** Do you think it's strong, deep technical expertise on how to leverage AI

**[2:59]** or having strong, deep context of the business and what you need to solve for?

**[3:06]** Definitely the context.

**[3:08]** I think there's a growing conversation that people are realizing, like, you know,

**[3:12]** the battle of models in Frontier versus Open and, you know, the fables versus others, like, that's

**[3:18]** actually not the story.

**[3:20]** Like, the story is what sort of context or ground truth is your model operating from.

**[3:25]** And so we spent a lot more time trying to develop the backend systems and the infrastructure that

**[3:31]** supports our AI rollout so that when I give somebody, you know, these tools, they've got

**[3:37]** the same plugins, the same skills that I've developed and the same, literally, frameworks

**[3:43]** of how they go talk to their team and gather information and project plan.

**[3:47]** And so what I've tried to do is scale the way that we innovate within our go-to-market departments.

**[3:52]** And, you know, that's less about, you know, giving them tools and hoping they're tech savvy

**[3:56]** and more about letting them be curious and have good conversations, you know, with generative AI

**[4:01]** that happens to have the toolkit, the compliance, the guardrails, and the skills that it needs.

**[4:07]** To build, you know, one-shot high-quality artifacts.

**[4:10]** And again, they're not coming out production ready with real data, but the fact that I have

**[4:15]** builders and departments coming back with, you know, complete dummy data, you know, fully

**[4:19]** fleshed out, you know, workflows, clickable prototypes, it's just showing that, you know,

**[4:24]** it's more about the preparation and how you deploy the tools versus, you know,

**[4:28]** finding somebody who's lived and breathed it for their entire life.

**[4:33]** Well, and I like the way you put it, how you got to go get somebody pilled in each of the departments

**[4:40]** and just spread the AI infection and let it take its form.

### 04:43 — How to find the one builder inside each department

**[4:43]** How do you go about looking for someone that you think is someone you want to really, really

**[4:50]** implant this ideation into? And then how do you support them after? I'm just wondering, like,

**[4:56]** okay, you go into a department, you're walking in HR or finance or sales or whatever.

**[5:00]** How do you pick the person that you're like, okay, this is going to be my AI person?

**[5:05]** I think part of it is just seeing who's naturally curious. I mean, when we were rolling out,

**[5:09]** we weren't necessarily looking to throw licenses to every single person and just saying, hey,

**[5:13]** guys, we have AI now. And so we were very strategic and we were picking departments.

**[5:18]** I was working with specific department leaders and I relied on them to tell me, you know,

**[5:22]** who are the people who lean into problems? Who are the people who come back and, you know,

**[5:26]** go watch webinars and are naturally curious and always trying to share new practices with the

**[5:30]** teams? Because those are the people who, if you give them good tools and a good context layer

**[5:35]** underneath it, they're going to naturally engage with AI the same way that they do in their day

**[5:41]** to day. So it wasn't necessarily who, you know, has been using AI the longest or who has the most

**[5:46]** AI apps built as much as who's always looking for ways to solve problems and constantly looking for

**[5:51]** ways to improve the team and the customer experience. And, you know, they're not necessarily

**[5:57]** brought out as builders at first, but once you give them the framework for capturing problems,

**[6:02]** converting that into potential like solution sets, thinking through planning and how you would scope

**[6:07]** out the project and what done looks like and doesn't look like, they've never been trained on that.

**[6:12]** But if you give them a playbook for it, that's really what allows them to go out and go from

**[6:18]** curious, you know, naturally, you know, like information seeking people to people who can

**[6:24]** actually take that and then execute building, you know, some sort of solution or workflow that you

**[6:28]** can layer on top of it. Yeah, I found, we went through this, I'd say maybe December of last year.

**[6:36]** We had a handful of people who were like deep on AI and experimenting and leveraging stuff, but

**[6:42]** it started to get a little bit more mainstream for us in December. It had our first like real hackathon

**[6:48]** building stuff together. And it felt like to me, I'm curious your opinion. It was like,

**[6:53]** okay, there are a couple major barriers we had to knock down. One was, let's just get an agent

**[6:59]** platform installed. So back then you had to do it in terminal or you had to do it in like VSCode or

**[7:04]** something. Now it's nice that Claude and OpenAI have really good desktop apps. I think they're

**[7:09]** pretty much, unless you're doing some real advanced stuff, pretty much going to give you

**[7:13]** everything you need, but just like, okay, let's break that barrier down. Then I feel like another

**[7:18]** big unlock was when we got people, we use Netlify, but or like for sale, you could use too. But once

**[7:25]** we got people hooked up with a Netlify account, it's like, okay, now you built this thing. Now

**[7:30]** you can push it here. Now you could share it with people. Like those were some things I just felt

**[7:35]** like they unlock them. Did you have similar things like barriers that you really had to knock down

**[7:42]** from people are like, Oh, I'm not a technical person. I'm not an AI person. And what helped

### 07:46 — Vibe-coding tech debt: data has a shelf life

**[7:46]** them just like unleash? Yeah. Well, I mean, for starters, like there's like this weird sort of

**[7:54]** tech debt that comes with like vibe coding and go to market, right? And this was something that I

**[7:59]** got smacked with really hard. Cause I was, you know, I was like a kid in a sandbox, just like

**[8:04]** playing all the time and building and innovating. And then all of a sudden, six months later, you

**[8:09]** know, I had a project that just slammed to a standstill because data has a shelf life. And I was

**[8:14]** like literally building the most complex HTML artifacts and nothing was hooked up to any

**[8:18]** database. I had no idea what I was doing. And so what I ended up finding is, you know, like the

**[8:24]** unlock comes from and you actually pull out like basic engineering discipline and then convert that

**[8:30]** into a way that you can teach people like, why would you want to get hub repo to back up your

**[8:34]** work? And why would you want to never put customer data in an LLM model that's doing model training?

**[8:40]** And so like you want to avoid the wild west of innovation and AI adoption, especially if you're

**[8:45]** in like compliance heavy industries like we are. So you, you really have to go in and like do the

**[8:53]** dirty work first, right? Like put the back end tools, make sure that they can't blow things up,

**[8:57]** teach them how to do basic project management and think like problem solvers and builders.

**[9:03]** That's what was the unlock for us. When I came back in some, you know, I, I just told her what,

**[9:08]** you know, get hub was. And I said, you know, I'm not an engineer. I just know cloud kind of told

**[9:12]** me that I need to use it to keep, you know, version control and stuff like that. And it's a

**[9:16]** way that I can share my projects. She came back with her own repo fully built out. And like here,

**[9:20]** you know, here's my repo. And you know, that just comes from a conversation, but like her being

**[9:24]** curious and seeking good information, went and watched a couple of YouTube videos, set hers up,

**[9:30]** made sure it was, you know, kind of all good to go and send it over to me. And it's like,

**[9:34]** you know, I don't think you can go higher for somebody who's going to take a one sentence and

**[9:37]** go figure out how to execute and become a part of that process. But that's really where we started

**[9:42]** being able to, you know, have a lot more faith that the work we were doing was in the guard rails,

**[9:48]** you know, keeping the data, you know, compliant, making sure our sock tubes not being, you know,

**[9:52]** compromised or anything like that, but still giving people the ability to innovate and build

**[9:57]** in like a safe structured environment with really high level tools.

**[10:01]** What's your opinion on? Because I've seen, I feel like there's phases to it. Okay,

**[10:08]** got some evangelists out there. They're out there building. Is there a certain point in time where

**[10:14]** this decentralized building of AI needs to get rained back in? Or is there some like middle

**[10:22]** ground compromise? When you're really starting to take these things to scale across the whole

**[10:27]** organization, how do you recommend structuring that on your teams? For me, it started with

**[10:33]** understanding I needed to go speak with our CTO. I mean, I used to pride myself on, you know,

**[10:37]** having production systems built and never pulling an engineering, you know, hour off of off of our

**[10:42]** product. But after a while, you know, when you're not just using go to market data, and you want to

**[10:47]** start looking at ways to incorporate usage data and product data, all have a ton of value, but we

**[10:54]** have to understand like, what does that mean from a compliance standpoint? How do we make sure we're

**[10:58]** using things, you know, appropriately? How do we sanitize different files before you ingest them

**[11:03]** into any model? Like we had, I had to go through and just like, let myself be vulnerable and let,

**[11:09]** you know, the adult in the room actually give me guidance on our posture and how to get aligned

**[11:14]** with that. And so one, I would say is like create a bridge between you and the engineering team,

**[11:19]** because they've, this ain't new to them, you know, they've been leaving and breathing this forever.

**[11:23]** And we're new to the whole game. And that's where you that's where if I would have done that earlier,

**[11:27]** you know, I wouldn't have had a wall of tech debt waiting for me, you know, by the time I was ready

**[11:32]** to think about how do I scale these tools and make them a little more automated. And so those

**[11:37]** conversations are really, you know, probably the first step is just create that bridge and leverage,

**[11:42]** you know, the insights that those those teams have and the experience that they built over their

**[11:46]** careers, and figure out how to translate that into to go to market motions and playbooks you can run,

**[11:52]** right with with a non engineer. Yeah, that makes sense. And I, I think it's this balance that you

**[11:58]** don't want to stifle people's creativity or hold people back from being productive. But at the same

**[12:02]** time, there's some stuff that's sensitive, I'm starting to think access to things like cloud

**[12:08]** codecs, getting hooked up on for cell and that with five, whatever that whatever your little AI

**[12:13]** tech stack looks like, I'm starting to feel like that's the new Google Sheets, Google Slides. It's

**[12:20]** like, yes, we shouldn't hold anybody back from having access to these things. At the same time,

**[12:26]** there's a difference between you working in a spreadsheet, and the spreadsheet that the CFO

**[12:31]** uses to do forecasting on the business. And it's like, okay, there's Yeah, you can build some cute

**[12:37]** AI stuff and things that help you be a little bit more productive in your day. But then there's like

**[12:41]** these business critical workflows and infrastructure systems that are set up that we need the

**[12:47]** professionals to manage. Are you seeing it that way too? Yeah, I mean, in some ways, like, like,

**[12:55]** in my role, I work cross departmentally. And my job is to make sure like the standards that every

**[13:01]** department is set are met in any AI interaction that any of our reps have, right. And so like,

**[13:07]** I'm not the person that gets to set our messaging framework. And, you know, sort of like our go to

**[13:12]** market message positioning and how we draft emails and how long they can be in the format of them,

**[13:17]** you know, like, I don't create the branding and design guidelines, I need to capture what the best

**[13:22]** looks like, and then build that into the system that the reps interface with. So all it feels like

**[13:28]** them is it feels like a 20 taller chat GPT license. But you've got connectors, context graphs,

**[13:34]** intelligence, guardrails rules, right? You know, non trained model environments, because if you go

**[13:42]** to enterprise and teams, by default, right, it's off. So you're not worried about, you know, rogue AI,

**[13:47]** where somebody forgot to flip their switch. And now you've got contracts and customer data,

**[13:51]** feeding an AI model, right. And so that's really what you have to look out for. You don't want to

**[13:55]** stifle innovation, but it's also not worth, you know, losing a key marquee account, because

**[14:01]** you had somebody do something with data that they shouldn't do. And now your software compliance

**[14:06]** status, you know, is at risk. And, you know, there's a lot more of a business impact to getting that

**[14:12]** wrong. And I wouldn't I wouldn't trade that for faster emails, or, you know, quicker copy or

**[14:17]** whatever most people are doing with AI right now. Yeah, no, it makes sense. The risk and compliance

**[14:24]** side of this equation is super important, especially if you're in a highly compliant

**[14:29]** industry, where you need to be keeping that top of mind. You mentioned something when you're going

### 14:35 — Why the context graph is the layer that matters

**[14:35]** through that I think this has become the hottest topic in AI. The models are all fantastic, like

**[14:42]** Opus and Sol, like they're good. That's not really holding it back. What tends to be holding people

**[14:48]** back is that context graph layer. Can you walk through maybe your approach to that or maybe

**[14:57]** actually just start with why is this layer so critical and important? Yeah, so I mean, I didn't

**[15:07]** come from like LLM training, you know, engineering background. So when I just got into this stuff,

**[15:13]** I was really just tinkering. And I didn't even know what a knowledge graph was or a context graph.

**[15:18]** I didn't know what an MCP server was like, I barely understood APIs, if I'm being honest with you.

**[15:23]** And so what I was doing is like, you know, a year and a half of organic go to market work and just

**[15:29]** sort of saving things and organizing them so that I can get them back out later, right? Because,

**[15:36]** you know, the context was the thing that just let me pick up these working sessions exactly where I

**[15:42]** left off. And it turns out that's literally kind of like what this thing is called. And so it was

**[15:47]** never really like starting out as like, I have a project and the project is to scope out a context

**[15:52]** graph. It was just sort of an accumulation of being of service to the go to market team and just

**[15:57]** collecting intelligence on all kinds of tasks, right? And so the part of a lot of people don't

**[16:03]** want to hear is there's no automated way to keep it 100% accurate. Like a lot of mine is automated

**[16:09]** at this point, but some of it's me every Friday afternoon, you know, doing a graph health, you know,

**[16:14]** scale and making sure that I'm cleaning up some of the nodes and once a month doing a bigger pass

**[16:19]** and making sure what's in there is still true. But that maintenance is what supercharges the

**[16:25]** rest of the team to where they're getting grounded real intelligence back. And so I can actually show

**[16:33]** you there's let me let me share my screen real quick just so you can kind of take a look at it.

**[16:39]** Yeah, absolutely. I always say people who share their screens are the real pros.

**[16:43]** There's people who talk about things and then people who show them so would love to take a look.

### 16:47 — Screen share: inside a live go-to-market context graph

**[16:47]** So I'm not going to dive into like that. This is what we would consider our go to market platform.

**[16:54]** And what this is is all the gaps filled for any of the tech stack where if there is a solution

**[16:58]** to a problem that we know exists, we've wanted to build it ourselves. So everything you're seeing

**[17:03]** here is a live production app that we use across our go to market team within there is our knowledge

**[17:08]** graph and ours has been built, you know, it's got a bunch of different nodes, you know, nine

**[17:13]** different groups and categories. And I'm not going to go too far into it. But what I did do right on

**[17:18]** in kind of anticipation of this is I took another project that I had been working on in a previous

**[17:24]** webinar where we were basically testing this this AI native go to market approach to building

**[17:31]** context before you build artifacts. And so what we did was we were looking at like a death care

**[17:36]** vertical SaaS company that might work for, you know, funeral parlors or creamery places. And we

**[17:43]** basically went out and we did all this research. So this is a fictitious company. But all of the

**[17:48]** market research is real. And this is what that would look like, right? Just the research we did

**[17:53]** for you know, to build like a fake company. There was 35 nodes, 123 connections between the nodes.

**[18:01]** And we called it plot IQ, right? Like this fictitious business. But every node here,

**[18:07]** along with, you know, the related go to market training material, this represents sort of the

**[18:12]** same exact workflow that I built locally at the startup that I work at. So it's the it's just

**[18:18]** reskinned to another vertical, another SaaS company, completely different buyers, personas,

**[18:24]** competitors. But the underlying theme is the same. If I were to connect this as a connector

**[18:30]** to our cloud environment the way that I do ours, every single node in here, all these connections,

**[18:35]** you have a transversable graph that is grounded, where every answer is grounded in the intelligence

**[18:43]** that is validated, constantly updated. And it doesn't live in, you know, two year old go to

**[18:49]** market product files, or, you know, your Google Docs that were created last year, or the PowerPoint

**[18:57]** slide that they showed you in one training, and nobody ever looked at again, it all lives in a

**[19:01]** graph. So whether you're a new hire, you know, being onboarded, and you want to make sure that

**[19:07]** they have access to the best information and a way to actually access the intelligence behind this,

**[19:14]** every single one of those is essentially a node that feeds the graph, right? And so there's this

**[19:19]** connection between, you know, where does all that tribal intelligence live right now, right?

**[19:24]** Sometimes my nodes are created by me doing a zoom session with one of like our head of sales, who's

**[19:29]** been at our company forever, and just letting him download his intelligence, his insights, what he

**[19:36]** sees, and capturing that so that now if anybody ever talks to Claude, we have that sort of tribal

**[19:42]** knowledge and feedback included in our responses. So that the challenge is really, you know, it's

**[19:48]** not can I get the best LLM, do I have enough credits, it's am I am I hooking up a supercharger

**[19:53]** to it, where the superchargers is literally fuel of top tier intelligence, that this wouldn't work

**[20:00]** for any other company, like, you know, we couldn't take this and sell it as a SaaS product,

**[20:04]** but it's perfect for what we do, you know, at the company I work with. And it makes everybody

**[20:10]** better, right? Everybody is better because they have instant access to this information.

### 20:15 — Build your own graph, step by step

**[20:15]** If somebody's listening wants to build this, let's assume they have very little AI and engineering

**[20:22]** experience. Assume they're a chat GPTing AI person right now. How would they go about

**[20:31]** building this out for their organization step by step?

**[20:37]** I would say first is do a content audit, right? Go to your teams and see what you have, and then

**[20:43]** you have to figure out what's true today, right? Because a lot of it won't be. And then once you

**[20:48]** figure out what's true today, then what I was doing just sort of naturally was I was I learned

**[20:54]** about this thing called a markdown file and you know how it was easy for AI to work with. And so

**[20:59]** I just started creating markdown files and folders and just was sort of organizing the intelligence

**[21:05]** as I was gathering it. If there was an old, you know, PDF document, a bunch of different like

**[21:11]** videos with transcripts, old one pagers, testimonial, you know, white papers, anything like that, I was

**[21:18]** just taking and I was having Claude ingest it for me. Analyze this document, review this transcript,

**[21:24]** capture the messaging, and then fill it into my ground. And so I was just doing this sort of

**[21:30]** naturally. Copy paste, copy paste, copy paste. Then when my company, you know, I was fortunate

**[21:34]** enough to work somewhere where they like to invest in me. And so they sent me to get a certificate

**[21:39]** last year at MIT. I'm doing one at Harvard Business School this year. And then I started learning,

**[21:44]** right, about, you know, the concept of these knowledge graphs and data graphs and nodes. And

**[21:49]** then I was like, oh, well, I didn't know that's that's what it was called. But I had just been

**[21:53]** organically scraping everything that I could get out of all the different types of media that you

**[21:58]** can think of. And then putting that into knowledge graph files, just markdown structure, organize,

**[22:05]** and then eventually I was able to use Claude to say, hey, you know, I just learned about this

**[22:10]** thing called a knowledge graph. Can you help me optimize this organic, you know, mess of

**[22:16]** information and make sure that the top parts of these have the right, you know, keywords and the

**[22:20]** relationships are there and that the graph is healthy and the connections are made. And so I

**[22:25]** never really had to go through and like individually edit every single graph. The hard part was just

**[22:31]** done because I worked for a year and a half supporting the go to market teams and was just

**[22:36]** collecting it like intuitively day by day by day. So when I went back to ask it to create it,

**[22:42]** it was there. That would be the same play I would run. Go to your teammates, go to where the tribal

**[22:48]** knowledge is, extract everything, get it organized, find out what's true today and what's not so you

### 22:53 — 75% of it was outdated: the content audit

**[22:53]** can get to a ground truth. And that ground truth for me, it was like 75% of all the intelligence

**[23:00]** that I had was either outdated or no longer relevant. And so I was able to scrap a lot of that

**[23:05]** and just use what was still true to form the initial graph. And now it's something where

**[23:10]** there's a maintenance schedule for it. Like I know different types of work that I'm doing when to use

**[23:15]** my ingest skills. So it knows, hey, tee this up for the graph and add a couple of modes. And then

**[23:20]** I know when it's time to run my graph health exercises, where the skill literally goes and

**[23:24]** checks all my nodes and make sure everything looks healthy. And I got a dashboard that tells me

**[23:28]** exactly how healthy my graph is. And so eventually it becomes this more automated thing that

**[23:35]** it's just always up to date and accurate. Never 100%. You always need human in the loop and some

**[23:41]** maintenance to be done. But if you can get that down, every single thing you do off the back of

**[23:46]** that graph, you could one shot high quality artifacts that you wouldn't even dream of.

**[23:52]** Most people are used to 20 iterations of conversations and asking, what are you doing?

**[23:57]** If you're getting to the point of frustration, I promise you, you have a context problem.

**[24:03]** And a lot of times when people start building these, so, okay, you're taking transcripts,

**[24:07]** you're taking artifacts, you're taking all these things and giving it to Claude,

**[24:11]** it'll end up start building your graph locally. What was your strategy for making it accessible

**[24:18]** across the entire organization so they could plug their AI tools into the context that would give

**[24:24]** them all of those opportunities? Yeah. So again, very kind of caveman approach. My first thought

**[24:31]** was like, well, I'll just make a bunch of markdown files that I'll create different projects for,

**[24:36]** and the markdown files and the projects will have the context that it needs for the specific workflow.

**[24:42]** And then, as I started thinking about the connectors, and we work with a partner called

**[24:47]** Endgame who does a similar job, but it's more focused on our accounts, our opportunities,

**[24:53]** and our contact intelligence that lives in our CRM and other systems, and they provide a graph.

**[24:58]** And so what I realized was like, they're really good at giving me the intelligence I need to

**[25:03]** know about our sellable universe, but what they lacked was this graph that I had that had our

**[25:09]** playbooks, our strategies, our coaching manuals, our product, our positioning, our winning zones,

**[25:15]** you name it, any sort of go-to-market intelligence, it was in there. And so I realized I needed to

**[25:20]** combine those two, and then again, just using some cloud and asking some questions and being curious,

**[25:26]** ran into a tool. There's a few out there, pine cones like one, there's a couple others,

**[25:30]** where you can essentially leverage their technology to upload your graph to it,

**[25:34]** and then turn that into a custom connector, right? So think of it as like turning on your outreach

**[25:40]** or your gone connector, you just sort of built one that you host yourself and you allow the team to

**[25:45]** hook up to it as well. So it was a very crawl, walk, run type of progression of getting to what

**[25:54]** we have today, but it's something that anybody could replicate. And the quicker you do it,

**[26:00]** the faster you're bottling up, what in a lot of cases is competitive advantage

**[26:05]** in the tribal knowledge, your industry expertise, your experience, what you know about your

**[26:09]** customers, and everybody gets smarter and everybody gets better. But you have to go through that dirty

**[26:16]** work of control burning content, figuring out what matters, what doesn't, and then working

**[26:21]** towards something that's a little bit more accessible and scalable for the rest of the team.

**[26:26]** Yeah, and every single turn of this just continues to compound. So the longer you wait,

**[26:32]** you're just missing out on that compounding interest equation of, hey, every time you do

**[26:36]** more work, you can add to the graph, you can add new scenarios, you can add new things,

**[26:40]** you can revamp something that's not working anymore in that context. So every single time

**[26:45]** somebody does something, if you set this up really well, you're just getting that 1% better

**[26:51]** every single day. And for those teams that aren't doing this, you're just burning daylight and

**[26:58]** burning time on that compounding interest equation. Yeah, and you mentioned this wave theory that I

### 27:03 — The wave theory of AI adoption

**[27:03]** have where AI adoption starts from trusting account intelligence into deal acceleration,

**[27:11]** and for us into pipeline monitoring, and now post sales. And so you see this customer lifecycle

**[27:18]** wave, but most teams, they want to start with content, right? And write my emails,

**[27:23]** create me my sequences. And that's what everybody's selling, so it makes sense. But the problem is,

**[27:29]** you can't check an email, it either sounds good or it doesn't. And there's no right answer to

**[27:34]** verify if there's no ground truth to work from. And so you can have a brand new rep using AI,

**[27:39]** getting really, really quality outputs to their eyes, but they don't have the tribal knowledge

**[27:44]** to know if this thing is hallucinating, right? And it hurts people all the time. And so people

**[27:50]** don't trust it, right? And then they stop adopting it. And if trust never gets built,

**[27:55]** it just basically gets its shelfware at that point. And we mentioned earlier, right? Context

**[28:01]** is the bottleneck. It has nothing to do with your content. And the data behind that,

**[28:09]** there's one of the case studies that was done, our H1 to H2 numbers. There was a benchmark that

**[28:15]** we looked at where we wanted to try to understand, is what we're actually doing in terms of AI

**[28:21]** strategy and some of these different changes we've made, like is it impacting numbers that we can

**[28:27]** measure, right? And from H1 to H2 last year, I think I mentioned we were at like 12 account

**[28:33]** executives to start the year, a little less than halfway through, we were down to about eight.

**[28:38]** We never really backfilled, didn't even have a BDR team back then. We started them in October

**[28:44]** of last year, but we still saw better sales cycles. We went from like a typical 12 to 18

**[28:51]** month for big marquee accounts down to six to nine months from half one to half two. We saw like 9%

**[28:56]** increase in win rates, like a 40% increase in average ARR for deal size. Like everything was

**[29:04]** going up and to the right where it mattered. And we were able to actually go back and see it's the

**[29:09]** intelligence. It's people are smarter. We're not getting, you know, kicking ourselves in, you know,

**[29:14]** in the foot every time we go out and then we make some sort of claim to somebody because AI put it

**[29:18]** in an email and nobody checked it. And so the context is really like it's, it's the premium

**[29:24]** fuel for the system. And it'll show up later, like in the performance data, if it's actually

**[29:29]** being adopted, trusted, and it's being used correctly. And if sales starts using it, marketing

**[29:34]** starts using it, everybody starts to see that this intelligence we're gathering makes them better.

**[29:39]** The sales handoff, the client success kickoff, the onboarding, there's no drop in intelligence

**[29:44]** from team to team. You really start to separate yourselves from like typical vendors who

**[29:50]** are bolting on AI and, you know, copy and pasting a bunch of stuff blindly and, you know, doing a

**[29:54]** bunch of slob versus the teams who have more intelligence about companies than any individual

**[30:00]** that we're selling to over there with clear, you know, perspective and a ton of intelligence to

**[30:07]** back the reasons why we're reaching out. And that all comes from the graph and the work that we did

### 30:12 — The numbers: cycle time, win rate, and ACV

**[30:12]** in the first half of the year. Can we go back to those results? Because the way you rattle them

**[30:17]** off and to those listening, it may sound like, oh, those are incremental improvements. When you say

**[30:24]** nine points on conversion rate as an increase, reducing sales cycle from nine months to six

**[30:30]** months. Those are dramatic improvements in the go to market leverage of your entire team. And I

**[30:39]** don't know if people listening really have an appreciation for how powerful movements on those

**[30:45]** numbers can be. Only a couple points on conversion rate can increase your bookings by millions,

**[30:52]** tens of millions at scale. And there's huge risk if you don't maintain those go in the other

**[30:57]** direction as well. And then if you can reduce sales cycle, I mean, reducing it by a third

**[31:02]** is absolutely insane and can get your pipeline turnover so much quicker to where you can get

**[31:10]** more in the year and getting more in the year moves up your growth rate, which the difference

**[31:17]** between 80% growth and doubling could mean multiples on your multiple. So I just wanted

**[31:25]** to take a pause because those are huge improvements, not just minor ones. And I think

**[31:31]** when you're pointing all of this productivity towards improving those metrics, the revenue

**[31:37]** results are dramatic. So I was just wondering if you wanted to double click on those a little bit.

**[31:42]** Yeah. And sometimes we have it easy in sales in some ways, because a lot of people have to

**[31:46]** prove like, what's the ROI on this AI stuff we're doing, right? I think, you know, like customer

**[31:50]** support and then like, I think that's probably the easiest place to prove it because the number of

**[31:55]** tasks you solve and tickets you close and that kind of stuff with AI, like it's pretty easy to

**[31:59]** measure. And sales is kind of similar because we're a performance, you know, like organization,

**[32:05]** like it's all about numbers. And so like, yes, we could have 100% adoption and people

**[32:09]** asking questions to the AI, but if it's not actually driving revenue, you know, accelerating

**[32:15]** pipeline, you know, helping us multi-thread into accounts and understand businesses in ways that

**[32:20]** we just couldn't do it before, you know, you don't get the same sort of downstream impact. And, you

**[32:25]** know, I always think of like leading indicators, lagging indicators, and what can you see in the

**[32:30]** middle that gives you a good idea about where you're going to end up. And for us, like the 70%

**[32:36]** ACV increase wasn't just like, oh, well, that's cool. We don't know how that happened. The 9%,

**[32:42]** you know, win rate improvement, like that was a very specific thing that was going into like our

**[32:47]** business cases and us really being able to tell an intelligent recommendation to somebody where

**[32:52]** it just makes total sense for us to do business together. The shortening of the sales cycles was

**[32:58]** really the convergence of the go-to-market teams working these accounts together, you know, and,

**[33:03]** you know, the numbers look good. I don't want to like, you know, go through like our public numbers,

**[33:07]** but we published that case study. It's out there. Actually, I'll give you the link, you know,

**[33:11]** in the follow up just in case you want to include it. But it talks about how we leveraged specifically

**[33:17]** some of these context graphs to be able to gather the intelligence needed to go and compete in a

**[33:22]** market where we're not the big incumbent. You know, we're a scrappy startup and we're taking

**[33:26]** business from some of the biggest players in the space because our sales process is differentiated

**[33:31]** from the experiences of other vendors. It's just not the same thing. And so when you're, you know,

**[33:36]** competing for a dollar spend and you've got a business case that is a clear cut, you know,

**[33:42]** couldn't be any more tailored from what you had in the conversations and comes from only the

**[33:47]** intelligence of the sales process. No copy paste, no random artifacts that you give to everybody

**[33:53]** else. No, no blanket marketing proposal that everybody uses. It's just a different type of

**[33:58]** experience that you provide. And it makes you go from tech vendor to pure consultative seller. And

**[34:04]** it's for us, it's been one of the ways that we've really been able to distinguish ourselves in the

### 34:09 — Where RevOps is going

**[34:09]** market that's pretty competitive. I'm curious, with everything going on, where do you think RevOps

**[34:17]** is going in the future? I think RevOps, especially in like my experience, probably holds a lot more

**[34:23]** of the folks that you're looking for to fill these go-to-market engineer seats, just because the

**[34:28]** backends, like I talked about, you know, leveraging some engineering discipline, like my counterparts

**[34:33]** at our company that are Salesforce certified and know our core systems inside and out are in some

**[34:39]** ways more critical than I am to the types of building that we're doing on top of like our core

**[34:44]** tech stack. And so I think, you know, RevOps is going to be a department that gets a lot more

**[34:48]** investment. And instead of going, you know, all in on FTE on sellers and the folks on the floor,

**[34:54]** I think the more people realize, you know, the enablement operations and, you know, the go-to-market

**[35:00]** deployment of resources is really where you're going to start to see leverage. Like it's the

**[35:04]** reason why we started at 12, we're at eight by mid-year, and we're still able to hit the numbers

**[35:10]** and have a record-breaking year, you know, without having to backfill it. In most cases, a company,

**[35:16]** you know, 10 years ago when I was running my old startup, if we had a couple reps go out like that,

**[35:20]** you know, somebody had to make up that pipeline. You know, it wasn't like the investors were just

**[35:25]** like, oh, that's cool. We'll go ahead and, you know, dock that from the expectation. And so those were

**[35:30]** scramble exercises. And for us, we just hunkered down on more enablement, more intelligence,

**[35:36]** better ICP, you know, better pre-qualification, and really just put the resources into investing

**[35:41]** in the people who were high performing. And I think that's the motion more people are going to

**[35:46]** start to adopt, right? You don't need to double your sales team. Sometimes you just need to let

**[35:51]** them do a little bit more with less. And AI is the perfect tool to do that if you know how to

### 35:55 — Build vs. buy: micro-SaaS and why he won't rebuild the CRM

**[35:55]** leverage it. One of the things I saw on your GTM operating system, which I thought was really

**[36:02]** interesting, it was a lot of custom built tools. And I think now more than ever, it's so much easier

**[36:10]** to build than it ever has been. I'm curious your take. What type of tools do you say, hey,

**[36:17]** these are pretty straightforward to build in-house. And then when do you want a professionalized

**[36:23]** vendor to bring into your tech stack? So from your perspective, what's worth building and

**[36:31]** what's worth buying right now? The way that I kind of describe it is like what I would call like

**[36:37]** microsass, right? It's not necessarily something you put an ARR, you know, go to market effort

**[36:42]** behind and build a company around, but they're like these really, you know, intricately built

**[36:48]** solutions that only work with your tech stack, right? And you know, they're sort of filling gaps

**[36:54]** that exist that would make your team better. But you know, if you went to Salesforce, they'd be

**[36:59]** like, okay, cool, we'll take the feature request, but you'll never see it because it doesn't have

**[37:04]** any, it's purpose for our business, right? It would only work for us. And so that's kind of the way

**[37:09]** that I distinguish it. Like if it's, I'm not trying, I've seen a lot of people talk about,

**[37:13]** counsel my CRM and build my own CRM, zero interest in doing that. Not any interest at all.

**[37:20]** Maybe why? I want to dive a little deep on that because I think I agree with you,

**[37:27]** but I have talked to people that have completely built a homegrown CRM, even a homegrown sequencing

**[37:34]** system. And I was like, I thought the workflow part might be the part that's a little bit more

**[37:38]** difficult to replicate and you need to rely on it, but what goes into your equation as to why

**[37:46]** I'm not going to build the CRM versus maybe some of these smaller things? Well, a lot of it starts

**[37:53]** with compliance for me, right? Like if we're SOC 2 certified, like I don't have the skill set,

**[37:59]** even at my level today, to ensure that everything that I'm doing and building is going to be SOC 2

**[38:04]** compliant, right? And a lot of these ERP, CRM, foundational source of truth type tools, a lot of

**[38:12]** people, the reason why they want to leave them is because they're garbage cans, right? They've never

**[38:17]** been able to turn it into a goldmine. And so if that's the way you feel about your CRM, then sure,

**[38:21]** you might want to build your own and start over and make it something that's a little more manageable.

**[38:26]** For us, I use it as a database, right? Now I'll tell you this, I do as much as I can to keep my

**[38:34]** reps out of Salesforce because it's one of the most cumbersome tools to click through and update

**[38:39]** and it takes a lot of time. I have ways that I leverage that data and give them other tools

**[38:44]** using the same information, but in a way that's more conductive to their workflow, like their day

**[38:49]** to day. So it's not like I'm championing keeping people in the CRM. All I'm saying is there's a

**[38:55]** database that already exists, that's already compliant, that has an integration economy built

**[39:00]** around it, and it's connected to all of our go to market stack. For me to take on, you know, do I

**[39:05]** want to rebuild the CRM, I actually have to think through the lifeblood and the connections, you know,

**[39:10]** of the entire stack, not just, you know, whether or not I like a CRM, right? We work with a lot of

**[39:17]** vendor providers, marketing has their tools, success has their tools, all of it's integrated

**[39:21]** to Salesforce. So for us to leave, you know, that project is probably a bit different in scope that

**[39:26]** maybe a startup is trying to decide, do they want to invest in the CRM or build themselves?

**[39:31]** Totally. Don't make sense. I just think some of those things where I was like, I wouldn't even

**[39:36]** think this would be a question or somebody would try to do this, but then I'm seeing people do it.

**[39:40]** I'm like, okay, well, what goes into that decision tree of building versus buying? And I think you're

**[39:48]** right. I mean, at a certain level of scale, also I always think about it as opportunity cost. Okay,

**[39:53]** you're going to pull, you mentioned like, hey, I try to not pull my engineers off of building

**[39:57]** the core product as much as possible, because every hour investing in your core product that's

**[40:03]** going to market, that's likely going to give you a better return than building internal tools.

**[40:08]** So I think of it as an opportunity cost thing too, like, hey, you'd actually need some pretty

**[40:12]** serious engineers if you want to replicate what all of these companies have done.

**[40:16]** Totally. Yeah. And again, in that compliance aspect, like what kind of data is in there,

**[40:20]** right? Are you buying or building compliance, right? Like that's a whole different, you know,

**[40:26]** ballgame. Like if I've just got a bunch of a lead list that anybody can get and everybody can buy,

**[40:30]** great. But if it's got customer data coming back from system and production, invoicing data coming

**[40:35]** back into their billing section, it's like, how am I going to make sure that I've accounted for

**[40:41]** all the stuff that that system's already handling for me? So I pick and choose my battles in terms

**[40:46]** of building. I prefer to look for the things that, you know, I wouldn't even ask any other vendor

**[40:51]** provider reuse to build it. I would, because it wouldn't work for any of the other customers.

**[40:55]** But if you've got APIs, MCP servers and ways that I can access your data,

**[41:00]** that's literally all I need with the plugins and the toolkits that I use.

### 41:04 — What the Salesforce-admin generation needs to learn now

**[41:04]** Totally. No, it makes sense. For some RevOps folks that are, I'll say, let's say they came up

**[41:12]** through the Salesforce admin kind of ranks. I know there's an eclectic background of how people fall

**[41:18]** into RevOps. But for some of those that might be in that more like legacy type of mindset with the

**[41:26]** RevOps role, what type of skills do you recommend they need to start gaining immediately? And what

**[41:34]** types of things do you think they need to be learning immediately so that they can stay

**[41:38]** relevant? And how existential do you think it is for their career?

**[41:46]** I mean, maybe not in the near term, but there's, there's going to be a whole, you know, group of

**[41:50]** professionals that come up behind the generation that are in the seats today that all they're,

**[41:54]** they're going to be AI native, since they were kids, right? Like, we're not talking about trying

**[41:59]** to learn it for a business. We're talking about people using it in their day to day lives, you

**[42:03]** know, for, let's call it a decade. When they show up into the work environment, it's one of those

**[42:09]** things where if you're an engineer that hasn't went back to school or got the latest CAD updated

**[42:12]** training, or, you know, have it went back and got your continuing education hours as a nurse,

**[42:16]** you're probably going to be falling behind the industry. Things are changing very, very quickly.

**[42:22]** I mean, I proactively seek certifications, webinars, invest quite a bit of time and money

**[42:27]** to try to stay at the cutting edge of what's happening, because it's the best way that I can

**[42:30]** support, you know, the team that I'm serving. But even I, you know, at some times feel like

**[42:35]** there's just no way to keep up. So one, don't try to learn everything, you know, focus on the things

**[42:40]** that actually matter and understand, if you're coming from a RevOps background, or, you know,

**[42:45]** you're a Salesforce admin, you've already got technical skills, like, that's not what I would

**[42:50]** be looking for in a, in say, a go to market engineer, then that's why I think they're already

**[42:54]** hiring in the building, what you need to look for is like, you know, how can you develop this

**[42:58]** knack for, for enablement, right? Not the traditional, you know, LMS, you know, knowledge

**[43:05]** base, training material, PowerPoints, enablement, but like, how do you actually go and help people

**[43:12]** be better at their job and make them more efficient, make them more effective, improve,

**[43:17]** you know, the internal customers that we have, improve their life and their workflows. And so

**[43:22]** the technical part is, you know, it's not the most important thing, it's the curiosity that I look

**[43:28]** for, because that's not teachable, right? So, you know, if you're technically inclined and look at

**[43:32]** things in ones and zeros, you probably want to start, you know, going and looking at some design

**[43:36]** thinking courses, or just some different ways to approach problems other than, you know,

**[43:42]** product scoping, you know, solution, prototyping, like, you have to be a little bit more open-minded

**[43:49]** and not just rely on the back end behind the scenes work and get out in front of the

**[43:53]** teammates that you're serving, you know, find these problems and understand what you have at

**[43:57]** your disposal, right? Like a lot of people maybe, you know, aren't as, as, you know, I would say

**[44:02]** entitled as I am in some ways, because we lean so much into AI, like I have all the tools at this,

**[44:07]** at my disposal that I can ask for, there's no limitations, you know, to me being innovative

**[44:12]** and serving my teams, you know, some people you have to build that trust, and you have to go out

**[44:16]** and show that you can do it on a small scale first, and it doesn't take, you know, an enterprise-wide

**[44:21]** operational, you know, project, find your own wedge product, right, within your department, build

**[44:28]** something that works, improve that, that you can be trusted to help, you know, improve the lives of

**[44:32]** your teammates, and then you'll be able to start, you know, sort of rolling out for there. So, you

**[44:36]** know, don't go swing for the fence, but also, you know, you got to rely on something other than your

**[44:41]** technical background, because people like me have, you know, built these teams, train these teams,

**[44:46]** work with people, we didn't just work with systems, and anybody in a go-to-market engineer role is

**[44:50]** going to have to figure out how to marry both the technical aspect, which I've been trying to get

**[44:54]** better at, right, and then the enablement aspect, those are going to probably start merging fairly

**[44:59]** soon. Yeah, it does feel like the value of the technical skill set is starting to drop a little

**[45:07]** bit, at least like the deep specific manual technical skill set, and then the context and

**[45:13]** creativity is becoming more and more valuable. So, I just think it's challenging, I think the

**[45:19]** RevOps role is becoming really, really dynamic, it's becoming really challenging, I think the

**[45:24]** expectations in the bar have risen by 10x of what people expected maybe five years ago, and I just

**[45:32]** see it continuing to grow, and what people will be demanding out of their RevOps teams and RevOps

**[45:40]** functions is going to be quite a lot. Yeah, we're not just looking at integrations and systems

**[45:46]** connecting and putting in custom fields anymore, we're looking at real operational

**[45:51]** transformation that can be happening, and they can be at the forefront of it, but they also have to

**[45:57]** understand that that old role is, like a good example of this, is we have a consultant that

**[46:02]** works for us, he's super good at what he does, and we've had this really weird Salesforce bug

**[46:06]** for a while where an address gets changed every once in a while, and we've went through everything

**[46:13]** you could possibly think of, digging through workflows, and looking at connectors, and calling

**[46:18]** Salesforce, and looking at every provider, and trying to troubleshoot, and luckily all these

**[46:22]** providers that we've tried to see who it is, they've got MCP connectors, and they've got APIs,

**[46:28]** and I didn't know this was going on, they kind of brought it to my attention, and then going through

**[46:33]** and just saying, "Hey, hook up to these connectors, and you tell me, go look in the log, see what this

**[46:38]** is, when was it triggered," and it literally reverse engineered down to what the actual issue could be,

**[46:43]** gave it to them, and they said, "Oh, that's interesting, let me try that," and then it fixed it.

**[46:48]** I've never used Salesforce before, I don't even know how to go back there and look at what's going

**[46:51]** on in Salesforce, but if I can deploy an AI solution towards it that can see all the systems,

**[46:57]** and look at these logs, and figure out what's triggering the automation, and where it's coming

**[47:01]** from, nobody knew how to do that, not even our consultant, and we're really good at what we do.

**[47:06]** We're not incompetent, it was just something that was very complex, and that's a skill set,

**[47:11]** where even having a consultant, and a dedicated full-time resource, and me throwing myself at it,

**[47:16]** and somebody trying before that, the problem persisted, and that the requirement for us

**[47:22]** to fix it was just giving a better system, all the information and tribal knowledge we've

**[47:26]** accumulated about the project, and literally watching it solve it within about an hour.

**[47:33]** That's crazy, and I think if that's not an example of where everything's going,

### 47:39 — Making the resourcing case to your exec team

**[47:39]** I'm not really sure what is. One thing that I think is going to be really important for

**[47:44]** people to wrestle with, too, that I'm curious your take on, the capabilities have gotten so good,

**[47:50]** the efficiency and effectiveness of RevOps people have

**[47:54]** tenexed, I think, over the last couple of years. At the same time, the needs, I think, have gotten

**[48:00]** even bigger, and I think it's put people in a situation where on the surface it looks like,

**[48:07]** "Hey, you can run super lean because there's all these new capabilities," but what's actually

**[48:11]** happening is the ceiling of potential work has just risen so high that anything could be done

**[48:15]** at any time, so now there's even more work to be done. How do you navigate the resourcing

**[48:22]** conversation with an executive team to say, "Hey, this is? I need you to invest in more

**[48:29]** headcount or more tools and more things because of XYZ?" How do you navigate that conversation?

**[48:37]** Any recommendations you have on how much a company should be investing in their RevOps org?

**[48:43]** It's tough to answer. I could answer it from the universe I'm from, which is your enterprise,

**[48:48]** B2B, SaaS, but it depends on what your go-to-market archetype is. If you're doing

**[48:55]** SMB community-driven motion or you're doing product-led growth, there's a couple different

**[49:00]** ways that you could approach that, but for me, it usually comes down to what can you

**[49:04]** tie it on in terms of revenue, and can you actually measure the impact, like me going

**[49:11]** and saying, "Hey, I want to invest in this end-game context graph because everybody keeps asking me

**[49:16]** to go and download all these transcripts and go through Salesforce and gather intelligence and

**[49:22]** create these account plans." There's a tool that can do that and it's connected to everything,

**[49:26]** and so yes, I thought about building it, but then it was like in compliance,

**[49:30]** it was already SOC 2 certified, I didn't have to worry about checking that box, so that was a win,

**[49:35]** right? But then it integrated into everything that we needed, and so when an executive comes

**[49:40]** to me and says, "We have a problem to solve," usually it's either training and better information

**[49:45]** and leveling the team up, or we're building or having to buy a solution that fills the gap.

**[49:52]** And so for me, what I'm looking for is like what actually solves the problem they're asking me to

**[49:56]** solve, right? But here's a good example. One of the very first problems that I got from our CEO was

**[50:03]** all the reps are doing dials, but they're not showing up and being logged in the CRM, right?

**[50:08]** And you would think, "That's a pretty easy problem to solve." The problem is a lot of them were

**[50:12]** happening in the field, they're getting calls, stuff like that. So yes, I could put a training

**[50:18]** together, yes, I could force everybody to go and manually enter their calls, they may have

**[50:23]** varying degrees of notes, and maybe they'll put the outcome and maybe they won't, like yes,

**[50:28]** you can force some sort of training function to solve that. I found, like there's a lot of them

**[50:35]** out there probably at this point, but like a really decent dialer, right, that worked with our system,

**[50:40]** but that also analyzed the call transcripts, added the notes, added the disposition, and logged it in

**[50:45]** Salesforce. And so all it was was a little tool, not very expensive at all, a decent overlay on our

**[50:51]** outreach platform so you can make your calls efficiently, but it actually, you know, not only

**[50:55]** did it make the reps more efficient and made them, you know, better, you know, gave them better

**[50:59]** information, but it also solved the problem the CEO had was, you know, we're having conversations

**[51:04]** and we're losing the intelligence. And so that was a very easy, "Hey, you said you have this problem,

**[51:09]** primary benefit, here's the secondary benefits that I've identified for our team and how it

**[51:13]** makes us more efficient." And so if you're solving a business problem with a solution that also makes

**[51:19]** the team better, I think that's an easy conversation to have. It's when, you know, if I go and just say,

**[51:24]** "Hey, you know, there's this really, like clay, for example, I've always wanted clay. I don't think

**[51:29]** we're gonna get clay," you know what I mean? It's really expensive, but you know, I've always wanted

**[51:34]** it. I'm not just gonna go over there for the sake of saying I want clay just to see what I can do

**[51:38]** with it, right? So you have to sell the business case internally. Like I literally run the same

**[51:42]** sales process. I teach my reps internally. Like you're multi-threading, you know, talking to

**[51:47]** different department leads, seeing if there's cross-departmental value, figuring out what use

**[51:52]** cases we can actually check boxes off if there's any overlap with the current tech stack. Got to

**[51:57]** know about that. And so you're just doing a sales process inside your own organization. And then

**[52:02]** when you build a business case for it, you'll know before anybody else, if you want to present it,

**[52:07]** like, you know, you'll know if you can actually have an ROI story to tell for an investment that

**[52:11]** we're about to make. And I force my vendors to go through that process with me. Like I make them

**[52:16]** help me develop my business cases. Most people don't do that very well.

### 52:21 — Headcount: three BDRs instead of four AEs

**[52:21]** What about on the headcount side? I think that makes a ton of sense on the tool side. And then

**[52:25]** you could do opportunity costs, like you mentioned, like, "Hey, I could go build it. I could go code

**[52:29]** something. And I could do the enablement. That's going to be, you know, 20, 40 hours of my time if

**[52:34]** you want to do that. I'm not going to be able to do these things." What about on the headcount side?

**[52:38]** Would you ever get the pushback of like, "Ryan, can you just do it all? Get you some more

**[52:42]** cloud tokens and a few more tools?" What do you need more headcount for?

**[52:47]** Yeah. And I mean, honestly, I think one of the things my leadership loves about me is like my

**[52:53]** first solution that comes out of my mouth is never we need more headcount, right? It's almost

**[52:57]** always how can we be more efficient using what we have to get more, you know, how do we get more

**[53:02]** toothpaste out of the tube if you want to put it that way. But there are times where like, you know,

**[53:08]** if we don't have market coverage, right, and we've got accounts that aren't being worked on and,

**[53:12]** you know, they're stale and we don't actually have enough people to work the market and the

**[53:18]** identified ICP that we have, then yes, there's obviously some situations where you need to

**[53:22]** backfill. But, you know, we've been trying to make the case, you know, when we went from 12 to 8,

**[53:28]** yeah, they want us to backfill. But, you know, and their preference is we put people back in those

**[53:35]** seats. But for us, we were able to do some account shuffling, brought in a couple of BDRs and put

**[53:40]** together a different look at our motion that allowed us to be more efficient without having

**[53:45]** to go back and get a bunch of account executives and ramp them up. And so sometimes it's not,

**[53:49]** you know, sometimes it's like, are we doing, are you talking about the right FTE? Because you guys

**[53:54]** want us to get four new account executives. I think we can bring on three BDRs and actually

**[53:59]** supercharge pipeline for the people who have already been performing and are still here.

**[54:04]** Right. And so I don't want to invest in their competition and watering down territories and

**[54:08]** accounts. I want to invest in resources with a different look, a different strategy. But,

**[54:14]** you know, that was something that had to be discussed among the execs. It was something

**[54:18]** that had to be sold for three, four years. They believed outbound does not work for our

**[54:24]** industry and our company, and they've never had a BDR team. But good data, right, seeing some things

**[54:30]** early with our account execs and knowing that there's finite numbers of accounts presented

**[54:34]** the business case. And it turned out, yeah, you know, the resources make sense to backfill some

**[54:38]** roles, but not in the way, you know, that the traditional, you know, workflow would happen.

**[54:43]** Oh, somebody goes down, we fill it. We've got market coverage. We stopped asking those questions.

**[54:47]** Now we're trying to ask, you know, what is the role we need? Like, what's the business today and

**[54:52]** what does it need to be in 12 months? And are we the team that it's going to take to get there? And

**[54:56]** if we're not, who else do we need? And if we don't need anybody else, how much better do we have to

**[55:00]** get? But we kind of, you know, think through those processes before we just assume throwing bodies

**[55:05]** and problems is, you know, the best approach. That growing all cost stuff, I think, at this point is

**[55:10]** pretty much war itself out. Like, I think those days are over. Yeah, yeah, they've been over for

**[55:15]** a little bit. It was a fun party, though. I got to enjoy a lot of it in the 2010s. I have an exit

**[55:20]** during that time. But I was lucky enough to be on one of those. I think my founder there timed it

**[55:28]** perfect. But it's tough for some teams to know, do I need one RevOps person? Can that one RevOps

**[55:37]** person help me when our sales team is 20 people, 50 people, 300 people? Like, when do you start to

**[55:44]** need some more people? But I think, yeah, starting with, hey, how can we be more efficient and solve

**[55:49]** this in a creative way is great. Just giving people a gauge. Like, there is a point in time where it's

**[55:56]** like, hey, I can't do everything that the business wants me to do. There's an endless task list and

**[56:02]** endless project list and things that could really move the needle. And we need to bring in some more

**[56:06]** people. So just wondering if you had a gauge for where that is. But I know it's a complicated,

**[56:10]** complicated thing to try to gauge out. Yeah, I mean, for us, it's pretty clear because we have

**[56:15]** a finite universe to sell into, right? So ours is activation rate. Like, do we have good activation

**[56:19]** and coverage across, right? And if we do, then we don't need to bring any more bodies on. And usually,

**[56:25]** you know, it's like, even if we lose a couple, you know, could we do more enablement, more

**[56:29]** optimization, you know, more operation support to let the people that are still here, that do perform,

**[56:35]** that have a high level skill set, you know, can we just give them more opportunity, right? And that's

**[56:41]** sort of the approach that we've taken. Now, if you're SMB mid market, and you've got thousands

**[56:45]** and thousands of thousands of accounts, like, yeah, there's probably a different thought process

**[56:49]** and strategy that goes into it. But for us, it's really about, you know, do we have the adequate

**[56:54]** coverage of the market? And are we enabling and putting our resources into the right people?

### 57:00 — Wrap

**[57:00]** 100%. Well, Ryan, this has been an amazing conversation. Thank you for sharing everything

**[57:08]** that you brought to the table. I think everything from how do you get your team enabled and AI

**[57:14]** pilled as much as you are, so you can start to really get that across the organization and start

**[57:20]** getting the benefits of that. Then I think I really appreciate you bring a demo to context graph and

**[57:25]** walking through step by step how to start building that out. Because the AI strategy is a data model

**[57:32]** problem. It's not an LLM problem. They're already, you already have way more horsepower than you'll

**[57:37]** ever really take out of them. It's really how can you get the right context fed to them so that way

**[57:41]** you can make the most out of it. And then I really appreciate you walking us through where you think

**[57:45]** RevOps is going, and how to think about building out your team. Because I think in this new world,

**[57:50]** the role is changing. The expectations are changing. Everything is really starting to

**[57:57]** change in this industry. So having some gauge of how should we be approaching this is super helpful.

**[58:03]** So Ryan, I appreciate everything you brought to the podcast today. I can't wait to watch

**[58:08]** what you and handle do next and follow all of your success. All right, man. Appreciate it. Thank you.


---

_LeanScale Knowledge Hub. Free to quote and cite with attribution to The LeanScale Podcast (https://www.leanscale.team)._