Humans of Martech

What’s up folks, welcome to our 4 part series of Crawling through the dungeon of martech architecture. You’ve arrived at Part 2: The Eye of Context.We cover:(00:00) - Intro (00:56) - In This Episode (01:28) - Sponsor GrowthLoop (02:32) - Sponsor: GrowthBench (03:32) - Welcome Back (04:09) - FLOOR 2: THE EYE OF CONTEXT (06:15) - Why AI Produces Believable Nonsense (09:00) - BOSS BATTLE: The Hallucination Oracle (10:07) - Data Quality: When Agents Read Your Messy Data (22:33) - Context Engineering: What It Is and Why It's Not the Same as Prompt Engineering (24:28) - Sponsor: MoEngage (25:25) - Sponsor: Knak (26:30) - Context Eng vs Prompt Eng (38:58) - Why the Industry Built the Wrong Semantic Layer in 2012 (46:33) - How Context Rot and Fragmentation Break AI Agent Performance (49:59) - BOSS BATTLE: Rotten Context Mage (50:37) - How to Build a Shared Context Layer for AI Agents (58:17) - Testing Whether Your Context Layer Works (01:01:35) - NEW ACHIEVEMENT: The Meaning Layer Is Live ---------------------------------------------------------------------------OPENING---------------------------------------------------------------------------Welcome back to the Dungeon of Martech Architecture.You’ve arrived at part 2. If this is your starting point, check out part 1 where we cleared the first floor’s boss in 2 forms: The False Truth King in the CRM, and The Export Hydra that spread it everywhere. That said, if you already have a data warehouse, you might be able to start right here.Episode 1: CRM GravityWe conquered the source of truth and discovered that the data warehouse replaces the CRM with portable audiences.Episode 2: The Eye of ContextToday, we learn why AI fails without shared meaning, build the context engineering layer, and dig into why the industry built the wrong kind of meaning infrastructure in 2012.Episode 3: The Correlation MasqueradeNext, we escape the correlation trap and build the causal memory layer that separates agents that optimize correctly from agents that confidently scale the wrong behavior.Episode 4: The Dispatch TowerThen, we tackle the governance chaos of 30 vendors all claiming authority, and confront the interface decision that most organizations already made without realizing it.Let’s start our descent.---------------------------------------------------------------------------FLOOR 2: THE EYE OF CONTEXT — AI Hallucinations, Data Quality, and Context Engineering---------------------------------------------------------------------------The layout of the second floor down the dungeon of martech architecture actually looks pretty fancy. It’s cozy, it looks modern, the whole palace is lined with mirrors. But it’s a bit creepy because once you look a little closer at the reflections, you notice that some of the details are off. The boss on this floor is low key danger that sneaks up on way too many teams – not like the big flashy monsters from the past 2 floors.Let’s say you have a new AI system running on your marketing data. You’ve got it producing stuff like scores, recommendations, campaign ideas. Initially, it actually looks solid.There’s no obvious AI sentence structures in the summaries, they read well.The scores next to accounts seem to make sense: higher ones next to well known brands and lower ones are gmail accounts.The campaign ideas are actually pretty fresh, you can tell that it’s tailored for your ICP.Every output is delivered with impeccable confidence.So the next step is asking yourself… how would you know if it was wrong?There’s a lot of obvious hallucinations that you probably catch when you chat with GPT or Claude, like totally inventing stuff. I’m talking about the details. The kind of wrong that passes the first glance. We’ve all seen that viral post on r/analytics about a company that found out AI has been making up analytics data for 3 months. Whether this post is from a real story or not, some versions of this are happening inside companies today. But this is happening everywhere right now. Even at some of the top AI companies on the planet. I’ve talked to technical marketing leaders that have greenlit agentic tools at their startups before the data definitions were settled. One of them called it ‘believable nonsense’, and that term kinda stuck with me. It’s the most dangerous form of hallucination, it sneaks up on you.This floor is harder than the last because the traps on the previous level were visible, once you knew what to look for: CRM exports nobody trusted, audience logic duplicated across platforms, copies drifting from the original. You felt that, you saw that. This floor’s failures are designed to look like success, until you dig into the details and look under the hood.Let’s look at the origins of The Hallucination Oracle boss. Why AI Produces Believable NonsenseHumans are wired to trust smooth, confident talkers. It’s actually baked into our evolution and how our brains develop from infancy. Studies on babies and brain scans show this is an innate thing that kicks in early.A person who sounds certain usually knows something, right?LLMs and AI systems break this calibration, they produce fluency without necessarily producing correctness. At first glance, the output sounds right for structural reasons, not evidential ones. And once something sounds right, we engage with it differently. We forward it. We build on it. We present it to stakeholders who don't have the context to question it.This is similar to the The False Truth King boss from the first floor in episode 1, but this is at the intelligence layer: output that has been processed, synthesized, and returned with all the structural markers of a trustworthy answer, but the problem is the reasoning underneath it is hollow.That’s Jason Dobbs, Head of Marketing & GTM Engineering at Kumo. He greenlit agentic analytics and predictive workflows at his startup before the team had settled on shared data definitions. The system produced outputs that looked reasonable right up until someone started asking follow-up questions:JASON DOBBS, Kumo AI"What made it dangerous wasn't really like the obvious hallucination. What we were seeing looked polished enough to be operational. At first glance the scores looked precise, the summary sounded coherent, the recommendations felt data-backed. But the moment you ask the simple follow-up questions -- why did you choose this account? What data drove this decision? -- the logic started to thin out. The lesson wasn't that the data was bad or the warehouse was bad or the model was bad. What was wrong is we were trying to automate ambiguity. We were asking AI to solve for confusion that we hadn't yet ourselves solved for internally. And once you do that, you enter the danger zone because the failure is essentially believable nonsense."This is some scary stuff right? When this believable nonsense gets trusted long enough to make it into a campaign, a decision, a board slide. Obvious hallucinations are easy to catch. Confident, polished, data-backed nonsense gets through more often than we think.The good news is that we already have a weapon perfect to slay this boss, we shaped it in the last episode: the data warehouse. It houses data. Data is how we defeat believable nonsense… but we need to enhance it.---------------------------------------------------------------------------BOSS BATTLE: The Hallucination Oracle----------------------------------------...

