• LinkedIn
• Twitter
• Instagram
• YouTube
• RSS Feed

Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS

What’s up everyone, today we have the pleasure of sitting down with Lindsay Rothlisberger, Director of GTM Innovation at Zapier.

Summary: Lindsay walks through the 6-component AI governance model at Zapier: a golden path to Cursor, a structured shared brain in Google Drive, data policies built with the security team, a visibility layer powered by a custom Zapier agent, a context engineering strategy that fights context rot, and a red-yellow-green skills review gate. If your team is figuring out how to govern AI at scale without killing the momentum, this is the inside view from someone who’s doing it live.

In this Episode…

• How Zapier’s GTM Team Built a 6-Component AI Governance Framework
• Why Visibility Has to Come Before Governance in AI Adoption
• How Zapier Fights Context Rot in Its AI Shared Brain
• How to Review and Govern AI Skills Before Sharing Them with a GTM Team
• How RevOps Shifts from Building AI Tools to Enabling Others to Build Them
• Why AI Builds Create More Silos Even When Governance Is Working
• How to Stay Grounded When Leading Through Rapid AI Change
• How to Get Buy-In for AI Projects Without a Deck

About Lindsay

Lindsay Rothlisberger is Director of GTM Innovation at Zapier, where she leads the company’s AI-powered GTM transformation internally and works alongside customers navigating the same shift. She spent 4 years building Zapier’s RevOps function from 0, scaling it into a cross-functional engine covering AI, systems, analytics, planning, and enablement, and growing ACV 10x in that time.

Before moving into the innovation role, she led marketing operations and lifecycle programs at UNiDAYS across B2B and B2C markets. She writes on LinkedIn about what Zapier is actually shipping, what works, and what doesn’t.

How Zapier’s GTM Team Built a 6-Component AI Governance Framework

Most RevOps teams doing serious AI work have been doing it longer than the current conversation suggests. The tools are newer and the terminology has changed, but building automated workflows that take unstructured data and produce structured, actionable outputs for salespeople and marketers? That’s exactly what good RevOps teams were doing before anyone put a trending name on it.

Lindsay’s team at Zapier started experimenting with AI several years ago, when it was first becoming accessible. Zapier gave its RevOps team the tools to experiment early, and rather than waiting for a strategy to materialize, they picked a specific, annoying problem: sales handoffs. Salespeople were going into first calls without enough context about the lead. The team pulled all the relevant unstructured data, engagement records, support tickets, email threads, and used AI to generate clean, contextualized briefing materials. The result was a measurable lift in lead-to-opportunity conversion rates, and a pattern the team has used ever since: find something specific that’s visibly broken, prove AI fixes it, then apply that logic somewhere else.

“I wouldn’t call them engineers. I would say they’re non-technical people who are building things, much like RevOps folks have been doing for a very long time.”

That early foundation matters now because the landscape has shifted in a way that affects RevOps directly. Claude Code, Cursor, and similar tools have made it possible for people with no engineering background to build real things. Sales managers are writing AI skills that generate quarterly revenue strategies for reps. CS reps are building account monitoring tools. Lindsay’s read on this is that the RevOps team’s job isn’t to slow that down. It’s to give it a governance structure so it can scale without creating a mess, and to be the team that built the foundation those builds are operating on.

At Zapier, that governance structure is anchored by an AI center of excellence led by a chief AI officer. The architecture is a hub-and-spoke model: the central team sets the frameworks, the guidelines, and the enablement resources; Lindsay serves as the spoke into go-to-market, with a partner who works alongside her. The 2 of them act as a feedback loop between what’s happening on the ground in sales, marketing, and CS and what the central team needs to know. The center of excellence is small, just a handful of dedicated people, but it reaches into every function through the spoke structure.

The first thing the center of excellence built for non-technical GTM employees was the golden path to Cursor. Cursor had already been adopted by Zapier’s product and engineering teams. For GTM, the barrier wasn’t the technology itself; it was the setup. Someone who’s spent their career in spreadsheets and CRM doesn’t automatically know how to configure a development environment. The golden path is step-by-step onboarding: from installation through a fully configured Cursor environment with the right MCP connections (Databricks, Zapier), the right rules, and the right context already loaded. The whole point is removing the 2-hour configuration overhead that otherwise kills adoption on day 1.

