Building Data Foundations that Last, with Ratheesh Kamoor

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 Ratheesh Kamoor of Warner Bros. about two decades in tech, from the dot-com bust to building data platforms for direct-to-consumer subscription products. They cover what makes a data foundation ready for AI agents, how to structure data teams, and where data careers are heading.

Ratheesh Kamoor is a technology executive and AI, Data & Analytics leader with 20+ years of experience building and scaling data-driven organizations, platforms, and intelligent solutions for global businesses. He specializes in bridging technology, data science, and business strategy to transform complex data into actionable intelligence, accelerate innovation, and drive measurable business outcomes.

Ratheesh currently serves as an executive at Warner Bros. Discovery, leading Data & AI initiatives that advance customer intelligence, analytics, and AI-powered business transformation. Prior to WBD, he held leadership positions at Disney and multiple startups, building high-performing teams and delivering data and technology capabilities at scale.

A passionate advocate for AI, generative AI, and open-source technologies, Ratheesh is focused on translating emerging innovations into practical business solutions that improve decision-making, unlock growth, and create lasting value.

What you will learn

• Why slow data is almost no data, and how lakehouse and lambda architectures help
• How to extend an existing data and ML platform so agents can run on it
• When a centralized, hub and spoke, or hybrid data team fits best
• How data engineer, analytics engineer, and product engineer roles are changing
• Career advice for early-career technologists in the age of AI

Chapters

0:00 Welcome and guest intro

0:17 From the dot-com bust to building data platforms

4:29 Why streaming was an early home for AI

5:44 Building a data foundation for AI agents

9:51 Centralized data platforms and a single semantic layer

16:24 How data roles are changing in the age of AI

21:32 Business and product skills, and managing agents

23:35 Career advice for early-career technologists

26:30 Is AI making everyone a manager?

28:36 More startups, more building, and bigger productivity gains

Transcript

Welcome and guest intro (0:00)

Lucas Thelosen

Welcome back to another episode of Directionally Correct. With me today is Ratheesh Kamoor. He's currently with Warner Bros., and he'll tell us more about his exciting journey in data analytics. Thank you so much for joining us.

Ratheesh Kamoor

Thank you for having me, Lucas.

From the dot-com bust to building data platforms (0:17)

Lucas Thelosen

Perfect. Let's start by having you tell us about yourself. How did you get here? You've had an interesting journey, and you're currently in the hotspot of data analytics in Seattle. So how did you get here?

Ratheesh Kamoor

I've been in tech for more than 20 years now. I went to school during the dot-com bust, and I still remember it. Remembering that dot-com time is important, because some of it is happening right now, and we'll talk about that later. I remember when I was in college around 2000, my professor used to tell me there was no point in learning any of this, because I was not going to get a job. That was a really fun experience. Fast forward, here we are, and we continue to make progress. We continue to have really interesting work coming along even after 22 years. We'll get to that. Whenever we talk about AI and how AI is changing the world, my memory goes back to that 2000 timeframe.

After my graduation, I spent more than 10 years, about 12 years, as an engineer. I started as a Java developer and became more of a Java architect, building various things. I never worked for large companies. I worked mostly for startups, building transportation systems, supply chain automation, identity management products, and things like that. I kept switching my domain from one to another for about 12 years.

Around 2012, cloud became a thing. Everybody started looking at cloud, and I became really fascinated by it. I decided to move my career toward moving workloads into the cloud. That was a really good experience as a technologist, going from on-prem systems to cloud, which is very similar to what's happening with AI right now. A big transformation is happening, right?

I moved into a lot of cloud technologies, and that went on for about five years. Then sometime in 2015, I got a call from ESPN. They said, "Hey, we want to build a new data platform ourselves. We want to get out of the vendor products, because building our own data platform and having our own data strategy is extremely important." I agree. Between 2012 and 2017, every company started saying, "We need our own data strategy. We need our own recommender systems and our own analytics platforms," and so on. I did not have any data experience. What ESPN was looking for was my cloud experience, because they wanted to build these data platforms in the cloud. I took that opportunity, even though I did not know anything about data platforms or Hadoop or Spark or anything like that. It was a really fun experience. We built the first data platform for ESPN, and eventually we used the same platform for ESPN Plus and then Disney Plus. We focused more and more on subscription products, and for the last eight years or so, my focus has been specifically on subscription products.

