223: Lindsay Rothlisberger: How Zapier uses a shared brain to manage AI context and skills

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

• (00:00) - Intro
• (01:23) - In This Episode
• (02:00) - Sponsor: Knak
• (03:08) - Sponsor: MoEngage
• (05:49) - How Zapier's RevOps Team Built Its AI Foundation
• (19:43) - Why Visibility Has to Come Before Governance in AI Adoption
• (24:58) - Sponsor: GrowthBench
• (25:58) - Sponsor: GrowthLoop
• (29:48) - How Zapier Fights Context Rot in Its AI Shared Brain
• (35:55) - How Zapier Governs Shared AI Skills from Review to Long-Term Ownership
• (39:27) - What Happens to RevOps When Everyone Around Them Can Build
• (45:05) - The Director of GTM Innovation Role and the Sharing Problem Nobody Has Solved
• (50:47) - What Keeps Lindsay Grounded in the Middle of All This Change
• (52:00) - Lindsay on Getting Buy-In and What She's Reading

Summary: When a startup claimed in April 2026 that it invented the marketing engineer role and that RevOps professionals "just do tool integrations," Lindsay Rothlisberger had heart palpitations. Her team at Zapier had been building AI into GTM workflows for years before the announcement. In this episode, she walks through the 6-component AI governance model she published publicly: 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. She also names the part of the model that's still broken, and it's more honest than most AI governance conversations allow. 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 done it.

About Lindsay Rothlisberger

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 zero, 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 RevOps Team Built Its AI Foundation

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.

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 wasn't completeness. It 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.

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 one: 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.

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 one 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.

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.

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.

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 one 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.

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 one 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.

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.

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.

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.

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 explain why something is happening in the funnel, not just what. Getting the slow layer right is table stakes. Getting the fast layer right is the actual competitive advantage.

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.

How Zapier Governs Shared AI Skills from Review to Long-Term Ownership

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.

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.

What Happens to RevOps When Everyone Around Them Can Build

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.

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. Who governs that? 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.

The Director of GTM Innovation Role and the Sharing Problem Nobody Has Solved

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 zero, 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.

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. Failure wouldn't be a missed adoption metric or a slow rollout. Failure would be embedding AI into how go-to-market works today without actually changing the underlying structure of go-to-market. She cares about transformation, not efficiency. 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 structure intact is the version of this that didn'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.

What Keeps Lindsay Grounded in the Middle of All This Change

Lindsay's answer to the happiness question is 2 things, and she's honest that the second one 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.

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 tend to hold up best through major transitions are the ones who defined what impact looked like before the scorecard changed, not after.

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.

Lindsay on Getting Buy-In and What She's Reading

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.

A working prototype, even a rough one, 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.

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 one 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.

What is Humans of Martech?

Future-proofing the humans behind the tech. Follow Phil Gamache and Darrell Alfonso on their mission to help future-proof the humans behind the tech and have successful careers in the constantly expanding universe of martech.

[00:00:00] Lindsay: now tools like Claude Code and Cursor are allowing non-technical people to actually build things.

[00:00:06] I wouldn't call them "engineers".

[00:00:07] I would say they're non-technical people who are building things, We, uh, formed an AI center of excellence. led by a chief AI officer,

[00:00:16] they set up, resources and the frameworks setting up their Cursor environment, with instructions how to connect Databricks MCP, how to connect Zapier MCP, as well as setting up our company shared brain.

[00:00:29] There's, like, the slow layer of context your company strategy, your ideal customer profile, your data definitions but then the other layer of context all the day-to-day conversations,

[00:00:39] So ideas, experiments that have launched, changes to lead routing Having, an agent that actually collects all that context from, like, Slack, from meeting notes, and puts it into a decision log at the end of the week.

[00:00:52] They can connect the dots from the data layer to why.

[00:00:56] ​

[00:01:23] In This Episode
---

[00:01:23] Phil: What's up, everyone? Today, we have the pleasure of sitting down with Lindsay Roethlisberger, director of GTM Innovation at Zapier. In this conversation, we explore the role of RevOps and marketing ops when everyone in sales and marketing can apparently become engineers overnight now. Lindsay shares how she's tackled this internally at Zapier, starting with their AI center of excellence, why they focused on visibility before any governance, how they built a shared brain and how it fights context rot, how they manage and review AI skills, and why the future of RevOps is context orchestration.

[00:01:56] All that and a bunch more stuff after a quick word from two of our awesome [00:02:00] partners.

[00:02:00] Sponsor: Knak
---

[00:02:00] ​

[00:03:08] Sponsor: MoEngage
---

[00:03:08] ​

[00:04:04] Phil: Lindsay, thank you so much for your time. Thanks for doing this on a Friday afternoon. Really excited to chat.

[00:04:09] Lindsay: Yeah, I'm so excited to be here. There's so much to talk about with how quickly AI is changing.

[00:04:15] Phil: Yeah, so we were chatting a lot about this post before we pressed record here. But in April, a startup in the SEO space claimed that they created the first ever marketing engineer role in April 2026. Marketing ops and revenue ops folks kinda reacted. A bunch of people had a bunch of different takes about this, uh, because it kinda reduced, like, the marketing ops role to plumbing, data cleanup.

[00:04:40] Like the post said, like, "This marketing engineer role isn't marketing ops. Marketing ops just does tool integrations. They just make sure nothing breaks. Marketing ops isn't actually, like, building automations and using AI." And meanwhile, all the people reading that are just like, "Dude, are you serious?" Like, "Of course we're building automations.

[00:04:58] Of course we're using AI." [00:05:00] People in marketing are using AI because the marketing ops team set up the foundation for it with, like, revenue, blah, blah, blah. So the funniest part, though, is that, like, marketing engineer has actually been around for decades. I found an old article, 1959, uh, like, using marketing engineering as a term. At WordPress.com, I worked with a whole department of marketing engineering way back in, like, the early 2020s. We had a VP of marketing engineering. So I have no issue with, like, category creation or even taking an existing category, refreshing it, which I think they're kinda trying to do. But claiming that you invented the role and that you're f- the first ones to use it while also dismissing the teams that are already doing that work feels a bit less legendary and a bit more accidentally revealing.

