Building Data Doula, an Analytics Agent People Trust, with Arthur Wang

Directionally Correct: Data 2030 is an educational podcast for data and analytics professionals, hosted by Lucas Thelosen, co-founder and CEO of Orion by Gravity.

In this episode, Lucas talks with Arthur Wang of Babylist about how a hackathon project became the Data Doula analytics agent, why analysts now own the semantic layer, and how his team decides which changes deserve human attention when AI reviews the routine ones.

Arthur Wang is a Principal Data Engineer at Babylist, where he builds AI-native platforms and tools, such as the Data Doula analytics agent, that make data accessible and trustworthy. He's worked as an analyst and engineer in tech startups, retail, utilities, and consulting as both an IC and leader. He lives in Portland, OR with his wife and daughter.

What you will learn

• How a data team of 20 to 25 divides the work between engineers and analysts
• Why data roles are becoming both broader and deeper as AI takes on more tasks
• How to decide what to buy and what to build in an AI analytics stack
• Advice for early-career data professionals on slowing down and focusing on what moves the needle

Resource mentioned

Arthur's blog post on building Data Doula, from the Babylist Engineering blog
https://www.babylist.com/engineering/blog/data-doula

Chapters

0:00 Welcome and guest intro
0:31 Arthur's path into data and Babylist
2:59 Using fulfillment data to cut costs and improve customer experience
7:11 Data team size and the engineer to analyst ratio
10:14 Building the Data Doula analytics agent from a hackathon
13:32 How data engineer and analyst roles are getting broader and deeper
16:08 Institutional knowledge and the cost of maintaining an analytics agent
18:19 Buying versus building, and avoiding vendor lock-in
21:54 The future of work and moving up a level of abstraction
23:36 Why attention matters more than time
25:10 Letting AI review low-risk changes so humans focus on what matters
27:35 Next projects and keeping the semantic layer from drifting
30:12 Advice for a 25-year-old data professional
31:00 Closing thoughts

Transcript

Welcome and guest intro (0:00)

Lucas Thelosen

Welcome to another episode of Directionally Correct. I'm Lucas Thelosen, the CEO and founder of Orion by Gravity. With me today is Arthur Wang. He built something very similar to what we built here with Orion at Babylist. When he posted about it and wrote a blog post about it, that really got my attention. I wanted to talk to him and hear his experience, not just building this, but also having run analytics teams and his journey to Babylist. So thank you very much, Arthur, for joining me.

Arthur Wang

Yeah, thank you for having me.

Arthur's path into data and Babylist (0:31)

Lucas Thelosen

Well, before we dive into analytics and your experience working on AI for analytics, I'd love to hear a bit about your background, how you got to Babylist, what you're doing there, and what Babylist does.

Arthur Wang

Yeah, for sure. Babylist is the leading registry and e-commerce platform for growing families. Chances are, if you know someone who's expecting a baby, they have a registry on Babylist. We provide a way for people to create a registry for things they want or need for their growing family, and also for after the baby arrives, for birthdays and holidays. We also have our own shop. We're expanding into the health space, so expecting parents can also get breast pumps and other medical equipment through our Babylist Health business. We're constantly growing. We just launched a showroom in New York, actually.

My role at Babylist is principal data engineer, and I actually kind of fell into data by accident. My background is originally in liberal arts. I studied anthropology and political science with a quant focus in college, and after I graduated I went into the Peace Corps, so not at all data. When I got back, I was kind of bumping around, and I got referred to my first data job by a friend. I had no idea what it was. It was sort of a generalist analyst role for a software company. It wasn't obvious to me, again, that it was a data job, but on my very first day my boss handed me an O'Reilly SQL book and said, "Learn this." That's how it all started, and I found I really liked it. Back then there was no AI. It was all hand-coding SQL, but every day I'd have an inbox full of questions to answer, and I really got to know data pretty well. I was hooked. I enjoyed the combination of coding, learning from data, and rendering that into actual decisions that would impact the business.

