Data Analytics Chat

Why Every Company Needs a Data Platform Strategy

• Ben Parker

Share episode

Send us a text

In this episode of Data Analytics Chat, host Ben Parker interviews Manoj Mohan, an engineering executive with experience at Intuit, Meta, Apple, and Cloudera. Manoj shares his journey from software engineering to data leadership, offering invaluable insights into building resilient data platforms and driving innovation in the world of data and AI.

Manoj discusses pivotal moments in his career, the challenges of moving from technical roles to leadership, and the importance of learning from both successes and failures. He emphasises the need for a data platform strategy over simply assembling a stack of tools, and shares practical advice for newcomers and leaders alike. The conversation also covers the pitfalls of focusing on quick technology wins, the critical role of governance, and how to future-proof your data strategy in an era of rapid AI advancement.

00:00 Treating Data as a First-Class Citizen
01:19 Welcome & Guest Introduction
01:46 Manoj’s Career Journey & Background
02:45 Transition from Software to Data Engineering
05:06 Moving into Engineering Leadership
07:11 Advice for Newcomers: Learning & Unlearning
09:12 Defining Moments in Manoj’s Career
12:05 Lessons from Career Setbacks
15:03 The Importance of Data Platform Strategy
17:18 Data Stack vs. Data Platform Strategy
21:06 Evaluating and Choosing Data Tools
24:04 Why Companies Buy Tools Instead of Building Strategy
27:13 Real-World Example: Great Stack, Failed Strategy
30:00 Governance and Business-Tech Alignment
33:00 Building a Scalable, Future-Proof Data Platform
36:00 The Role of Data Platforms in AI & Innovation
41:00 Final Thoughts & Farewell

Thank you for listening!

manoj mohan:

if you don't treat data as a first grade citizen, you will end up creating data silos, brittle integrations that don't scale. let's not treat data as a stack of a collection of tools. Instead, let's think of it more along the lines of a platform as a product mindset. Always be willing to learn and unlearn because, we have seen technology revolutions take shape. And sometimes also repeat over time. So there are nuggets of wisdom that you learn and apply as principles and in other instances you would, you would unlearn some of it. And similarly, the other things I would say is focus on, the problem solving part of it. You wanna truly focus on the problems that are the biggest pain points for your customers, for your stakeholders that you're trying to solve for. And then once you have identified the problem statement, you wanna solve for it with a bigger lens.

ben parker:

Welcome back to Data Analytics Chat, the podcast where we discuss the world of data, ai and the careers shaping it. I'm your host, Ben Parker, bringing you real stories, expert insights, and practical advice to help you thrive in this data-driven world. Today I'm excited to welcome man Mohan engineering executive who has worked for some of the leading companies such as Intuit, meta Apple, and Cloudera. In this episode, we'll explore his exciting career path, his pivotal moments that shaped his career, and discuss why every company needs a data platform strategy and not just a data stack manoj. Welcome to the podcast.

manoj mohan:

Hi Ben. Thank you for having me. Excited to. We here?

ben parker:

I'm looking forward to the conversation. So I'm just dive into the sort of question. Do you wanna introduce yourself and give a bit of background to your career journey manager?

manoj mohan:

Hello everyone. Manoj Mohan here. I am an engineering leader focused on making data and AI useful in everyday products. things like faster onboarding, smarter recommendations, safer and scalable, AI ML workflows or things that I do on a day in, day out basis. I have left globally distributed teams across several different companies with a key focus on building modern data stacks, ML ops, developer enablement. I structure teams for clear outcomes to double down on product velocity, building reliable platforms and experiences that customers can trust. that's a quick intro about me.

ben parker:

Brilliant. And you started your career more in the software field, didn't you? So how have you found that, that transition into data?

manoj mohan:

