Transcript
Speaker: You change your platform, but a lot of the problems don't go away. It's too easy to to focus and blame the challenges around tooling. Where you need to be looking, in my opinion, is around that culture, is around the identity, is around the operating model of your data organisation. A platform transformation doesn't necessarily address those fundamental questions. Especially now, while we're in this this era, a really exciting era of agentic technology is starting to take off. You know, there's more tools, there's more technology. AI is fundamentally an amplifier. It will amplify what is there, be it good or be it bad.
Speaker: so If you have strong foundations, clear ownership, embedded governance, you will find very quickly that AI accelerates value. you have the opposite, AI is just going to accelerate chaos.
Speaker: I strongly believe that opportunities exist and a shift towards AI-native engineering practices are going to deliver benefits around delivery speeds, around quality, around organisational effectiveness.
Speaker: Today's episode is brought to you by Omni. Most companies I speak to want AI analytics but are failing to put projects into production. That's where Omni is different. It's the semantic brain that grounds AI in the heart of your business logic, giving you governed answers, whilst also the depth to identify root causes. It's intelligence everywhere, from your spreadsheets to their chat feature, even within your product. Omni moves you beyond the dashboard.
Speaker: Don't just take my word for it. Trust teams like Replexity and Synthesia that are already using Omni to deliver intelligence that people trust. Check out them in the show notes or visit omni.co. That's O-M-N-I.co.
Speaker: Now, back to the show. Hello everyone, welcome to another episode of the Stax Data podcast. My name's Harry Gollop, I'm your host, and today we're going to be dot speaking with Philip.
Speaker: um Specifically, what we're going to be speaking about is how data transformations really follow a similar arc. um Teams struggle to deliver lead to to deliver, leadership decides the technology is the problem, buy new tooling, migrate to a new tool, and um lo and behold, maybe the scene same systemic problems are still there.
Speaker: This is where today Phil is going to talk through his approach to how he's approached a a large transformation in a high volume business. feel got if Phil is Phil Goddard, the head of data at Sportsbook Platform at FDJ United and leads a 70-person data team distributed across Europe, Australia.
Speaker: um And he's come from a really interesting journey through a PhD in theoretical physics into then data science before moving into senior leadership, where I've been really sort of captured by his product-centric data approach to building teams. So we're going to dive into everything today from data mesh, data products, and a really interesting discussion hopefully around build versus buy.
Speaker: um And I suppose where obviously where AI is is taking us and what is important to organizations. So um yeah, Phil, it's a pleasure to have you on the show. are you doing today?
Speaker: Yeah, doing really well and thanks so much for the introduction, Harry. Yeah, really excited to ah to get stuck into our conversation. Excellent. Well, look, I've obviously got a bit of an intro, Phil, but for the audience, be great just to hear a bit more about yourself, your career, let's say from a PhD in theoretical physics to to where you are now. and Yeah, help help the audience hear hear a bit more about yourself.
Speaker: Yeah, um I think, yeah, really good question. So I think maybe it's you to look back academically, as you mentioned, a doctorate in theoretical physics, thoroughly enjoyed that. um I decided at that point it was time to leave leave academia.
Speaker: um I think from there, I was fortunate enough to to take a contributor role as a data scientist. um And I think probably spent about five years in in various roles as a contributor for data science. I think one of my ah earlier roles, which I think was very formative in terms of my career, was a position at a large FTSE 100 retailer.
Speaker: um I think this really, to me, ah it was this era of everyone being very interested in machine learning, interested in data science. Everyone was very convinced of the value of it. um But what I found is very few organisations actually had that maturity to think from a product-centric perspective and to build and deliver end-to-end products.
Speaker: So while my focus was on recommendation systems there, I really experienced firsthand that frustration of being unable to build and deploy those products end to end. So very quickly finding that ownership, skills and accountability weren't in the same place, weren't even in the same reporting lines. So think many listeners recognize that pattern of one team doing data science, doing some research, and essentially chucking it over the fence to an engineering team. and kind of having to hope that they'll take and deploy and manage product kind of in the intent of what you meant.
Speaker: um And I can really tell you from that experience, ah if if the accountability and ownership aren't clear, product outcomes are never going to be so successful.
Speaker: um i I think that was a really formative experience for me, um experience for his challenges. um i had an excellent mentor um who certainly gave me a lot of business awareness and leadership grounding that you wouldn't get in you wouldn't necessarily get from a physics doctorate.
Speaker: um But really, I think if I'm honest, it was those frustrations which really picked my curiosity and my thinking around operating models, around accountability, around what it takes for data organisation to unlock its potential.
Speaker: So it was that experience onwards, as I joined Kindred's with required FDJ, but I started my journey more into leadership. I'd say it was that experience which really formed my thinking, my focus around product centricity within data.
Speaker: Amazing. And where have you ended up now? It seems Kindred, there's been a bit of a, was there a acquisition? It'd be good to set the scene, because I think we're going dive into, I suppose, your journey of the data platform and the data team. So yeah, like who who are FDJ and um what what role do they play?
Speaker: Yeah, so ah f FDJ, um my my French is terrible, but ah Le Francais de jeu. So broadly speaking, the French National Lottery, um but they've ah begun expanding around to online betting game as well as their, say their more traditional routes around around the lottery.
Speaker: So they're quite a kindred group. um We were a predominantly Europe-based online operator. ah The acquisition it completed about two years ago. um So essentially it's been a journey journey from there onwards in terms of that integration process and ultimately where my focus is around Sportsbook platform, really building a strong asset that can be used and capitalized by by the entire group.
Speaker: Excellent. So let's dive into this sportsbook platform. And yeah, I imagine in the industry that you're in real time is extremely important for the type of decision making you're making. So what makes a real time sportsbook platform unique in terms of its data demands? And um how does that sort structure the way that you've thought about the data organisation?
Speaker: Yeah, I think that's really good question. So for anyone broadly who's not familiar with with the industry, what ah what a sportsbook is. So a modern sportsbook platform, for me, is genuinely one of the more technically demanding products or platforms that you could build.
Speaker: So you think about this on the back end, you're offering prices, you're processing bets, you're managing risk, and doing this all across, say, potentially thousands of markets sporting markets simultaneously.
Speaker: You have to be able to respond to sub-second, respond to in-play changes in in, say, sub-second timeframes and do all of that within a heavily regulated environment.
Speaker: On the front end, it's all about content and customer experience. So you need to be able to serve relevant content, the right time to customers and perhaps somewhat uniquely you you know that the relevancy of an event will expire the second the final whistle blows. It's not like a typical catalogue on ah on an online retailer.
Speaker: um And the reason why i really love the context is that data is not a support function and our structure has to reflect our ability to deliver product outcomes.
Speaker: So in our case, pricing models are the product, risk systems are the product, personalization is the product, and ultimately if data fails, business is going to fail.
Speaker: And that really forces a clarity about ownership and accountability that I believe in many data for organizations never have to confront. Interesting. Can you give us a sense of the scale?
Speaker: um Yeah, like what what what are the volumes? What do they actually look like that you're you're dealing with? Yeah, in terms of data volumes, highly, highly significant. So there's numbers of sources you have to be looking at. So in terms of offering,
Speaker: you'd be consuming from various V providers, essentially consuming events every time there's an update to a price. So um you have to be able to consume, process those, update your offering in very low latency. And if you're building in-play pricing, if if you're building your own pricing models on top of that you have to respond and offer those prices you know again sub-second in terms of bets um broadly will be proportional to the size of your customer base so if you're talking
Speaker: across you know an operator our size as you roll out as we roll our platform out across multiple markets it's the order of millions in terms of an active customer base so you can think during say the upcoming world cup at the final uh potentially thousands of bets uh trying to be placed simultaneously and you have to maintain um that's um maintain that good experience In terms of data products, again, you can think about things like risk management. You're having to track every bet. So you're looking on the orders of you know significant sized clusters being provisioned in terms of streaming aggregations. It's very important, for example, for traders to understand the liabilities around
Speaker: particular offerings, how are we exposed at any given time? Because those decisions ultimately will drive operational decisions, which could be the difference between being profitable or making significant loss. So um Volumes are significant, the types of data processing will vary from kind of large batch processing jobs to real-time streaming jobs, but it's the latency requirements which ultimately adds a lot of the to me the interesting challenges
Speaker: Yeah, it sounds like the pat of the platform has to be quite malleable and quite have quite a lot of elasticities with the yeah peak volumes can be humongous, as you say, with like massive sort of international events, which draw a lot of attention. um Yeah, is that a challenge that you have to sort of deal with, with um yeah your products always being able to come up cope with with demand, even when they have these huge peaks?
Speaker: Yeah, absolutely. and And I think some probably quite unique challenges as as well. So again, typically the World Cup's a nice example where it's huge volume, but concentrated over a very small number of events.
Speaker: um So you get a lot of imbalance. So again, if you're looking in kind of a nice, well behaved streaming platform, you've got very well balanced data processing across partitions.
Speaker: and that's not necessarily the case here. You have to be able to deal with that extreme asymmetry and also dealing with, you know, during the middle of the night, it might be very quiet. So ideally you're able to dynamically scale your clusters down, save money on resources, and then be able to gracefully roll back that ah a resource to be able to deal with the workload. So yeah, certainly a lot of challenges from from the infrastructure management side of things as well.
Speaker: Nice, I can only imagine. but um As you said, today's less focused in on the infrastructure and the the technology side, and i're suppose more focused around this this product angle um and and operational, I suppose, efficiencies and structure. So, Phil, I know this is something you're really so passionate about and you've already sort of made that clear.
Speaker: Where in your career, you've obviously come from an academic into being a data scientist and then into a late leader. Where did this sort of um understanding and emphasis on that sort of product focus of a data team and and and and data products of of what you're building come from, and when did you notice that really sort of become prolific?
Speaker: Yeah, I think that's a good question. so Again, my interests early on, again, say focusing around recommendation systems, I think that really helped sharpen that interest. So appetite was broadly, you know, broadening my skill sets, trying to adopt and and develop engineering skill sets as well. Again, back to the point of where does the end-to end to end skill sets exist? Perhaps I was very enthusiastic and very ambitious to say, well, why don't I try and learn that that entire end-to-end skill set?
Speaker: I think i transitions ah when I transitioned into leadership, again, it' ah you're much more efficient if you've got a a highly skilled, highly empowered team of of people with the right skills to be able to build and deliver those but boost types of product end-to-end.
Speaker: um But it was really, i think, get back to answer your question, where kind of it my focus really started to to revolve more around but that product centricity.
Speaker: it was It was at the time when when I took this head of data science role within Kindred at the time where the Sportsbook platform was initiated. And it fell in quite naturally that it was a product platform already embracing many concepts in engineering around domain-driven design.
Speaker: a lot of analogies, say with models such as data mesh, in terms of how you can structure an operating model for a data team, analogously to a product centric engineering organisation.
Speaker: So I think it was around building up a, ah or alongside of my peer group and the leadership of the platform, building up a very let's say that the culture, a culture really embracing accountability, really embracing autonomy between product domains, product outcomes. And from there, would say things started to fall into place quite naturally in terms of This was an operating model and a mindset which naturally aligned with the outcomes we were we were trying to achieve, rather than potentially finding an operating model and than trying to force it into place just because of preference or just because of ah ideals.
Speaker: Interesting. So that leads me on quite nicely to understand, like we're we're talking about like a product-centric data organization. um what does that actually look like? You've sort of you flirted with it a bit a bit there, Phil. So yeah, help help the audience understand how it how product-centric data organization would look different maybe to core centralized model.
Speaker: Yeah, I think that's an excellent question. And maybe, um you know, an overarching theme is that I believe that those models fundamentally are optimize for different objectives. I'm not saying or claiming for a second that one is right and one is wrong.
Speaker: So what's a product centric data organization? And i think the most important A simple and elegant definition is it is one which organizes around product outcomes.
Speaker: So your data capability sits within product domains, potentially multiple product domains, um and those domains are accountable end-to-end for both the data and the business results that it drives.
Speaker: Whereas a central data team or central data organization will typically position itself as a service function along the lines of you put in a request for data or for a report or for a deliverable, COGS will turn and you'll get a delivery.
Speaker: So that model optimizes for predictability and throughput. In terms of product centricity, I think I can think of a few distinguishing features.
Speaker: um So one of them firstly would be end-to-end product outcomes. So back to my example of one team does this, throws it over of the fence to another team. In a product-centric organization, there is no handover to build that product end-to-end.
Speaker: the outcomes are of which sit within the domain. I think, secondly, in in terms of structure, there be product owner owning the domain outcomes. So that is the person who ultimately makes the prioritization decisions, owns the product KPIs, and sets the direction of the team.
Speaker: And then finally, I think you can look at it in terms of success is not much in terms of tickets closed or tasks completed. It's ultimately whether the product's KPIs have moved in the direction that benefits the business.
Speaker: and And again, it comes back to to this point. It's really critical that the choice of operating model aligns with your business needs. Again, I wouldn't claim that product centric is the correct choice in every case, but back to my context, it's aligned very well with what we're trying to achieve.
Speaker: one of the One of the things you've mentioned a few times, and you you you brought it up again there, was this accountability and where that sort of starts and finishes and who has that over these these products. and ah how How do you actually decide where this accountability sits and what's maybe, you know, where you draw the lines and how how how do you think about that if ah for other data leaders?
Speaker: but I think that's a very good question. And i think Yeah, have a start to that. I think accountability is fundamentally important in the product-centric model because the extrapolation of a product-centric model is that you decentralize.
Speaker: You decentralize into your product domains where you have ownership of the outcomes and ultimately everyone within the domain um has to be aligned and attuned with the success of that domain.
Speaker: um I mentioned data mesh and I think it ties in quite nicely to to to to to data mesh as a model um because amp yeah fundamentally I believe if you if you apply a decentralized model like data mesh it really does emphasize the um the accountability layers which which are required.
Speaker: So maybe just kind of a very quick overview of what data mesh is, but for anyone who's not familiar before it before I continue along that point. But data mesh ultimately is an organizational model that draws on domain-driven design. So domain-driven design is a software engineering philosophy introduced by Eric Evans, I think probably just over 20 years ago. So very clear ideas. You structure your systems around business domains that generate value, and those domains clear boundaries and explicit interfaces between them. It was Sharmat Dhani who then took these principles and applied them to data.
Speaker: So I'd say a very high level, if you you agree with the principles of domain-driven design, you would naturally agree with the that the logic of data mesh. But data mesh revolves around four principles, and I think this is where it comes quite nicely back to that accountability point. So I think about the four principles of data mesh in two halves.
Speaker: So the first two principles, domain ownership and data as a product, to me, basically talking about accountability, who owns the domain, who owns the product, how does that that product domain interface with others?
Speaker: And then the second two principles around self-service data platform and federated governance, to me, that's about how you make that accountability scale. And so ultimately coming back to to to accountability models, um I guess my fundamental point is that if you start shifting to a product-centric operating model, you will naturally start to decentralize. And if you've decentralized, accountability and economy is absolutely critical. You will fail if you do not have that culture set up
Speaker: One of the things I think um we've seen is that data mesh obviously um was pushed everywhere, um I think, and it was sort of seen as, okay, this is this is the the the best way of working and um this is how how data seems should be done. And we saw a big push from a lot of companies trying to move to a data mesh style. And and actually I've seen quite a lot of companies then undoing what they what they tried to do because they did lose a bit of,
Speaker: bit of control, I suppose. What's your views on on data mesh and maybe where it works and why maybe it doesn't sometimes, Phil? Yeah, i I think that is a very fair point and a fair observation.
Speaker: And Ultimately, i believe that stems from trying to force in an operating model that doesn't align with your business context. So, you know at the time, data mesh being seen as very cool, very sexy operating model, everyone should adopt it. But again, potentially people adopting it where the identity of your organization wasn't necessarily product centric.
Speaker: And so you you essentially set yourself up with an operating model which is incompatible with the value that ah or the identity of of your organization.
Speaker: So, you know, thinking about that, I think there are a few failure modes which were which were quite common with with that data mesh alignment or or where it could have gone wrong. again,
Speaker: again Maybe that that first point we've already made is applying to the wrong context. To me, it makes sense in a product-centric context where domains are measurable outcomes.
Speaker: It doesn't make sense to me if you're running a service service-led organization. um it The next point probably would be around investing in a model without culture.
Speaker: So again, you can create domain teams, you can draw a very exciting org chart, you can call it data mesh, but if you haven't actually shifted how you operate to say that accountability is going from the central point to decentralised, you'll have a nice org chart, but the culture doesn't match the organisation that you're building.
Speaker: And the the third failure mode, which I think was quite common, really comes to choosing tooling over accountability. So it was where there was a hyper focus on building the self-serve data platform at the heart of your of your mesh.
Speaker: um and focusing more on that in terms of what you actually wanted from the operating model. So that self-service platform exists to enable and scale the accountability model. It's an enabler, not the goal in itself. um So if you're focusing on building a platform before your culture and operating model is ready, you're just going to gravitate back to a central model where you've got a central data platform, certain central things.
Speaker: You'll end up with the same bottlenecks. and ultimately just hitting the problems that we were trying to get around and by choosing a new model. Where do you think the... um I mean, I think the halfway house is a hub and spoke model, which has obviously been around for for a long time. What's your views on whether that sort of fits in? Because we've sort of, I think it's felt quite binary as data mesh or or centralized. But yeah, I feel like the hub and spoke seems to be a happy medium. What's your views on on on that model, Phil?
Speaker: Yeah. I think hub and spoke is the very appropriate model when you're going through a transition period of your building at the new function.
Speaker: So to that point, I think centralization can also be a good model for a very young data organization. If you're building from scratch or if you're strategically transitioning, say, from a central to to to to but to a product-focused organization.
Speaker: So what are the benefits of centralization? You've got standardization, you've got pooled expertise, you know you can move your experts from one domain to another um and and benefiting upon that.
Speaker: um It brings governance discipline, which I would say immature product domains can't yet sustain on their own. So if that's kind of a life cycle, you see a lot of organizations which will default into kind of that hub and stroke model you're you're starting to push power and and autonomy into domains but you've got that mothership where you've got extra expertise you you can kind of um you know redeploy more funds more fungibility with your resource uh and again you get a lot of benefits from that but
Speaker: ah would I would claim that there will come a tipping point where as these product domains start to mature, they're becoming held more accountable for measurable product outcomes.
Speaker: And then they'll start to find that the speed that they need to move at is incompatible with the overhead of of having that that centralized um your entity above them.
Speaker: So for me, I think Going from centralized to hub and spoke is a transition and then from hub and spoke to full full den decentralized model again is a very natural and appropriate transition point.
Speaker: And you get there at the point where you're ready to to let your domains grow up. You're left ready to trust to them, to give them the autonomy, the trust that they have a purpose, of direction.
Speaker: clean measurable business outcomes that they're leading towards, but ultimately they need to be able to run autonomously um to to achieve those goals. Excellent. Yeah, I think it's definitely seems like it could be a, it's that it helps with that transition and maybe some of the, the pain points you mentioned about if your business isn't ready for that operating model, there's a there's a good sort of halfway house to not try and force everything too, too quickly.
Speaker: and Phil, one of the the core sort of topics we've been mentioning is this obviously product centricity.
Speaker: Data products are rising. The terminology has been rising for several years now and it's being adopted by by a lot more teams. But one of the things I see is the definition for a data product is vastly different and depending on who you speak to, which is um not surprising in the data industry if you look at any of the roles and terminology that we have, but what was the definition of a data product to you?
Speaker: Yeah, good question. And I can answer the mix by giving my deck. um So I personally would define a data product as a capability which is owned and operated by a domain team, a capability which delivers the defined output to a known consumer and does so in support for the measurable business outcome.
Speaker: So within that, there are four tests, which i I would claim all have to be true to consider something to be a data product. So there's a known consumer a like who is depending on this product.
Speaker: There is a well-defined, well-managed, well-reflected interface. It's an accountable owner. So again, that owner could be product owner for the domain. And crucially, there is a business consequence to fail.
Speaker: So if a product fails, something the business cares about, something measurable, ah should break. yeah And who owns these products at FDJ? Is it people? Is it teams? Is it a role?
Speaker: Yeah, the that's that's a good question. So at a high level, we we break down between ah the notion of having a business owner organization, essentially the stakeholders representing the business strategy, for business direction, business needs. So it's ultimately the this is what needs to be built. um And then on the the tech, the build, the delivery side of things, we have an organization of product owners.
Speaker: So essentially, it's a one-to-one mapping of a product owner to a product domain who will work hand-in-hand with their business owner, um and then the technology team ah around that as well.
Speaker: Excellent. Okay, so that's a... That's where that accountability so comes in as well for for you guys. Then teams are the ones that are are responsible and they have that onus um to to look after.
Speaker: Interesting. So we've got this accountability point um and we sort of know where that ownership sits on the the product side. But these products are ultimately being fed by e ah data from your data platform. Yeah.
Speaker: Now, when we spoke, Phil, you I told you about the, I suppose, Cognify and how we were set up and and our vision was seeing everyone moving to the modern data stack and buying their tooling rather than rather than building. um You then said, that's exactly the opposite of what we've done. So, um yeah, help there's obviously the the amazing tools, Databricks, Snowflate, DBT, et cetera, which you can plug and play.
Speaker: Tell us a bit about your data platform and why maybe you've chosen to not go down that buy route. Yeah. I think that's, yeah. This well this this could be a a podcast in itself focusing on that's this question.
Speaker: um but Maybe just a starting point before I start to to delve in a little bit more into detail. um I think Databricks and Snowflake are exceptional products, Databricks especially. um i remember when I first started, it was essentially ah managed Spark platform, but seeing how they evolve their product towards an AI native data platform, a complete ecosystem, um I think it's very impressive.
Speaker: So that that the vendor model allows you to move very fast, but you move fast at the cost of ownership. um and And additionally, great I would say that the vendor model, they they don't position as accelerators, they position and their interests lie in long-term customer relationships.
Speaker: um In many cases, that's absolutely fine. And that's you know a really good and appropriate decision to to make. um But for us, the data platform wasn't a commodity purchase. It was a core part of our sportsbook ecosystem and to us needed to be positioned as a strategic differentiator.
Speaker: um And see the control of that to a vendor roadmap, however good the vendor is, wasn't compatible with what we were building. So I was in the position that I had the investments and the internal skill set to build.
Speaker: um But again, to be clear, in different contexts, I could very well make a very different decision. Yes. And how do you think about that decision? Like what were some of the, the thought processes and that you could maybe share and how you weighed up them them trade-offs? so I think there's definitely people in the audience that will be at, well, either smaller companies thinking they might have the capabilities and and want don't want vendor lock-in. Equally, I know that there's some listeners, there there'll be listeners from
Speaker: quickly scaling companies where they're they're reaching the limits of what these tools are capable of and maybe now in that that deliberation phase how how do you weigh up trade-offs in in this sort of space Yeah, I think that that build versus buy is such an important topic and such important debate if you're a data leadership or data platform leadership.
Speaker: And my view really is it it cannot be a personal preference. You cannot take the mindset, you know, i I prefer buying. So whatever context I was in, I was always buy or I prefer buildings regardless situation, I would go and build.
Speaker: um It has to be led by the context. the maturity of the business and outcomes that you're obliged to be delivering this leader. um In terms of the framework, um there are certainly some questions I would ask.
Speaker: And i I think the starting point and the most important point is a skill barrier. So do you actually have the capability to build? um Build requires platform engineering platform engineers.
Speaker: not greater engineers um and that is a very important point so you mean people who've experienced designing building and operating infrastructure at scale it is a although it's an adjacent skill set it's a different skill set so if you don't have platform engineers and don't have a platform to hire them build isn't a realistic option it is just going to be a liability um um You mentioned teams which are scaling and again depending where you are um on the scaling side of the journey, um I do believe another legitimate motivator for buy is time to value.
Speaker: So vendor platforms will massively reduce that time frame. You'll get to production quicker with a much lower cap from engineering overhead. And you know that in itself for many organisations means the right call it is to go and buy.
Speaker: um There are some considerations of what you're buying into. um So vendor lock-in. Vendor lock-in to me isn't just with technology. It comes back to how capabilities and culture start to become shaped around the vendor's opinionated model.
Speaker: and If you got to a point where, say, you're only hiring people who have experience with ah at a specific platform and you decide to change platform, you may find that your your way of working, your operating model is intrinsically locked in to to a particular platform.
Speaker: um But maybe from another angle, so that not not necessarily the strategic considerations, but the virtual ones, you can look at the cost. i mean For modest data volumes,
Speaker: um The overhead of hiring a platform engineering team is is going to cost way more than cost of processing, even if you're paying a premium for a managed platform.
Speaker: But as you get larger and larger and larger, you start scaling up, um you will hit a tipping point where self-manage makes more sense from a cost perspective.
Speaker: um and will scale a lot more elegantly if those data volumes uh continue to to continue to grow so that brings you to ultimately can you have your cake and eat it um uh i do think buy than shift is a perfectly valid strategy to get the the best of both worlds uh or you may buy and find you never need to shift there never is business case to shift But the real problem is when it's not a strategy, it's the CFOs tapped on the shoulder and told you the cost is firing out of control and need to migrate to a platform and you need to do it quickly.
Speaker: That means you're under pressure, you may not have a plan, you may have a team who's fully dependent on the ecosystem that vendor. And that to me is not a transition, um that that looks more like a crisis.
Speaker: Yes, and that is something that I think many companies and teams have to go through. stinks of, you know, a new CTO joins the company and wants to put their stamp on things. And the easiest way to do that is by it might not be moving over to a home-built platform, but it might be moving ah moving platforms.
Speaker: um how how'd you deal with Have you ever had to deal with that kind of um pressure? And I suppose justifying why your route has been, and technology choices and platform is the right decision, Phil. Because I definitely know leaders out there that have had this top-down pressure to for a migration, for a change of tooling, um when so often it it makes very little difference.
Speaker: Yeah, I think that is a very
Speaker: interesting observation. And I think it's one which resonates wouldn't be with me quite strongly. um ah ah i I've seen that pattern several times across my career.
Speaker: um And sp it it's a very interesting one where, you know, it maybe be taking a step back, it's a common pattern. There's a data organization, everyone is bought in to the value of data. We want to be data driven. We see data as the way to unlock value and not growth. um But, you know, something doesn't feel quite right. We're not quite getting the value that we want.
Speaker: um And to your point, a new data leader may come in and say, right, aha, the the reason why we're we're not getting the value out of data is the platform. It's a tooling constraint.
Speaker: So you know During my career, I've seen it from kind of the the Teradata movement to the big data era. So you move from Teradata to Hortonworks or CloudAire on-prem.
Speaker: A few years later, you then say, haha actually, what we need to do is then migrate to a cloud provider. So you go from on-prem, data platform to the GCP and AWS and but What i have seen and what what really this kind of stayed with me is just the observation that you change your platform, but a lot of the problems don't go away.
Speaker: And that's really because it's too easy to to focus and blame the challenges around tooling. Where you need to be looking, in my opinion, um is around that culture, is around the identity, is around the operating model of your data organisation. You know, a platform transformation doesn't necessarily address those fundamental questions. um And again, if you don't answer those questions, you know, especially now, while we're in this this era, a really exciting era of AI, agentic technology is starting to take off.
Speaker: You know, there's more tools, it's more technology. But ultimately, if you don't have a good view of accountability culture operating model, and we're bringing more and more and more tooling into the mix, um you know, now is the most urgent time, in my opinion, to be asking those questions. um It's about where does accountability lie versus what are the tools we need to bring and plug in?
Speaker: think that's really interesting point and something that yeah I think many should maybe turn to look at before before looking at your at your tooling. and I think it's some of the points have said, you know, tooling sometimes can be transformational, but I think there's plenty of stages before tooling that need to be considered.
Speaker: and Well, Phil, it's been great touching apart from, I suppose, operating models, how you see sort of a product-centric data team look, and and also your your your thoughts on build versus buy and and the platform that you guys have have built at FDJ.
Speaker: um It wouldn't be a data podcast in 2026 without talking about AI. So, um yeah, I suppose what's your what your take on where we're at as a as an industry right now and and what's what what what's happening and and where where are we going?
Speaker: Yeah. Yeah, as you say, it wouldn't be a data podcast without that question. oh So what's my stance on AI? I view it as AI is fundamentally an amplifier. It will amplify the what is there, be it good or be it bad.
Speaker: So if you have strong foundations, clear ownership, embedded governance, you will find very quickly that AI accelerates value. If you have the opposite, ah AI is just going to accelerate chaos.
Speaker: um I strongly believe that opportunities exist and a shift towards AI native engineering practices are going to deliver ah benefits around delivery speeds, around quality, around organizational effectiveness. You know, ah the the the time is right, in my opinion, to to get on board and start understanding how you can invest in this.
Speaker: But I do think we need to continue to cut through the hype. And that really means still looking at foundations. And governance to me, I think, is a foundational area which is often overlooked. um But it's not governance as as people typically think about it. So governance is is always, especially in data circles, is always thought of a constraint. It's thought of bureaucratic overheads. um Governance is now an enabler.
Speaker: um It's what will empower your AI systems to make them trustworthy and scalable. but if If you think about things such as your Atlantic layers, data contracts, quality standards, lineage, these days they're not bureaucracy. They're the foundations to be consumed by an AI system. And, you know, what 10 years ago would be a static governance artifact that you prepare just in case you got audited.
Speaker: Suddenly now these are the same artifacts which are powering your AI systems and that should really excite people. So if you invested in governance properly, you're not going to be behind AI. You're going to be able to move ahead and accelerate how quickly you move ahead.
Speaker: um like I'd like to use the analogy to ah to to quite a familiar concept. like Everyone in tech knows about technical debt. I'd really encourage people to start thinking about governance debt as a concept. like Pay this down and then you'll be ready to accelerate and really get the value out of automation and AI.
Speaker: I think what what does it mean for the individuals, for people in the industry? i think one of the biggest things I've seen is like the change in maybe the types of skills that people need to be improving and focusing in on the execution layer as I've sort of been speaking about is is becoming much easier. um And and it's you know that you you require less less maybe knowledge on that.
Speaker: um on that Maybe not, maybe not quite yet. But I think the yeah the ability to ah to frame a problem is becoming so very important and to understand what the impact is. So yeah, what's your view on um like what what skills should um to should data professionals be focusing in on the improving as they as we grow in this industry?
Speaker: Yeah, I think it's it's a really good question. And it' obviously technical skills are important. It is being able to stay abreast of kind of all of this new tooling. But, you know, maybe I'd answer this by taking an honest stance around a lot of service oriented roles. So automation is already absorbing repeatable parts of data work.
Speaker: So you can think of things such as route routine reporting, pipeline maintenance, query generation. And this technology is only going to improve. It's going to absorb more of that work. More is law. It's only going to get exponentially quicker.
Speaker: Absolutely. And when we're seeing that, yeah even going back a couple of years, you know being semi-skeptical about kind of the the the power of text-for-SQL, but seeing how far that has come along in such a short amount of time, um it is very powerful.
Speaker: But people need to see this as a release valve rather than a threat. And you note that it dawned to me that really business stakeholders who who who serve these kind of routine tasks, they always wanted to control. They always wanted to be able to get their hands in the data, but there was a technical barrier. but They couldn't yeah know couldn query the data. They didn't go SQL. So have to sign an analyst or someone to basically be the middleman or middlewoman doing that work for them.
Speaker: But so we will see roles which are defined by execution of repeatable tasks or question answer tasks um ah being progressed. But what we will see and to to your question, what are the skill sets that matter to to develop are we are going to see roles which are defined by judgment, trust and accountability for outcomes growing.
Speaker: Anyone is going to be able to ask a question and get an answer to a question. But the way to start thinking about it is, but who is going to be supporting people in asking the right questions?
Speaker: So the data and AI is not going to replace data people. um It will heavily disrupt parts of data work that can just be cued, prioritised and delivered brief.
Speaker: But I believe we should be pushing to automate all of that work and building and maintaining trust around that. And that is the human element, which to me is fully irreplaceable. I couldn't agree more. I think that's a really good way of looking at it and and a really nice mindset, I think, for for listeners too.
Speaker: to take and that's a great place to leave it and a great point to to share. So, um Phil, it's been a pleasure to have you on the on the show. Thanks for sharing your insights across operating models, product mindset, your platform and of course, you where we're going in in the industry when it when it comes to AI. It's been a pleasure having you on.
Speaker: ah Thanks so much, Eric. Really enjoyed the conversation. It's been an absolute pleasure. Amazing. Well, that's it for this week, folks. We'll see you in a couple of weeks. For now, goodbye. hi everyone just a quick one from me if you've enjoyed today's episode ah be so grateful if you could hit that follow button leave us a rating even better ask to show on to a friend who might also get some insight from it it really helps us grow the community and continue to share amazing conversations I also wanted to take a minute to talk to you about Cognify.
Speaker: Those of you that don't know, Cognify is the leading recruitment partner for modern data teams. We help some of the world's best organizations scale data and drive real value from the hires that they make.
Speaker: you're thinking about building a team or making a hire and you're struggling with talent or just want some insights on the market, then I'd love to jump on a call with you and tell you a bit more. Equally, if you're looking for a job and want to find your next dream role, then reach out to myself or any other Cognify team.
Speaker: We'd be happy to see if there's anything on our books that we can help you with and give you general advice on the industry. Finally, big thank you to Omni, this season's sponsor. If you'd like to learn more about the AI analytics that Omni can deliver you, then check out the link in the show notes or come speak to me. i can happily point you in the right direction.
Speaker: Again, thanks for listening and look forward to seeing you in few weeks' time.