That context is the shared brain: a structured Google Drive hierarchy with company-level, department-level, team-level, and working group-level folders. The first iteration meant converting existing documentation into markdown files and organizing them into a folder structure that agents could traverse predictably. Lindsay describes the experience of setting it up as oddly satisfying for an ops person who has spent years wishing the organization’s institutional knowledge lived somewhere findable instead of scattered across a Google Drive that nobody had cleaned up in years. The goal of the initial build was a working foundation that gave people enough context to get value from their agent setup without needing to build from scratch.

The companies operating furthest ahead in AI adoption right now are the ones that treated the shared brain as infrastructure rather than a side project. Getting every GTM employee configured, context-loaded, and working from a shared knowledge base is unglamorous work, but it’s the layer every other build depends on.

Key takeaway: Before anyone on your GTM team builds anything with AI, create a centralized setup guide that handles environment configuration, approved MCP connections, and context loading from a structured knowledge base. Start with the tools your technical teams are already using and build a version of that golden path for non-technical employees. The 2-hour configuration friction that stops people on day 1 is a solvable problem, and solving it once prevents you from solving it individually for every person who tries to onboard.

Back to the top ⬆️

How Long It Actually Takes to Build a Shared Brain

The shared brain question that comes up in every version of this conversation is a practical 1: how long does it actually take? Zapier’s first rollout was a 4-week sprint, and the design of that sprint was deliberate about scope. Rather than trying to capture everything the organization knew, the team focused on what Lindsay calls the slow layer of context: things that don’t change often. Company strategy documents. Ideal customer profile definitions. Lead and opportunity definitions. Basic playbooks. These documents already existed. The sprint was mostly about converting them into markdown files and putting them in the right folder structure, not generating anything new.

“We didn’t try and boil the ocean. We really just wanted to get a foundation that could give folks enough context to get value out of their agent harness.”

That framing matters. A shared brain doesn’t need to be comprehensive on day 1 to be useful. It needs to be accurate, structured, and findable. A partial but well-organized context layer outperforms a complete but disorganized 1 because agents depend on consistent file structure to traverse it predictably. Phil’s observation during this part of the conversation matched what a lot of ops leaders report: Claude Code ends up being a forcing function for folder hygiene in a way that no internal initiative or documentation sprint ever quite manages, because having an agent depend on your file structure gives you a reason to care about it that accountability alone doesn’t provide.

Key takeaway: Run a 4-week sprint focused exclusively on the slow layer: company strategy, ICP definitions, lead and opportunity definitions, and core playbooks. Convert what you already have into markdown files and put them in a consistent folder hierarchy. Don’t try to capture everything. A working foundation that agents can traverse predictably is worth more than a comprehensive archive that’s hard to navigate. Ship the foundation, then iterate.

Back to the top ⬆️

How Zapier’s Security Team Became a Governance Partner

Zapier’s security team has a nickname in Lindsay’s governance model: the data narcs. It’s a term of affection. The security team is described as deeply embedded with the AI center of excellence, working alongside the policy-setting process rather than reviewing finished decisions after the fact. That positioning changes what the security team can do. They’re architects of what “AI safe” means for Zapier, not gatekeepers deciding whether individual tool requests pass a checklist.

“In partnership with the security team, they developed our skill that reviews our skills for data and security compliance.”

The data team is equally embedded. Zapier’s data partners in go-to-market understand the specifics of the GTM data architecture, which means they can translate between what security requires and what the RevOps team is actually trying to accomplish. Together, the data and security teams built something worth noting: a skill that reviews other skills for compliance before anything gets shared. It’s a meta-skill, a governance tool built in the same format as the thing it governs. When someone wants to promote a skill from personal use to shared use, it runs through that review skill first.

The broader shift in how security teams are positioned relative to AI initiatives matters for every GTM org going through this. The security teams building real influence right now aren’t the ones saying no to tool requests. They’re the ones writing the policy that defines what safe looks like for a given organization, often building the enforcement tooling themselves. For RevOps teams, building that relationship before any skills are shared is significantly easier than building it after a compliance issue has already surfaced.

