 |
Humans of MartechFuture-proofing the humans behind the tech. Author: Phil Gamache
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. Language: en Genres: Business, Careers, Marketing Contact email: Get it Feed URL: Get it iTunes ID: Get it Trailer: |
Listen Now...
223: Lindsay Rothlisberger: How Zapier uses a shared brain to manage AI context and skills
Tuesday, 9 June, 2026
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 RothlisbergerLindsay 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 FoundationMost 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 BrainThe 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 ...