[00:05:43] But, uh, I don't know. Do, do you guys both have hot thoughts about that post also? Darryl?

[00:05:48] Darrell: Yeah, I mean,

[00:05:49] 1 — How Zapier's RevOps Team Built Its AI Foundation
---

[00:05:49] Darrell: I know Lindsay posted about this, and she said she was having heart palpitations watching sales and marketing become engineers overnight. And maybe we can start there, Lindsay. Like, what AI workflows did you have in place already, and what sort of new ideas surfaced when marketing and sales people started to get their hands dirty with this stuff?

[00:06:09] Lindsay: Yeah, thanks for teeing me off. I, I totally agree with you. I've, I've been saying for years that I think marketing operations people and revenue operations people are not only engineers in many cases, but also serving as product managers in a lot of ways, and that we're needing to, like, truly understand the problems and go to market and the gaps and the user experience of our, quote, "customer sales and marketing."

[00:06:34] Um, so I think that- You know, it's been something we've been doing for a very long time. Um, our RevOps team started working with AI several years back, so, uh, sort of when it was first the hot new thing. Um, luckily Zapier has been really, uh, AI forward, I would say, in supplying folks with the tools that we need internally to be able to experiment with AI.

[00:06:58] So very early on, our [00:07:00] RevOps team rolled up our sleeves, um, and really started building AI into what I would call, like, our existing processes. So, like, for example, we were able to take all of the context about a lead, you know, all the engagement data, um, information about tickets and emails and things that they said that maybe were unstructured data, and use that to generate, like, these really nice lead handoff, um, materials for the salesperson, so that the sales was sort of teed up with talking points and everything they needed to know about the customer.

[00:07:32] And we saw some great results from that early on, like, uh, we increased conversion rates from lead to opportunity. Um, and so that gave us sort of a mental model for how to a- apply AI in other ways across the funnel. So that really set us up well for today's, uh, state, where now tools like Claude Code and Cursor are allowing non-technical people to actually build things.

[00:07:59] I wouldn't call them [00:08:00] engineers. I would say they're non-technical people who are building things, um, much like RevOps folks have been doing for a really long time. Um, but it set us up to be able to help consult with those teams, help understand how to take the really creative and interesting ideas that are coming from these people that are very close to these problems in their space, in marketing and in sales, and be able to integrate that into the way that people actually work at scale, and I think that's, like, the new role that marketing ops and RevOps are needing to step into.

[00:08:33] Darrell: Yeah, and I love that. I mean, if that's not building and using AI, then, you know, what, what is, right? And the

[00:08:41] the, the, the problem that I have is the, the term engineer being used so lightly. You know? What-- There was GTM engineer, now there's mark- uh, marketing engineer.

[00:08:50] It's kind of like if you were to use ChatGPT to diagnose yourself when you're feeling sick, and now you're

[00:08:57] Phil: a doctor.

[00:08:58] Darrell: Now you're a [00:09:00] PhD. You know? And it's just, that's not what engineering is. Um, I think it downplays or discredits the profession itself, and I think it is definitely just a, a big play to gain attention.

[00:09:13] Lindsay: Yeah.

[00:09:14] Phil: And you also had, like, a follow-up post to that

[00:09:16] too, right, uh, Lindsay? Like, you published right after the hul- the heart palpitation one. Uh, you kinda laid out how Zapier is actually handling this behind the scenes. Um, so, uh, we, we kind of invited you to, to come on the show to have us, like, walk us through this in detail.

[00:09:32] The post was full of really cool information about what AI governance models look like for the GTM team at Zapier. So there's like six main components, uh, that you laid out in the post, and I don't know if we're gonna have time to unpack all six of them here. But, uh, we'll start from the top and, and we'll see, uh, we'll see how this goes.

[00:09:52] The, the first one was this, like, golden path to Cursor. I'm a huge fan of Cursor myself. It's like my code editor of [00:10:00] choice. It's where I'm running Claude Code, my content pipeline for the podcast in. Uh, I, I'm guessing that at least like for GTM teams, Cursor is kinda like the AI coding environment being used as the work surface.

[00:10:12] Um, do I have that right? Like getting kinda set up so you, like, you have like centrally built frameworks with setup instructions so people aren't like starting from scratch essentially. So I'm assuming this is like a shared operating model, like templates, preset environments with rules, approved configs.

[00:10:28] Maybe talk about that a little bit. Like you mentioned setup guidance for key MCPs like Zapier and, and, and Databricks. Can you walk us through that?

[00:10:35] Lindsay: Yeah. Yeah, totally. Uh, so Cursor is my tool of choice as well. Um, I find it to be extremely powerful. Sometimes though, I feel like, you know, I'm not a technical, um, person. I am, I'm, l- you know, the first time I logged in, I was like, "Terminal, open terminal. What is that?" So, so it's definitely like, uh, it, it was a bit of a learning curve, um, for me.

[00:10:57] Um, I have much more technical folks on the [00:11:00] RevOps team at the time, so that was helpful. Um, but yeah. So at Zapier, we've got access to agent... several agent harnesses that we can, um, sort of decide based on preference. So a lot of folks are primarily using Cowork. Um, some folks are, like, living and breathing in Cursor or Claude Code.

[00:11:19] So it's, we leave that up to the end user. But what we did do is we, uh, formed an AI center of excellence. So that AI center of excellence is led by a chief AI officer, um, within our company. So he, um, sort of heads up that, that central unit, and it's actually a small team. Um, I think it's actually just a f- a few people that are, like, dedicated to this.

[00:11:42] And really what they do is they set up, um, the resources and the frameworks and the guidelines and the enablement. And I am a part of that AI center of excellence as, like, a guild member dedicated to go-to-market. So [00:12:00] I'm sort-- It's like a hub-and-spoke model. Um, there's the central team, and then I'm sort of the spoke out to go-to-market, and I have another person who works with me, um- on that within go-to-market as well.