What's up everyone, today we have the pleasure of sitting down with Keith Jones, Head of GTM Systems at OpenAI.Summary: Keith's GTM systems team at OpenAI got split across 2 orgs, ran into the most wildly practical cost center problem imaginable, and ended up proving exactly why distributed systems teams at high-velocity companies don't work. In this episode, he walks through the full restructuring journey, explains why "be close to the money" now means be close to the budget rather than the revenue motion, and breaks down Symphony and harness engineering — the open-source agentic code orchestration tools his team built to ship production-ready GTM changes without going to the nth degree of "write this Apex class." He also has a filter for separating human candidates from AI-generated applications that is simple, specific, and immediately usable. If you run a GTM systems team, build one, or just want to understand what operating at 10x growth actually requires, this one is worth your time.About Keith JonesKeith Jones is the Head of GTM Systems at OpenAI, where he leads the team responsible for the tools, platforms, and technical infrastructure behind the company's go-to-market motion. He began his career across sales ops and marketing ops roles before joining Mural, where he built and led the GTM Systems function. He later served as Senior Director and Analyst at Gartner, covering revenue technology, before moving to OpenAI. Keith joins this episode as a technologist and practitioner; the views and opinions he expresses are his own and do not represent OpenAI.What Separates GTM Ops from GTM SystemsThe naming debate in martech ops has been running so long it's almost a genre. Marketing ops, revenue ops, GTM ops, GTM systems — the titles keep multiplying and nobody agrees on where one ends and the other begins. If you're in this function, you've had the conversation. In job interviews. In org design meetings. In budget justifications. It goes nowhere, and it keeps happening.Keith has a more useful framing. When he first came on the show, he drew a clean line. GTM ops handles process design, training, and the frontline support that keeps the humans in your GTM org running. GTM systems owns the tools, the technical infrastructure, the back-end work: Salesforce, integrations, scaling, the stack. That line still holds. But he's added something that makes it more useful than a job description.They're the ones in the room with every sales segment leader, every functional head, absorbing what the business actually needs and translating it into something buildable. Without that translation layer, a systems team is guessing. And guessing at OpenAI's pace doesn't go well.At OpenAI, both functions have kept evolving alongside the company. Denise Dresser came in as CRO with a complete vision for reshaping the go-to-market org. B2B marketing got folded in. The company launched ads. The org changed repeatedly and fast. Through all of it, the underlying logic held: GTM ops partners with the business, GTM systems delivers what that partnership requires.As for the labels, Keith's position is that they're the wrong thing to anchor on. At OpenAI, the specific titles of marketing ops or rev ops matter less than who owns the stakeholder work and who owns the technical delivery. The names on the teams are almost secondary. The friction comes from not having clarity on which team does which job and what flows between them. Most organizations that treat these two functions as interchangeable tend to find out why that's a problem the hard way.The clean requirements that GTM ops provides to GTM systems aren't a process nicety. They're what keeps a systems team from building the wrong thing at the wrong pace.Key takeaway: Draw a line in your own org between who owns stakeholder requirements and who owns technical delivery. If one person or team is carrying both, something is consistently slipping. Establish a regular meeting rhythm where GTM ops and GTM systems leaders hash through priorities together, and treat that handoff as seriously as any technical dependency.The Cost Center Problem That Reunited OpenAI's GTM Systems TeamOpenAI's GTM systems team didn't move under finance because someone had a grand theory about org design. They moved because of a cost center problem. And the cost center problem showed up in the most unglamorous way possible: headcount.The original case for moving was practical. Keith's team needed to accelerate a set of deep financial integrations — Salesforce data flowing into ERP systems, billing pipelines, downstream finance reporting. The work required close collaboration with the finance function. The initial plan was a wholesale move. What the org settled on instead was a compromise: split the team. Some engineers stayed under go-to-market. The rest moved into what OpenAI calls Enterprise Platform Technology (EPT), the org that reports to the CFO. On paper, the logic held. In practice, the friction started almost immediately.Two separate cost centers sharing an overlapping team create problems that don't announce themselves upfront. They surface sideways:2 separate budget owners with different priorities pulling the same engineers in different directions, Shared consulting firms split across orgs, with different teams allocating the same people to different workstreams, Tooling budgets that required negotiation across reporting lines rather than a single decision, Headcount competing directly against a new CRO's vision for building out the go-to-market orgThat last one is what forced the decision. Denise Dresser joined as CRO after budgets were already set, bringing a complete vision for reshaping the go-to-market org and the headcount requirements to execute it. Keith found himself competing against her priorities for resources from the same finite pool. Not by design. Just by the math of 2 leaders sharing one budget.The conversation was brief. Dresser knew Keith's team would keep supporting go-to-market regardless of which org they sat in. She knew she could hold him accountable. But she couldn't justify choosing between revenue-generating hires and systems resources from the same budget line when the answer was that obvious.The reunified structure looks different from what existed before. Keith now has a peer leading quote-to-cash and revenue-adjacent systems. Keith owns top-of-funnel data enrichment, pre- and post-sale workflow, and the support systems org. The org got flatter, the division of responsibility got cleaner, and the cost center competition disappeared.How GTM Systems and GTM Ops Stay Aligned After the SplitGTM ops stayed under the go-to-market umbrella when GTM systems moved to EPT. The obvious question: how do they stay connected? Keith's answer is a biweekly meeting he calls the most productive hour on his calendar. Six to seven people in the room from both sides of the new org boundary:Keith and his peer leading go-to-market systems, The manager running all of Enterprise Platform Technology, including people systems, supply chain, and revenue systems, The most senior leaders from growth, go-to-market ops, and rev opsNo prep deck. No pre-circulated agenda. Everyone spends 5 to 10 minutes writing down their top of minds — what's keeping them up at night, what's shifted, what needs cross-functional attention. Then the group talks through it. Where do the priorities overlap? Where are they diverging? Which teams need to be working together on something they're currently doing separately?It's not a status meeting. It's a priority alignment session with people who have the authority to act on what comes out of it.The distributed period was hard. It was also clarifying. The experience exposed exactly which parts o...

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

