Humans of Martech

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.

  1. 6d ago

    228: The Dispatch tower (The Dungeon of martech architecture, part 4)

    What’s up folks, welcome to our 4 part series of crawling through the dungeon of martech architecture. You’ve arrived at our final episode, part 4: The Dispatch Tower. We’ll tackle: (00:00) - Intro (00:59) - In This Episode (01:30) - Sponsor: Mammath Growth (02:33) - Sponsor: GrowthLoop (03:58) - FLOOR 4: THE DISPATCH TOWER (04:39) - What Happens When 30 Vendors Turn On AI at the Same Time (21:24) - Boss Battle: The Agent Avalanche (22:53) - Why You Need a Central Referee, With Agent Guardrails (26:48) - Sponsor: Knak (27:55) - Sponsor: MoEngage (28:52) - Privacy Compliance and Data Minimization (38:38) - The Dispatch Layer that Controls Routing Logic (44:00) - The Layer Above the Dispatch is the Interface (47:20) - What Production AI Agents Look Like on a Governed Data Foundation (50:27) - The Deterministic Layer: Why the Interface Can't Run on Guesses (53:09) - System Stewardship: The Role That Emerges When You Clear This Floor (59:33) - FINAL ACHIEVEMENT: The Dungeon Is Cleared ---------------------------------------------------------------------------OPENING---------------------------------------------------------------------------Welcome back to the Dungeon of Martech Architecture. You've arrived at the final floor. Parts 1 through 3 built the foundation, the meaning layer, and the causal memory. Part 4 is the floor most organizations have been living on the whole time, often without knowing it. 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 ContextWe learned why AI fails without context engineering and built the shared meaning infrastructure that keeps agents from misinterpreting what they read. Episode 3: The Correlation MasqueradeWe escaped the correlation trap and built the causal memory layer that separates agents that optimize correctly from agents that confidently scale the wrong behavior. Episode 4: The Dispatch TowerToday, 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 finish our descent. --- ---------------------------------------------------------------------------FLOOR 4: THE DISPATCH TOWER--------------------------------------------------------------------------- Congratulations martech crawler, you’ve arrived to the final floor of the dungeon. Let’s face it, most of your fellow crawlers will never make it this far. They’re still lost in political battles debating why the CRM shouldn't hold product activation data or they ended up falling prey to the correlation trap and I forever stuck in the boomerang room. But you’ve made it. You’re proudly wearing the 3 badges of honor on your jacket: data janitor, context king and causal brainiac. This floor is the hardest because it combines collaborative political battles but some serious technical obstacles as well. The layout of this floor is best described as a hot mess of agent spaghetti. Every vendor in your stack has an agent now. Your ESP has one. Your CDP has one. Your MAP has one. Your CRM has one. Your ad platform has one. Each one has separate logic, separate assumptions, separate permissions, and a roadmap slide that says “autonomous.” None of them knows what the others are doing. And nobody volunteered to referee this stuff. At the top of this floor, there is a door most organizations never noticed. Whoever controls that door controls what instructions get through, which systems can act, and which agent gets authority over the customer. What Happens When 30 Vendors Turn On AI at the Same Time Your inbox is probably already full of emails from every platform in your stack, all saying some version of “Turn on AI today.” Each one promises autonomous intelligence. Each one wants permission to write, recommend, segment, suppress, score, enrich, personalize, or trigger something. Each one is operating from its own model of the customer. None of them can explain what happens when two agents try to update the same record, message the same person, or optimize against conflicting goals. You are now the referee. Congratulations. Rich Waldron, CEO of Tray.ai, describes how this feels on the ground: RICH WALDRON, Episode 162"If you're the marketing ops leader and your 30 vendors are telling you to go turn on the AI for their application, you sort of become like an AI referee. You have to figure out, well, do I turn it on for this one and not for this one? And is this one gonna overwrite what occurs here? You feel it already. Your inbox floods with vendors begging you to 'just turn on our AI capability' -- 30 different platforms all promising transformation. Suddenly you're an unwilling AI referee asking impossible questions: which AI systems should I activate first? What happens when one AI's decisions contradict another's? Are all these systems feeding sensitive data into the same models?" "Agents backed by an iPaaS give you full governance and control of where execution happens. For teams drowning in vendor AI chaos, the third option -- iPaaS-backed agents that naturally integrate with everything -- provides centralized governance, unified control points, and consistent execution environments." Rich is describing the nightmare version of the final floor: every vendor ships an agent, and marketing ops gets stuck deciding which ones are safe, which ones are redundant, which ones are risky, and which ones quietly conflict with each other. The answer is not to let every team turn on whatever they want. It is also not to create a central AI police force that blocks everything until innovation dies in a committee. The middle path is an operating model: a small central group that sets standards, reviews risk, creates reusable patterns, and lets the business move quickly without turning the stack into a haunted appliance store Funny enough, I spoke with someone who actually did volunteer for that AI referee job – her title is a bit fancier though. Here’s Lindsay Rothlisberger, Director of GTM Innovation at Zapier and also a member of their AI Center of Excellence. At Zapier, she sits at the spoke of a hub-and-spoke AI Center of Excellence, a small central team led by a Chief AI Officer, with Lindsay as the GTM representative responsible for translating governance into go-to-market practice. Her work covers deciding which AI tools get activated, setting the standards for what a shared skill has to pass before it enters the internal library, and keeping track of what people are building before it fragments into 100 unsanctioned experiments. LINDSAY ROTHLISBERGER, Zapier"We have a skill that reviews our skills for data and security compliance. It gives you a red, yellow, green. 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. But it is a standard review skill that runs through all of these different things." Every shared skill at Zapier has to have a named owner. If it's used across a team, someone is accountable for maintaining it. Skills covering go-to-market operations are owned by RevOps. New builders who want to ship a skill that runs through a cross-functional workflow pair with a RevOps partner to build it. The governance operates as a co-authorship model, designed to make s...

    228: The Dispatch tower (The Dungeon of martech architecture, part 4)
  2. Jul 7

    227: The Correlation masquerade (The Dungeon of martech architecture, part 3)

    What’s up folks, welcome to our 4 part series of Crawling through the dungeon of martech architecture. You’ve arrived at Part 3: The Correlation Masquerade.We'll cover: (00:00) - Intro (01:16) - In This Episode (01:36) - Sponsor: Knak (02:44) - Sponsor: MoEngage (04:02) - FLOOR 3: THE CORRELATION MASQUERADE (05:08) - Why Agentic AI Optimizes for the Wrong Thing at Scale (11:30) - The Boomerang Effect on AI that Erodes Revenue (20:40) - Why Marketing Attribution Data Can’t Tell AI Agents What Actually Caused the Result (28:28) - Sponsor: Mammoth Growth (29:31) - Sponsor: GrowthLoop (33:56) - How Bad Signals Masquerade as Evidence (42:27) - BOSS BATTLE: The Correlation Boomerang Archer (43:27) - Reducing Exposure While the Foundation Is Built (49:07) - Building a Causal Memory Layer With a Context Graph (01:02:15) - Achievement unlocked: Causal Evidence Layer Established ---------------------------------------------------------------------------OPENING--------------------------------------------------------------------------- Welcome back to the Dungeon of Martech Architecture. You've arrived at part 3. If you're just joining, go back to parts 1 and 2, where we demoted the CRM, built the warehouse, engineered the context layer, and built the shared meaning infrastructure that keeps agents from misinterpreting what they read. 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 ContextWe learned why AI fails without context engineering, built the shared meaning infrastructure, and dug into why the industry built the wrong kind of meaning infrastructure in 2012. Episode 3: The Correlation MasqueradeToday, 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 TowerNext, 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 continue our descent. --- Okay so we’re making our way down to the third floor with blood sweat and tears. But we’re feeling good. Our data is clean-ish. You’ve built a context bundle that we’re proud of and we collaborated on it with multiple people and shared definitions. We’ve got a nice big fancy data warehouse as our source of truth. Our warehouse holds a complete record of what happened. We can query patterns, correlations, historical campaign data, audience behaviors, outcome signals: all of it is available.  But the problem we’re about to find out is that none of what we’ve built so far can tell an agent whether the thing it's optimizing for was ever the right thing to optimize for. None of it explains why an intervention worked, or whether it worked for the reason the model assumes it did. Let’s step through. ---------------------------------------------------------------------------FLOOR 3: THE CORRELATION MASQUERADE--------------------------------------------------------------------------- The layout of the correlation masquerade is like a high speed train to nowhere.  You’ve spent two whole floors meticulously cleaning the “atoms” of your historical customer data and building a sturdy warehouse so that you can let AI and agents loose on the data. Maybe you’re starting to play with ‘next best action sequences’, building propensity models predicting the likelihood that certain cohorts of users will churn, maybe running reinforcement learning loops on historical context and doubling down on your best campaigns.  Everything looks like it's working... until the world rumbles and you realize you're still in a trap. The layout of this floor is a room where every single action comes back wrong. And it’s not technically AI’s fault, they’re just optimizing for a finish line that’s actually just the end of the first heat of 8 heats. It’s a trap. Why Agentic AI Optimizes for the Wrong Thing at Scale Jason Dobbs, the Head of Marketing Ops and GTM Engineering at Kumo describes it like this: JASON DOBBS, Kumo AI"A warehouse is a record of what happened. It's not a rulebook for what an agent should do next. If you let a generic agent optimize directly on historical correlations with unbound authority, you can absolutely scale the wrong behavior. A product that correlates with high LTV does not necessarily cause high LTV. Prediction is not policy. Once you cross into action, you still need guardrails, business rules, approvals, evidence that it's actually driving business outcomes." An AI system that treats prediction as their gold standard will happily optimize for proxies while the actual outcome you care about degrades. The Prediction Trap Tobias Konitzer spent years studying this failure as a computational social scientist before bringing that lens to marketing. His argument is that predictive models describe what's already happening, and marketing is about changing what's going to happen. Those are different jobs, and the data warehouse doesn't distinguish between them by default. TOBIAS KONITZER, Episode 212"The nature of predictive models is they represent the status quo. Someone is going to churn, or someone is not going to churn, but that is the status quo. And there is really no point for marketing if everything is just status quo. There is no marketing role here." He describes a CRM head at a billion-dollar outdoor brand who found that high LTV customers had a strong correlation with viewing a specific product, a pair of jeans. The obvious response was to push those jeans into the welcome flow. The correlation ran in the wrong direction, though. Those customers already had high LTV before they saw the jeans. The jeans showed up alongside the relationship, long after it was established. Scaling that logic into the welcome flow pushed irrelevant products onto a broad cohort with nothing in common with the original high-LTV segment. The analysis was reproducible and data-supported; it just never verified whether the jeans caused the high LTV or merely accompanied it. An agent running the same logic would scale the error across every customer who matched the surface pattern, efficiently and invisibly, before anyone stopped to ask. Tobias calls this lazy thinking, and risky thinking: analysis that feels like rigor because it's data-supported and reproducible, but skips the question that would disqualify the conclusion. The Boomerang Effect on AI that Erodes Revenue When you let agentic AI loose on the data warehouse it has access to a TON of data. That's amazing. But raw data and then events and actions often leads to predictions that are based on correlation, and not causation. For example, let's say you task an agent with improving the number of free users that convert to paying users. The agent sees in the past that a discount campaign to a certain cohort of active free users on a certain day resulted in a high % of paying user conversions. The agent concludes: this campaign works. Scale it. But what it can't see: those active free users were already the most likely to convert, they were on the edge of paying with or without the discount. The campaign didn't cause the conversions. It just correlated with them. The agent found the easiest pattern in the data and called it a lever. Run that campaign at scale and a few things happen. You hand discounts to users who would have paid ...

    227: The Correlation masquerade (The Dungeon of martech architecture, part 3)
  3. Jun 30

    226: The Eye of context (The Dungeon of martech architecture, part 2)

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

    226: The Eye of context (The Dungeon of martech architecture, part 2)
  4. Jun 23

    225: The Fall of CRM gravity (The Dungeon of martech architecture, part 1)

    What’s up folks, welcome to our 4 part series of Crawling THROUGH THE DUNGEON OF MARTECH ARCHITECTURE You’ve arrived at Part1 : The Fall of CRM Gravity  (00:00) - Intro (00:57) - In This Episode (01:31) - Sponsor: MoEngage (02:28) - Sponsor: Knak (04:53) - FLOOR 1: Why the CRM Lost Its Authority (06:09) - Why Every Team Moved Into the CRM (And How It Lost Its Authority) (13:57) - Why Sharing CRM Data Always Breaks It (18:02) - Why CRM Gravity Outlasts the Technical Argument (24:04) - BOSS BATTLE: The False Truth King (25:44) - Sponsor: GrowthLoop (26:48) - Sponsor: GrowthBench (34:56) - Why Centralizing Data Only to Copy It Out Defeats the Purpose (39:31) - BOSS BATTLE: The Export Hydra (40:53) - How to Move to a Warehouse-Native Architecture (46:36) - How to Achieve Portable Audiences (56:52) - How CLI/MCP Servers Are Changing Marketing Stack Integration ---------------------------------------------------------------------------OPENING---------------------------------------------------------------------------Welcome to the descent into the Dungeon of Martech Architecture, a 4-part journey through the unhinged and constantly expanding world of marketing technology. As a massive sci-fi fan currently reading the Dungeon Crawler Carl books, I have used their level-by-level progression as the direct inspiration for this 'dungeon crawl' analogy, and while you don’t need to know the books to enjoy the journey, those who do will recognize some of the gaming lore and achievement-style rewards woven into our descent.  This will be educational and helpful for anyone that works and builds martech, and hopefully it’s also a bit fun. Without a doubt though, it will be weird.  Here is your quick guide to the floors ahead: Episode 1: CRM GravityYou’ll conquer the source of truth and discover that the data warehouse replaces the CRM with portable audiences. Episode 2: The Eye of ContextYou’ll learn why AI fails without shared meaning, why context engineering is the layer between data and agent authority, and why the industry built the wrong kind of meaning infrastructure in 2012. Episode 3: The Correlation MasqueradeYou’ll 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 TowerYou’ll 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. --- Be honest: when was the last time you pulled up a number in your CRM and actually trusted it? like… no second-guessing, no “that feels a bit off”… just total confidence? Maybe you didn’t really have time to double check the logic behind the number and you were too excited to share the positive results. So you forwarded it to a peer.  Or maybe you’ve been in that meeting… 2 people arguing over a number, both pull it up in the same CRM, and somehow get 2 completely different answers… and no one can explain which one’s actually right. We’ve all been there, we’ve felt it. That dark, creeping dread. When “which number is right?” gets answered with “well… it depends who built the report,”. They know it. You know it. The CRM admin knows it. Everyone in the room knows it. You don’t have a source of truth… just a CRM that’s turned into a dumping ground of lost updates that have slowly compounded into competing versions of reality. Call it counterfeit truth or data mirage… I call it bad data. Data that has the appearance of authority without the actual authority behind it. It's everywhere in the modern marketing stack. And the CRM is often where it starts. That’s where our first boss is hiding.  ---------------------------------------------------------------------------FLOOR 1: Why the CRM Lost Its Authority--------------------------------------------------------------------------- If you’re in B2B or B2C the first floor looks a bit different but only because of terminology. In B2B the 2 cornerstone platforms are the CRM and the MAP: the Customer Relationship Management software and the Marketing Automation Platform. Sales works in the former, marketing works in the latter, ops is stuck making the two talk to each other. In B2C though, for some reason you all decided that the MAP is actually called a CRM and the B2B version of the CRM isn’t really needed because there’s often no sales team, instead it’s a customer support or product led motion. In both scenarios though the same thing happens to that central platform. It gets inherited by teams that weren't its original audience. It accumulates data it wasn't designed to hold. And it becomes the unofficial source of truth for the whole business without anyone explicitly deciding that was a good idea. Why Every Team Moved Into the CRM (And How It Lost Its Authority) So how did we get here? CRMs were built for one job: tracking the sales motion. Contacts, deals, stages, activity logs. They were good at that job. Then marketing moved in. Marketers ruin everything. But leadership is worse. Leadership started pulling board metrics from the CRM. Then the product team added usage data. Then we added ABM and account signals, and we had to push that data somewhere. Then AI interactions needed a home. What a mess. Everyone needed a record of the customer, and the CRM was already there. It’s literally called the Customer Relationship Manager. So it became the shared folder everyone saved their customer work into, even though it was designed for a very specific kind of work. The problem is that once data is stored in a CRM, it starts reflecting the team that works there. Sales edits the contact. Marketing overwrites a field. Customer success adds a note. Each edit is local logic applied to what everyone assumes is shared truth. The data looks official but you know deep down that the authority behind it belongs to whoever edited it last. Meg Gowell, Head of Marketing at Elly.ai and former Head of Marketing at Typeform  crossed over from a Salesforce-first organization to one where the warehouse had already taken over: MEG GOWELL, Episode 155“The tricky part of our tech stack is that I’m used to Salesforce or HubSpot being the single source of truth. Here, our core business is represented more in the data warehouse than anywhere else, and Salesforce supports the sales-led part of the business. Understanding how those data pieces come together is something I’m still working through. I’ve only been here three and a half or four months, and it’s tricky. The biggest challenge is figuring out how the self-serve and sales-led motions fit together. In PLG, they have to serve one another. If your tech stack doesn’t support that, it becomes really hard. We run into questions like: do we have all the right data points in the right places for people to act on them? Do we know everything we need to know? I’ve really experienced how important the underlying data structure is, and how important consistency across tools is. In the past, there was this wide spectrum. In one area, we had a very advanced multi-touch attribution system. In another area, it was very basic reporting. So there was this weird mix of super deep and super surface-level, but without an underlying structure that fully worked. I think that happens to a lot of companies when they’re growing fast. You take opportunities where you see them, and you move quickly. Now we’re taking a step back and saying: we really ...

    225: The Fall of CRM gravity (The Dungeon of martech architecture, part 1)
  5. Jun 16

    224: How OpenAI’s GTM leader structures teams and spots standout candidates with Keith Jones

    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 Jones Keith 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 Systems The 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 Team OpenAI'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 org That 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 Split GTM 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 ops No 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...

    224: How OpenAI’s GTM leader structures teams and spots standout candidates with Keith Jones
  6. Jun 9

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

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

    223: How Zapier uses a shared brain to manage AI context and skills with Lindsay Rothlisberger
  7. Jun 2

    222: How senior MOps practitioners are navigating the 2026 job search with Ashley Langford

    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 Off The 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 2026 The 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 Resume Most 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...

    222: How senior MOps practitioners are navigating the 2026 job search with Ashley Langford
  8. May 26

    221: You need Minimum Viable Readiness for AI because perfect data doesn't exist with Jason Dobbs

    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 Dobbs Jason 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 Wrong Every 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...

    221: You need Minimum Viable Readiness for AI because perfect data doesn't exist with Jason Dobbs

Ratings & Reviews

5
out of 5
7 Ratings

About

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.

You Might Also Like