[00:12:11] So the two of us work on, like, making sure that those things translate into go-to-market, making sure that we're sort of boots on the ground about how people are building and what they need in go-to-market, and, like, being that feedback loop back. But one of the awesome things that this, uh, center of excellence stood up out of the go was a golden path to Cursor.

[00:12:28] And, um, like you said, it was-- You hit the nail on the head. It's really step-by-step instructions for non-technical folks, um, in setting up their Cursor environment, as well as setting up the other big piece of this model, which is our sh- company shared brain. Um, so in, uh, Zapier, like, we have a lot of non-technical folks.

[00:12:51] They're not provisioned with, like, GitLab access or anything like that. So we built a shared brain in, um, Google Drive to start. Um, and that's sort [00:13:00] of evolved since then, but our initial version was a Google Drive, and it's very structured folders. So company d- you know, company level, uh, department level, team level, and working group level.

[00:13:13] Um, so we started by populating context from across the org into those, um, Google Drive folders. And, um, first, I will say converting, uh, the materials in those folders into markdown files. So, uh, that was sort of our first iteration of, like, building the shared brain. And so, um, I helped sort of facilitate that from the go-to-market side, but then the central, um, center of excellence built, like, the model for it and, uh, the Cursor setup with instructions how to connect Databricks MCP, how to connect Zapier MCP, all the rules and guidelines around safe use.

[00:13:50] Um, uh, our data team s- ingests that data so they can understand how people are using the tools if they're-- we wanna avoid anything risky. Um, so yeah, [00:14:00] centralized management, but then the hub and spoke where I'm sort of, like, on the ground in go-to-market, and then the shared brain being, like, a major part of building that initial, uh, rollout out.

[00:14:12] Darrell: And h-how long did that take, Lindsay, like s- like doing all of the setup and, you know, creating that shared brain? Because I find that that's actually the-- It's such an important step, but it's also kind of tedious.

[00:14:23] You know? Like when-- If you're in like Claude, for example, you have to like upload all the files, and you're kinda looking around, and you're not sure what it has access to and not.

[00:14:31] So like what-- Did it take like a few weeks or?

[00:14:34] Lindsay: Yeah, we operated and we called it a sprint. Um, it was a four-week sprint. Um, we had a lot of these... A lot of tools were in place, like Cursor, for example, for our product and engineering teams have been using this stuff for a while. So, um, it was really about, um, getting the whole company and non-technical users on board with how to do this stuff.

[00:14:58] Um, and like you [00:15:00] said, we really just started simple. Like, what are the-- what's the layer of context that I think I labeled it below as, like, slow-moving, changing context, like company strategy, um, our ideal customer profile, our definitions of leads, um, our basic playbooks. So it was really about converting things that we already had into just a really clear file structure that go-to-market could use.

[00:15:28] Phil: Nice. Lots of MD file conversions from, uh, like DOCX extensions

[00:15:34] or, or PPT files. Yeah. Uh, a lot of folks are probably going through that process right now. It's, it's tedious, but, like, I don't know. I, I, I find joy in, like, the old school model of, like, arranging things into folders because,

[00:15:46] like, Google Drive, like, the thing I have against it is, like, most people don't use folders in Google Drive.

[00:15:52] It's just,

[00:15:52] like, this big dumping ground of all your things, and all people can just, like, search to find the, the, the file they're looking for. And you can never [00:16:00] find the damn file I wanna

[00:16:01] find in Google Drive if it's not set up in folders. So, um, yeah, Claude Codes, like, actually forced me to, "All right, this is the folder I'm giving Claude access to, and I'm separating it by project.

[00:16:13] Every project has a README. Every project has a context file." And so just, like, from there, it's just, like, a forcing function to get you organized, which is, like, the, the dream of a rev ops and a marketing ops

[00:16:24] Lindsay: I know. Yeah, it was, like, oddly, like, fulfilling. Like, I was like, "Yes, playbooks are nestled under sales enablement, are nestled under," like, typical ops person. But yeah, it was, um, it was a good exercise, and like I said, like, we didn't try and boil the ocean. We didn't-- Not everything is in there yet. Like, we really just wanted to get a foundation that could give folks enough context to get value out of their agent harness.

[00:16:50] Phil: Yeah, makes sense. So the second thing that you'd mentioned in, uh, the, the components of your AI governance model, uh, at Zapier is the data [00:17:00] policies. So these are like safe use guidelines for customer data, deploying shared apps, and publishing views. And in this one, you kinda gave credit to your security team.

[00:17:09] Uh, you called them the, the data narcs, uh, for, for this one. Early in my career, like the security, the, um, IS teams, like they were kind of in the background, mostly disapproving tool requests and like saying like, "No, this is, uh, does- doesn't cross like SOC 2, and this doesn't have like PHI guidelines." Nowadays, I feel like they're central architects to the AI strategy, and, uh, RevOps teams have to be friends with, with a lot of those folks. Like customer data and how it's consumed by AI, how it's stored, how it might leak, i- is incredibly important in, in a lot of the work that we're doing. I feel like the best security partners I've, uh, been with, like are overloaded with AI request toolings across like different folks in the company, could easily just say no to a bunch of stuff.

[00:17:57] But the best ones are kinda like finding ways, [00:18:00] sometimes in partnership with the center of excellence, to define what AI safe is for certain tooling, like zero retention architecture, only accessing PII through proxy mask gateways. Can you talk about that a little bit? Like how, how do you work with the security team at Zapier?

[00:18:15] What's the separation of area of ownership with like the GTM innovation team versus like the, the security team?

[00:18:22] Lindsay: Yeah. Yeah. Yeah, the security team is very deeply embedded with the AI Center of Excellence, so they work really hand in hand in developing the policies. We also have an incredible data team at Zapier who's been building a really strong data foundation for several years to be able to support this. So, um, our data partners also, um, are embedded.

[00:18:44] We have data partners that are embedded in go-to-market and really understand the in and out-- ins and outs of, uh, our go-to-market, like, data architecture, what we need. So they were a really nice conduit in working with the data team, and they actually in part... Or sorry, with the [00:19:00] security team. They also, in partnership with the security team, developed our, uh, skill that reviews our skills for data and security compliance.