What's up everyone, today we have the pleasure of sitting down with Ashley Langford, Marketing Operations and RevOps Leader.Summary: Ashley Langford has every credential the MOps job search advice says you're supposed to have: 2 Marketo Champion designations, a decade of B2B SaaS experience across multiple industries, a strong community presence, and a track record of building functions from scratch. She's still getting auto-rejected within minutes and ghosted by companies she was genuinely excited about. In this episode, she breaks down what the MOps job search actually looks like in 2026 from the inside, including how she uses Claude to build an interview packet before every meeting, why she has a hard line against unpaid take-home projects, and how the director-level search carries friction points that most job search content ignores entirely. She also says something most practitioners won't say out loud: she realized she was performing confidence instead of having it. If you're in a search right now, or know someone who is, this one is worth your full attention.About Ashley LangfordAshley Langford is a Director of Marketing Operations and 2-time Marketo Champion who has built and led MOps functions from scratch across B2B SaaS companies including LastPass, Integrate, HackerRank, GreenSky, and Waystar. Her work spans fintech, insurance, biotech, and HR technology, with deep expertise in Marketo, Salesforce, 6sense, and Looker. Adobe's Marketo Champion program selects around 40 practitioners globally each year; Ashley has earned the designation twice, in 2020 and 2023, and is also a Marketo Revvie Award Finalist.What Nobody Warns You About When You Get Laid OffThe shame of a layoff hits in a specific, quiet way that almost nobody includes in the public job search conversation. It doesn't look like despair. It doesn't stop you from applying, updating the resume, or showing up to the networking calls. It just tilts you. You overexplain the layoff in interviews. You hedge when confidence is what the moment requires. You walk in grateful to be considered instead of knowing what you're worth.Ashley Langford is 4 months into a search that should, by any rational measure, be going better. She has 2 Marketo Champion designations, a decade of track record across multiple industries, and genuine community presence. Her time at LastPass ended in a layoff that was clearly business-driven following the company's public turbulence. None of that insulated her from the quiet voice that arrives anyway.She didn't recognize it immediately. It took a few conversations before she saw what was happening. "I was performing confidence instead of actually having it," she says. For someone whose professional identity is built on expertise and results, that admission is uncomfortable. But naming it is where you start. You can't correct what you haven't acknowledged.The market doesn't help. Ashley has the credentials, the community ties, and the network. She's done what the standard job search advice prescribes. She's still getting auto-rejected within minutes and ghosted by companies she was genuinely excited about. "I haven't been ghosted this much since I was on Tinder like 12 years ago," she says. "At least then I knew why."The honest accounting: being well-credentialed matters inside the MOps community, where a Marketo Champion designation opens doors with people who know what it means. Outside that community, there are plenty of doors where it doesn't register. And the external recruiter pipeline, which used to generate steady inbound interest for practitioners at her level, has gone almost completely quiet. That drought is a real signal about what's happening in this market. The job posting numbers don't capture it.The practitioners who move through a senior search with the most clarity tend to be the ones who name what they're carrying early. The public-facing posture, excited about what's next, lots of great conversations, is one layer. The private reality of a Wednesday afternoon is another. Closing that gap starts with honesty about the performance, not just the tactics.Key takeaway: Name the performance gap before your search does it for you. After your next interview, write down 1 moment where you hedged, over-explained, or undersold your work. Identify the specific claim you avoided making. Draft the version with a number attached, and practice saying it without softening it until it sounds like your default.Where the MOps Job Search Actually Happens in 2026The job search advice is consistent about channels. LinkedIn, niche job boards, the hidden market through direct outreach and community presence, networking as a KPI. The framework is reasonable. What's harder to find is how it actually plays out for a practitioner with a specific profile in a specific market.Ashley's day starts on LinkedIn. New postings first, then the feed, because hiring managers sometimes announce open roles informally before they list them. From there: VC-backed job boards, which surface companies building fast. She's tried the Ashby job board search technique and found listings that hadn't appeared anywhere else. Greenhouse, the ATS platform, now has a cross-company search function that most people haven't found yet.After all of it, where are actual responses coming from? LinkedIn. The hidden job market is real and worth working. It's also producing less than the visible one right now. Anyone spending most of their search trying to unlock doors not listed on job boards while ignoring the platform still generating replies is optimizing against their own results.On conversations as the primary KPI, Ashley's take is more nuanced than the standard advice. She's gotten jobs through her network before. The approach works. But it requires having the kind of network that actually moves for you: people who will pick up the phone and make a call, not just say they'll keep an eye out. "The ratio depends on your network that you've actually built, not the one that you wish you have," she says.There's a structural wrinkle for MOps practitioners specifically. MOps people tend to be industry-agnostic, which is part of what makes the role valuable. Ashley has worked in fintech, insurance, biotech, and HR tech. That breadth is an asset in the market. It's also why her first-degree connections aren't concentrated in any one industry or company cluster. The broader the career path, the more spread out the network, and the harder it is to find someone who happens to know someone at the specific company hiring right now.The conversations-versus-applications question resolves the same way for most people: you need both. The ratio just depends on what you've actually built, and being honest about which bucket your network falls into before committing to a strategy built around the other one.Key takeaway: For 2 weeks, track which channel produces each actual response, not each application sent. If LinkedIn is generating replies and Ashby isn't, redistribute your time accordingly. Add the Greenhouse cross-company search to your daily routine and check it alongside LinkedIn. Both tools are free and most people haven't found the second one.What Hiring Managers Actually Look For in a MOps ResumeMost job seekers are guessing at what the other side of the table actually looks for. The tactical advice is everywhere: tailor your resume, use keywords from the JD, follow up with the recruiter. What's far less available is the hiring manager's actual perspective from someone who's done both in the same search.Ashley has built MOps teams. She's reviewed application stacks. She knows exactly what she skims past and what makes her stop. Now she's running that same lens on her own materials, which is a sharper fe...