From ESPN Plus to Disney Plus to HBO Max at this point. I can share some of that experience in general terms. I don't want to talk about specific use cases we're working on right now, but in general, any direct-to-consumer product is very similar in nature when it comes to consumer data. How do we build the platform, and how do we use consumer data to optimize the whole lifecycle of the customer? That has been my life, 24 hours a day, seven days a week, for the last few years.

Why streaming was an early home for AI (4:29)

Lucas Thelosen

Fascinating. I often talk about how AI is now getting to B2B, but AI has been very much present in the streaming business. We all got used to Spotify telling us what the next song is that we'll probably like. It's automatic, it's magical. You get very used to it, but a lot of AI was put behind this early on to make it possible. I go into my HBO Max, I go into my Disney account, and it recommends things to me, and that's what I expect. No administration needed.

So it's really interesting to talk to someone who has been at the forefront at Disney and now at Warner Bros., working in data, which has been a data-heavy industry. Maybe you can talk a bit for our listeners about how data has been impactful. So many organizations stop at the business KPI dashboard. That's all they do, and some people are even struggling with that. But you can take it so much further, and you have taken it so much further. How have you seen it be successful? How do you really drive adoption of data? How do you create a data culture in an organization?

Building a data foundation for AI agents (5:44)

Ratheesh Kamoor

Absolutely. You're right. As a direct-to-consumer business, we're fortunate to have lots of data. We know everything a consumer does. We know what button they click, what page they go to and what they don't go to, how many movies they watch, and any offline interactions as well, like what email they opened or what push notification they received. We're fortunate to have tons and tons of data. That also opens up a lot of challenges for a data platform leader or data analytics leader. We have to run the data platform very tight when it comes to cost. That's part of the reason that in the last two organizations I've worked with, we always decided to build our own platform and also build use cases on top of that.

You slightly touched on top-level KPIs. That's absolutely important, and we continue to support it. I don't think it's any less important to look at top-level KPIs, even at the CEO level or any C level, on a daily basis. I would still say that's the number one use case for a data platform, because we're running a billion-dollar organization, and it's important to have that health check every single day. That is very foundational.

But data platform architecture is changing a lot. Lakehouse architecture is very common in our industry now, and in any industry with lots of data. We cannot just have data warehouses to build reports anymore. I always tell my team that slow data is almost like no data. If you wait a few hours or a few days to get a metric, the importance of that metric goes down. So we always put together a sort of lambda architecture running on a lakehouse architecture. That is very foundational at this point.

If you look at it right now, we don't really build a platform from a reporting perspective, to your point. We're looking at more AI-native platforms. We're working on how to take the existing platform we built for ML workloads and analytics and make it ready for agentic workloads. That's a common pattern you see in the industry right now, making progress on how to build agent systems on top of that. We definitely don't want to build a separate data platform for that. Data foundations have to be safe. I've been fortunate to have a really strong data foundation in my company and the previous company I worked for. But if some of your listeners don't have a data foundation, that's the first thing you have to have. That means a scalable data platform, a cost structure in place, cost governance, security, data lineage, and documentation. That is super foundational.

Then there's how to build an agentic platform on top of that, where you can build agents. We can go into the analytics area as well, but more than just analytics, how do you take actions when something happens in our data? How do you build those agents? How do you govern those agents? How do you keep track of what they do and how much they cost? That's something we spend a lot of time on these days, using the data semantic layer we have and building agents on top of it. Some of them are for analytics, and many of them go beyond analytics.

Centralized data platforms and a single semantic layer (9:51)

Lucas Thelosen

You talked about the infrastructure that's necessary for it all to work, but how do you get the business to actually use the data and take action? What is the most impactful thing? Is it the Monday morning report that's prepped and ready to go? Is it that for every single meeting, the teams have clear definitions of their KPIs? Do you push it into their teams or Slack? How do you think about getting it to the business and allowing the business to interact with it?