[00:19:09] So they built a skill that, um, folks reference when they want to push a skill, you know, to a shared state, um, that they worked in partnership with us to un-- really understand our use cases and what we're trying to do. Um, so yeah, I totally agree. It's really important, I think now to, for, uh, security and data to sort of change the way that they work with teams.

[00:19:37] Darrell: Nice. Yeah. And, um, I wanted to talk a little bit about visibility, you know, which is a huge part of AI enablement. And, uh,

[00:19:43] 2 — Why Visibility Has to Come Before Governance in AI Adoption
---

[00:19:43] Darrell: you've mentioned you have a shared Slack space at Zapier where people bos-- uh, post what they've built. And I know that this can quickly turn into a lot of noise. People feel like, "Oh, there's so many things people build.

[00:19:56] I'm, I'm behind." I felt that way personally. Um, and [00:20:00] it sounds like you've built an agent to filter those updates for you. How do you filter out, like, what is just a, you know, fun little side experiment versus something that you can actually use for the business and the COE has to pay attention to that?

[00:20:16] Lindsay: great question. Yeah, so I built a little, uh, Zapier agent that just, um, scans the different Slack channels where people share. And the other thing I did was, this is a little bit of a trick, but I said, "Everybody, share what you're building. It's really important for all of us to learn and build community and ideate."

[00:20:36] So you really do have to build that kind of culture because, um, otherwise I just couldn't keep track of stuff, so kind of trick people a little bit. But also it is great to celebrate, um, you know, all of the creative ideas. So yeah, I've created a shared Slack channel where most of the time people do post, which is our go-to-market AI transformation, um, channel in Slack, and so people will post there.

[00:20:59] There are [00:21:00] also folks just sharing within their teams, and so I have y- a little, my little agent, like, looking at team channels too where I know there are some creative folks. And so what it does is it sends me, um, every Monday a list of everything from the prior week, uh, that folks created or shared out.

[00:21:17] And sometimes they're just personal skills. They're just things that help them do, like, an aspect of their job. Um, but sometimes they're skills that are pretty repeatable. Like, we had someone in customer success, um, build a pretty incredible, like, account pulse skill that looked at, like, account risk and, like, what contacts have been dormant and where should he follow up, you know, next week based on his book of business.

[00:21:44] And so that's the skill that I'm like, "Oh, we need to pull this skill into, like, what we're thinking about in RevOps and see how can we embed this into the way that CS works, and how can we make this shareable, and how can we make sure that it's, um, [00:22:00] adopted across the team in a way that's meaningful." Um, so yeah, I get that digest every Monday, and I check a box.

[00:22:09] So I react basically, like, yes, no, yes, no, and if I react yes, it goes into my little, uh, database of skills that I can kind of keep tabs on, and that's how I'm approaching it today. I'm sure that will change in the future as new, like, tools and things, uh, surface, but that's helped me just understand what's going on and also figure out what to scale and what, um, could have even broader impact than it is with just, um, the silo of one person using it.

[00:22:40] Phil: Such a cool i-internal use

[00:22:42] case there, Lindsay. I, I, don't wanna take us on too far of a, a tangent here, but

[00:22:47] re- uh, like, Zapier is a fully distributed company, Right.

[00:22:51] Like, everyone is, is remote. And when I was at WordPress Automatic, we were also fully remote, uh, completely distributed. And one of the things I struggled with the [00:23:00] most is, like, figuring out what other teams are working on when it's distributed, and there's so many other teams that we had, like multi-products in the company, and it was almost like a half, half of your time was spent distilling information from other teams to see what they're working on.

[00:23:15] Like, if they need help with this and with that, and just reading updates from other team, because when you're async and fully remote, everyone is writings updates and writing stuff. And so now there's so many use cases for agents to, like, start your day, "Hey, I've read all of these updates from all these teams.

[00:23:32] This is the most important stuff for RevOps and GTM innovation." Um, my brain is going crazy on, like, all the use cases for, distributed teams that are so deeply ingrained in, like, written async culture. Um, do you have, like, use cases for, for that too?

[00:23:47] Lindsay: 100%. Yeah, no, that's, uh, really glad that you mentioned that, 'cause I do think like, yeah, Zapier's culture is very much that distributed, default to action, solve [00:24:00] problems. Um, but it can be a lot of information out there, and so how do you sort through, like, what's most important, what's relevant? Um, but that's when the context about who you are, your role, and what you need is important for an agent to have, and it can start to sort of like parse through that for you.

[00:24:14] So I love that use case of like, um, I have one that's just like gathering, um, at the end of the week, like all of, you know, the times the certain topic was mentioned that I wanna kinda keep tabs on. Um, so keeping a pulse on things is a good use case for agents for sure, especially in that kind of environment.

[00:24:35] But I think it leads me to like, we'll talk about this a little bit later, but like the context layer and like how you can actually start to build toward a context layer that updates itself and keeps, um, the things that are most relevant, most relevant for agents in the future. Um, and so yeah, that's something I'm actively thinking about too.

[00:24:58] Sponsor: GrowthBench
---

[00:24:58] ​

[00:25:58] Sponsor: GrowthLoop
---

[00:25:58] ​

[00:27:01] Darrell: You've also mentioned that for the GTM org, you've been hosting office hours where people can demo AI tools and skills to spread adoption and inspire usage. Um, can you share some cool examples that you've featured and, uh, anything that you can share?

[00:27:17] Lindsay: Yeah, definitely. So it's so funny how this has sort of evolved. So our RevOps team used to do enablement in a different way. Like, here's how to... Like, if you wanna build your own automation on Zapier, um, we can help show you how to do that, 'cause we're sort of the experts of automation, like even internally, because we're using it so heavily.