What's up everyone, today we have the pleasure of sitting down with Jason Dobbs, Head of Marketing and GTM Engineering at Kumo AI.(00:00) - Intro (01:24) - In This Episode (01:57) - Sponsor: MoEngage (02:54) - Sponsor: Knak (04:35) - How Undefined Data Definitions Make AI Confidently Wrong (08:18) - Why Context Engineering Replaces Prompt Engineering as the AI Bottleneck (12:59) - The Five Non-Negotiables for AI Readiness in Marketing Ops (15:42) - Why Marketing Ops Is the Context Architect in an AI-First GTM Stack (24:50) - Which Data Problems Block AI Deployment and Which You Can Ignore (28:29) - Sponsor: GrowthLoop (29:32) - Sponsor: AttributionApp (34:24) - What Goes Wrong When Agentic AI Optimizes Directly on Warehouse Correlations (42:02) - When to Ship AI Before Your Data Is Ready and When to Fix the Foundation First (48:23) - What GTM Engineering Actually Means When AI Automates the Middle (50:55) - How Jason Dobbs Decides What Deserves His Energy (53:08) - What Jason Is Reading: Intelligence History, Mind-Opening Nonfiction, and Dune Summary: Jason Dobbs spent 7 years assembling intelligence briefings for the President, and he says most AI failures in martech are the same problem he was solving in 2003: teams acting on context they never actually agreed on. In this episode, he breaks down the 5 non-negotiables of minimum viable readiness before you deploy any AI agent, explains why the marketing ops function is becoming more critical as AI takes over execution, and argues that unbounded AI autonomy creates more risk than warehouse data ever will. He also defends GTM engineering as a real discipline rather than a rebrand, and closes with a Dune analogy that lands better than it has any right to. If you think AI readiness is primarily a data engineering problem, this episode will change how you think about your team's role in it.About Jason DobbsJason Dobbs is the Head of Marketing and GTM Engineering at Kumo AI, where he leads go-to-market for KumoRFM, the world's first relational foundation model, which generates accurate, explainable predictions directly from warehouse data. Before Kumo, he served as Global Head of Revenue Marketing at Logitech, where ABM and advanced segmentation drove 40% of B2B sales revenue and 79% YoY ARR growth. He also co-founded Trypp, an autonomous UX research agent for continuous post-ship product monitoring, and has held marketing and analytics leadership roles at Seagate, HTC Vive, Apple, and Google.Jason spent 7 years as a United States Air Force intelligence officer, including work on the President's Daily Intelligence Briefing, an experience that shapes how he thinks about assembling trustworthy context for high-stakes decisions under uncertainty.How Undefined Data Definitions Make AI Confidently WrongEvery marketing ops team has heard the warning: AI is only as good as the data you feed it. You've nodded along. You've probably said it yourself. But the warning leaves out the most important detail, which is what the failure actually looks like when the model is running.Jason Dobbs knows what it looks like. He learned it from a crash. He rides high-speed F1 electric skateboards at 50 to 60 miles an hour, and he's fallen before. He can tell you he's never fallen the same way twice. When he greenlit agentic and predictive workflows at Kumo AI before the data architecture was ready, the failure followed the same logic: unexpected, and avoidable only in hindsight.The model returned results that looked operational. Scores came back precise. Summaries sounded coherent. Recommendations felt grounded. The failure was invisible to anyone who didn't already know what correct should look like.The weakness surfaced when someone pushed. Ask the follow-up question, why did you score this account, what data drove this decision, and the logic fell apart. The definitions feeding the model had never been agreed on across the business. Sales and marketing were not working from the same idea of what a qualified lead meant. The AI had scaled an unresolved internal argument into what looked like a confident answer.Jason traces the failure to a structural problem that predates any model decision. When a system cannot explain its own outputs, and when nobody in the room has standing to say what the correct answer should look like, you have built a very polished way to be wrong. That is dangerous precisely because it passes a surface inspection. People who were not close to the data trusted the output. Nobody pushed back.What he carried out of that experience was a reframe of what marketing ops actually produces. The shared definitions, the trusted data sources, the named owners, the workflow guardrails: that is the product. Every AI initiative sitting on top of unresolved questions about what the business means by its own terms will generate outputs that look credible right up until someone has to act on one. Speed to AI deployment and quality of AI output run in opposite directions for teams that skipped the definition work. The ceiling on any AI system is the clarity of what the business agreed it was optimizing for before anyone touched a model.Key takeaway: Run this diagnostic before signing off on any AI or analytics initiative: can a human reproduce the logic behind the output and explain who owns the decision that follows? If nobody can answer that cleanly, the system is automating an unresolved argument. Start by documenting shared definitions for your 5 most-used business terms (pipeline, qualified lead, active customer, opportunity, churn) and get explicit sign-off from sales, marketing, and ops before any model sees them.Why Context Engineering Replaces Prompt Engineering as the AI Bottleneck"Context engineering" is appearing in every AI strategy conversation right now. Scott Brinker devoted a report to it. Conferences are building entire tracks around it. The framing is right, but for most teams the phrase still points at a feeling rather than a concrete set of decisions.Jason Dobbs's version is more precise. "Fix the data" is the directive most teams have been living under for years, and the structural problem with it is that it makes the work sound like a single epic project with a clear endpoint, a Holy Grail that teams have been questing toward since before the first CRM went live. The warehouse always has gaps. The CRM always has problems. The right question is narrower: what minimum context and control does this specific workflow actually need to produce a trustworthy output?That reframe narrows the scope from an organization-wide data quality initiative to a workflow-specific requirements checklist. For any given AI decision, the context bundle has 6 components: the definitions the system is operating from, the data sources it has access to, the tools it can invoke, any memory it carries between sessions, the guardrails on what it can do autonomously, and the escalation path when confidence runs low. Those requirements are specific to each workflow. They're answered by asking exactly what this workflow needs, not by cleaning the warehouse in general.The shift from prompt engineering to context engineering reflects how the bottleneck has moved as the models matured. A prompt is the last instruction a model receives. Context is everything it's working with before that: the definitions, the data access, the scope of authority, the path back to a human when a decision exceeds what the system should make on its own. Teams tuning prompts while leaving the underlying context undefined are optimizing the most visible variable in the system while the one that actually governs quality sits untouc...