After I left that job, I spent a while in consulting, probably half my career. Eventually I wanted to go back to building things and seeing them grow. I had my first child in 2021, and we used Babylist for a registry, so I was a Babylist user. Right when I was looking to make a transition, Babylist was hiring a data engineer, so it seemed like a perfect fit. It was a great fit through the interview process, I landed at Babylist, and I've been there since, for the last four years.

Using fulfillment data to cut costs and improve customer experience (2:59)

Lucas Thelosen

Fantastic. I think the consulting background is really interesting. As unusual as that may sound, you have an unusual background, and I've heard a lot of people say, "I was a political science major, an economics major, a little random background, interested in things." You're curious, and you want to turn a bunch of stones over and see what's behind them. One of the things you mentioned along those lines is finding those insights. That's what you do as a consultant a lot, too. You go into accounts, you look at things. And then at Babylist, of course, you've done that a lot as well.

One of the things I'm always interested in is what you've uncovered. What are some of the findings? A decent amount of the audience is always interested in how to justify the spend on analytics. We all hear that Amazon is very data-driven and Google is data-driven, successful companies. But how can I get my company to also invest in data, with more than the theoretical examples of Uber, Amazon, or Google? I want the concrete story of how much we invested in data and what we got out of that. I think those stories really help practitioners say to their bosses that we should invest some more in data. So what have you found that was impactful?

Arthur Wang

Yeah, absolutely. At Babylist, as I mentioned, we're both a tech company, with our registry and apps, and an e-commerce company. We fulfill goods. We have a shop, and we ship stuff to you. We're constantly trying to optimize this, not just for the bottom line but also for customer experience, which feeds a flywheel. You have a better customer experience, people love to shop with you, and that helps grow value as well.

The customer experience especially depends on our fulfillment process. People often think of the world of atoms and the world of bits. I can't remember who said that, but I thought it was great. Atoms is the physical world, the supply chain, the warehouse, the fulfillment center, drop shippers, all that. Bits is your app experience. But for the typical person buying something, it's all the same thing. Your app can be great, but if stuff arrives at your door broken or lost, or never gets to you, that's a bad experience for them. That's all part of the same thing, so we're trying to optimize the whole consumer experience.

On fulfillment, there's actually a lot of great data. People often think of product analytics, where you have clickstream events to measure behavior on the site, but there are also lots of things you can measure in the world of atoms, where there's a lot of prior art. Things like, did your gifts get to you before the baby shower? Did they get to your front door in good condition? Were people able to return things easily? These all flow through our systems, along with the typical user behavior event tracking. This kind of data has helped us make decisions like which carriers we use, or whether to ship ourselves versus through a drop shipper.

We constantly make these decisions. We picked up a carrier and then offboarded them, because they were cheaper and fast enough, but we decided they could be faster and could be higher quality in how they get goods to people. We also use data to decide where to put our fulfillment center. We have one in Columbus, Ohio, that was specifically chosen based on where we see purchasing through our shop. We want to make sure we're located in a way that we can reach the majority of our customers. Overall, I think these decisions have resulted in a better bottom line, with more efficient fulfillment and more value for the money we spend on fulfillment, but also a better customer experience. And having all the well-modeled, clean data helps us keep adjusting based on changes in the real world, external factors like tariffs, or macroeconomic factors like supply and demand.

Data team size and the engineer to analyst ratio (7:11)

Lucas Thelosen

Perfect. What is the current team composition for the people working on data within your company? How large is the organization as a whole? I'd like to give people a perspective on how big you're thinking and operating.

Arthur Wang

Yeah, our company has definitely grown a lot, but I'd say we're still pretty lean for the size of our business in terms of customers and revenue. We're just shy of 500 people right now. That's not counting the wonderful folks who work in our fulfillment center and our CS folks, but the central Babylist folks who work on Slack, I'll say the Slack people. On the data team, we currently have seven data engineers and analytics engineers. I used to be able to count easily and name everyone instantly. I'd say we're between 20 and 25 people total on the team. So there are seven data engineers, then a few leaders on the team, and the rest are analysts and data scientists.

Lucas Thelosen

Okay, interesting. What is the data scientist to analyst composition, approximately? So seven data engineers. Those numbers are always super helpful, because I get a lot of questions like, what should the ratio be? What do you think it should be right now? What's your opinion?