[00:27:38] And now it's changed where we're actually, um Tapping other people to lead these types of sessions. So for example, we had a sales manager who built this really awesome skill, um, that reps can run, and it's, um, called How I Hit My Number. And it essentially takes, um, you know, all the [00:28:00] data about the leads and the deals that they're working currently, um, any risks, like, uh, the types of people involved in the deals, and it generates a strategy for them over the next, the, the length of the quarter, how am I gonna meet my number?

[00:28:14] Like, how should I be spending my time across these different deal sets? So that's something that maybe we would've enabled reps on how to do in the CRM, like previously, and now, um, we actually had this sales manager run through his skill, run through how he used it, how he recommends reps use it. Um, and so it's sort of changing the dynamic where, like, we're becoming more of, like, enablers and, like, guardrails and, like, setting the systems and the infrastructure, but letting people who are really close to the problems figure out how to solve them.

[00:28:48] Another example, um, I might highlight, uh, we have someone who built a competitive watchtower skill, so it kinda keeps an eye on, like, all of our confed- [00:29:00] competitors in the space. Like, what are they talking about on social media? Like, are they making ch- changes to their go-to-market strategies, their, their products that we should know about?

[00:29:09] And so, um, that's a skill that he built and is applicable across other folks in go-to-market who might want access to it. So he led that session and how to use it, how he applies it, and then that in turn builds more creators, more develop- more, more people developing off of those ideas, um, which has been really exciting, but can also be scary for ops people who are, like, trying to figure out, like, how to manage all of it.

[00:29:34] Like, do we let it ride? Like, do we try and help people perfect these skills? And we're sort of figuring out what that looks like, but this is what's working for us right now.

[00:29:44] Phil: Yeah, super cool examples there. I'm glad we, we detoured into, to some of those.

[00:29:48] 3 — How Zapier Fights Context Rot in Its AI Shared Brain
---

[00:29:48] Phil: But I wanna take us back to the shared brain, the, the context layer that is self-learning that you, you kinda teased out there, 'cause it is one of the, the components that you mentioned for, uh, the AI governance. Like, I-- we've had a lot of conversations on the podcast about context engineering.

[00:30:04] It's like the, the word of 2026, right? And y- you mentioned that each foundational team maintains their own context layer, uh, in, in revenue teams. It's like playbooks, enablements, data dictionaries, and you use all consistent folder structure that agents can read more easily. Um, there's like a solid chunk of work that a lot of teams are going through right now.

[00:30:27] We talked about this start of the show, like converting existing docs into .md files. Uh, it- it's one thing to kinda build an initial context layer for an agent, but it's also another thing to keep it alive and, and updated. Um, so tease that out for us. Like, how do you guys tackle context rot, uh, the whole structure behind this?

[00:30:46] You said the context layer that's con- like learning by itself. Unpack that for us.

[00:30:51] Lindsay: Yeah. So you have to keep in mind, like, the context of Zapier too. So Zapier has tools to be able to connect, uh, to [00:31:00]

[00:31:00] your tools. So, um, Zapier is actively working on and thinking through how we bring context from all of our tools into that context layer that is naturally staying up to date. Um, so that's really exciting, um, and one thing that I'm just, like, very, uh, excitedly awaiting.

[00:31:19] Um, but in the meantime, other things that we're doing, um, internally in go-to-market to keep context fresh. Um, so like I said, we have the clear owners of the different layers of context, um, personal, team, departmental. And then the way I think about it is there's, like, the slow layer of context of l- like, the things I mentioned earlier about that don't change.

[00:31:40] So your company strategy, your ideal customer profile, um, your data definitions and things like that. So we put a lot of time, I will just say, side note, we put a lot of time into context around the data definitions. I'd say that is, like, such an important place to start. We had our RevOps person, [00:32:00] um, who works specifically on analytics really go through and build a lot of context into lead definitions, opportunity definitions.

[00:32:08] If someone asks for a lead report, make sure you're asking them, are they asking for an MQL report? Are they asking for, you know, something else? So I will side note that, um, very important to start there. Um, but then the other layer of context that I think folks are still really figuring out how to utilize in the best way is- Just all the day-to-day conversations, like we were mentioning before, that happen.

[00:32:34] So ideas, experiments that have launched, um, changes to lead routing or changes to territories or, you know, anything that's sort of happening day to day in the organization. If you can figure out how to harness that, then you can have agents become very powerful because they can connect the dots from the data layer to why.

[00:32:59] Um, [00:33:00] and so that context often is living in humans' brains or in conversations or in meetings. So what we're doing about that is starting to be really, um, particular about documenting, um, sharing decisions, like at the end of a Slack thread, closing it out, like, "Here's what was decided." At an end of a meeting, making it really clear what decisions were made and which were not.

[00:33:24] Like, my partner is sort of in a similar field, and we joke like, "Are you gonna have to start saying at the end of meetings, like, 'Let the record show that...'" You know? Like, in a way that an agent can understand, because we are seeing them get better and better at sort of sussing out, um, things that happen, but it's not perfect yet.

[00:33:44] And so do you wanna rely on that for updating your full context layer? Maybe not necessarily just yet. Um, so we're taking stepping stones, and the thing that I'm thinking about is, like, those decisions, documenting, putting things in public. [00:34:00] Um, an idea that I have, um, that I think we're gonna try out with a small team and go to market at Zapier is having, um, an agent that actually collects all that context from, like, Slack, um, from meeting notes, and puts it into a decision log at the end of the week.

[00:34:15] So we can see, like, here are all the decisions that were made or things that were discussed, and I would call that, like, um, you know, a first step. And then having a human be able to review that and say, like, "Okay, this is an update we wanna make. This is not," and having agents then update the context layers.

[00:34:32] Um, that's a way I'm thinking about it. Another thing I'm thinking about is how you potentially tier different levels of context. So for example, um, you're gonna want an agent to know that if you make a pricing change, that's a really big deal. Whereas if someone has a random idea about an experiment they wanna run, maybe that's not weighted quite as equally in terms of, like, how we want agents to think about the context.

[00:34:54] So those are other things I'm thinking about is, like, creating some sort of, like, tiering system. Again, I'm a very [00:35:00] operational person, so I, I, I think in process and systems. Um, but we'll see. Like, there are so many new tools coming out, and, like, agents are getting better and better and better. Um, so it's definitely keeping all of us on our toes.