great question. I started my career mostly as a software engineer slash data engineer building ETL jobs, day in, day out, and, started running into a similar problem. Every new product or business team that we were working with wanted something different, and every time we ended up building a new flavor of the pipeline and metrics. it was more like extending a duct tape, not something that could automatically scale. over the last two decades, I've been lucky to lead several engineering organizations at large enterprises. Scaling systems that handle, billions of transactions. And in each of these roles, the realization for me has been that if you don't treat data as a first grade citizen, you will end up creating data silos, brittle integrations that don't scale. this was the origin that inculcated the platform mindset within me. How do you focus on building a common governance model? How do you think through about data discovery right from the start? How do you bake and self-serve capabilities as part of your design and things like that? by being able to instill such a thought process within the teams, the organizations are able to move a lot faster without having to reinvent the wheel. For me, the paradigm shift and the learning has always been, let's not treat data as a stack of a collection of tools. Instead, let's think of it more along the lines of a platform as a product mindset. that's how I have progressed and the whole. Volume, the scale of data has always fascinated me and I ended up spending more and more time on building and managing data platform stacks.

ben parker:

Brilliant and interesting to hear. So obviously you're coming from a technical background. How have you adapted to moving into leadership? Because that, that's a big challenge. There's so many tools, technologies out there now that businesses are using. How have you, how did, what was your journey to adapt that skillset?

manoj mohan:

you brought up a couple of things, Ben. Why move, why transition from an engineer to an engineering leadership? that was the first part of your question. For me as an engineer, I could define and own all of the outcomes. However, the extent of impact I could bring to the table would be very much limited to the 40 hours of work I would put in. And for me, the gratification was to deliver bigger, broader, more exciting things. And what that meant is I had to work with a team, collaborate with cross-functional partners. that's what encouraged me or excited me to pursue engineering leadership in the first place. And the way I think about engineering leadership on how I deliver value is a couple of different things. One, lead with clarity, lead with vision to focus on building high performing, highly engaged. Engineering teams. And three, once you have the vision for the longer term target state on what you're trying to build, how do you break that down into more modeler incremental outcomes? And that way you're able to accelerate on getting to that longer term target state. that's how I think about the engineering leadership aspect. happy to add more color if you have any questions there.

ben parker:

Look, you've got amazing profile and obviously delivered some, massive projects for these big companies. I guess for newbies, I guess new to tech, how would you, what advice would you give them to go about learning?

manoj mohan:

What advice would I give them with respect to learning? Maybe a few nuggets, if I may share. One. Always be willing to learn and unlearn because, we have seen technology revolutions take shape. And sometimes also repeat over time. So there are nuggets of wisdom that you learn and apply as principles and in other instances you would, you would unlearn some of it. Like we have seen. The databases the database world evolved from relational and highly structured to becoming more unstructured. And then again, travels back to being more structured and things like that. That, that learn and unlearn, I would say is one capability. And similarly, the other things I would say is focus on, the problem solving part of it. You wanna truly focus on the problems that are the biggest pain points for your customers, for your stakeholders that you're trying to solve for. And then once you have identified the problem statement, you wanna you wanna solve for it with a bigger lens.

ben parker:

Brilliant course. Some great advice there and know a lot of people are trying to get into the field now. Amazing time to be in the industry, isn't it really? it's that advice would be really beneficial to the listeners. I guess move on to the next question then. So if you had to pinpoint one or two defining moments that changed your career, what would they be?

manoj mohan:

Great question. I think one of my early early discoveries was when I started working as a data engineer for one of the large scale data warehouses. We had several different scrum teams, each building their own siloed data pipelines, their own definitions and on. what happened was on paper we were working on a very sophisticated data stack. With the latest and greatest of tools. But in practice, every project was more of a one-off scenario. When our business stakeholders came back asking for a particular KPI what's our real customer churn rate? We would end up surfacing several flavors of answers instead of one consistent metric. in essence, we had not built out a shared consistent data foundation. We were only reactively catering to the individual asks from our business stakeholders. that was one early, learning through one of the initiatives I had worked on. The second one was much later where I led the modernization efforts to re-engineer a cloud native data stack. We were moving from a mix, a fragmented mix of Vertica and Hadoop and hive running on EMR. Two more of a near real time intelligence platform capable of supporting AI driven personalization for, millions of customers. And as we launched this initiative in production, one of our product managers made a remark along the lines of something your team's work has reduced the time to market for a new feature from several weeks to potentially just one week. this. Second experience was more of a truly aha moment. That gave me the realization that a well-designed data platform isn't just a backend asset. It can truly be an accelerator for your business goals. these two experiences, one early on of the pain of fragmentation. Learning from it. And two, the transformative impact of a unified consistent platform pretty much shaped up my thinking and operating principles. And that is what essentially convinced me that every company needs a data platform strategy, not just a stack of tools solving for their data needs. Essentially the tools can change every few years, but whereas a resilient platform if built right, would become the core part of your company's operating DNA. that's how I see it.