Key takeaway: Bring your security team into AI governance conversations before you share anything, not after something creates a compliance issue. Ask them to define, in writing, what AI-safe handling looks like for customer data, PII, and shared applications in your environment. Then build a review checklist based on those definitions that any shared skill has to pass. Zapier turned that checklist into a skill itself, which makes the review repeatable and self-documenting. A lightweight version of that gate is achievable in a few hours and prevents problems that would take weeks to unwind.

Back to the top ⬆️

Why Visibility Has to Come Before Governance in AI Adoption

At Zapier, AI builds spread quickly. The company’s culture defaults to distributed problem-solving: when tools for building AI workflows become widely accessible inside an organization that already runs on automation, people build things. A lot of things. Some solve real problems that could scale across the whole team. Some solve 1 person’s workflow quirk and never need to go further. Sorting between those outcomes without slowing down the flywheel is the visibility problem, and Lindsay solved it with a Zapier agent.

The mechanics are simple. She built an agent that scans the Slack channels where people share what they’ve built: the go-to-market AI transformation channel and a handful of team-specific channels where she knows creative people are active. Every Monday, the agent sends her a digest of everything shared in the prior week. She reviews it and reacts: yes or no. A yes reaction sends the item into a lightweight database she can track and follow up on. A no means it’s noted but not actioned.

“I get that digest every Monday, and I check a box. So I react basically like yes, no, yes, no, and if I react yes, it goes into my little database of skills that I can kind of keep tabs on.”

The digest format matters because it changes the nature of the decision. Real-time Slack alerts would be noise. A weekly digest is a decision session. Looking at 10 items in 1 sitting makes it obvious which builds have potential beyond the person who created them and which are personal workflow tools that don’t need to scale. A customer success rep built an account pulse skill that tracked account risk, dormant contacts, and follow-up priorities for his book of business. The kind of build with obvious legs across the CS team. The weekly digest surfaced it. Without the visibility layer, it would have stayed a 1-person tool indefinitely.

The digest depends on culture as much as it depends on the agent. Lindsay was direct: she told her team to share what they were building because she knew she couldn’t govern what she couldn’t see. People share partly because they get recognition, partly because the channel celebrates builds rather than just logging them. When something gets surfaced and scaled, the builder gets credit. That feedback loop creates its own incentive structure.

Most AI governance programs start by writing policy. The teams seeing better outcomes start by building visibility: figure out what’s actually happening before trying to control it. Policy written without data about how people are using AI tools tends to be either too restrictive to matter or too vague to enforce.

Key takeaway: Build a weekly summary of what your team is building with AI before you write any governance policy. The simplest version is a Zapier agent scanning the Slack channels where people share their work and delivering a digest every Monday. Set up a yes/no tagging mechanism so the items worth tracking don’t get buried. You can’t evaluate what you can’t see, and the people writing the most interesting skills often aren’t the ones raising their hands in all-hands meetings.

Back to the top ⬆️

Office Hours as an Adoption Engine

Zapier’s RevOps team used to run office hours the traditional way: here’s how to build an automation, here’s how to use the CRM, the experts teach and the others learn. That model has changed. The office hours are now led by whoever built something worth showing, regardless of where they sit in the org.

A sales manager built a skill called “How I Hit My Number.” It takes a rep’s current leads and deals, identifies risks, maps the stakeholders in each deal, and generates a personalized quarter strategy: how should I spend my time across these deals to hit my number? The sales manager ran the office hours session himself. He demoed his own skill, explained how he uses it, and showed other reps how to adapt it to their books. Lindsay’s team didn’t build it. They gave it a stage and handled the review process.

“We’re becoming more of enablers and guardrails and setting the systems and the infrastructure, but letting people who are really close to the problems figure out how to solve them.”

Another example from the office hours: someone built a competitive watchtower skill that monitors what Zapier’s competitors are saying on social media and flags changes to their go-to-market messaging or product positioning. He led the session, walked through how he built it and what to watch for, and the result was more people experimenting and building on top of what he’d already proved out. The builder got credit. The knowledge spread peer to peer.

The shift this creates in RevOps’s role is real. The team moves from being the builders and teachers to being the platform: they set the standards, handle the security review, maintain the infrastructure, and create the conditions for other people to ship. That’s a more strategic position. It also requires letting go of control over what gets built, which Lindsay acknowledges can be uncomfortable for ops people who are used to knowing exactly what got created and how it works.