[00:35:13] Phil: record show or, uh,

[00:35:14] Darrell: Awesome.

[00:35:14] Phil: AI save to memory. Something like

[00:35:23] Darrell: that's like the... What's that called? Remember those in meetings, it's like the Robert's Rules order, like the... I don't know if you remember that. That's kind of what it reminds me

[00:35:32] of.

[00:35:32] Phil: Robert's

[00:35:33] Lindsay: No, you're gonna have to walk us through it.

[00:35:34] Darrell: It's like you have to say like, "I second this motion,"

[00:35:37] Phil: Oh,

[00:35:38] Darrell: yeah, I'll, I'll say, "I." So

[00:35:40] like, it

[00:35:40] can't do it until it's officially like that.

[00:35:42] Yeah.

[00:35:43] Lindsay: we would go back to that?

[00:35:45] Darrell: or

[00:35:45] something

[00:35:45] Phil: hear, hear.

[00:35:47] Darrell: Yeah, exactly. Yeah. Yeah, some meetings are still run like that, which is crazy.

[00:35:51] Lindsay: That's so funny.

[00:35:53] Darrell: Claude Skills? And, uh,

[00:35:55] 4 — How Zapier Governs Shared AI Skills from Review to Long-Term Ownership
---

[00:35:55] Darrell: I know there's been a lot of hype about Claude Skills. There's repos and directories of a bunch of skills. There's even directories of directories. So there's a lot about that. You've mentioned that any shared skill at Zapier has to go through a security and data review before landing in your internal use case library.

[00:36:12] Can you talk about that, uh, for us?

[00:36:15] Lindsay: Yeah, so we have a skill that reviews... We don't want any security risks. We're very, uh, particular about PII and customer data, of course, so, um, we don't wanna be, uh, using that readily in our skills. So, uh, reviewing for that, but then also, um, our review skill looks at the quality and how the skill is written as well.

[00:36:35] Um, and it sort of flags anything there. And what it does is it, 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. So it's a pretty simple process. Um, but it is a standard review skill that runs through all of these different things.

[00:36:56] Um, and then the thing that we're looking for at like the [00:37:00] team or department level when we're sharing skills is also, is it a, a valuable use case? Like is it, um, like from a RevOps perspective, just, um, referencing the right context, honestly, about like how we do things and how we want people to work. So that's another element.

[00:37:17] Darrell: Love that. You've also mentioned that skills are spreading across the teams now. How are you, uh, tackling building the mechanisms for wider distribution and long-term ownership? And, uh, how you, how you think about things like maintenance? Like, for example, does the skill library need to be managed like a product catalog with owners, version

[00:37:36] history, et cetera? Um, how do you think about all

[00:37:39] that?

[00:37:40] Lindsay: question. It's something we're actively figuring out. But yes, the first step for us has been to, um, ensure that skills are owned, so they have to have an owner. If it's shared across a team, there is an owner responsible for that skill. In many cases right now, skills are owned by RevOps.

[00:37:56] Um, that's, uh, makes sense for us in how we [00:38:00] work in many cases, especially if it's, like, across, you know, more go-to-market operations in terms of, like, flagging deal risks. There's a skill for that. Um, there's skills for handoffs from, like, solutions architects to the post-sale team, um, things like that. So we wanna, uh, be able to maintain those, like, products, um, when they're shared across teams.

[00:38:22] Um, another idea that we've had is creating some sort of embed program where, um, if somebody wants to build a skill, but it really touches go-to-market operations, like for example, handoffs, I think is a great example of that, um, that they can sort of like pair up or embed with a RevOps partner just to make sure that, like, we're building it in a way that is repeatable across many members of the team and not just for their specific need or what's coming up for them.

[00:38:52] Um, and so that allows us the ability to give people, like I said, closest to the problems, the opportunity to truly solve [00:39:00] them. It also shifts the role of RevOps a little bit, um, into more of that, like, orchestrator, enabler, um, overseer, um, and I think ultimately helps us be more strategic, um, because we're not necessarily always in the weeds of building these things, but we really have partners, um, who can partner with us to make sure they're the highest quality that they co- possibly could be.

[00:39:26] Phil: Yeah, such a cool point, the,

[00:39:27] 5 — What Happens to RevOps When Everyone Around Them Can Build
---

[00:39:27] Phil: the future of the revenue ops orchestrator. I actually had a question for you on that. Like, the, the rev ops person who is excellent at their job, like Deep domain knowledge, strong analytical skills, maybe doesn't have the coding background. Uh, what's your honest read on, like, where they fit in a world where people they support can now build their own tools?

[00:39:53] Like, we kinda talked about this a little bit. Everyone is becoming a marketing or a revenue engineer.

[00:39:58] What, what are

[00:39:58] your thoughts there on, like, the [00:40:00] future of RevOps orchestration?

[00:40:02] Lindsay: Yeah, it's really interesting. It like- I don't know. I'm, I-- My point of view on this changes literally every day. But the way, the way that I'm thinking about it now is... A- and I'm thinking of it in context or, like, as within my own organization, like what I've actively seen. Like, I gave the example of the analytics team, um, within RevOps at Zapier today.

[00:40:26] Like, they, uh, are responsible for the de- the definitions of, like, stages and data and, like, how we call that information. Um, they're now responsible for making sure that agents understand all of those points and information to be able to enable agents to surface up the right data in the right context.

[00:40:50] Um, but then the other thing that they're also responsible for doing is helping people apply those insights in a way that's really [00:41:00] meaningful for the full business. So, like, if somebody notices a campaign is really struggling or, like, a deal pipeline looks off, um, then that role of that RevOps person is probably not necessarily, like, 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?"

[00:41:25] Like, uh, they actually can become the conduit to the decisions in terms of, like, what we build and, uh, where we focus and where the ICP should change based on that information, for example. So I think it is an opportunity, um, for folks in RevOps to level up, um, and repurpose a lot of their skills around alignment, around, like, tying the how work happens to what to do about it, aspects of it.