What's up everyone, today we have the pleasure of sitting down with Alex Halliday, Founder and CEO at AirOps.(00:00) - Intro (01:19) - In This Episode (01:54) - Sponsor: Attribution App (02:57) - Sponsor: GrowthLoop (04:19) - How AirOps Pivoted to AI Content Engineering (08:23) - The Real Definition of Content Engineering and Why It's Not About Publishing More (13:14) - What a Content Engineer Does That a Senior Content Marketer Does Not (27:31) - What It Actually Takes to Get AI Content Past a Human Editor (30:52) - Sponsor: Knak (32:00) - Sponsor: MoEngage (43:21) - Why Review Becomes the Bottleneck After You Automate Content Production (47:13) - Why Enterprise CMS Integration Is Harder Than the Content Quality Problem (51:07) - Why the Agent Runtime Is the Next Competitive Battleground for Content Teams (55:02) - What the Case Against Content Engineering Gets Wrong About the Role (58:08) - What a Content Engineering Team Looks Like in 3 Years (01:03:45) - How Alex Decides What Deserves His Energy Summary: Alex built AirOps to help teams access company data, then a conversation with Sam Altman and a cramped middle seat on a flight to Atlanta changed everything. In this episode, he breaks down what content engineering actually means — not just generating more AI content, but building the systems infrastructure to maintain quality, freshness, and brand accuracy across everything a company has ever put online. He makes the counterintuitive case that great content engineering puts more humans into the content process, and explains why 98% of AirOps's pilots convert to annual customers while most AI content pilots fail. If you think AI content is just a faster way to publish more, this episode will change how you think about it.About Alex HallidayAlex Halliday is the Founder and CEO of AirOps, where he leads the development of AI content engineering systems that help brands build visibility in AI search. Before founding AirOps in 2022, he served as Head of Product at MasterClass, where he was the company's first product hire and helped scale revenue 10x. As a Venture Partner at SparkLabs Global Accelerator, Alex has made early investments in OpenAI, Anthropic, Groq, and Discord.How AirOps Pivoted to AI Content EngineeringIn early 2022, the LLM moment hadn't happened yet. Not publicly. GPT-3 existed but was barely on anyone's radar in marketing. Most "AI for marketing" conversations were still about sentiment analysis tools and basic chatbots. The prevailing assumption was that software had rules, rules had limits, and those limits were the floor you designed around.Alex Halliday had an unusual vantage point. As a venture partner at SparkLabs Global Accelerator with early investments in OpenAI and Anthropic, he was closer to what was actually happening than almost anyone in his world. He still wasn't ready for what came next.It started with a conversation. He was in San Francisco with Sam Altman, something he made a habit of — whenever they crossed paths, Alex asked the same question: what's sparking your imagination these days? On this particular occasion, Altman's answer was different. The AI stuff was getting really good, he said. When Alex pushed for specifics, Altman told him they were getting close to AI that could read all your emails and tell you what to do for the week. It sounded completely insane.Alex filed it away. Then, a few weeks later, he was on a flight to Atlanta, sandwiched in the middle seat between 2 large men with nowhere to go and nothing else to do. He finally opened an OpenAI account and started building.That experience in a cramped middle seat sent AirOps in a new direction. The company had been founded to help non-technical employees access company data — a broad, useful product with no obvious north star. Knowing the paradigm was shifting and knowing what your company should actually do about it are different problems. Alex had to translate that conviction into a focus, which meant making a hard call. When a space is growing as fast as LLM applications were in 2022 and 2023, trying to be everything to everyone is a trap.The answer came from the data, not from a whiteboard. When the team looked at their heat map of usage, 1 cluster burned hotter than anything else: technical CMOs, leaders of 50 to 100 person marketing orgs, working nights and weekends inside AirOps building ambitious content systems. High-taste users with strong opinions and no patience for tools that couldn't meet their standard. The market was doing what markets do when they find something they want — it was insisting.By mid-2023, AirOps had committed fully. The customer was the high-taste marketing professional who wanted to build content systems at scale, not just generate more content. Every decision since has been built around that person. The most important pivots rarely happen in planning sessions. They happen when you actually use the thing, look at the data honestly, and trust what the market is telling you over the story you had planned to tell.Key takeaway: Look at your usage data and find the cluster of users who are working hardest and complaining most specifically — they are telling you who your product is actually for. Make time to try the tools reshaping your industry with your own hands. Alex's pivot started in a cramped middle seat he couldn't escape. Any open hour will do.The Real Definition of Content Engineering and Why It's Not About Publishing MoreMarketing teams have been chasing the wrong metric since LLMs went mainstream. The race defaulted to volume: how many posts, how fast, how much can you automate. That framing made sense in an era where more content meant more crawlable pages, more keywords, more surface area for Google to index. The era has changed.AI agents now sit between buyers and brands. When someone asks ChatGPT or Perplexity a question about your product category, an agent synthesizes content from across the web — your owned pages, third-party publications, Reddit threads, review platforms — and returns a single answer. That agent is not counting pages. It's evaluating quality, depth, freshness, and what Alex describes as information gain: the degree to which any given piece of content adds something new to what the model already knows.That's a meaningfully different standard. A 2022 blog post with outdated product language, stale statistics, and broken links doesn't rank lower in AI search — it's absent from it entirely. Webflow, 1 of AirOps's customers, saw what investing in content refresh workflows does to those outcomes: 42% more traffic and AI-attributed conversions performing 6x better than standard organic. That's a maintenance story, not a content production story.There's also a conflation doing a lot of damage in this conversation. Content written with AI assistance gets lumped together with content generated by AI with no original grounding or context. The studies that say "AI content performs poorly" tend to define AI content as the second category, and the conflation goes unexamined in most LinkedIn commentary. The distinction matters enormously. Content that draws on real interviews, proprietary data, internal expertise, and company-specific context performs differently from content that's a model recombining what already exists on the internet.The brands performing well in AI search right now are treating their content library as a living system with real quality standards — a garden that requires ongoing maintenance rather than a publishing archive. They're building workflows to keep content fresh, surface internal knowledge that's been sitting in Google Drive unused, and maintain what...