Key takeaway: When someone on your team builds an AI skill that solves a real problem, give them the office hours slot rather than translating their build through your ops team. Peer-to-peer demos produce adoption faster than top-down enablement because people trust a colleague who solved the same problem over a central team explaining what they should want. Build the office hours cadence first, then let the best builds from your weekly digest fill the agenda.

Back to the top ⬆️

How Zapier Fights Context Rot in Its AI Shared Brain

Context rot is the quiet enemy of every AI governance model. A shared brain built in month 1 reflects reality in month 1. By month 6, lead definitions have shifted, territories have been redrawn, and a campaign that looked promising is nearly dead. If the agents running on that context don’t know any of it, they keep surfacing outdated information as if it were current, and the recommendations slowly get worse without anyone knowing why.

Lindsay’s team thinks about context in 2 layers. The slow layer covers things that change rarely: company strategy, ICP definitions, lead and opportunity definitions, basic playbooks. Zapier spent serious time getting this layer right, particularly around data definitions. If an agent receives a request for a lead report and doesn’t know whether that means an MQL, a raw contact count, or something else entirely, the output is wrong and nobody’s sure why. Defining those terms precisely in the shared brain, with explicit clarification rules baked in, is foundational work. Lindsay says most teams consistently underinvest in it.

“We joke like, ‘Are you gonna have to start saying at the end of meetings, like, Let the record show that… Like, in a way that an agent can understand.'”

The fast layer is harder. It’s all the day-to-day context that lives in people’s heads, Slack threads, and meeting notes: the decision that changed lead routing last week, the experiment that launched Tuesday, the territory adjustment nobody documented because everyone in the room already knew. If agents could connect that context to the data layer, they could explain not just what’s happening in the funnel but why. That’s the difference between a reporting layer and an actual decision-support system.

Zapier’s approach to the fast layer is still developing. The team has started being more deliberate about closing out Slack threads with explicit decision summaries and ending meetings with clear statements about what was and wasn’t decided. The Robert’s Rules of Order comparison that came up in the conversation is apt: there’s something almost parliamentary about designing human communication so that agents can reliably index it.

The next step Lindsay is planning is an agent that collects context from Slack and meeting notes and compiles a weekly decision log for a human reviewer to approve and route into the shared brain. Human-in-the-loop by design: the agent surfaces what happened, a person decides what becomes official context, and the agents then update the relevant layers. She’s also thinking about tiering: a pricing change carries more weight than an experiment idea, and the context layer should reflect that difference rather than treating all inputs as equally authoritative.

The day-to-day context layer is the part every team underinvests in, and it’s the part that determines whether an AI system can connect funnel data to business decisions. Teams that maintain both layers gain the ability to ask and answer “why” questions about performance, which is where AI starts creating strategic value beyond saving time.

Key takeaway: Audit your shared brain for the 5 data definitions that generate the most confusion when someone asks an AI tool about your funnel (lead, MQL, SQL, opportunity, and pipeline are a good starting set). Write precise definitions for each, including what they exclude. Then build a weekly habit of closing Slack threads with an explicit decision summary and ending meetings with a clear statement of what was decided. These 2 changes address the slow layer and the fast layer without requiring new tooling, and they dramatically reduce the context drift that makes AI recommendations unreliable over time.

Back to the top ⬆️

How to Review and Govern AI Skills Before Sharing Them with a GTM Team

At Zapier, a skill built for personal use is different from a skill shared across a team, and the moment something gets promoted from “this helps me” to “the RevOps team is using this,” it goes through a review. The review is itself a skill, which is one of the more interesting structural choices in the model.

The review skill checks 2 things. Security first: it scans for PII exposure, improper use of customer data, and any usage patterns that create risk under Zapier’s data policies. Quality second: it evaluates how the skill is written, whether it references the right context, and whether it’s doing what it claims. The output is a red-yellow-green rating. Red means there are specific things that must be fixed before the skill can go shared. Yellow flags issues worth addressing. Green means it’s ready.

“It gives you like a red, yellow, green. Like red, here’s what you definitely need to fix. And in most cases, Claude can just say, ‘I can go fix that for you. Would you like me to do it?’ And just do it.”