Arthur Wang

Yeah. What should the ratio be?

Lucas Thelosen

Well, maybe tell me what you have right now and what you think it should be.

Arthur Wang

Yes. We're hiring another senior data engineer right now, so that's a plug. If anyone is watching this or listening and you know any great folks, we're still hiring for that, so definitely let me know. I think that's a pretty good ratio, because the way I see things going, data engineers will increasingly focus on building platforms and capabilities. They don't need to be in there touching everything, like building data pipelines or data models every day. That's going to increasingly be done by the people with more direct domain knowledge and exposure. So I actually expect that the ratio will be even more skewed toward analysts and scientists versus data engineers in the future.

Lucas Thelosen

Okay. Sorry, I missed this. You have seven data engineers. How many data scientists and analysts do you have, approximately?

Arthur Wang

Let me think. Right now it's probably 13 or 14, I think. And that counts the managers of our analysts and scientists as well.

Lucas Thelosen

Okay, so about a two to one ratio. And that gets us into what you built, a system where people are able to ask questions and get answers. Of course, we built a system as well for that. You're thinking that the ratio will actually increase further and you'll have more analysts. What do the analysts do in that world? And maybe walk us through your journey of building the self-serve.

Building the Data Doula analytics agent from a hackathon (10:14)

Arthur Wang

Yeah, for sure. I'll start with the journey of how we built this. All of this started in 2025, and Babylist was really leaning into AI at that time. We had been exploring AI in 2024, and in 2025 is when agents really became an actual thing. We had a hackathon, and that's where Data Doula, our analytics agent, was born, from a hackathon project. Across our tech org, we had this push to explore how this revolutionary technology could actually change things. Some things were a bust and some things were great. We built the agent, we proved it out, and I think the value became immediately apparent, because everyone had experienced the pain of the old way.

Product managers would have some novel question, and they'd always have to ping an analyst. These questions weren't necessarily deep or complex, but they required an analyst to write SQL, and that meant the analyst would be pulled away from whatever deeper strategic work they were doing. Sometimes answering the question required a relatively trivial addition, like I need a new column or I need a new filter on this dashboard, and that often meant an engineer would be pulled away from their work. Everyone felt this pain across multiple roles. So we did the hackathon and we released this analytics agent, and the agent really took off. We have quite high adoption across the business.

I think the key to growing that adoption has been increasing the knowledge available to this agent and also making sure the agent is trustworthy. We took the approach of constraining the agent to data that is governed and modeled in our semantic layer. Coming back to what the role of the analyst is here, I and a small team released the initial POC, or V0, of this agent, which covered only a subset of data, and I describe that in the blog post. That was to prove that the agent works and that the answers were trustworthy. We vetted the agent with analysts, and it was actually myself and a couple of other people who wrote the semantic model behind that.

But we always knew that if this was really going to scale and take off, it couldn't just be the engineers, our small group with a one-to-two ratio, constantly building this. We knew we had to start letting analysts own the agent. So in the future, and even today, analysts are the ones who primarily own additions to the semantic layer. They own the modeling, they own the semantics, the definitions, the rules. Part of that is also me letting go, and not trying to get in there and review every change line by line, but saying, "Here are the tools that let you expand Data Doula's knowledge. Go for it. And here are the tools to assess the quality of that and to test it." We make that as frictionless as possible for the analysts to truly own the agent, instead of me having to be the safety net for everything.

How data engineer and analyst roles are getting broader and deeper (13:32)

Lucas Thelosen

Yeah. So do you think the role of the data engineers is going to be more on the architecture of the data underneath, and the analysts on context enrichment and adding to that? Is that how you see the roles evolving?

Arthur Wang