[00:41:54] So yeah, I think it's a, an interesting time. I think a lot's changing. Um, but I think [00:42:00] having the context of how to build and process and, like, what it means to define a process and edge cases and nuances is highly valuable in this regard, too, even if you're not necessarily the builder.

[00:42:14] Darrell: Got it. Got it. And I wanted to ask you about, uh, this question where, you know, most tools, like pretty much all SaaS platforms are AI-enabled now, right? Marketing automation platforms are AI-enabled, data tools are AI-enabled. How does that work with the AI center of excellence? You know, it... And how do you balance that? Um, because, you know, obviously you're probably ha- you probably have your eyes on the AI-specific tools, but what about those other tools? Like, are they, um, sort of governed by like rev ops or marketing

[00:42:51] ops? How do you blend those two together?

[00:42:54] Lindsay: Yeah. So the tools that are solely go-to-market [00:43:00] specific tools or even point solutions within the go-to-market stack are still owned and managed by our RevOps technical, um, tool owners. So those tool owners work with security and data directly on getting approval for AI functionality within the tools, and that ownership has not shifted, um, to our AI center of excellence.

[00:43:26] The AI center of excellence is really at, like, a, an organizational level. Um, but yeah, we've maintained the ownership of go-to-market tools within, um, go-to-market.

[00:43:39] Phil: Yeah, that ma- that makes sense. I

[00:43:41] feel like it's, it's tricky too, right? Like, you don't wanna like slow things down too much, but the

[00:43:48] separation line between what is an AI tool, what is a GTM tool? Now tools are

[00:43:53] Lindsay: It is

[00:43:54] Phil: headless. Is it all data? Is, is all data AI? Like, like who

[00:43:58] knows? And the definitions [00:44:00] are all kind of fluid there, and it's about how do you balance the rigor and like the data governance

[00:44:06] piece by still enabling teams to go fast and and scale and, and, and still have fun and not be like boxed into all of these rules all at the same time.

[00:44:17] Lindsay: landscape's changing, so who knows?

[00:44:20] Phil: Right. Yeah, like I, I wanna do a fun post with, uh, Scott Brinker's new, like a super

[00:44:27] massive infographic chart about like comparing the number of tools in 2026 that have AI in their H1 versus in 2016. And

[00:44:38] it goes from like blank to literally every single one of

[00:44:41] them has AI at some point in the H1. Uh, maybe a fun post there for, for you, Daryl.

[00:44:47] But couple last questions for you, Lindsay. I did wanna like ask you about the, the new role. Like we started the conversation making fun of or like pointing fun at a company that was claiming to have created

[00:44:58] a job

[00:44:58] title last month, even though [00:45:00] it's kind of existed for almost 70 years now. Your new title is actually new.

[00:45:05] 6 — The Director of GTM Innovation Role and the Sharing Problem Nobody Has Solved
Timestamp: ~00:39:
---

[00:45:05] Phil: Like their earliest usage I was able to find for it was like mid-2025. Um, you ran a RevOps team for like couple of years now and had like 12 people

[00:45:16] on the team. Now you don't. You don't have those 12 people anymore. What did you actually give up to take on this new roles? And curious to ask you, like two years from now, what does failure in the director of GTM innovation role actually look like?

[00:45:31] Lindsay: Yeah, you're giving me anxiety. Um, no. Uh, yeah, so I was the RevOps leader at Zapier for three and a half years, and prior to that I led marketing operations. Um, so then we sort of combined the two and stepped into that role. So that was a pretty formative, uh, experience for me, getting to, um, build and scale RevOps, um, across enablement, sales, [00:46:00] marketing, uh, CS, and that's really honestly the only reason I feel like I'm in this role that I am in now.

[00:46:06] So it's really credit to that experience of being in RevOps. RevOps is a broad function. I think people don't realize, like not only is it the tools, the systems, it's the analytics, compensation, deal desk, uh, marketing operations, lead management, also strategy alignment. Like it is broad. And so I feel like that just set me up so well for what's next.

[00:46:32] So in this new role, I'm responsible for go-to-market AI adoption internally, but also the other half of my role, which is really exciting, is I get to spend time with customers trying to figure that out for themselves as well. And so, um, I get to learn from what other people are doing and sort of have boots on the ground in terms of how they're applying Zapier and other tools to be able to achieve their AI transformation goals.[00:47:00]

[00:47:00] I was really-- It was hard for me to give up a team. Like I love leading folks. I think that experience was really helpful for me in figuring out how to lead a larger team and try and drive vision and accountability. Um, so that was a big change. But I think for me now, getting to focus on this problem space or like very exciting, um, change that's happening within tech today is like I, of course, like just wanna be in the center of that.

[00:47:32] I think failure would be if we Um, did it really just change the way that go-to-market works? Like, I think, um, you know, in the past we've embedded AI into how we work today, but I think, like, there's an underlying shift happening, and I think even the role, we talked about revenue operations changing, I think the role of marketing is changing, the role of sales is changing.

[00:47:56] Um, so really figuring out how to do that in a [00:48:00] way that, like, sets us up for sustainable revenue, and also is, like, people first and human first and, like, how do we make sure that humans are supported by agents in a way that, um, helps all of us grow and learn. So yeah, I'm excited about that.

[00:48:18] Darrell: That's awesome. I mean, I think you're in the perfect spot because, you know, a role that exposes you to AI and forces you to learn really quickly.

[00:48:26] You know, I think that, you know, folks doing maybe... Y- you know, it's not like a bad thing, but I think if you're really burdened with people management right now, um, it may slow your progress a little bit in like experimenting with these tools,

[00:48:39] you know,

[00:48:39] Lindsay: Yeah, for sure. I was in meetings a lot.

[00:48:43] And, and now I get to, like, think about these problems and, like, figure out what are the frameworks and talk to people, and so it's, it's really, really exciting for me.

[00:48:54] Darrell: That's awesome. Um, so with the AI governance model, so you've, you've, you've basically said that [00:49:00] it's still in progress, like it's still work in progress. What's part of the governance model right now that you know is broken but haven't gotten a chance to fix yet?