The friction is low because the remediation is automated. When something comes back red, Claude can fix the flagged issue on the spot. The gate exists but the process doesn’t become a bottleneck, which matters in an organization that runs on speed and distributed action.

Once a skill passes review, ownership matters as much as the review itself. Every shared skill has a named owner. If RevOps owns it, RevOps maintains it. If a sales team owns it, a specific person on that team is responsible for keeping it current. Lindsay describes treating shared skills like a product catalog: there are owners, there’s version accountability, and there’s a retirement path when something stops working. A skill with no owner decays. And decayed skills break the adoption flywheel quietly: people use them, get bad output, and lose confidence in the whole system without necessarily knowing what went wrong.

The embed program handles the edge cases. When someone wants to build a skill that reaches into go-to-market operations, things like deal handoffs or pipeline risk flags, they can pair with a RevOps partner to build it together. The builder brings the domain problem and the creative energy. RevOps brings operational knowledge: how the process actually works across the full team, what the edge cases are, how to make it repeatable rather than bespoke. The builder gets to solve the problem they understand best. RevOps gets to ensure the output is something the whole team can use.

That reframing of RevOps as an orchestrator rather than a builder is the more significant structural shift. The team has always owned process. Now they own the standards and the infrastructure that other people build on, and that’s a better position to be in when AI is enabling everyone else to build.

Key takeaway: Create a review gate before any AI skill gets shared across your team. Build a checklist with 3 sections: data and security (does it handle PII correctly?), quality (does it reference the right context and produce reliable output?), and value (is it useful beyond the person who built it?). Assign a named owner to every skill that passes the review, and document that ownership in the skill itself. Start an embed program for any skill that reaches into operations: the builder brings the problem, you bring the operational knowledge to make it scale.

Back to the top ⬆️

How RevOps Shifts from Building AI Tools to Enabling Others to Build Them

Every RevOps leader is sitting with some version of the same question right now: if the people they support can build their own tools, what’s left for RevOps to do? Lindsay’s answer is grounded in what she’s watching happen at Zapier, not in a general theory about where the function is heading.

Her example starts with the analytics team within RevOps. That team owns the definitions: what counts as a stage, how to call a data point, what a lead means. Those definitions used to exist so humans could run consistent reports. Now they exist so agents can surface the right data in the right context. The job description hasn’t changed on paper, but the actual work has. Maintaining those definitions used to be about consistency across a reporting layer. Now it’s about making sure every agent operating on Zapier’s GTM data starts from the same ground truth.

“That role of that RevOps person is probably not necessarily digging into the data and building the report, but it’s like, ‘Okay, how do I advise the senior leaders in sales and marketing with what to do with this information?'”

The second shift is where the strategic opportunity is. When a campaign underperforms or a deal pipeline shows an anomaly, the RevOps person’s job stops being “dig into the data, build the report, present the findings.” The agent handles that. The RevOps person’s job becomes helping senior leaders decide what to do with the information. They become the advisor who can connect data to decisions because they understand both the business model and the underlying data architecture. That’s a meaningful upgrade in strategic influence, and it’s available to RevOps professionals who understand how the data is structured even without a coding background.

The SaaS tool governance question Darrell raised gets a clear answer from Zapier’s model. Most SaaS platforms now have AI built in: CRM tools, marketing automation, data platforms, and the question of who governs that functionality is often unresolved. At Zapier, go-to-market tools are still owned and governed by the RevOps technical tool owners. Those owners work directly with security and data to approve AI functionality within their tools. The AI center of excellence operates at the organizational level. The tool governance layer stays within go-to-market. That separation keeps things from getting blurry in a way that would require routing every SaaS AI feature through a central committee.

Having the context of how to build and process, and what it means to define a process and its edge cases, is highly valuable even for RevOps professionals who won’t be the ones writing code. The RevOps function that focuses on data ground truth and decision advisory will remain central in AI-first GTM organizations. The one that focuses on building and maintaining reports faces a harder road.

Key takeaway: If you’re in RevOps and thinking about where the function is heading, start by auditing your data definitions. Every lead definition, stage definition, and territory rule in your systems is something an AI agent needs to understand correctly to surface useful output. Treat that context documentation as the core deliverable of your role for the next 12 months. The RevOps professionals who own the data ground truth are the ones whose advice will carry the most weight when leadership is trying to understand what an AI-generated report actually means.