Maybe also organizationally, do you think of a hub and spoke architecture for your teams, where you have spokes of analysts in each team? Maybe we talk first about the organizational structure you've seen work really well, and then how we actually get the business to listen to data. Of course, it helps a lot to have a leader who is very much into data.

Ratheesh Kamoor

That's a really good question. I don't think there is one answer to that. I've worked with companies where the data organization is all centralized. I've worked with organizations where it's completely decentralized. And I've worked with organizations that have multiple data platforms. So I don't think there is one answer, but at a high level, I do think we need a single platform. That's non-negotiable. I've seen organizations where marketing has one platform, ad sales has another, and subscription or finance has another. In my opinion, that is way too much. At least from a consumer data point of view, it's important to bring all the consumer touchpoints into one place and create a single semantic layer.

I believe the organization that puts together that platform and the data semantic layer is better off centralized. We obviously collaborate with various stakeholders. We get requirements from more than 50 different tech teams, product teams, and business teams, and we work very closely with all of our partners. But I do think creating a single semantic layer across the organization is extremely important.

Lucas Thelosen

Would you say that, because a lot of companies have acquired multiple different companies over time, and some companies have multiple brands underneath them, this is still true for those kinds of organizations? Or if you have different brands, is it okay to have the platform unified just within a brand? Or do you think it needs to be across brands?

Ratheesh Kamoor

That's a good question. I would ask the leadership what the business strategy is. When large companies acquire other companies, sometimes they intentionally keep them separate. You don't want to mix them together, because sometimes you're buying a company because you see value in it, and you see that it should run independently and run faster. It should not be absorbed into the large corporate environment. If that's the reason, then yes, maybe it should have its own data platform.

But if you look at a meaningful acquisition, there are reasons behind the acquisition to create a 360-degree view of consumers. Say I bought three companies, all of them direct-to-consumer, and they're running independently. That's totally fine. But as an enterprise organization, you need a customer 360. You need to understand what a customer has been doing across these three different companies. Then we probably should look at a centralized platform, at least to bring those consumer signals together. Otherwise, any kind of cross-brand promotion or cross-brand monetization will be really, really hard.

So you brought up a good point. It depends on the organizational structure and on what you're optimizing for. As data leaders, we always push for a single platform. But what you're touching on is the reality. Sometimes you will have a hub and spoke architecture. And going into how you use the data, that's a very different scenario. I've seen a model built by the marketing team, and I've seen a model built by the finance team. In some scenarios, that has been good. I have teams building models for the marketing team and teams building models for the finance team, and I also collaborate with business teams that build their own models. I call it a hybrid model, because it depends on whether they have the capability and the know-how. If they do, we enable them to build the models, analytic solutions, reports, and things like that.

So we are not adamant about how we should set up the organization. It depends on what capabilities and know-how each of these teams has. Some teams have come to me and said, "I don't want to build this capability. I just want you to build this and serve it to me on a daily basis." I also have teams coming to me and saying, "I know what to do, just give me access," and we enable them to build the models and analytic solutions. That's totally fine. I usually call this a hybrid model.

Lucas Thelosen

Perfect. I was smiling because we got acquired, Looker to Google, in 2020. At Google, and I can probably share this freely, when you want to sign in to check your benefits or your pay stub, you have to authenticate, and for a brief moment you see YouTube in the URL. That acquisition happened so long ago, and it still authenticates through the YouTube brand. It's like, okay, Google, that's funny. Sometimes you acquire a company and they do things better than you do, so you use pieces from their stack. And it's funny how...

Ratheesh Kamoor

That's a good point. I think the mantra there is whatever works.

How data roles are changing in the age of AI (16:24)

Lucas Thelosen

Exactly. So we get to an interesting topic that's on a lot of people's minds, which is team composition and careers. Where are we going? You talk a lot about setting up the models for your different teams, so I imagine you're a very data-engineering-heavy organization. What will those roles be in the future? I talk a lot about the semantic layer, but there's also business context. As we get things ready for agents, we may have to curate the business context a bit more, the skills, those kinds of things, which goes beyond just data engineering. How do you think about it? Where do you think things will go in the future? Maybe the business context should be created by the business instead of the data team. I'd love to hear your thoughts.