ben parker:

Amazing. That's good to hear. Then I guess those aha moments in your career, they're really powerful, aren't they? Because they stick with you forever. And it's that's a massive learning in your career, and that's just gonna build confidence with yourself.

manoj mohan:

Yeah, absolutely. I think the massive successes as well as the massive failures or the, or not so great failures. I see all of them as a learning opportunity. In fact, every crisis, I see it as a learning opportunity. And if you're able to learn and invite the values from even your failures, that just makes you more resilient and that just enables you to succeed in a bigger way in future.

ben parker:

Yeah, definitely. Like any learning the small wins, the big wins, you stack them up. Over your course of your career, that just adds to you and obviously your knowledge gain is gonna be, yeah, something strong and that's going to just add to your credentials and obviously love. Now you are into more leadership now, then that just builds, you can provide that guidance and knowledge and share with your team members, can't you?

manoj mohan:

absolutely. I think we, be it any of our engineering processes, be it any of our, operational excellence reviews. We try to do the postmortem and through the postmortem we try and learn and build out our good operating principles. And over a period of time you realize that if your good operating principles cover for the biggest of the hurdles you have run into in the past, you have naturally improved your processes and become a lot more resilient as a team. By just learning from your early on mishaps.

ben parker:

So then have you ever faced a like major career setback?

manoj mohan:

absolutely. I think and if I think about it, it ended up being one of the most valuable learning moments of my career. Let me add some color to it. early on in my career, I was leading a large scale initiative at a high tech manufacturing company. The goal was to modernize our data stack, move to, a fancier set of new tools, state-of-the-art pipelines, make our dashboards prettier and all of it. we ended up delivering all of it. We hit our project milestones. We launched all of this in production for our users and celebrated our milestones. However, after a few weeks. While reviewing the adoption metrics, the usage of those dashboards, we got to know that was at an all time low. Talking to our stakeholders, we got to know that the users were actually struggling to make sense of the new dashboards and the computations within the KPIs. And we had done a not so great job of handholding and educating the users along the way. that was a big realization post launching it in production. And the realization was that our failure was not really about the tools or the technology because we had approached it, we had approached the whole project along the lines of a stack upgrade or a tools upgrade, an infrastructure upgrade. Instead of actually investing in building out some of our common entity definitions building out the data discovery capabilities and self-serve capabilities and so on. So what had happened was we had missed out on the opportunity of potentially transforming building the foundation of a platform that could have truly quadrupled the impact of our stakeholders. So this was a huge learning lesson in my opinion. That we got to focus on the overall data platform strategy, and that is so much more critical, so much more valuable as compared to doubling down on a technology or an infrastructure stack upgrade, because eventually your platform strategy is your long term competitive mode. Yeah.

ben parker:

So looking back, how did you deal with stakeholders at that time? Because it must have been Yeah, challenge.

manoj mohan:

Yeah, great question. Most of the companies I have worked with, we adopt something called as a a triad leadership model. Where you identify an engineering engineering. You identify the product manager and you've identified the user experience lead, and you try and do this at every level of the organization, and between the three folks or the, between the three partners, engineering, product management, and user experience, you get to own and deliver the entire platform roadmap, the product roadmap, the product capabilities and so on. So that's one that's been an integral part. That's helped immensely. Along with building out the rigor of maintaining your product backlog comprehensively learning from the customer, VOCs and and ruthlessly prioritizing so that you're truly focused on the most critical aspects of enhancements or features or bug fixes that have been requested that can deliver the best value for your users. Yeah.

ben parker:

Okay. Brilliant. And yeah, thanks for the information there. So I guess in today's competitive industry it's, yeah, it's a lot of people competing. Do you think has given you a genuine edge?

manoj mohan:

Okay. Great question. So I believe one of the things I do as a engineering leader is. To focus on the product centric pain point as a first step, and then apply or bring my technology hat into the equation. So typically I would start with the outcome, translate that outcome or pain point into a simple set of testable bets, and then try and use the lightweight technology solve for us to get there. And applying this lens enables me to balance the value proposition for our customers, for our business stakeholders, and for the team. And it also enables that, for me to switch between the overall forest view as compared to the tree level execution and be able to balance it based on the need of the hour. If I wanna, if I may quote an example, I would say. Like when we were de, when we as a team were debating about how to best integrate AI assisted workflows I encourage my team to focus on one of the real customer pain points to begin with rather than let's just bring LM into the mix approach. And by doing this, we were able to narrow down a specific pain point. We identified a set of baseline KPIs on how we would measure the progress, and subsequently we then leveraged the right foundational models that did a significantly better job as compared to our existing, ML model that was you running in production. So this not only made our users happy because they saw how their pain point was getting alleviated. But it also reduce the volume of support tickets for our engineers. So I think that approach has possibly given me a much better edge over the years.

ben parker:

Brilliant. I love that.'cause it's, yeah, business first. So many people out there. Again, going the tech first and then trying to find a problem when it's, you should stick to the business objective and then use tech as the tool to create a solution.

manoj mohan:

Yeah. Yeah, absolutely. Yes.

ben parker:

It's, it is just funny how many people do it the other way around or, and especially speaking to a lot of businesses that just, I guess now everyone wants to jump on the LLM hype and obviously know why else is gonna pretty, it's, yeah, it's impressive. But again, you need to actually have your business objective in mind. First.

manoj mohan:

Yeah, it's always good to start with a pinpointed, pain point, right? And if you have ways to measure or quantify that pain point even better. And if you don't, I would strongly encourage you to be able to baseline it. With some sort of measurement that accurately depicts that pain point, because then you can keep the integrity for the team and the honesty that you know, to what extent you're able to solve it and improve that pain point. By, by, by reducing that footprint. Yeah.

ben parker:

Brilliant. Cool, cool. No, I really like that. And, okay, let's move on to the data topic. So we're gonna look at why every company needs a data platform strategy and not just a data stack. So I guess, do you wanna start off with just mentioning what's the difference between a data stack and a data platform strategy?

manoj mohan:

Sure. Sure. A data stack, I would say is the collection of tools that you are leveraging to store, to process, and to visualize data. It is, think of it along the lines of having having a garage full of expensive sports cars. But you don't have, you're not focused on the roads, you're not focused on the traffic rules, and there is no GPS or no infrastructure, right? So it looks great, it looks impressive, but it's not going to get you from one place to where you really want to go. Now, if you think about the data platform strategy, on the other hand. The data platform strategy is all about building the right infrastructure, building the right governance model, building those shared foundational capabilities that will enable every single team to adopt the same paved path and accelerate on their outcomes when it comes to, whatever outcomes you're trying to generate from that data. So that's how I see the distinction. And, the stack of tools as your data stack can potentially change over time which is very natural with the fast pace of technology. But the platform strategy ensures that there is consistency and there is standardization across the entire company, even if there are multiple engineering teams and all of these teams align and moving in the same direction. Now to the second part of your question as to why does it matter? If you don't have a platform strategy, every new tool that you bring into the mix is going to add to the noise. You might speed up an individual team with a new tool, but you're not increasing the overall velocity of the organization. If the focus is to improve that overall velocity of the organization, the right platform strategy is super, on the critical path. It becomes the connective tissue that accelerates decision making, enables AI readiness amongst many other things and potentially turns your, all of your data from being a cost center to being a competitive mode. For your company? Does that answer your question, Ben?

ben parker:

That's brilliant. I was just thinking. How do you go about evaluating the data stack then?'cause there's so many tools out there now and new ones getting released. So I guess what's been your advice into choosing the right tool or tools? I.

manoj mohan:

great question. And I don't know if I have. Definitive or a single line answer for it other than, saying it depends quite a bit on the use cases and what they're trying to solve for at that point in time. my guidance would always be one. In terms of data stack, in terms of the problem statement across your organization, you might want to, one, prioritize. Ruthlessly on what you immediately want to solve for, right? Carve out the longer term vision and the target state, but then break that down into what do you really want to raise their focus and solve for in the immediate future? And in that landscape of problems. Evaluate, build versus buy evaluate or do quick POCs on some of the state of the art tools and technology stack. And evaluate them for feasibility. Evaluate them for your use cases, your functionality needs that are critical, and then make a wise investment. Is how I would suggest it. And as you do all of this. It's also important to ensure that you're not losing out or reactively thinking about the platform strategy, because typically the platform strategy is what takes longer time to evolve. You wanna make sure you wet out the governance model, you wanna wet out the shared services capabilities. You wanna vet out how you're thinking about the lineage and tracking and things that. this is how I would approach it. I know I'm giving you a. Fairly hazy answer, but that's how I would approach it.

ben parker:

I appreciate that and this okay. Challenging one, isn't it? Because every business has got different use case. And I've got, obviously there's so much out there now, isn't there? I think if you put the tools, technologies out there, especially all the different components to a data project now, there's so much that needs to be integrated into a complete solution. I guess it is a constant learning and I guess another. Area learning, isn't it? Within the business, you need to keep adapting these new technologies, being aware or new products that are out there. Kicks on your toes,

manoj mohan:

you're bringing up a really valid and problem because. Typically what happens is buying a new tool always feels like instant progress. Something along the lines of instant gratification on social media, right? A lot of the demos from the newer state of the art tools makes it look like you can solve all your data problems with. Leveraging the, that new tool, however, that, might or might not pan out for the landscape of problems that you're trying to solve for. And that's where, that's where you'd never want to rely on a tool or a stack of tools to solve all your problems. You truly want the strategy aspect not to take a backseat because all of these tools. Will depreciate over time. Whereas if you have the right platform strategy that will compound over time. And that compounding effect is going to make it more and more of a competitive advantage. And the further you delay it the farther away you are from having that competitive advantage.

ben parker:

Okay, and so why would many companies focus on buying tools rather than designing a long term data platform strategy?

manoj mohan:

Can you repeat that, Ben one more time?

ben parker:

so why do so many companies focus on buying to tools opposed to designing a long term data platform strategy?

manoj mohan:

a lot of times what happens is you buy a tool, you get it implemented, and over the years you have accumulated a lot of tech debt that's been unresolved that. Unresolved technical debt translates to massive magnitude of work. If you had to get it all resurrected to the original state. Now that's when companies typically think about, okay, how do I make a quick win? How do I get rid of this technical debt without having to invest time, energy, and effort in solving for it? And they start evaluating. Tools, the latest and greatest tools so as to make instant progress so as to not solve for all the tech debt and get the gratification of, hey, I have, eliminated all of my technical backlog, tech debt, and I'm solving for the latest and greatest. However, that truly does not happen, Because tools are tangible, tools are easy to buy. Tools are easy to show as a quick win. However, if if you are moving from one tool to another, and if you don't have an overall strategy on how you're going to manage that data, how you're going to govern that data, that's only going to backfire over some time over the elongated time window. So that's been my experience. what, irrespective of the tools. You want to stay focused on the instrumentation part of it, the shared foundations part of it, the governance part of it, the lineage part of it, the easy discoverability part of it, because all of these things are what are capabilities that you will always have in terms of consuming the data across several use cases, and if you solve for all of those capabilities. Then you have automatically, created means for the organization to thrive for leaning in on that particular use case and solving for it as compared to expecting some tool to solve for all of this, which rarely happens.

ben parker:

Yeah, no, I think it's obviously you speak to a lot of companies and you do go down the buying tools route. Yeah, I guess it's, there's challenges I guess across the all businesses, isn't there really? And I guess it depends, I guess a bit, I guess a big factor is speed, isn't it, as well? If you buy and talk technologies, it's gonna be a quicker turnaround, isn't there?

manoj mohan:

I think you, you think of it as a quicker turnaround. You think of it as an instant gratification but it probably solves for a much smaller fraction of your use cases. And for the heavy lifting, for everything else, it's going to take you significantly longer effort. And by the time you realize it's too late. It's too late in the equation.

ben parker:

Okay, perfect. So do could you share an example of a great data stack, but that's failed due to a lack of strategy?