What's up everyone, today we have the pleasure of sitting down with Elizabeth Dobbs, AVP of Marketing Technology, Data and Growth at Databricks.(00:00) - Intro (01:18) - In This Episode (01:47) - Sponsor: Knak (02:55) - Sponsor: MoEngage (04:16) - Why Velocity Beats Permanence in Marketing Data Architecture (12:00) - Why Databricks Embedded Data Engineers Inside Marketing (15:02) - Inside Databricks' 3 Marketing Ops Agents (18:56) - How Databricks Built an AI Analyst That Marketing Teams Actually Trust (26:13) - How Agent Tagatha Cut Months of Manual Content Tagging to Hours (30:07) - Sponsor: AttributionApp (31:09) - Sponsor: GrowthLoop (34:48) - How Agent Atlas Replaced the Rules-Based Segmentation Wheel (39:28) - Why Marketers Don't Care Whether You Call It an Agent (43:32) - How to Get Data Warehouse Access When Your Team Doesn't Own It (48:36) - What Databricks Is Actually Testing for in Marketing Hires Now (54:04) - What Gives Liz Energy Outside the Office Summary: Elizabeth Dobbs spent 6 years at Databricks doing something most marketing leaders only talk about: building the data infrastructure before deploying the AI on top of it. She's shipped 3 production agents (Marge, Tagatha, and Atlas) and she'll tell you exactly what broke first and why the team kept going anyway. You'll hear how a marketing lakehouse becomes the foundation that makes every agent actually work, why the agent label debate is a distraction, and what Liz is genuinely testing for in marketing interviews now that AI-polished resumes all look the same in Greenhouse. If your AI ambitions are running ahead of your data foundation, this episode is going to reorder your roadmap.About Elizabeth DobbsElizabeth Dobbs is the AVP of Marketing Technology, Data and Growth at Databricks, where she leads the team responsible for the company's full marketing stack, including data engineers and data scientists embedded directly in marketing. Promoted to AVP in February 2025 after more than 5 years building Databricks' marketing data infrastructure from scratch, she architected the company's marketing lakehouse and deployed 3 production AI agents serving the entire marketing org. Before Databricks, she spent nearly 7 years at Khoros in a series of marketing operations and demand generation leadership roles, including Chief of Staff to the CMO.Why Velocity Beats Permanence in Marketing Data ArchitectureIf you work at a company called Databricks, you assume the marketing data is fine. The word "data" is literally in the name. When Elizabeth Dobbs was interviewing 6 years ago and someone in sales ops told her straight up that the data was a complete mess, she thought they were being politely humble. She took the job. She found out they meant it.What she encountered fit the startup playbook exactly. Agencies hired for agency's sake because headcount was thin. Systems that barely talked to each other. Stacks of what she calls "human middleware," people spending their days manually bridging gaps the infrastructure couldn't close. Databricks was probably no worse than any other high-growth startup at that scale. But fixing it meant accepting something most marketing teams resist: building for permanence is a waste of energy.When Liz and her team sat down to fix things, they made a call that runs against how most marketing orgs are wired. They stopped trying to build the perfect foundation. At 1,000 people, you might get away with it. At 10,000, perfection is a distraction. By the time you finish, the company has changed shape again. So they optimized for velocity. Centralized data imperfectly. Built shared definitions that not everyone followed consistently. Accepted the bubblegum-and-duct-tape reality. And they stayed intentional about exactly 1 thing: knowing which decisions you cannot walk back.The one-way door framework is how they sorted the rest. Some decisions hurt to make but compound over time. A marketing lakehouse, all first-party data in 1 governed and catalogued place, is the example she keeps returning to. There is no SaaS tool you would buy, no agent you would deploy, that wouldn't benefit from having that foundation underneath it. That makes it a no-regret decision even when it's brutal to build. The other category, the rip-and-replace bets, is where you move fast and hedge. Agents might automate an entire workflow in 18 months. They might not be ready. You place smaller bets there and iterate. What you don't do is apply the same level of commitment to decisions that actually shouldn't last.6 years later, the core of Databricks' marketing stack looks a lot like it did when Liz started. LeanData. Familiar prospecting tools. The same basic webinar infrastructure. The vendors who survived are the ones who grew alongside the team, who stayed flexible as Databricks scaled well past what their standard playbook assumed. In a market that treats every tool as disposable, the ones that last are the ones that earned it. The companies that build durable AI systems in marketing will be the ones who made the unsexy architectural call first and let everything else follow from it.Key takeaway: Before committing to any AI agent or new platform, split your roadmap into 2 categories: one-way doors and reversible bets. A centralized, governed marketing data layer goes in the one-way door category. Pour resources into it without condition and treat every setback as a speed bump. For everything else, including which agents you deploy and which tools you layer on top, move fast, hedge small, and iterate. Run that filter on your next planning cycle and you'll stop debating tools and start building the foundation that makes all of them actually work.Why Databricks Embedded Data Engineers Inside MarketingMarketing ops leaders who don't have embedded data engineers spend a lot of time explaining to others why they can't move faster. Liz's team has data engineers and data scientists who report into marketing, not into a central IT org. Most people assume she fought for it. The actual story is less dramatic and more instructive.It came from 2 leaders giving the team room before they could prove the full return. Her CMO Rick and CCIO Mike Hamilton were direct about it: we have our own fires, you know enough to be dangerous, you know where the lines are. File Jira tickets if you need something outside your lane, but otherwise go run. That kind of organizational trust is rare. What made it stick was showing the velocity difference on something concrete. Bring in 1 or 2 data engineers with actual marketing domain experience, and the speed gap becomes obvious. Marketing data has its own rules. MDF means different things to different teams. ROAS has regional variations. Pipeline attribution is a political minefield. Someone who has lived in that domain moves 10 times faster than someone learning it in place.That observation turns out to apply directly to the agents Liz's team built later. You spend months onboarding a new hire with marketing domain context. That person leaves before the investment fully pays off and you start over. Agents don't do that. You train them, you give them the context, they hold it. What Databricks figured out with internal resourcing, they've since encoded into how they think about deploying AI. The parallel is direct and Liz draws it explicitly: the reason domain knowledge matters for people is the same reason it matters when you're configuring an agent.The team that resulted from this structure is part of why Marge, Tagatha, and Atlas were even possible. You can't build a marketing lakehouse without engineers who understand what the data is supposed to represent. You can't deploy an agent ...