Yeah, I think there's a lot of overlap. There always has been, and there will continue to be overlap. The way I see roles evolving is that everyone's role becomes both broader and deeper. Broader in the sense that everyone is doing things that were previously not in their job description. Analysts are doing data modeling, and some of our analysts are even building pipelines to ingest raw data into the data lake, which is amazing, because they know what they need immediately. And engineers are shifting toward building more tooling rather than just building the data pipelines. Our roles are getting broader, but that also, paradoxically, frees up more time to go deeper on the things you are truly uniquely positioned to do. Because analysts aren't fielding all these ad hoc questions, they can focus on deeper analysis. Because they're not waiting for a data engineer to add a column or whatever, they can, while they're still in the flow, get that column added using AI and then immediately turn around and do their analysis.

That's how I see the role evolving. Coming back to your original example, I think that's right, because that lets us focus on the things we're more uniquely positioned to do. For engineers, that is building the tools that let other people do more self-serve. For analysts, that is taking the context and the logic that's already in their heads, the deep domain knowledge, and putting that in a place that is available to AI. I see that being a big chunk of what they do in the future.

Actually, Ramp's head of data made a great post about the new modern data stack, and there was a line in there that I sent to one of our data science managers, because she had said basically the exact same thing in the past. The new role of the data scientist or data analyst is to encode their knowledge into an actual structure that can be repeated and reused by anyone, AI and human. I'm sure I'm mangling the paraphrase, but the idea is that a core part of the role is to take that knowledge and get it out of your head, out of you typing on a keyboard or prompting an agent, and put it in a place where someone else can use and reuse it.

Institutional knowledge and the cost of maintaining an analytics agent (16:08)

Lucas Thelosen

Yeah. I think a great analyst is usually the one who has been around for a while and has a lot of that institutional knowledge. They attended a couple of the really important meetings. They remember that in 2021 there was a bug in the system, and that's why there was this weird day. All these things are there, and they know the data that's accessible and the business questions people are thinking about. Bringing those two worlds together, really being aware of all the data and all the possible business questions, takes a lot of time for a person to build up. One of the biggest challenges I've seen is when that senior person leaves or gets promoted or something like that. Now you need to codify that knowledge and make that accessible to a broader team, so you're not dependent on this one person joining your meetings. You have a conversation in the marketing team, a huddle, and questions come up, and if that super senior person had been there, they would have been able to connect the dots, but they were not there. So now we have meeting note takers and everything actually listening. A big part of the proposition of our product is this ambient learning, taking the context from the meeting note takers and adding that to the knowledge base, suggesting edits for the data team to approve, and enriching the analysis further.

Now, you're particularly unique right now in the world, because Meta published an interesting article in the spring of 2026, quickly followed by Anthropic, about building internal analytics agents. Meta's was interesting. I think it took them like a weekend to get the prototype out, and then it took them six months and 20 engineers to get to production. And I was checking with a friend, and I think it's about 12 people to maintain it constantly, which is a significant investment over the longer term. Anthropic didn't talk about the ongoing maintenance, but they're also on a similar journey. So from your point of view, where do you see things going? We have dedicated engineers who do nothing but maintain the analytics agent, the ambient learning structure, the model switch-outs, and all these things. What is your thinking?

Buying versus building, and avoiding vendor lock-in (18:19)

Arthur Wang

Yeah. My thinking is that reports of the SaaSpocalypse are greatly overstated. I think there's absolutely still a place for buying over building. A lot of people get AI-pilled and immediately think, "I'm just going to build everything. I'm going to let Claude run wild and replace all my products." But they quickly run into the crucible of production. You have to operate the thing. You get paged when it goes down. You get DMs when the answers are wrong. My personal philosophy is that, with the way things are moving and changing so quickly, each team has to find its own balance of buying versus building. It's no longer a binary. In the past it was kind of a binary, but what I see happening is more and more teams having a core that they build, buying around the exterior, and composing their stack out of that.

For us, for example, we use Snowflake, and we use Snowflake's agent as part of the core, and we use dbt as part of the core, and we delegate a lot of the things we don't particularly want to build to Snowflake. But we build some of the things that matter to us, like how we maintain our semantic layer, or how we manage our skills. That's what I see the future being. The key is that we're not buying everything and we're not building everything. That gives us the ability to be flexible. We can replace pieces of this if we want. We can buy something, or we can get rid of something and build it ourselves if we deem the purchased solution insufficient.

