Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS
What’s up everyone, today we have the pleasure of sitting down with Elizabeth Dobbs, AVP of Marketing Technology, Data and Growth at Databricks.
Summary: Liz spent 6 years at Databricks building the data infrastructure before deploying any 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.
In this Episode…
- Why Velocity Beats Permanence in Marketing Data Architecture
- Why Databricks Embedded Data Engineers Inside Marketing
- How Marge Led to Tagatha and Tagatha Led to Atlas
- How Databricks Built an AI Analyst That Marketing Teams Actually Trust
- How Agent Tagatha Cut Months of Manual Content Tagging to Hours
- How Agent Atlas Replaced the Rules-Based Segmentation Wheel
- Why Marketers Don’t Care Whether You Call It an Agent
- What Databricks Is Actually Testing for in Marketing Hires Now
Recommended Martech Tools and Agencies 🛠️
We only partner with products and agencies that are chosen and vetted by us. If you’re interested in partnering, reach out here.
🎨 Knak: Go from idea to on-brand email and landing pages in minutes, using AI where it actually matters.
📧 MoEngage: Customer engagement platform that executes cross-channel campaigns and automates personalized experiences based on behavior.
🐾 AttributionApp.com: Multi-touch attribution software that gives you auditable, full-funnel clarity across every channel — find out your “true” CAC.
🔄 GrowthLoop: The agentic, composable CDP that drives compound growth by uniting your cloud data + AI into one marketing engine.
About Elizabeth Dobbs
Elizabeth 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 seven 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 Architecture
If 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 six 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.
“What are the one-way door decisions where we’re gonna go through and it’s really hard and painful to step back? And what are the things where we think we can make architectural decisions which could be painful up front, but will pay us dividends in the long term?”
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 one 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.
Back to the top ⬆️
Why Databricks Embedded Data Engineers Inside Marketing
Marketing 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 CIO 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.
“These agents are a blank slate. You spend a lot of time training, enabling, providing context, explaining the nuance. And the cool part is, yeah, with agents, like they learn it and they’ll just kind of continue it. But when you think about internal resourcing, you’re training a human. A lot of times it’s not the same person.”
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 that tags content correctly without someone who knows what the taxonomy should mean for a Databricks audience. The org chart isn’t the story. But it’s the thing that made the story possible. The orgs that move fastest on AI deployment usually share one thing: specialists who understand the domain the AI is serving, sitting inside the team that needs to use it.
Key takeaway: If you’re trying to get better data infrastructure for marketing, stop asking for a data team and start asking for one data engineer with marketing domain experience specifically. Make a concrete case for what that person can move in 90 days that a generalist couldn’t. Show the velocity difference on something real, even if it’s small, before asking for more headcount. The model earns its seat at the table through demonstrated speed, not through an org chart argument.
Back to the top ⬆️
How Marge Led to Tagatha and Tagatha Led to Atlas
Most teams building AI agents for the first time pick the easiest use case. Something low-risk, well-scoped, easy to declare a win. Databricks started with the hardest 1. Marge, a natural language interface to marketing data built on Databricks’ own Genie product, came first because the team saw it as the future and wanted to move toward it before the technology was fully ready. That decision set off a chain reaction that neither Liz nor anyone on the team planned in advance.
Marge launched with gaps. Her contextual knowledge was thin. The product was still evolving. Rather than pulling back and waiting for the right moment, the team treated it as a signal: Marge needed better data underneath her to give reliable answers. That realization is what created Tagatha. Agent Tagatha, originally called Tag Your It Bot, is a content tagging agent that goes through all of Databricks’ marketing content and applies structured tags to it automatically. It wasn’t born as a standalone project. It was born because Marge couldn’t do her job without better-tagged content feeding into the lakehouse.
“We’re gonna come to work on Monday and we’re gonna have 3 new audiences we didn’t think we had on Friday. And by the way, we don’t have 2 quarters figured out.”
Tagatha’s tagging work then surfaced the next problem. Once the content layer was structured, the team could see how fragmented the audience segmentation was. Rules-based segments on one side, intent signals on the other, and no clean way to bring them together fast enough for a team moving at Databricks’ pace. That’s what created Atlas. The segmentation agent was built specifically to handle the kind of audience problem that appears on a Monday morning with no warning and no quarter already figured out. Each agent revealed the thing the previous agent couldn’t do alone.
The philosophy Liz uses to describe this is “speed bump vs stop sign.” When Marge launched with gaps, the team logged every failure as a direction signal for what to build next. The same logic applied when Tagatha hit drift problems, and when Atlas exposed how much segmentation complexity still lived in manual rules. Every problem in the chain was a speed bump that pointed toward the next build. The architecture took shape through iterative use. Now Marge has the foundation she needed to do the deep analysis she was originally supposed to do, because the 2 agents that followed her gave her better data to work with.
Key takeaway: Start your first AI agent on the problem causing the most friction for your team, not the safest use case you can guarantee. Document every gap the first agent exposes, because those gaps are your roadmap for agents 2 and 3. The teams making real progress with AI in marketing aren’t planning multi-agent architectures from the start. They’re building one thing, learning what it can’t do, and building the next thing from there.
Back to the top ⬆️
How Databricks Built an AI Analyst That Marketing Teams Actually Trust
The question most teams skip when deploying an AI analytics tool is how the end user will know whether to trust the answer. Liz’s 2-word answer for how Databricks solved this with Marge: “Slowly and painfully.” The longer version involves 3 specific things the team built, and they matter more than the underlying technology.
The first was a semantic layer built from conversations with actual marketers. Marketing has sub-disciplines with genuinely different vocabularies. The partner team’s version of ROAS is different from the events team’s version. MDF means something specific to one group and something completely different to another. The team sat down with each discipline, mapped out how they defined every key metric, and trained Marge to understand that when different teams use the same term, she should be calculating it the way that team expects. Most AI analytics deployments skip this step entirely. They assume shared vocabulary. Marketing data doesn’t have it.
“We don’t release her to the wild and say good luck everyone. It is constantly governed and reviewed. And if we have issues, we will reach out to the marketer and say, hey, we can see your whole query. What felt wrong?”
The second was a trusted answer system. Thomas, who leads the data work, built out a library of certified question-and-answer pairs that Marge references when responding. If your question maps to a certified answer, you see a green checkmark. You know the answer is 100% right. You can see the SQL that generated it. The pairs are also contextual: a question about ROAS for EMEA can pull a trusted answer for AMER if the 2 are structurally equivalent, and Marge will flag it as certified. This is the thing that actually moved adoption. Marketers presenting data to leadership need to know they can stand behind it. A green checkmark gives them something to point to.
The third was a weekly feedback loop. An hour or 2 every week, the team reviews Marge’s query history, looks at bad answers, and goes back to individual marketers to understand what went wrong. When a marketer runs a query that produces a result they don’t trust, the team can see the full query and follow up directly. This level of ongoing governance is unusual. Most teams ship the tool and move on. Databricks treats Marge’s accuracy as an ongoing operational responsibility.
The architecture behind Marge has since evolved to match the depth of usage. The team started with one Genie space trained on everything. When marketers started going deep on specific areas, the broad context became a liability, too much information for precise answers. Now there are child genie spaces, each trained on a specific domain like digital advertising data. A marketer types into one interface. The routing happens automatically in the background. They don’t need to know which genie space they’re in. The complexity is hidden. The AI tools that actually get used are the ones that make it easy to know when to trust the answer, and that hide the infrastructure from the person who just needs a result.
Key takeaway: Before rolling out any AI analytics tool to your marketing team, build 3 things: a semantic layer that maps each team’s specific definitions for every shared metric, a set of certified question-and-answer pairs the tool can reference with a visible trust signal, and a weekly feedback loop that treats bad answers as errors to investigate rather than limitations to accept. All 3 together are what separate a tool people actually use from one that gets a trial period and quietly disappears.
Back to the top ⬆️
How Agent Tagatha Cut Months of Manual Content Tagging to Hours
If you’ve ever tried to retag 5 years of blog content after a product rename, you know the exact feeling Tagatha was built to eliminate. Strategy changes, ICP updates, new product launches, taxonomy overhauls: every one of them triggers the same painful backlog of content that now carries the wrong labels. Product marketers spend days on it. And the moment it’s done, the next change is already scheduled.
“Tagging is just a business problem at Databricks in general. And content was actually the simplest part of it.”
What makes Tagatha different from a CMS tagging feature is what it’s trained on. Every agent Databricks has built runs on the same marketing lakehouse foundation, which means Tagatha has access to all the business context the team has encoded over years: what each tag represents, how the taxonomy maps to campaign programs, which terms apply to which audiences, how to resolve a tie when content fits multiple categories. A generic CMS agent can read a blog post and guess at tags. Tagatha knows what a tag means to Databricks’ marketing team and what getting it wrong would break downstream. That’s a different problem than text classification.
The name evolution tells the build story honestly. It started as TAGit Bot, which reflected how much manual checking the early version required. Multiple bots in sequence, each verifying the previous one’s work, because the system couldn’t get from content to clean tag without several check-in points in the middle. The team renamed it Tag Your IT Bot. Eventually it became Agent Tagatha. The architecture got cleaner as the underlying models improved. A lot of the complexity that required those intermediate checking bots has been absorbed by better foundational models. Liz’s observation is direct: if they were building Tagatha today with the models available now, the hero’s journey of V1 through V4 probably wouldn’t have been necessary.
That observation opens into a broader point the team has started thinking through carefully: the right model for the right job. Claude might outperform OpenAI on one task. OpenAI might be more cost-efficient on another. Some tasks warrant a more expensive model. Others don’t. As more agents run in production, the question of which model to use for each one becomes a real operational decision, not a philosophical one. Tagatha’s evolution from a multi-bot checking chain to a cleaner single-pass architecture is partly a story about improved models and partly a story about the team learning to route the right workload to the right tool. Content tagging looks like an operations problem. Databricks treats it as data infrastructure. The teams who make that same reclassification will find that their campaigns, their agents, and their reporting all get cleaner at the same time.
Key takeaway: Map every tagging decision in your content library to the campaign segment it feeds. If you can’t trace that line, you have a data problem presenting as a content problem. Fix the taxonomy first: define what each tag means to your specific business and how getting it wrong would break something downstream. Any agent you deploy for content tagging will only be as accurate as the business logic you’ve already defined for what each tag represents.
Back to the top ⬆️
How Agent Atlas Replaced the Rules-Based Segmentation Wheel
Most B2B marketing teams are running some version of the audience problem Atlas was built to solve. You have segments built on title and job function, the traditional rules-based approach, and you have intent signals coming in from content engagement and product activity. Both matter. Neither maps cleanly to the other. The meetings where you try to reconcile them produce a lot of conversation and very little resolution. In EMEA, “Head of” might mean Director level. Or it might not. Nobody agrees. The conversation happens again next quarter.
At Databricks, this problem ran on 2 tracks simultaneously. On one side, the team had granular rules-based segments by title, region, and seniority. On the other, Tagatha was generating rich content engagement signals: who was interested in Genie, who was focused on data warehousing, who was engaged with agents content. Bridging those 2 worlds manually meant every new program kicked off the same cycle of debates about which audience applied and what the overlap meant. The segmentation was holding up the execution.
“Even before this idea of next best action, this is just foundationally: how do we organize our audiences, ourselves, our programs, in order to enable the idea of next best action?”
Atlas was built to bring those 3 vectors together: seniority and role (because knowing whether you’re talking to a decision maker or a practitioner will always matter), topic and product interest (from Tagatha’s tagging layer), and the ability to accommodate a new audience that didn’t exist on Friday when Monday’s campaign brief arrives. The goal was a segmentation structure that could move at the pace Databricks actually operates. Not a static rules library that required a sprint to update. Not a system where a new product launch meant 3 weeks of segment maintenance before a single email goes out.
Atlas doesn’t do next best action. Liz is clear about that. Next best action, deciding which message goes to which person at which moment based on a full behavioral picture, is a separate problem and probably a separate agent. What Atlas does is get the foundation right so that next best action is actually possible.
Right now the team is using Atlas to test segment efficacy across web, email, and digital channels. The audiences are defined. The team thinks they’re future-proofed. The next layer, aligning the message and timing with the channel, is where the roadmap is pointing. Audience segmentation built on static rules is a liability that compounds with every new product, every new market, and every new quarter. The teams winning at personalization will be the ones who let intent signals and rules-based logic operate together instead of fighting for the same spreadsheet.
Key takeaway: Audit your segmentation model by asking one question: if a new audience category appeared tomorrow morning, how long would it take your current system to accommodate it? If the answer involves a meeting and a sprint, you have a rules-based bottleneck that will slow down every personalization effort you run on top of it. Build the intent layer alongside the rules layer before you deploy any agent that depends on knowing who the audience actually is.
Back to the top ⬆️
Why Marketers Don’t Care Whether You Call It an Agent
The agent definition debate is consuming a lot of energy in marketing right now. The canonical definition requires goal direction, full autonomy, no human approval required at decision points, and the ability to rewrite its own tasks. By that standard, most things teams are shipping and calling agents don’t qualify. Liz’s view on the debate: it doesn’t matter, and the obsession with the label is getting in the way of shipping things that actually work.
“Sometimes a marketer would prefer something that just works than something that’s almost trying to do too much. If you’re trying to do everything at 50%, sometimes you’re actually putting more work back on the person than they had before.”
The failure mode she’s describing is specific and common. A team builds something that can technically do 10 things but does all of them at 50% accuracy. The marketer using it now has a new job: reviewing and fixing 50% of the output. That’s a worse outcome than doing the original task manually. A well-scoped automation that does one thing at 90% accuracy has far more value. The marketer doesn’t need to know whether it meets the philosophical definition of an agent. They need to know whether trusting it saves them time or costs them time.
Liz’s team has been doing something harder than building agents: they’ve been rethinking what work should look like before deciding which tools to use. The question isn’t “what can we automate?” It’s “what does this work actually consist of, which parts are genuinely low-value for a human to do, and what would it look like if we redesigned it from scratch?” Most marketing teams skip that step. They buy the tool or build the agent, then discover the work it was supposed to replace is still happening in slightly different form.
The hype cycle around agents has also crowded out attention to what good workflow automation can actually do. Some of the most valuable things Databricks has built for their marketing team are not agents by any strict definition. They’re well-designed workflows with reliable outputs. The teams that insist on calling everything an agent are, as Liz puts it, packaging a really good workflow in an agent bow. The bow is optional. The workflow doing the work is what matters. The companies that win with AI in marketing will be the ones that shipped the right tool at the right accuracy threshold, regardless of what they called it.
Key takeaway: Before classifying your next build as an agent, define what a working output looks like and what accuracy threshold a marketer needs to trust it without editing. If the honest answer is 80% or higher, the tool earns its place. If the answer is 50%, you’re building a first-draft generator that may create more work than it saves. Scope the tool to do fewer things at higher accuracy before adding capabilities. A focused tool that works is more valuable than an ambitious 1 that requires constant supervision.
Back to the top ⬆️
How to Get Data Warehouse Access When Your Team Doesn’t Own It
Most marketing ops people who want better data access think the problem is technical. Liz’s answer is that it’s almost entirely social, and the 3 things she recommends don’t require any technical skills to start.
The first is coming with curiosity instead of demands. If you approach the data or engineering team with a list of things you need them to do for you, you’re starting from a transactional position that rarely goes well. If you come with a genuine question, “can you help me understand how the data is structured here?” or “where would I look if I wanted to find X?”, you’re inviting someone to explain something they care about. People who work in data are usually happy to explain their domain to someone who’s actually interested. That conversation builds the relationship. The relationship is what gets you access later.
“Databricks did not work for marketing to be totally transparent. We’ve had to grow up and adapt and modify the product to fit our use cases.”
The second is building cross-functional relationships before you need them. At the scale Databricks operates today, going through the standard ticketing process is, as Liz puts it, the slowest path to where you need to go. If you need something urgently, you’re calling on a favor. You can only call on a favor if you’ve built the relationship first. The people who can move fast inside a large company are almost always the ones who have spent time building relationships in other functions, not as a career strategy, but because they’re genuinely curious about what those functions are doing and useful when they can be.
The third is simpler: just ask. Her father’s version is “the worst they can say is no.” Most marketing ops people assume that access to data infrastructure requires political capital they don’t have or approvals they’d never get. Often they haven’t asked directly. Often the answer would be yes, or yes with conditions. The people who get access to things inside organizations are usually the ones who made a specific, reasonable request rather than assuming the door was closed.
Liz applies all 3 of these to the customer 0 experience at Databricks specifically. The marketing team was one of the first internal production users of Genie and one of the first customers on Unity Catalog. That didn’t happen because marketing had leverage. It happened because the team had built relationships with the product side over years, showed up with curiosity about what was being built, and made direct requests to be part of the testing.
The admission she makes about that journey is worth holding on to: Databricks’ own platform didn’t work for marketing when they started using it. They had to push the product team to fit the use case. Speed bumps. Not stop signs. Access to data infrastructure is a trust and relationship problem before it’s a technical one, and the best case you can make for expanding that access is a business result that wouldn’t have been possible without it.
Key takeaway: Pick one cross-functional data counterpart and make their job easier before you ask for anything. Find something they struggle to track that you can help with using data you already have access to. Then ask for the expanded access you actually need. Every data partnership that delivers for marketing starts with a specific favor, not a general ask. Build the relationship with curiosity first, call on it with a direct request second.
Back to the top ⬆️
What Databricks Is Actually Testing for in Marketing Hires Now
The “how do you use AI today?” interview question is effectively dead. Liz stopped asking it because the answers are useless now. Everyone knows the question is coming. Everyone has a prepared answer. And a prepared answer about AI tool usage tells you nothing about whether the person can actually think with the business context that matters. She moved on before most hiring managers realized the question had stopped working.
What she’s testing for instead is business context: can you explain not just what you built, but why you made the decisions you made, what you found along the way, and how you changed course when the original plan stopped fitting the problem? For both technical and marketing roles, that ability to articulate the decision behind the work, not just the output, is what she’s listening for. Data engineering skills are getting commoditized by the same tools that are making everyone’s resume look perfect. The hard part, knowing your business well enough to build something that actually serves it, is what agents can’t replace.
“I think almost everyone has cracked the nut on: take job description plus my resume, ask ChatGPT to customize it, and then you load that version of your resume and cover letter into an application platform. If you’re a hiring manager, you look in Greenhouse and they all look the same.”
The resume problem is a practical consequence of this. Hiring managers are now looking at Greenhouse queues full of perfectly tailored applications that are genuinely indistinguishable from each other, because many of them used the same tool with the same inputs. The candidates who stand out in conversations are the ones whose verbal answers are nothing like the polished version on paper. They’re the ones who can talk through a complicated decision they actually made, including what they got wrong, without sounding like a LinkedIn post.
Her advice for people currently looking: the warm intro is the only reliable differentiator left. Build your network, lean on your existing relationships, ask for introductions, ask for referrals. Use AI to craft targeted outreach to hiring managers directly, a concise explanation of who you are and why you’d be a good fit, rather than using it to optimize a resume that will land in a pile of identically optimized resumes.
And send the thank you note. It still works. Most people don’t send it. The small gestures that require human judgment and actual follow-through are more valuable now, because the generic polish has been automated away. The interview market in marketing is running the same AI problem every marketing team faces: you can generate something that looks right and says nothing. The people who stand out are doing the work that can’t be faked.
Key takeaway: If you’re hiring for marketing roles, drop the AI-usage question and replace it with a specific business context probe. Ask candidates to walk you through the single most complicated decision they made in their last role, not what they built, but what they decided and why, and what they changed when the original plan stopped working. The people who can answer that question clearly, including the part where they got something wrong, are the ones building actual business judgment. That’s the differentiator agents can’t replicate.
Back to the top ⬆️
What Gives Liz Energy Outside the Office
When Liz describes what re-energizes her outside of work, she ends up describing the same problem she spends her days solving. 2 kids under 5, an aging dog who has been with the family longer than either of them, and a husband who has strong opinions about the distance she’s willing to drive to pick up secondhand furniture. The life outside the office is full, loud, and deliberately analog in the ways that matter.
But then there’s the 10:30pm version of Elizabeth Dobbs. The one sitting at her laptop, vibe-coding an agent designed to aggregate listings from Craigslist, OfferUp, Facebook Marketplace, Poshmark, and Mercari into one curated list of deals for things she or her kids actually need. Her husband finds this particular hobby less charming than she does. She considers it perfectly rational. The intersection of technology and the thrill of getting something at a fraction of retail price is, by her telling, exactly where she finds joy.
“The only secret to the success is your time has to be literally not valuable to you.”
The observation she makes about secondhand marketplaces is the same one that shaped how she thinks about marketing: timing is everything. If you see a good listing and you don’t respond in the first few minutes, someone else already has. That’s the same logic as SDR follow-up speed on a marketing campaign lead. The behavior pattern is identical. What differs is only the domain. She’s been training herself to spot those patterns for years, which is probably part of why she’s good at identifying where an agent can step in and handle the timing problem faster than a human can.
She packs her kids into the car for the 45-minute drive to pick up the bike she found. Her husband asks if they can not. She points out she got a good deal. The 45 minutes of her time not being valuable, her words, is the price of the deal. It’s the same tradeoff she makes professionally: some costs are worth taking if the outcome compounds.
The people doing the most interesting AI work in marketing tend to build things for themselves before they build them for their teams. Liz vibe-codes at 10:30pm. She drives 45 minutes for the deal. She knows exactly how agents think about timing because she’s been solving that problem in her personal life long before she had a job title that let her solve it at scale.
Key takeaway: Find the personal problem in your life that maps to a professional problem on your roadmap. Build a version of the solution for yourself first, even if it’s rough. The domain knowledge gap disappears when you care about the outcome enough to actually use the thing you built. If you’re struggling to validate whether an agent is good enough to deploy, use it yourself on a problem you actually care about and see whether you’d trust it. Your own reaction is the most honest signal you’ll get.
Back to the top ⬆️
Episode Recap
The central argument Elizabeth Dobbs makes, across everything she builds and everything she recommends, is that the data foundation has to come before the agents, drawn from the specific experience of having deployed them in the wrong order and watched what happened. Marge launched before the data underneath her was ready. The gaps she exposed led to Tagatha. Tagatha’s structured tagging layer exposed the segmentation problem Atlas was built to solve. The architecture took shape through iteration, built by following what broke. That’s a more honest account of how AI systems actually get built in production than most of what gets published about the subject.
The tactical thread connecting all 3 agents is the marketing lakehouse. Every agent Databricks has built runs on the same centralized, governed foundation. Tagatha’s tags feed Marge’s contextual knowledge. Atlas’s segments are built from Tagatha’s output. Marge’s deep analysis is better because Atlas has defined cleaner audiences for her to reason about. You can’t swap one of these out without affecting the others. That interdependence is a feature, not a problem, but it means the lakehouse decision, the one-way door Liz is most emphatic about, has to come first. Everything downstream is only as good as that foundation.
The bigger-picture implication for practitioners is about where agent adoption actually fails. Liz’s pre-interview framing was direct: failures are a people, process, and product problem, not a technology problem. The teams that struggle with AI agents are usually struggling with 1 of 3 things: data that isn’t clean enough to give the agent reliable signals to work with, processes that haven’t been redesigned to fit what the agent actually does, or people who are waiting for the tool to be perfect before they’ll trust it. The technology is usually not the bottleneck. The organizational readiness around it is.
Liz is also willing to make the uncomfortable admission that goes with the customer 0 role. Databricks’ own platform didn’t work for marketing when her team started using it. They pushed the product to fit the use case. They ran into problems that had no playbook. They treated every failure as a speed bump and kept going. The fact that they’re now one of the most sophisticated internal users of the platform is a direct result of having been willing to be the alpha. That’s a harder path than buying a tool that already fits. It’s also the path that produces an actual competitive advantage.
Databricks is still not human-out-of-the-loop on agentic content execution. That’s still ahead. The audiences are defined, the segments are future-proofed, the data is governed. The next layer, right message to right person at right time on right channel, is where the roadmap is pointing. The team is bullish on where it goes. They’re also clear-eyed about how far there is still to go. That combination, real progress and honest accounting of what’s still broken, is rarer in AI marketing conversations than it should be.
You can follow Elizabeth Dobbs and her work at Databricks on LinkedIn. The Scott Brinker co-authored martech stack report referenced in this episode is worth reading alongside this conversation for a broader picture of how the Databricks marketing infrastructure fits into the current state of the martech landscape.
Full episode ⬇️ or Back to the top ⬆️
Event Shoutouts
Might be the most unhinged marketing event of the year? Built for PMMs and CMOs that want to get out of the city for three days, bond over trauma, and ship something that makes you feel like a badass. (10/11 – 10/14 in Holland, MI). Use the code HUMANS at checkout.
Join the world’s best B2B marketers for 2 full days of tactical content, in-depth sessions, and meaningful connections. Use HOM20 at checkout.
✌️
—
Intro music by Wowa via Unminus
Cover art created with Midjourney (check out how)
Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS
Related tags
<< Previous episode
Next episode >>
All categories
- AI (99)
- career (63)
- customer data (60)
- email (64)
- guest episode (173)
- operations (127)
- people skills (34)
- productivity (10)
- seo (6)
See all episodes
Future-proofing the humans behind the tech
Apple •Pocket Casts•Google •Overcast •Spotify •Breaker •Castro •RSS