Back to the top ⬆️

Why AI Builds Create More Silos Even When Governance Is Working

The episode opened with a company claiming to have invented a job title, which made the closing irony sharper: Lindsay holds a title that genuinely didn’t exist until mid-2025. Director of GTM Innovation is a new role. But it grew out of something much older. She spent 3.5 years building Zapier’s RevOps function from 0, and before that led marketing operations. That combination is the only reason the new role exists in the form it does, and she’s direct about giving credit where it’s due.

“I worry that we’re actually creating more silos.”

She’s honest about what she gave up: a team of 12. Managing people, building toward a vision, watching someone develop in their role, that work was genuinely meaningful. The trade she made was giving it up to focus entirely on the problem she finds most interesting: figuring out how AI-powered GTM actually works in practice, both internally at Zapier and alongside customers navigating the same transition. The role includes spending time with customers trying to figure it out for themselves, which means learning from what works across organizations rather than just inside 1 company.

Her definition of failure in the role is worth sitting with. For Lindsay, failure means embedding AI into how go-to-market works today without actually changing the underlying structure of go-to-market. She defines success as transformation at the level of how marketing, sales, and RevOps actually operate. The role of marketing is changing. The role of sales is changing. The role of RevOps is changing. Doing AI work that makes those existing roles faster while leaving their fundamental shape intact is the version of this that doesn’t work.

The broken piece she names is specific: hosting and sharing agent output. Lindsay built a campaign monitoring skill that tracks lead interactions, reviews first sales calls, and generates a qualitative view of how a campaign is actually performing, not just a dashboard number but an assessment of what reps are hitting on, where messaging is landing, and where it isn’t. It’s genuinely useful. It also lives in her Cursor environment. Getting that output into the hands of the full go-to-market team in a form they can use every day is unsolved. Her Vercel account helps with hosting and productionalizing some builds, but for less technical GTM professionals there’s no good shared surface.

AI governance built around individual builds rather than shared infrastructure is governance in name only. The output problem Lindsay describes is structural: until AI skills can be hosted, shared, and updated as living services accessible to the whole team, the gap between what individuals can do and what organizations can benefit from keeps widening.

Key takeaway: Before you build your next agent or skill for your team, decide where the output is going to live once you share it. If the answer is “in my Cursor environment” or “in a Slack message,” you have a distribution problem. Build for shareability from the start: a simple Vercel deployment works for anything that needs to update regularly. Design the output format around what the person consuming that information can actually open, read, and act on without needing to be in the same environment as the person who built it.

Back to the top ⬆️

How to Stay Grounded When Leading Through Rapid AI Change

Lindsay’s answer to the happiness question is 2 things, and she’s honest that the second 1 is harder to find in a new role than it used to be.

The first is relationships. She’s always led through connection: reaching out to people one-on-one, staying in conversations that matter. That hasn’t changed and won’t change with the role. The form it takes looks different now than it did when she was managing 12 people, but the orientation is the same.

“I have to feel like I’m having an impact. Like, I can’t do something that doesn’t feel like it’s worthwhile. That’s really draining for me.”

The second is impact, and this one is harder in a new role. When you’re running RevOps, you know what success looks like. Pipeline is healthy or it isn’t. The handoff process works or it breaks. The metrics are clear and the feedback is close. In a role built around innovation and transformation, the feedback loop is longer and less defined. Lindsay says she’s still working through what having an outsized impact looks like in this context, and she’s not pretending the transition has been smooth. The thing she’s holding onto is the habit of relentlessly looking for opportunities where her particular combination of experience and access gives her an edge, even when the role doesn’t hand her a clear scorecard.

The leaders and teams that hold up best through major transitions define what impact looks like before the scorecard changes.

Key takeaway: When you move into a new role or take on a meaningfully different kind of work, spend your first 90 days identifying 2 or 3 places where you can create a result that’s clearly traceable back to your specific effort. The goal is to rebuild the feedback loop that makes work feel meaningful, not to prove yourself to anyone else. Look for the problem where your particular combination of experience and access makes you the right person to solve it, then solve it visibly enough that the output is attributable.

Back to the top ⬆️