Ratheesh Kamoor

If you look at the time before Gen AI specifically, I'll start from there. Say three or four years ago, a large organization would have some percentage of people, and I don't want to put a number on it, maybe 10 to 20 percent, as software engineers building a data platform. Then you would see a large population of talent usually titled data engineers, maybe 20 to 30 percent, responsible for bringing data into the platform, building the semantic layer, and creating lineage and glossaries and those kinds of things.

Depending on the organization, some have a title called analytics engineer. Analytics engineers are responsible for creating metrics. They are still engineers. They know SQL very well and Python a little bit. Maybe they are not as strong as data engineers. They may not know Spark very well, or the ins and outs of Flink or Spark. But they are much closer to the business requirements, and they know SQL and Python and so on to create those metrics. Then some organizations have dashboard developers. Some may not have that, because that's moving more to the business side, and a lot of it is becoming self-serve. Then there's a large portion, maybe 40 to 50 percent of people, who are usually data scientists or ML engineers. Data scientists start building models, and the models are productionalized by ML engineers, who do MLOps and things like that. There are various ways you can set up an organization.

Now, you're touching on this context layer. About two years ago, I heard the term prompt engineer. That did not last long. It lasted probably six months. Luckily, we did not offer any of those roles, though we are a little bit slow at rethinking titles. I was looking at the job portals wondering what on earth a prompt engineer is. Now there is a new term called context engineer.

I would think about it a little differently. What we are doing in our organization is trying to make our data engineers, analytics engineers, software engineers, and ML engineers do more and more Gen AI. That's relatively easy, in my opinion. If you have a strong software engineering background, learning LLMs and how to build an agentic platform is not that hard. So I would still say software engineering and all of these titles are very important, but how you look at the work is very different.

I'll give you an example. If you're an analytics engineer or a data analyst, knowing SQL is still important, because you need to know what logic goes into the code. You still need to know that. But it's not enough, because arguably the newer models can write better SQL than you could by yourself, or Python code or any other code. So knowing tools or languages is still necessary, but it's not enough. If you look at the industry, there's a term called product engineer. That means you need to know the business. How do you use that code? How do you use the data? How do you create an outcome? Those things are extremely important. So I think more and more that every title, no matter what you call yourself, whether software engineer, data engineer, ML engineer, or data scientist, requires knowing the business and the product and how to make an impact. And you use AI to move really fast. You can move 10x faster right now, and that will be an advantage in my opinion.

Business and product skills, and managing agents (21:32)

Lucas Thelosen

It's interesting to hear. I come from the business analyst side. I started off in spreadsheets. I built beautiful spreadsheets, and I thought that's all people ever needed. You started off on the engineering side, so it's interesting to see these come together. I talk a lot about data product management and how to manage data with a roadmap in your organization and plan out for the future. You think a lot about data models and building the foundation for it all to happen. I do think if you can do both, if you can bring business and product together with the technology, then you're in a really fantastic spot. And what those titles will be called in the future, sometimes I wonder if it will be something like the COO of agents, the operations person coordinating all of that. That could be one.

Ratheesh Kamoor

You can have so many agents working for you in the background, for sure.

Lucas Thelosen

And then you have to keep an eye on them. We have people moving on who still have six agents running, and who knows what they're doing. You have to actually pay attention to all of that and make sure there are not three agents doing the same job. There has to be some centralization to it. It's going to be quite interesting over the next year as we all get used to this world of being managers of agents.

Ratheesh Kamoor

We are actively upgrading all our existing systems so that they can either interact with agents or react to what agents are doing. A good example is that we have an existing FinOps program in the data platforms area. We are integrating it so that FinOps reports how many agents are running, how much money they're costing, token cost, and things like that. And if something goes wrong, how do you kill that agent? My point is that all of these existing systems will still be valuable, but you need to look again at how they work and how to make them agent-friendly.

Career advice for early-career technologists (23:35)

Lucas Thelosen