manoj mohan:

Sure. And I think a lot of companies would resonate with with something like this. A few years back I was working at one of the large consumer app companies and they had invested heavily. What most folks would call a best in class data stack. They pretty much had everything like real time streaming to a data warehouse, a modern transformation layer, machine learning notebooks, beautiful dashboards, and on paper it was all super impressive. However the platform strategy was missing in this whole equation. Each department would define their own core metrics, and they had created their own silos in the interest of moving fast. Each of the go-to market functions like take sales or marketing, had their own definitions as to what constitutes an active customer. And this active customer definition would not reconcile when data scientists from across different functions would be trying to, come up with the right feature definitions for their ML models. Eventually, this came to a point where the teams would summarize their metrics, go to higher up leaders and when the leaders got visibility into these siloed versions. They realized that these numbers don't tally up or reconcile. the realization the fallout was pretty expensive because eventually we had several different flavors of metrics and the act of reconciling resulted in a lot of redundant work. There came a time when there was some trust lost within the data team and the KPIs. And the realization for me was none of this was related to the tech stack or the technology aspect of it. It was mostly because the tools had been put in place without the right governance, without those shared definitions I was talking about earlier. Essentially the core elements of. What constitutes a platform strategy? that experience and everything that I learned from it, I tend to repeat that with my teams because repetition never ruins the prayer. my storyline now is a great stack without the strategy, is going to fail sometime or the other. And it fails in ways that undermine the confidence of all those data stakeholders. And when that happens it's going to take ages for us to recover from something like that. that's the story. Yeah.

ben parker:

and it just shows you governance is so important, isn't it? It's one of them topics that's, it's, it's gaining way more popularity, but it's, I think there's a lot more needs to be done with business on governance because it's, I guess it's not, it's glamorous as other areas, but it's so important I think for businesses to get that right. And then this can mitigate risks and errors.

manoj mohan:

Yeah. Yeah, absolutely. And there are a ton of different tools that solve for data. A governance as well. However, you can't really look of data governance as a standout capability because it has to seamlessly embed with all the rest of the, rest of your infrastructure, rest of your tooling, rest of your instrumentation and things like that. So that's when it derives the best of value. Yeah.

ben parker:

Yeah, and like situations like that obviously, was there like a fallout between business and tech?

manoj mohan:

Say that again, Ben.

ben parker:

Was there like a, let's see, a fallout between business, the business side, and tech on that sort of example, you just give.

manoj mohan:

Yeah. I think the best approach is where you have all the stakeholders, accountable stakeholders, and the decision makers working in conjunction by defining the core of those pain points that you want to solve for. Like there have been instances with large enterprises where, business tries to solve for it on their own in a siloed manner or the technology team tries to solve for it in a siloed manner. And I have seen both of those approaches fail miserably over time because, because then. The governance in itself has been limited to a much smaller finite boundary instead of, solving for it in a holistic manner. Working connected at the hip, working as accountable partners, identifying the right priorities and solving for it systemically is what derives the best value for an organization.

ben parker:

Yeah. Brilliant. I think communication is yeah, key, isn't it?

manoj mohan:

Yeah. Yeah, absolutely. Yes.

ben parker:

So how should companies develop a scalable and I guess, future-proof data platform strategy?

manoj mohan:

Okay. Fantastic question. Let me, let me try to summarize it without going into all the, we. Maybe one, I would say aligning on a single source of truth for, core data entities by domain, be it the customer, be it the transaction all of that. What are the core definitions of those foundational layers, and how do you get all of that owned by that particular domain set of power users? I think it's integral or critical. The second one I would say is all of the platform capabilities I have been talking about. I think it's important enough to, to highlight and proactively invest in them before you actually solve for the specific use cases. How can ingestion pipelines have built in quality checks? How can you enforce the right governance right from the word go? How do you capture all of the metadata associated with execution? And all of these things are, I think, constitute the platform capability. The third, I would say would be, design for evolution, not permanence, right? Because tools are bound to change. The warehouse data store you pick for today might not be the one you might be using a few years from now. But if your platform your platform and platform strategy, abstracts those core capabilities, you can swap that underlying technology without disrupting the business or without disrupting any of those use cases. I would stop there because all of these all of these operating principles. Can lead to outcomes where the platform scales, from the current workloads to five x or 10 x of those workloads without the need for having to rearchitect all of it. It could even, it could even scale seamlessly for all of your AI workloads which probably were not envisioned at the start, if you have those right platform strategy measures. So my suggestion I would say, would be something along the lines of, start with the focus on the strategy to codify, your, codify your platform capabilities to the best extent. And then plug in the tools the data stack tools that you want to plug in that order. Not the other way around. And that's how you are, you keep that vision for the longer term. And not just for what you need to solve the next quarter. So that's how I would approach it.