Lucas Thelosen

Yeah. One of the core principles I hold close is also the ability to switch out technologies, to switch out providers. We made the decision internally to switch from Claude Code to Codex, and we're going to switch back at some point. I think it's good to keep competition and keep the best one, to keep everybody on their toes. The ability to switch around is really important, so there's no more vendor lock-in like with the older systems. I don't want to name any particular names, but a German company, for example, from back in the day, locks you in, and then you can't move and you're stuck with their pricing and all of that. It's nice to see that I can easily switch from OpenAI to Anthropic. It's not quite as easy with databases, as you probably know. There's a bit more of a commitment there.

But as we build our technology, we have that as a core principle, that you can easily switch away from us if you ever wanted to. It's all openly accessible. I think the only way to win in this world, especially right now, is to be really good at what you do and continue pushing forward.

So we talked about analytics and the data team. In general, what is your philosophy of where things are going in the future of work? What are the skills people need to have as we more and more become architects and managers of agents? Where do you see things going there?

The future of work and moving up a level of abstraction (21:54)

Arthur Wang

Yeah. I'll talk mostly about data teams, but I think this applies to all roles in general, at least all white-collar work. To me it's clear that AI will represent an increasing share not only of how we do our work, like using Claude Code and Codex to build things, but also of what we create and build. Yes, we're using agents to build and test pipelines and data models and all that, but now, as we shared and talked about, we're building AI features and agents as well. I think this mirrors the broader tech landscape, and this is already coming to non-tech roles as well. I've talked to marketers who are building agents to do their work. Overall this represents all of us moving toward a higher level of abstraction and delegating more. Like you said, we're becoming more architects rather than getting into the weeds on things.

What this means for roles, like I said, is that roles are going to get broader and deeper. As we can delegate more, we can take on more functions into our own scope of work, but we can also get deeper into the things we're uniquely positioned for. I don't think all roles are going to blend into one. I think we'll still have specialized roles. It just means your ability to operate on your own is going to increase. An analyst isn't going to say, "Oh, I need this new column added to the data pipeline, so I have to wait for an engineer to pick up a ticket." Now they can just do it.

Lucas Thelosen

My cofounder always says that we're only limited by the clarity of our thoughts.

Arthur Wang

Yes. I think that's great.

Why attention matters more than time (23:36)

Lucas Thelosen

To that point, I started thinking more and more about attention being my currency. You became a parent. I became a parent a while ago. I have four daughters. As a professional, you're maybe struggling with balancing life outside of work and work, and you only have 24 hours in the day. So I started thinking about what actually matters more than the 24 hours I have, and that's the attention I have. The attention I give my child, the attention I give my partner, the attention I give my work.

I find that now that I have AI to do work extremely fast for me, I have this board meeting and I need to create a deck for it. The deck creation, a couple of iterations, takes 25 minutes. It used to be six hours, or I don't know, something like that, tweaking all these little things. Now it's only 25 minutes to do an amazing job on a board deck, but I need to pay very close attention. This can't be an 11 p.m. job where I'm burning the midnight oil to get this board deck done. This needs to be a 10 a.m. job, where I'm really mentally there. So I'm thinking more and more about attention, and how I can charge up my attention and what depletes my attention. Funny enough, of course, the whole foundation of LLMs is that attention is all you need, so I'm coming full circle to that. I'm thinking a lot about attention being our currency of the future.

Letting AI review low-risk changes so humans focus on what matters (25:10)

Arthur Wang

I agree with that. That resonates with me a lot. You can do so much more, and paradoxically your ability to get things done suddenly hits a wall sometimes. One thing I'm seeing is people gradually releasing their hold and deciding what matters most for them to actually pay attention to. I think that's also part of the future of work, releasing more and more to agents, and everyone developing more of their muscle for prioritization and picking your battles.