What's up everyone, today we have the pleasure of sitting down with Tata Maytesyan, Growth Consultant, Keynote Speaker, and AI Trainer.(00:00) - Intro (01:08) - In This Episode (01:46) - Sponsor: GrowthLoop (02:50) - Sponsor: Attribution App (04:34) - Which Marketing Tasks Are Actually Worth Automating (13:07) - Why Deep Generalists Outperform Channel Specialists in Marketing (26:07) - Sponsor: MoEngage (27:04) - Sponsor: Knak (35:06) - Why Marketing Org Charts Are Not Getting Flatter (43:01) - Why Change Management Determines Whether AI Adoption Actually Sticks (48:03) - The Fear of Automating Yourself Out of a Job (53:13) - The Voice Diary Technique for Tracking Your Own Energy at Work Summary: Tata Maytesyan runs an AI bootcamp for marketers on Maven and consults with scaling companies across Europe. In this episode, she breaks down why the best AI automation targets are the boring, repeatable tasks nobody talks about on LinkedIn, and why the specialist-to-generalist shift in marketing is already happening whether your org chart reflects it or not. She also gets direct about what's really going on inside companies claiming to go flat, the 100-hour threshold for building genuine competence across domains, and the self-preservation fear she hears from leaders every week. If you have ever wondered whether you are building your career around the right foundations, this episode is worth your full attention.About Tata MaytesyanTata Maytesyan is the founder and CEO of Grow Global Tech, where she builds AI-powered marketing systems for tech scale-ups and runs a hands-on AI bootcamp for marketers on Maven. She spent 15+ years leading growth inside Nike, Deloitte, and Picsart, including a stint as Head of Product Strategy and Operations for Picsart's content and AI division, a platform with over 100 million monthly active users. She has since advised more than 40 companies across 12 countries on go-to-market strategy and AI adoption, and consults primarily with CMOs and CEOs at companies between a few million and $200 million in annual revenue.Which Marketing Tasks Are Actually Worth AutomatingThe wrong starting point for AI adoption in marketing is inspiration. Most marketers scroll LinkedIn for jaw-dropping use cases: ad creative generated at scale, competitive analysis in 10 minutes, entire campaign briefs written by agents. It looks impressive. It's also almost never applicable to your specific job on any given Tuesday. Tata has spent years watching this pattern play out with consulting clients and bootcamp students. Her fix is deliberately boring.At the start of every engagement, she asks everyone in the room to close their AI tools. Then she opens Miro and maps how the team actually works. From there, 3 questions run against every process on the board: how often the task repeats, how acceptable an imperfect output would be, and whether it's something you actually enjoy doing.Those 3 questions quietly eliminate most of what people think they want to automate. Frequency kills off exciting-but-rare workflows not worth touching. Risk tolerance separates contexts where imperfect output is acceptable (most content tasks) from those where it isn't. Tata advises a healthcare client where certain work is patient-facing, and mistakes there carry real consequences. The enjoyment filter protects the parts of the job people actually like, because automating something you love is just spending money to make work less interesting.Her own example from the day this episode recorded: she built a script to pull LinkedIn post metrics (impressions, comments, likes) into Notion. Before that, an assistant handled it. Before that, she did it herself. She describes the task with open contempt, which makes it the perfect candidate: something done constantly, where imperfect output is acceptable, and which requires 0 joy to hand off. She calls it boring is sexy. "Figure out the workflow you do repeatedly, and then if mistakes are manageable and you're okay with them, delegate and automate with AI."People get frustrated when they hear this. You show up to a bootcamp or hire a consultant expecting to leave with something impressive. Instead someone hands you a whiteboard. But Tata is direct about the tradeoff: "It takes time and it slows you down, sort of feels like it slows you down. In fact, it speeds you up."The same logic applies to how people first explore AI tools. Pure tinkering has value: testing a new model, playing with a capability outside any work context. That's curiosity, and it's worth protecting. But when something needs to work reliably in your actual job, setup is non-negotiable: context files, folder structure, clear instructions. The AI can't fill in what you don't give it.The most durable AI workflows come from people who got honest about which parts of their week are boring, repetitive, and low-stakes. LinkedIn will give you inspiration. Your Miro board will give you your actual starting point.Key takeaway: Map your actual workflow before opening any AI tool. For each repeated task, ask whether mistakes are acceptable and whether you actually enjoy doing it. Frequent, low-risk, low-joy work is the right first target. Build from there.Why Deep Generalists Outperform Channel Specialists in MarketingThere's a running debate in marketing about whether to go deep in a specialty or build broad across domains. The specialist argument has genuine weight: if you've never actually run an SEO campaign, how do you know when an AI is confidently producing garbage? Tata sees the point. She also thinks the framing is wrong. Specialization built around channels is the vulnerability, and channels keep changing.Her term for what marketers should actually become is "deep generalist," a phrase she found on the internet and adopted because it captures something the T-shaped marketer framework mostly misses. A deep generalist has real expertise in at least 1 domain but deliberately builds breadth around it. The depth is still there. The difference is the deliberate horizontal stretch.She watches this compression play out in her bootcamp every cohort. At the start of cohort 6, a participant said her team of 4 had been cut to just her. As the remaining content writer, she was now responsible for everything: SEO, social, website, the whole thing. That's not a future prediction. It's already the operational reality for a large share of the marketing workforce, and the people who trained deep in a single channel with no adjacent experience are the ones struggling most.The channel argument is where Tata's case gets sharper. An "SEO specialist" built around Google search has a real problem now that AI Overviews are reshaping how search works. Nobody building a "TikTok specialist" career a few years ago expected it to become a top-performing B2B SaaS ad channel. But 1 VP of business development recently told Tata that's exactly what's happening at their company. Channels are fluid. Betting deep on any specific 1 locks you into an increasingly narrow position.Her own example: at Picsart, 1 division had no SEO function and no budget for an agency. Tata spent 2 months doing the SEO work herself, learning enough to direct AI through the process. When the business eventually hired an SEO agency, the agency was impressed by what was already in place. She had put in enough time to know what good SEO looked like and how to direct AI against that standard effectively.The underlying skill that makes all of this work is judgment. Generating an image is table stakes. Knowing whether it's good, whether it fits, whether an agent's output is trustworthy enough to use: those require domain awareness that a speciali...