ben parker:

Okay, good. And then with the strategy, how often would you I guess with the fast paced things happening, how f would you reevaluate the strategy? Is there, would you, is there a timeframe? You would keep looking at this?

manoj mohan:

Great question. So I would look at it more along the lines of the forest view. What I mean by that is periodically every, as you plan for your fiscal year, as you carve out your next one to three year roadmap. Look at all of those critical business functions that you absolutely want to deliver on, and you're being hampered by, by the problems within the technology stack within your approach, right? And once you have those critical pain points, and if that gets to a tipping point where you're not able to where technology is hampering the progress of your business. That is the time when you would want to reevaluate and maybe think of it more like a green field at that point in time. But if you don't get to that sort of tipping point if you want, if you're able to stay ahead of the curve with, with with the right incremental advancements plugging in into the platform and if that is enabling everything that the business needs based on criticality. You, you could continue with that stack. So that, that would be a rough way of evaluating where you stand.

ben parker:

So there's a lot going into this strategy. There's a lot to do.

manoj mohan:

Wow. Yeah, absolutely. I think the product thinking or the leadership in terms of the thought leadership I think plays a very crucial role. You have to anticipate what the needs of the business are going to be. Be it real time, be it near real time, be it the scalability of AI workloads all of that you got to anticipate and you got to, use that anticipation and that thought leadership to, to solve proactively as much as possible.

ben parker:

Yeah, definitely. And I think it's obviously it's crucial, isn't it? Especially with the time we're going through. Everyone wants growth, everyone's going through innovation. It's yeah, you need to be, proactive as opposed to reactive in the market.

manoj mohan:

Yeah. Yeah.

ben parker:

So obviously we're in an era of AI and real time decision making. How crucial is a data platform in driving innovation and growth? I.

manoj mohan:

Great question. Okay, so if you think of, let's say, use cases like real time AI as a flight that's ready to take off. I would say the data platform is more like the runway and the AI models would be more like the engine of that particular aircraft. In other words, I would say if your data platform is broken, the flight might never take off at all. So it's that integral, it's that critical in my opinion. And to share something from my past, I think we used to ship AI features. Slowly in the past, in, in one of my, work stints because the data would be delayed, the data had duplication and there would be, it would be inconsistent across teams and so on. So when we did a retrospective through one of those planning efforts, we decided and flipped on that approach, we started to invest and build out a platform with event streaming so that we could support, real-time use cases and so on. We invested in building out a governed feature store that building out the right scalable contracts for sche evolution and things like that. After we invested in all of these guardrails for our platform, our data became more trustworthy and more self-served, and as a result, any team, any of the teams, consuming teams could start to prototype at a much, much faster pace. And, they could even launch it in production in a couple of days which was something we had never seen before. So in my opinion, I would say invest, invest once on building that runway the runway of that data platform so as to have reliable, governed and trustworthy data that can actually compound the entire innovation flywheel. That's how I see it.

ben parker:

Brilliant No, I like that Example. I think it's, good because I think you obviously when businesses are going deploying new models, you need to be able to have experimentation and able to do it at scale now, isn't it? Is a big challenge firms.

manoj mohan:

Yeah. Yeah.

ben parker:

Brilliant. cool. Man, it's been a pleasure having you on the podcast. You've provided some amazing insight, guidance, and I really appreciate your time. And yeah, you've got an excellent career to date. So thank you for joining me.

manoj mohan:

And great questions Ben. Thank you for all the insightful questions. Happy to, happy to be on your podcast and look forward to our interactions in future.