One way this manifests for us is that we've made a big push for enabling people outside the data engineering team to build anything, to contribute to our repos, whether that's dbt, Airflow data pipelines, semantic models, or agent capabilities. We started with analysts, but we're quickly expanding to engineers on other teams and even product managers. One way we do this, without us having to review everything constantly, is that we have an AI review system with auto approval, with thresholds and criteria that we're constantly tuning. That represents a conscious decision for us to say that this class of change, this type of change, with certain heuristics and rules, is something we're willing to be hands-off on. The other side of this is that we have plenty of deterministic checks paired with the AI checks to ask whether a change is safe. We'll check that your data model doesn't error out. We'll build the things downstream of that change to make sure they're not wrong. We verify things automatically in our CI systems.

That has really freed us up to dedicate our very limited, almost decreasing attention capacity to the things that matter most. That means the most complex changes, the changes with the largest blast radius, or the most sensitive changes, like data models that go before our SLT and the board. Those are the things actually worth deep human attention, and we let the people with the most context own the things that won't have as much of a blast radius.

Next projects and keeping the semantic layer from drifting (27:35)

Lucas Thelosen

Okay. Yeah, really interesting. This is along the lines of what I was going to ask, which was what projects you're excited about for the next three months or so. That's somewhat already aligned with this. Do you have anything specific you're excited to test out next?

Arthur Wang

Yeah, absolutely. Like I said, that's an ongoing project. The initial launch was a big project, and I didn't work on that myself, but I consulted on some of it. They did a great job, and they're constantly tuning it to bring more people into the fold and let more people participate, so that's going to keep happening. One particular project I'm very excited about is that we're partnering with one of our vendors to develop what they call a context calibration system. Essentially, it's a feedback loop, partly automated, for improving our semantic layer. We'll be tuning how much humans are in the loop on that. At the start, we'll probably let agents mine the traces and propose a change that goes through the normal PR process, and we'll approve. But perhaps in the future this might be fully automated. Who knows?

Lucas Thelosen

Yeah, that's super interesting. We have that in Orion, where it ambiently listens to team channels. If it notices something that might be added to the semantic layer, the context layer, or the decision context, we blur it all together and just call it context, but as it notices drift and changes, it suggests the change to the champion of the metric or the administrator of the whole instance. Having this constant feedback loop is really important. In leading the Looker professional services team, there was just so much drift happening that people didn't realize. Before you know it, three years in, everything is a giant mess, and you're just building new things because nobody knows how to maintain the old things anymore. So having the loops and the maintenance cycle is a really interesting feature, and AI can definitely help with that. We've seen a decent amount now of auto approval, where small, insignificant changes can be edited by the AI already, and major changes that affect multiple dashboards should be flagged. I haven't seen all that many products with that built in already, so I'm proud we have it, and I'm excited to hear that you're experimenting with that as well. I'm curious what your experience will be with that.

Well, this has been really interesting. One of my closing questions is, what would be your advice for your 25-year-old self?

Advice for a 25-year-old data professional (30:12)

Arthur Wang

I think the advice I would give my 25-year-old self is slow down. It's a marathon, not a sprint. Looking at myself back then, I alternated a lot between obsession with whatever the latest buzzword tech was and just coasting from burnout, not wanting to learn anything, just clocking in and out and not having any passion for anything I was doing. Sometimes I still feel both sides of that coin today, with how quickly our profession and our industry are changing. If I could go back, I would tell myself, you don't have to do everything. Not everything is worth doing. Slow down and think about what's really going to make a difference in the long run for yourself and your career, as well as for whatever your team is at the moment, and try to focus on moving the needle toward that, however incrementally.

Closing thoughts (31:00)

Lucas Thelosen

I think that's really good advice, especially today. When you feel like every day you're not on Twitter or whatnot checking everything, you're falling behind, which is really not true. I was part of the Google leadership when ChatGPT came out, and we all felt like, my god, all these things need to happen right away, and we only have months. Now we are here three years later, and the world has changed. Yes, it has. But it's years, and it moves, and it takes time. If you take a week off or so, you can come back and catch up again. So I think that's really good advice. Well, thank you very much. Thanks for joining this podcast.

Arthur Wang

Yeah, absolutely. Thank you again for having me. It was great catching up. And I love the name for the podcast, too, of course.

Lucas Thelosen

Directionally correct, yeah, that's all we can hope for.