How to Get Buy-In for AI Projects Without a Deck

The fastest path to internal buy-in for a new idea, in Lindsay’s experience, is showing something real rather than arguing for something hypothetical. She’s spent years trying to build consensus through documentation: here’s the data, here’s the analysis, here’s the recommendation. That approach works sometimes. It works slowly. And it requires the audience to make a conceptual leap that many people won’t make on your timeline, no matter how well the deck is built.

“If you show people, that’s the best way to get buy-in. So even if it’s at a much smaller scale, like experimental, or you can create a crappy first version of something to really help people understand it, I would say just do it.”

A working prototype, even a rough 1, changes the conversation from abstract to concrete. People react to something they can see differently than they react to something they’re being asked to imagine. The RevOps instinct to build a complete case before acting is valuable at scale, but it can be a liability when you’re trying to get something new off the ground for the first time. Build the smallest version that lets you run a 5-minute demo, then show it.

On books: Lindsay’s nonfiction pick is the Real Housewives franchise, which she counts as documentary content and stands by. Her fiction pick is The Midnight Library by Matt Haig, a novel set in a library where you can see the different versions of your life depending on which decisions you had made differently. Phil noted that Haig has a new book releasing shortly in the same universe. Lindsay is adding it to the list.

Key takeaway: The next time you’re trying to get buy-in for an AI skill, a workflow change, or any idea that requires someone to visualize something that doesn’t exist yet, build before you present. Start with the smallest version that can run a live demo, even if the data is hardcoded and the interface is rough. A proof of concept that runs in 5 minutes changes the conversation from “should we explore this?” to “how do we scale this?” Build it this week.

Back to the top ⬆️

Episode Recap

Lindsay Rothlisberger makes 1 central argument across the full episode: RevOps was doing AI before AI was a trend, the infrastructure RevOps built is exactly what makes AI useful at scale, and the function’s next role is governance and orchestration rather than building. The episode opens with the “marketing engineer” controversy and closes with a candid admission that the hardest unsolved problem in AI governance is sharing agent output across a team, and that gap may be creating more silos than it eliminates. Everything in between is the practical architecture of how Zapier got from early AI experiments to a 6-component governance model that’s been shared publicly.

The 6 components she describes are: a golden path to Cursor that onboards non-technical GTM employees into a configured AI development environment with MCP connections already set up; a structured shared brain organized by context layer across company, department, team, and working group; data policies developed in partnership with the security team and enforced by a review skill; a visibility layer driven by a custom Zapier agent that delivers a weekly digest of what the team is building; a context engineering strategy that separates slow-moving context from day-to-day context and plans for a human-in-the-loop decision log; and a skills review and ownership model that assigns every shared skill a named owner and requires a red-yellow-green gate before anything goes shared.

The most honest moment in the episode comes when Darrell asks what’s broken. Lindsay doesn’t deflect. She built a campaign monitoring skill that generates qualitative output she can’t easily share with the team. Her Vercel account helps, but the broader problem remains: AI workflows built in individual environments don’t automatically become team infrastructure, and the gap between a useful personal skill and a shared organizational capability is wider than most AI governance conversations acknowledge. That admission cuts to something real about where the industry is right now, even inside a company as well-positioned as Zapier.

Her take on the future of RevOps is the chapter worth returning to. She’s not arguing that the function survives by learning to code. She’s arguing that RevOps survives by owning the context and data definitions that agents need to be useful, and by becoming the team that translates data into decisions rather than data into reports. That’s a genuine shift in what the job is about, and it’s 1 that plays to the strengths of strong RevOps professionals regardless of their technical background. The function that focuses on data ground truth and decision advisory remains central. The function that focuses on building and maintaining reports faces a harder road ahead.

You can follow Lindsay on LinkedIn, where she writes about what Zapier is shipping, what’s working, and what isn’t.

Full episode ⬇️ or Back to the top ⬆️

✌️

—
Intro music by Wowa via Unminus
Cover art created with Midjourney (check out how)

Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS

Related tags

See all episodes

Future-proofing the humans behind the tech

Apple •Pocket Casts•Google •Overcast •Spotify •Breaker •Castro •RSS

• LinkedIn
• Twitter
• Instagram
• YouTube
• RSS Feed