[00:49:10] Lindsay: Yeah, I think one of the things that's challenging right now in go-to-market is, um, for us, is building and sharing the output of what an agent generates. Um, so an example of this is I built this awesome skill that monitors a specific campaign that we were really excited about end to end. So it's looking at, like, all of the lead interactions, and then it's also looking at all the first calls with our reps, and it's, like, creating this, like, overarching view for me of, like, how that cam- campaign is performing, but not just a dashboard.

[00:49:45] It's, like, qualitative, you know, information. It's like, what are the reps hitting on that they should be or, you know. So that's really awesome. How do I host and share and keep that up to date and embed into the way [00:50:00] that the go-to-market team works every day? I think that's where we have a lot of room to improve.

[00:50:06] I now have a v0 of Vercel account, so I can host, um, a, productionalize a lot of the things that I am building. Um, but I think for go-to-market folks, um, who are maybe less technical, there's not a good way to sort of like collaborate. Um, and I worry that we're actually creating more silos. Um, so yeah, that's probably what's top of mind for me and what we're looking to solve, um, in the near future.

[00:50:35] Phil: Awesome. Lindsay, I feel like we could keep riffing on this, especially the, the shared brain that, that you're working on. I think your, your new role is super exciting and fun. Got some, some fun questions to, to finish us off today. Uh,

[00:50:47] 7 — What Keeps Lindsay Grounded in the Middle of All This Change
---

[00:50:47] Phil: you're obviously a RevOps leader, GTM innovation leader. You're also a mom and a wine plus cocktail expert. One question we ask everyone on the show is: how do you decide what deserves your energy at any given moment, and what's your personal system for staying aligned with what actually makes you happy?

[00:51:05] Lindsay: Yeah. So relationships are really important to me. Human connection is really important to me. I've always led that way, and I wanna continue to build that in the way that I work now. So I think it's, like, having a lot of conversations, like reaching out and talking people, to people one-to-one. Um, so continuing to do that.

[00:51:25] The other thing I, I... that has benefited me, uh, maybe it's my anxiety again talking, but, like, 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. Um, so in this new role as I'm transitioning, I'm still working through, like, what that looks like, um, in this new model, where in RevOps, I kind of knew, like, what I needed to focus on.

[00:51:52] Um, so just, like, just relentlessly looking for the opportunities and the areas where I can have, like, a, an outsized [00:52:00] impact.

[00:52:00] 8 — Lindsay on Getting Buy-In and What She's Reading
---

[00:52:00] Phil: What's your best tip, Lindsay, for helping people get internal buy-in for their crazy idea?

[00:52:08] Lindsay: Just do it. I, like, this is a, this is something I learned. Like, I have spent-- I have spun my wheels trying to convince people of things that we should be doing. Like, "Here's a document. I looked at all the data." Like, "Have you seen this?" Like, you know, influence is hard, um, especially as RevOps folks. Sometimes we have, um, we don't have the authority to make decisions in some cases.

[00:52:30] We're really, like, teeing up information and hoping people make decisions with that information, and we can guide them. But the thing that I've learned is, like, if you show people, um, 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, a, you know, a crappy first version of something to really, like, help people understand it, I would say just do it.

[00:52:55] Darrell: Love it. Another quick one. What's your favorite nonfiction book and what's your favorite [00:53:00] fiction book, and why?

[00:53:02] Lindsay: Okay. My favorite nonfiction, I don't know if this counts, but it's definitely the "Real Housewives" franchise. Um, I

[00:53:09] Darrell: wife watches that show.

[00:53:11] Lindsay: Yeah. So, um, you know, you get a real inside peek into these women's lives and worlds. I really recommend everybody check it out, um, if you haven't. Uh, and then, uh- Fiction, I love novels that are sort of like, um, I don't know what you'd call this genre, Phil, 'cause you and I were talking about this book, but it's like not necessarily like sci-fi, but just kind of like otherworldly.

[00:53:37] Uh, so Midnight Library by Matt Haig. It's a story about how you're in this library and you can, um, see different pieces of your life if you had made different decisions or taken a different path, and you can kinda see how those different versions of your life would've played out. Um, so I found that book to be like really exciting and quite the page-turner.[00:54:00]

[00:54:00] Phil: I... I... It- it's on my to-read list, and I actually had a hard time, like, figuring out what Like shelf to, to put that one on. Like,

[00:54:08] Lindsay: Yeah.

[00:54:10] Phil: philosophical inspirational fiction, but, like, fantasy/speculative fiction. But it's super cool. Yeah, like Daryl and I are both huge fans of anything with, like, uh, time travel or, like,

[00:54:23] space ideas. But I actually just, like, threw a comment in there 'cause I

[00:54:27] stumbled upon, like, a... My Instagram is just like a book talk, like just

[00:54:31] people recommending books, and, uh, I saw that the same author, Matt Haig, is, uh, releasing a new book, uh, in a couple of weeks in the

[00:54:42] same universe as, uh, Midnight Library. I think it's called Midnight Train. So it's still, like, you don't have to read them in order. It's in the same universe. But I feel like I gave you some recommendations

[00:54:54] based on that, but you maybe wanna check that one out first.

[00:54:57] Lindsay: That sounds great. Yes, I love those kinds of [00:55:00] stories.

[00:55:00] Phil: Awesome, Lindsay. This has been super fun. Really appreciate you coming on and, uh, yeah, helping us unpack one of, uh, uh, your, your posts that did super well on LinkedIn. Uh, I've been following you for a while on LinkedIn and,

[00:55:13] uh, appreciate all the insights you share from one of the leading companies, I think, in, like, RevOps and demystifying what the heck is going on with, like, contacts and automation in this space.

[00:55:23] So yeah, thanks for doing what you do, and thanks for coming on and, uh, sharing your time.

[00:55:28] Lindsay: Yeah, thank you so much. I'll keep doing that. Yeah, so much is changing, so gotta stay on top of it.

[00:55:34] Phil: No kidding. All right, thanks.