Absolutely. In the world we're in right now, what advice would you give someone who is early in their career? Maybe yourself. If you were back in the dot-com bust, what would you say in 2026 or 2027? What should you do?

Ratheesh Kamoor

I think the big learning for me during the dot-com bust is don't lose hope. If you look at the tech industry, it has always been changing. Every five or ten years there's a new big thing coming, and there's a narrative of, okay, everything is ending, and there's no use learning anything now. I don't really agree with that, because the foundations are important. I would still learn computer languages and how to code, because even if you use AI, you still need to know what's going on underneath. It is extremely important to know that. But going back to my previous comment, that's not enough. I tell my kids as well, work hard, learn, learn more, be curious, and learn new things all the time. Everything is still valid.

I still think learning computer languages is needed, even though we will use AI to generate code, and agents will mostly manage that code very well too, hopefully. It is still extremely important to know the ins and outs of computer systems, if you want to be an engineer. The only thing I would say is that learning languages and tools is not enough. Pick a domain and be really good at that domain. If you're 25, you can start your own company. You don't need to hire too many software engineers. You can start a one-person company, hopefully. Those kinds of things are fine. And at the end of the day, make AI your friend, not your enemy.

If you look at Main Street, there is a lot of narrative around people wanting to go against AI. I don't know if that's a good idea, because the technology exists, it continues to evolve, and it continues to be adopted across enterprises. I don't think anyone can stop it. Bringing AI to your side and using it to your advantage is extremely important. You can see that in 2010, when cloud came in, there was a lot of discussion around, we don't need systems engineers anymore. Those kinds of things are usually what I call a narrative, maybe not the reality. So I'm still very hopeful about the future for tech professionals. You can call yourself whatever you want, software engineer, data scientist, or ML engineer. I think we can all move faster with AI, learn to use AI, and move fast. That's what I would say.

Is AI making everyone a manager? (26:30)

Lucas Thelosen

When I was early in my career, I really wanted to be a manager. I was very ambitious. I wanted to be a manager really fast. I realized there's a lot of benefit to actually being the person doing the work. One of the things that stuck with me is that when I became a manager, it was actually really hard for me to let go of doing things myself. I think there's an analogy here to the current state of AI, where you now have AI doing the work for you, and you need to manage it very closely. You need to pay attention to it, and you need to be able to spot mistakes and notice when the overarching architecture is going sideways. So I think your path to becoming a manager is vastly accelerated. How can you make sure that by the age of 24, whatever it might be, you're a really good manager? That's how I often think about all these AI agents doing work for you.

Ratheesh Kamoor

That's very interesting. You're probably a manager of all the agents. Maybe not of people working for you. I'm just joking. I don't completely agree with that. I think if you need to scale, you still need more people. People with AI skills, in my opinion.

Lucas Thelosen

I do think so too. I still see a lot of people hiring, and everybody is still hiring. Yes, we can all be more productive, but so can your competition, and now the bar is just being raised. So I'm not necessarily worried about the job market as a whole. You have to be able to pay attention to the outcome of the work and criticize it, because it looks really, really good. It's funny, my kids and I just got this book. It's a kid's book, but it's completely AI generated. We didn't pay attention on Amazon. It was only three dollars and fifty cents. And they're finding all these mistakes in the book. It's spot the mistakes, and they're having such a blast finding them. I'm like, that's actually a really good skill.

More startups, more building, and bigger productivity gains (28:36)

Ratheesh Kamoor

Absolutely. And to your point, if we can build more things faster, you will see more startups, and we've already started seeing it. There are so many startups popping up really quickly. On the enterprise side too, if we can build more, we build more. We don't build less. It's not like you back off. You can see a huge productivity increase in the developer community, and we see close to 80 percent productivity increase in production support type jobs. Because then what do you do? You move those people to build new things. You don't need to spend a lot of time supporting the system. You're not going to stop building. You'll still build more features, and faster. So that's going to happen on the enterprise side too.

Lucas Thelosen

Well, thank you so much, Raj. This was phenomenal. This is a great podcast, and I think people will really appreciate it. Thanks for joining me here.

Ratheesh Kamoor

Thank you so much. Thanks for having me.