The mission at The LEGO® Group is to “Inspire and Develop the Builders of Tomorrow”. As a Chief Data Officer, Orlando Machado provides a lens on how he builds the teams that operate effectively together as an operating unit, optimized to use data to address an unique opportunity that will inspire and delight many people.
Meet Orlando and learn about how he tackles a wide variety of problems at any one time, from data to restaurants, culture, music, and of course data teams.
Welcome to the Soda Podcast. We're talking about the Data Dream Team with Jesse Anderson. There's a new approach needed to align how the organization, the team, the people are structured and organized around data. New roles, shifted accountability, breaking silos, and forging new channels of collaboration. The lineup of guests is fantastic. We're excited for everyone to listen, learn, and like. Without further ado, here's your host, Jesse Anderson.
With me today is Orlando Machado. He is the chief data officer at LEGO Group. Welcome Orlando. Thank you for joining us.
Thank you, Jesse. And great to be here.
Would you mind introducing yourself a little bit more?
So yeah, as you say, I am the chief data officer for the LEGO Group, and I've been at the LEGO Group since February this year. So relatively new to the organization and a real privilege to be at one of the world's greatest companies in my view.
In terms of my background, my history has always been in the world of data. So I've been working in the world of data and data science for about 25 years, starting in academia, actually. So I worked in an epidemiology department for a few years, where I was doing statistical modeling, the kind of thing that would be called machine learning these days. I spent a few years in a marketing agency, again, running data and analytics teams, mainly around trying to understand consumers better and better so that we could create more relevant experiences for them.
I then spent about six years at a company called dunnhumby. Dunnhumby is best known as the data science arm of Tesco, a very big retailer, particularly big in the UK, it has had a global presence in its time. But dunnhumby was one of the first companies to use data at scale to try to understand customers better, to target marketing, but also to create better in-store and online experiences.
So from dunnhumby, I moved to a company called MoneySuperMarket. MoneySuperMarket is a UK based price comparison website, so it's an online only business. I was chief data scientist there for four years where I set up the data science and data analytics teams, used to try to optimize the online price comparison world. After MoneySuperMarket, I spent five years at a company called Aviva. Aviva is a big global insurance company headquartered in the UK. So I was chief data scientist at Aviva before joining the LEGO Group in February this year.
So I've had many roles in the world of data. I've seen the world of data evolve from very, very small beginnings. There wasn't too much data in the world in the mid '90s. There's a phenomenal amount of data in the world now. So the disciplines have evolved, the capabilities have evolved and the teams around data have also evolved. So really delighted to be here, talking to you about that.
That's awesome. I am super jealous of your resume. I just need to say that. And let's geek out for a second on LEGO, that's awesome. What does 10 year old Orlando think about you working at the LEGO Group?
Well, I think 10 year old Orlando would have no concept of the fact that people actually could have a job at the LEGO Group. The LEGO products seemed to be always there, they seemed to be magical, they seemed to be present in everyone's homes and they were things that people interacted with. But the idea that actually one day I could have a job in that company would've been beyond my wildest dreams. It wouldn't have been anything that I could have considered.
And I think that's true of many of these big, enduring brands that have evolved over a period of many years. They start off as being kind of mysterious. I think it's a lesson for everybody really that if you've got a brand that you admire, try to think about the way it comes together, try to think about the people that work there and try to think about how you might make your way into a company like that because it's always people at the end of the day.
Yeah, I found that to be interesting. We pigeonhole ourselves and think that we can't be in there or can't go to those companies we admire, and yet you can. You can find a way and you obviously found a way. So when you mentioned LEGO Group, you were talking about how it just magically appears on shelves. Now that you're there and you've peeled back the curtains, you can see that it's very different. Tell me about that data journey for LEGO Group.
It's fascinating. I think the LEGO Group is a very interesting company because we are a manufacturer, we have supply chain and logistics, we have a wholesale operation, we have a retail operation. So we have direct to consumer considerations around customer experience, loyalty. We have many, many aspects that are often seen in many different companies and we have them all combined into one.
So there's a huge complexity to our operation, even though ultimately we're trying to rally around a very simple mission, we want to inspire and develop the builders of tomorrow. So we want to put easy to understand, inspiring products into the hands of kids and increasingly adults. So we have a huge population of adult fans now. But when you get behind the scenes, actually each part of that operation has a real opportunity to be optimized using data. And I think we've made a lot of progress in many of those areas.
I think there's still a lot to do because we have grown up as a manufacturer and these other parts of our operation have been relatively recent. We are thinking much more about our direct to consumer experiences now than we were a few years ago. So there are always areas in which we can learn, but there's a huge amount of data in our operation now. We have many connected devices, which wouldn't have been the case many years ago. So as the generation of data improves and as it expands, then the opportunities to get better and better at doing what we do also increase.
Let's say we have a ton of data at LEGO Group, is that in and of itself, that's all that's that's necessary, or do you need more in order to get value?
To me, trying to get value out of data always starts with trying to understand the company strategy and trying to understand the organization that rallies around that company strategy. And so the data is never enough. We need to understand what we're trying to do, what the business objectives are. We need to understand well defined problems that we can solve with data. And we need to create teams, not just technical teams, but big teams of stakeholders that can help us execute against that because it's only when all of those things come together that we really generate any value at all. We see many industries have instances of generating huge volumes of data that don't create any value at all. And that's very easy to do now because the technology to store data is very, very cheap. If you want to get value out of data, we need to have all of the different pieces of the jigsaw working together.
So you mentioned two important parts of that jigsaw. One was the team structure that we'll go back to. And one was the question you're trying to answer or trying to, yes, I guess answer. How do you try to establish that question that you're trying to figure out?
To me, it's a combination of curious people who are commercially binded, working together. We need to understand the questions that are going to help us deliver against our company strategy. So this might be about commercial objectives. It might be about some of our ambitions around sustainability. So we need to have a clearly defined business imperative for trying to solve a problem. And we need to have people who have a good understanding of data and technology to help put on the table the ideas in which data can help. So we need that cross-functional conversation that helps define those problems.
We definitely do, and so that cross functionality is important. And so now we move on to that team structure. What do you think is the optimal team structure or what team structure have you put in place at LEGO in order to do that?
I'm always wary of thinking about optimal team structures. I think different types of teams can work in different types of organizations. I think the size of an organization can often have a very big bearing on the type of structure that can work well. LEGO's a large organization. It's quite federated. We have lots of different business units trying to deliver against different parts of our ambition. So trying to, for example, centralize everything that we did, wouldn't typically work because that might create too much distance between a central function and a local business objective.
So to me, what we've tried to do is create the right level of centralization. So we have a central team that manages some of our core technology and our data platforms. We have a central team, which does a level of cataloging and understanding the data quality that sits on our platforms. And we have a central team building data science products. So this is data scientists with highly specialized skills working on well defined products that solve business problems. So those are central functions.
Alongside that, we have a data governance team that is helping the whole of the organization understand the requirements for using data responsibly. And we have another team that I've created called data strategy and community, which is about connecting up data practitioners from across the LEGO Group. And these might be business intelligence folk. It might be data analysts. It might be people who are just trying to understand KPIs and how to use them without trying to misinterpret them. So the data strategy and community team is about helping us build skills literacy and communities of practice across the whole of the LEGO Group so we don't have to centralize everybody who's trying to use data because that would put way too much distance between our central function and our business units.
So we're trying to operate to a kind of hub and spoke model so we have enough stuff in the center so that we can try to understand common standards, common practice, and common technology, but we also try to enable the whole of the organization to use data in a way that's fit for their own purpose.
That's interesting, the hub spoke model. I talk about that in Data Teams, but I also point out that it's a later evolution of the company. Do you happen to know how long it took at LEGO to get from, let's say that really centralized team into that hub and spoke model?
At the LEGO Group, we had an interesting setup in that round about five, six years ago. We started creating teams around some really quite advanced problems, things like recommendation engines for LEGO products, things like optimizing marketing effectiveness. The kind of things that many agencies around the data world do, we began to centralize within the LEGO Group. And so it's taken a few years of establishing data science best practice within the company before we've been able to centralize a bit further things like data strategy and data literacy, and some of the other adjacent areas.
The interesting thing is that in contrast to some retailers actually, it can sometimes be harder than some retailers to get all of the relevant data into one place for us, because we have such a complex set of arrangements with partners. We have situations where we have data coming from many, many different sources. So in some ways it's easier for us to tackle some of the more advanced cases than it is some of the simpler cases around just trying to understand all of our customers where they're interacting with us, whether that's in store, online, in a theme park. So some of those parts are maybe later in the journey for us, whereas centralizing things like data science, actually, we can realistically do a little bit earlier.
Oh, that's interesting. So one piece I really find important about having on a data journey is C level representation. Your title is obviously chief data officer. And what I found is that when companies don't have a C level executive, it shows that there isn't as much buy-in in data. Could you talk about your voice at, not just the board level, but at the C level, as well as all the way down?
My current role doesn't sit on our executive team internally, but it's very connected with a piece of our corporate strategy, which was written at the beginning of this year around getting as much value as possible out of data and analytics. So we have C level strategic intention, board level as well, buy-in for having more investment into data and analytics and we also have a program at C level called our digital transformation. So we have investment around reorganizing ourselves to get better value out of contemporary digital skills.
So I couldn't agree more about C level buy-in. I think having the CEO on board, having all of the executive team on board with a data program is absolutely essential. But in terms of my current role, I don't sit on the executive team, but I have connections with them through the strategy and through our digital transformation program.
How is that organizationally underneath you for the rest of your organization? I assume that those hub and spoke teams are directly reporting to you.
Yeah. The roles that I described are reporting to me, so the head of data strategy and community, the head of data governance and the heads of the data platform, data foundation, and data science products team report directly to me. I also have people reporting to me who are principal engineers. So people that can help us evolve our technology and to continue to evolve our technology as technology itself changes. And I have some people helping me around things like agile ways of working also reporting to me.
We also have then business intelligence teams that sit outside of my world and my role will be about trying to connect up those teams to help knowledge sharing, best practice, standard tooling, data literacy, and just helping us all get more and more value out of data in an indirect way.
Excellent. So one of the issues that you have mentioned before, and that was data governance, and you were talking about how it's going to be difficult in order to balance those two issues. Could you talk more about that importance of balance there?
To me, data governance has a slightly bad name. I think that if people hear the term data governance, they can imagine it's about purely policy writing. It's about being the internal police. It's about being the head teacher that you might get sent to if you've been bad in some way. And I think some of those aspects are important and it's crucial that everybody gets to understand how to use data in a responsible way that respects privacy and security and access management and all of those important things.
But equally, governance is about helping us unlock the value. It's helping us grow through data, and it's helping us grow in a way that's responsible. So access management is not about just trying to say, you can't do anything. It's about saying, how do we ensure that the right people can do the things that they want to? And I think that's the balance that we need to get right. The balance between protectiveness around data and then using data to fuel growth and governance is about balancing both of those aspects. It's about the balance between protectiveness and growth.
No, I completely agree. I've seen data governance as being a heuristic for saying no, here, you can't do that because of some data governance problem. But it's much harder and it requires a much different person to say we couldn't do that, but here's what we can do. And I think that's a key for heads of data governance, for example.
Yeah. I mean, to me, proper data governance is the key to unlocking innovation and it's the key to unlocking experimentation and the ways that we can grow through trying new things with our data, because we can't really try anything new, if we don't know what we're allowed to do. So I think having a proper framework for governance is absolutely crucial to trying to get as much value out of data as possible.
When we caught up before you were talking about trying to recruit that head of data governance, so a quick plug for you and LEGO Group. If you want to work at LEGO and that intro of Orlando made it exciting and interesting, you too could work there as the head of data governance. And we were talking about how hard this role is to fill. You have an audience right now, what would you like to tell them?
Well, I want to get people into the LEGO Group who are excited by the possibility of using governance to unlock opportunity. Now, I don't want somebody in the role who's excited by the idea of telling everybody no, because it's all about just trying to unlock opportunity responsibly. We are a responsible company. We're incredibly proud of the reputation that we have, and we want to maintain that and capitalize on that to be able to continue to grow and continue to learn. So I want somebody that's excited by the idea that we can innovate, grow and set the foundation for the future of our organization through responsible use of data.
So let's talk about that responsible use of data. So LEGO Group has some sensitive data about our children, so my children play with LEGOs. And as I think, well, what sort of data would I like LEGO to have? Or how would I like LEGO to deal with my children's data? These are the sorts of issues that you're dealing with and that that head of governance would have to deal with. Tell me, how would another organization, or what advice would you give to another organization dealing with these sorts of issues?
Again, it's down to getting the balance right between learning and protecting the interests and the rights and the privacy of consumers. And I would say that when those consumers are children, then there's a particular sensitivity. So we take a very conservative approach when we're thinking about children's data in particular. Actually, on the flip side, we have a lot of adult fans now, and some of our adult fans are very happy to give us all sorts of permission to use their data to learn, again, in a responsible way, but people want us to learn about the way that they interact with products and the way that we can evolve our products.
So we are very conservative when it comes to the use of children's data. But increasingly we have big groups of fans who are very interested in telling us what they think about our products, and if those fans are adult fans and they are happy to consent to us using their data, then we're happy to enter into a contract around that. It's a very two-way kind of relationship that we have.
But we're always trying to think about, essentially what our consumers would think about what we're doing with the data, even if they're legally allowed to consent, then I think that's one situation. But we're very conservative in situations where we are not legally allowed to get consent, or we're not sure. We take the conservative approach of not collecting data if we don't think that people would want us to do so.
No, that's an important ethical, I think distinction there is the default is conservative. When you're dealing with children's data, default to conservative. But you also talk about those adult fans of LEGO, myself included. I forgot to tell you when we first met, but I create videos on YouTube of LEGOs. I've actually explained distributed system concepts with LEGOs. One of those videos, I explained how HDFS works with LEGOs and it has over a 100,000 views. I think it has 120,000 views now. So there are some pretty crazy uses of LEGOs out there.
I think we see internally that LEGO bricks are a fantastic tool for brainstorming, idea generation, even meditation. So I think we see many, many uses of our products way beyond what maybe our founder would've thought about. But I think we're becoming very established and very skilled at using our products in a lot of creative ways.
You get a bunch of engineers, I've been thinking about this quite a bit. Engineers like to say that they're not creative and yet most of them spent 8 years old to 12, 13, 14 just playing with LEGOs and creating and I would argue that those are the most creative people out there. What do you think?
I totally agree. One of my biggest bugbears, if people are talking about data, is that people try to create this tension between data and creativity. Coding itself is often a very creative discipline because it involves creative problem solving. Now it also involves a degree of discipline and version control and trying to think about rigor, but at its heart, there's a big creative element to it. So I think there's no tension between data and creativity and the best companies are doing both.
And they're allowing their employees to be creative. They're giving them the space to be creative as well. So maybe you could share what is your greatest data story or data team story that you've never told before?
Oh, that's a difficult one. I like to tell stories so stories that I've never told before are tricky. I think one thing that I would say though, is that I worked at a company, dunnhumby, for six years. Dunnhumby's very well recognized as being a pioneer in the area of data science and in particular customer-centric data science. I would say the story that isn't told so often is how dunnhumby got ahead of the game by investing in, I guess what would now be called data engineering. So trying to think about the foundations and the building blocks and the technology that enables data science. And to me, it was one of the first companies to over invest in those kind of foundational technologies. Now nobody called it data engineering at the time and it would be different in many ways to data engineering as a contemporary discipline. But I would say that that company recognized very early on that data science was nothing really without the underlying technology.
That was an important one. So that would've been, what was that? 2012? Do I remember that right?
Well, I would say dunnhumby was investing in the technology behind databases, data warehouses from the 1990s, for sure. And it continued to invest in those technologies as they evolved. And I think that combination of the foundation with the science was one of the keys to their successes.
Oh, that's interesting. That's been my bent for the past eight plus years is saying, "Hey, data science, it may be the sexiest job, but there's a data engineer behind that that's making that possible." You also mentioned something as you were leading into that question and talking about customer focused data science. I found that most companies are thinking, how does this data science algorithm benefit us, but they completely leave the customer out. How do we refocus that and say, let's make something that is usable by our customers?
I think when I worked at dunnhumby, we worked very closely with Tesco and Tesco ended up owning dunnhumby, but something always struck me within the way that Tesco would think about customers at the time, which was many people are talking about customer loyalty, but really it's about the business being loyal to its customers. And if you start to reframe loyalty in that way, in about what can we do as a business that makes us devoted to our customers, then the data science opportunities drop out of that, trying to think, what is it? Can we just do one more thing that will help our customers in some way? That places the customer at the heart of what it is that we're doing as a business. And I think making that connection is really crucial.
And how do you as CDO really try to push your team to focus on the client then, or the customer?
I think encouraging people to experience the brand in the way that customers experience the brand is always extremely important. Whether that's shopping on our website, whether that's shopping with a partner, or whether that's actually playing with products. So it's fantastic that we can, within the LEGO Group, encourage people to play with our products as part of their job and it's a huge perk for everybody working here. But there's a serious side of it as well, because I think without trying to understand how real people engage with you, I think you've got very little chance of trying to come up with real customer-centric innovation.
It's interesting you mentioned that because I'm experiencing that with a client right now. Nobody's went through the customer journey. They're not really dogfooding. So let's say I'm a CDO, let's say I'm a manager at a company where it isn't as cool or fun to play with as LEGO, how do we get that customer focus or people excited about going through that customer journey?
I think the tone needs to be set from the top. I think there is no substitute for senior members of staff, the CEO, the executive team role modeling that behavior of really trying to obsess about the customer experience. And also don't forget the customer can mean many different things. We can be in a business to business context where the customer might be another company, a partner, but always trying to obsess about the way that other people experience your product, your brand, your service has to be role modeled from the top. And I think if a company isn't really prepared to do that, I think it's likely to be in trouble.
I think it's very hard to try to diagnose problems, it's also very hard to innovate because only the company can understand the opportunities for the next stage of the journey. It can be very hard to ask customers or partners or other people directly what we should do next. You can try, but you can get very flaky results. But it's that combination of putting yourself in the customer's shoes together with understanding the opportunities for realistic next steps for your business that can lead to real innovation.
One thing that may help people is you didn't always work at LEGO, you worked at Aviva, and there you were given an award from DataIQ 100, and this was about advocating for that use of data and data science. And that was a 322 year old company. So everyone talks about transformation, but they don't really understand the requirements of a data program. Tell us more about how you did that and how you achieved this award.
Yeah, I mean, the award was a surprise. I was nominated for it. It was a real delight. I wasn't expecting it. But where it came from was going into a company like Aviva, which as you say is a very old company, it was founded in 1696, so it's had to reinvent itself many times. And when I joined Aviva in 2016, that was just the latest stage of many reinventions that it's had to do over time.
And so creating a global data science practice was a real opportunity to showcase the way that we could use technology, not just for traditional insurance use cases, which are typically just about predicting risks to try to set prices, but showcasing how we could use data science to personalize the customer experience, to use artificial intelligence agents to try to speed up our internal processes, to develop brand new products using new data sources that we didn't know existed before. So it was about showcasing the benefits that came from taking a much broader view of data and helping, again, our CEO and our executive team understand how that could lead to a real transformation of that business.
So coming back to LEGO, you're relatively early on in your career at LEGO, so you've been there pretty recently. Could you share some of your thoughts for, let's say somebody who's becoming a CDO or maybe they're a VP in data engineering, VP of a data team? What do you think they should be doing in those first 30, 60, 90 days?
My experience of joining the LEGO Group has been slightly unusual. We're undergoing a big digital transformation program, which is broader than just data. So one of the things that I was trying to do very quickly was understand the key stakeholders involved in that transformation and try to understand the initiatives that were already underway that I could use to the advantage of the data community. So how to translate that into other roles, I think the key thing is understanding the current status of the company, what its ambition is, what its strategy is and who the key stakeholders are that you might need to connect with or collaborate with or influence because ultimately transformation is all about people. There's technology involved, but it's primarily about people. So trying to get a really good understanding of what everybody's priorities are across a broad range of stakeholders would always be first priority.
I think second priority is about trying to look at the work that's been done already. It's very rare to be starting with a blank piece of paper. Try and look at some of the good work that's been done already and work out how to use that as a platform for growth. How do you take that to the next level? How do you make it more reusable or more scalable? Because it's always better to try to amplify something that's there already than to try to come into an organization before really understanding it and come up with something entirely new, because there will always be a reason why somebody has tried that before, it hasn't worked, it doesn't work for the company. Really just try to ground yourself in what's there already rather than coming in with very different ideas about how things should be done.
Now, I think once that starts to work, and once that starts to gain momentum, do bring your experience from other organizations, other companies, other roles that you might have been doing in the same organization, because ultimately people get hired, partly because of the experience that they're bringing to that role. So don't be embarrassed about that, but always use the current state of the company as a platform to grow.
Now you used an important word there, momentum. How do we get momentum, let's say in spite of maybe technical debt or coming in brand new?
I think it's always about quick wins to some extent, trying to work out some quick ways in which some kind of tangible value can be delivered. Now that tangible value doesn't have to be monetary value. It could be about streamlining your process, or it could be about making an exec team member's life easier by putting more information together when it used to be hard work to try to collect it up from various sources. So try to think about the pain points, the things that are on people's minds and how you can quickly demonstrate how data in some way can make that a little bit better. And I think that's how the momentum comes.
In my case, I was talking to somebody a few days ago and I was telling them ... They were trying to talk about or tried to figure out how to gain some momentum in the organization, how to find those wins. And I told them to find somebody with that bleeding neck in the organization. There's somebody with a bleeding neck who will be your best friend. Don't try to be everybody's best friend initially, in my opinion, try to find that person and then they will go out and evangelize for you. They'll tell everybody, Orlando is your best friend ever. If somebody else sings your praises, that's so much easier. Do you have any thoughts on that one?
Yeah, I agree. And I particularly agree around just trying not to solve everything. Trying to pick a manageable problem to solve with a stakeholder who you think is going to turn into an evangelist, I think is a very good approach because I think that's how that momentum gets built. It's built through word of mouth ultimately. It's like any other type of brand building for that matter. It comes from what people say about the thing you're trying to do, not what you say about the thing you're trying to do.
Good. So what do you think is unique about how data is used at LEGO Group?
I think what's interesting and unique is the sheer variety of use cases that we have, anything from optimizing the way that our molding machines are calibrated, all the way through to personalizing the experience on our direct to consumer website. So we have so many of these kinds of opportunities, many of which we haven't tapped into yet. So I think there's a world of opportunity there. And one of the things that I'm trying to do by creating this kind of hub and spoke model is help people across the LEGO Group understand how they can get value from data, even if they're very early in their own journey about the opportunities.
So we are a very complex organization. We're doing many, many, many things. We want to do them all better and better, and so the opportunities there are enormous. And I think especially combined with the fact that molding machines are calibrated, many of our processes are generating information, we have apps that our partners are using that are generating data, the opportunities are endless. And I think trying to use that in a way that is for an inspiring mission that I think makes everybody smile is a real winner in terms of a combination of opportunities.
I would add on to your list of interesting data, you mentioned theme park data. I mean, I'm sitting here trying to think of any other company I can think of with that wide variety of data. And I could really only think of Disney, but I don't think they do their own manufacturing either, I think it's all outsourced and licensed.
Yeah. I mean, I think that Disney does a very good job of trying to create customer experiences, which are consistent across the different touch points. We want to do that and we want to include manufacturing in the mix. So I think that we have a very complex set of challenges that we can solve with data, but we've got a very inspiring opportunity that I think will make a lot of people happy.
There was another part that I heard you talk about and I've read about and that's LEGO Group's sustainability goals. And now that you have data, how are you using that data in order to hit some of those sustainability goals?
Well, we have recently used or launched some prototypes of products that we have made using more sustainable materials. But I think ultimately it's about just trying to think about all the different ways in which we want to be more sustainable from the efficiency of our manufacturing processes, through to the packaging that we're using. So we have many opportunities there. Quite often sustainability is to do with efficiency to some extent. So we want to be able to work out how much energy we're using, whether the materials that we're using are sustainable and whether our processes are sustainable. So there are many, many opportunities there to use data to help us in that journey.
So kind of switching topics, who's your favorite role on your data team?
I'm not going to talk about favorite people on my data team. I think, to me, the key thing is that it is a team rather than a collection of individuals. So I've created a structure that has many interdependencies by design. So my team is not a team of leaders who come together to give status updates. It's a team of people that need to work together to operate effectively. But I think the most important role that that team plays is the connection between business objectives and technical solutions. So trying to think about the problem that we're trying to solve, and then try to think about how our technology can deliver against that is the important connectivity role that the team plays.
Excellent. So as you think about your teams and the layouts of your teams, you talked about that star configuration. So just to help tease that out and have people understand that, you have both data scientists, data engineers, and who else are on those teams as far as roles?
In my team, we have data governance people. We have a broad, what we call archetype around being a data specialist, which encompasses data visualization, data governance, data training, and literacy. So a number of different skills, which are typically slightly less technical than data engineering and data governance. And it would be those teams that would be responsible for helping us connect with our stakeholders across the LEGO Group, in other departments, other teams, and helping those teams connect with each other as well. So we want to build communities of practice taking the kind of cue from the way that some software communities of practice work and they evolve standards, they evolve ways of working, they involve better and better practices of working. So some of the roles in my teams are less technical, but they're more about enabling the organization.
So thinking about what they do, what shouldn't they do? In other words, what doesn't fall under the remit of the data team?
One of the things that we are trying to avoid is things like business intelligence reporting happening in the central team. We think it's a much better approach for us to enable business teams themselves to do data intelligence reporting, KPIs, dashboards, those kind of things. But we want some degree of centralization of where the data's sitting, the way the data's prepared to some extent and the tools that we're using to create those kind of insights or those kind of dashboards. So we don't want to be a central function for every use of data across the operation. We want to try to get the right level of centralization so that people are working in a fairly consistent way across the organization, but they're also close to the problems that they're trying to solve.
So we're trying to draw the line where we say, once you get to a certain level of data science specialization, then there's benefit for that being in a central team. And that's because data science resources typically, it's a much rarer resource right now and it benefits from people being in a very tightly knit team so that they can learn from each other. And it also benefits from us centrally being able to point the right kind of problems to that very specialist skill set. So we're trying to say that the slightly less specialist data practitioners should be much more federated.
I completely agree with that sentiment. In the book I talk about, you can drive your Ferrari to the grocery store, but it seems like a waste. So it's really important to use the right individual, right tool for that job. And you rightly point out these resources, data science, these data engineering resources are much more limited, so we need to be careful there. So thinking about that, what do you think is the most challenging role on a data team?
Well, I talked about the favorite role around being the connection between business problems and technical solutions, that can often be challenging as well. And I think trying to build that into a discipline as people evolve from a very technical place can be something that people have to learn. So I think always maintaining that focus on the problem that we're trying to solve rather than the solution is an ongoing challenge. It's an ongoing initiative. It's something that we need to stay focused on.
So it's my favorite. I think it's the most important. I also think it's something that always needs focus because having come from a technical place myself, I understand we could spend many, many of years trying to learn a very small piece of detail around the way a technical solution works and that the skill around combining that with a business problem often comes much later in people's journey, in people's training, in people's development. So it always needs a focus. I think it always needs a challenge. And quite often the skill is around taking things up a level, just trying to help people see the strategic benefit of what they're doing, rather than just some of the details of the solution they're working on right now.
Excellent. Since you've had so much experience across so many different companies, you've probably seen some consistent challenges. What are you seeing as a consistent challenge when you're building a data team?
I think the challenge that we've talked about, about the right degree of centralization versus the federated approach of having data scientists, data analysts spread out across the organization is always something that is an ongoing discussion. And I wouldn't say that there's a one size fits all solution. I think that some companies are well suited to one model and some companies are well suited to another model, but that to me has been an ongoing discussion actually over the years. And I found that different solutions have worked for different companies. And I spend probably more time now trying to think about the broader organizational structure before trying to propose a data team structure than I would've done a few years ago.
I think the other challenge or the other kind of consistent discussion is around the definition of data scientist. I think I've probably evolved in my thinking and maybe even come full circle on this over the years. I think at one stage I would take quite a broad approach to data scientists or use the term data scientist and include analytics, BI to some extent, a very broad range of definitions. Whereas I think to my mind now, there is some benefit in trying to take a slightly narrower definition for the reasons that I talked about, the fact that you've got a very specialist skillset, and these are the Ferrari drivers and you want to make sure that they're driving around a racetrack because that's how you're getting value from them.
And the ability to up skill people in broader data skills, I think is much easier now than maybe it was a few years ago. There are many tools, there are many courses, there are many ways. It's a much more accessible topic to get into now. So trying to centralize or trying to label people who are analysts as data scientists, to me sounds counterproductive now. I don't think there's as much benefit. Whereas we should be trying to up skill as many people as possible in the basics of data literacy and trying to avoid some of the pitfalls of data analysis.
So you mentioned a definition, would you mind sharing your definition of a data scientist and data engineer?
Wow. I'm not sure that I've actually come up with a definition, but I would say that it's somebody that's using advanced mathematical statistical machine learning tools to solve business problems. And again, there's that kind of conversation around what does advanced mean? But typically we're talking about situations where the output of what they're doing will be an algorithm of some kind. And so that's distinct from a business analyst or a business intelligence analyst whose output might be a couple of insights about customers or trading or commercial performance. I think where the output is an algorithm that's to me when somebody tips over into being a data scientist.
And what about data engineer?
To me, a data engineer is a software engineer who is fantastic at building the foundation for data science at scale. I think that a data engineer is the person that helps us understand the specific technologies around data in all its various sizes and guises, and helps create the environments for data scientists to do their work.
I'm high-fiving you right now and I'm super proud because great minds think alike. Those are almost exactly the ones I do in Data Teams, the definitions I give for both those, because oddly enough, it's pretty difficult to give a definition of a data scientist and a definition of a data engineer and what I find is that HR people need that definition. You have to write a job description that says, I need this type of person and they'd have these skills and they have to do these things. And as much as people chafe at, let's say these definitions, at an organization, at an enterprise, you absolutely have to have these definitions and they have to be clear and understandable.
Yeah, I think that's absolutely right. And I think for me, the importance of data engineering is something that we need to continue to promote. I'm coming from a place where my early experience with data science was entirely offline. We would have a snapshot of data maybe on a floppy disc or something and I would be able to create algorithms and not really think about engineering. And it was actually only in my time at Aviva, so starting in 2016, that I started incorporating data engineers into my teams, because to me, it's the combination of those skills that helps us scale up and it helps us really take advantage of some of the technologies that are available now. I think it's very often that data scientists and data engineers can work in silos, but I think the real value happens when they work together.
I completely agree. And that's basically my definition of data ops is bringing in those people, bringing data engineers, bringing data scientists into a single team that can provide end to end value. And I think going back and saying, hey, this is an advanced thing, do this once, friction is your biggest issue, that's my opinion. Friction is your biggest issue, then you bring that into a single team, you want to eliminate that friction, but their friction will get significantly better.
Yeah. And having been a data scientist, I know that some of the discipline around production grade coding is not something that comes naturally to data scientists. Data scientists are much more experimental. Essentially, we want to hack about and create models and try to think about some of the ways in which we can maybe make predictions or think about the way that we can extract trends. We're not thinking about the efficiency of code and version control and documentation and scaling and all of these different things that come much more naturally to a software engineer. So trying to find those people in the middle, I think is absolutely the key to trying to repurpose so that we can get more leverage from the intelligence that we're creating and also to scale so that we can deliver as much benefit as possible.
I completely agree. My issue has been people trying to find that unicorn. Quite honestly, most companies, most of the time, you're not going to find that unicorn who can do both incredible production code, as well as that awesome machine learning model, that's difficult. But what you can do is find two people and get them to work well together and I think that's a much easier path for companies and organizations. So thinking, you were talking about the past, what do you worry about for the future of data science and data engineering?
I still think that there are risks that the buzz and the hype around data science and data engineering leads to people maybe hiring data science teams, hiring data engineers, hiring a bunch of people with PhDs, without a clear idea about what these people are going to do. And so that's always a challenge when something becomes very hyped. It's always a challenge when we have executive roles that are emerging now without too many clear definitions about what they really are, and without always the skills in the executive teams to hire the people that have got the relevant experience.
So I think we'll have a little bit of time over the next few years were the roles of chief data officer, the roles of technology functions continue to evolve. And I think there'll be some pitfalls along the way where people make some mistakes. People will hire a bunch of these skills, they'll hire chief AI officers or chief blockchain officers, or whatever it is that is the term that people want to think about, without really understanding some of the detail behind that because it's often in the detail where the real understanding of value comes. Historically executive teams have not had to think about that so much, they haven't had to think about some of these areas.
So I think we've got a slightly bumpy road for the next few years where people really learn how to get value out of these technologies. But then, after that, I'm pretty optimistic. I think there will be more data in the future than has ever been in the past and I think people will continue to get value out of that data. I think as long as that is done responsibly with a good sight of consumer expectations, a good sight of privacy, a good sight of security, then I think we've got a very optimistic future.
I couldn't agree more. That was an awesome summary. Since we were giving definitions, what's your definition of a CDO then?
Wow. Well, I think CDOs typically have quite a broad remit and my remit essentially is to try to help the LEGO Group get as much value out of data as possible. And to me, it's the CDO's role to try to put in place all of the relevant functions that help unlock that value. Now, I see some CDOs being very much focused on the governance side of data. I see some CDOs being very focused on the advanced analytics and data science side of data. My view is that it needs to cover both and it needs to have the breadth of all of these skills, because I think it should be the enabling function for the whole organization, not just a sideline or a department that just helps a small number of people. So I think I'm very keen on this becoming a broader and broader role. And of course, I'm slightly biased. I'm talking a little bit about the team that I've put in, which is deliberately quite broad, but that's come from a real belief that I think without that breadth, then we'll have an opportunity missed.
I couldn't agree more once more. You and I are going to co-author my next book. I'm just going to record some things. But yes, I have a section in the book where I talk about what C level executive should the data teams be under and I talk about that. If you have a CDO, they could be more of a data warehouse, data governance person, and they will have a different bent, they will look at this from a very different angle. Likewise, a chief analytics officer, they may come at it from much more of a data science background. Ideally, I'd want someone like you. Too bad you're taken, but I would hire Orlando. I would hire Orlando for that position because you can see that mix. Those of you who are listening, you can really see that mix. He's not just talking about the data science side. I've talked to people on that way, and I've talked to people on the data engineering side, but this mix is really what you're looking for. So kudos to you, Orlando. No wonder the LEGO Group picked you.
So thinking about that team a little bit more, how would we go about upskilling and training them for those new roles?
Well, I think again, there's no one answer to this. I think there is a lot of opportunity to use boot camps and training courses and internal initiatives to try to cross train like-minded people with the right kind of capabilities. I also think a degree of hiring from external sources to help role model behaviors, if you're trying to change the organization or you're trying to change the focus, I think is often useful. To me, the key is always to try to attack the problem from as many angles as possible. I think trying to say we're going all in on one solution is very rarely the right solution, or it's very rarely something that I've seen work. I think trying to work out as many ways of trying to attract and upscale and inspire people as possible is a good way to go.
That can be anything from running internal conferences, internal training programs, internal events, seminars, knowledge sharing groups, creating forums, curating material that comes from other sources because there's no need to invent stuff, there's a lot of good material out there. But I think there is a need to help people navigate the material that's out there and navigate in a way that's well suited to the organization that you're working in.
So a combination of all of those things, to me, is the way to go. Trying to think about how to train internal staff, but also trying to bring in people that help role model behaviors, if you're trying to change a culture, is also important. So it's always about just getting the balance right across all of those different initiatives.
As you look at your people, there's some words I want to put in your mouth and you tell me if I'm wrong. And that was, it sounds like you have a differentiation between data literacy and the skills needed for that, the people needed for that, separate from your data teams with your data scientists and data engineers. Is that a good summary of your thoughts there?
I would say almost. So I would say the primary audience for our data literacy initiatives is going to be people outside of my team. I think that the key thing to do is to help data practitioners who don't sit on my team, work out the development path that's right for them and work out the next thing and the next capability and the next piece of best practice.
I would also say though, that we want to offer the same kind of progression to people in my team, we just might be starting from a different base. So data literacy can be anything from trying to understand KPIs or A/B testing and what kind of traps you might fall into, if you misinterpret the data, all the way through to neural networks or advanced machine learning, or just trying to work at what the next stage is in a journey of trying to become a better and better data professional.
One interesting thing that I've seen ... And we're going to be interviewing Harvinder Atwal, that's going to be coming out later in this series. And for those who will hear that, you will hear that both Orlando and Harvinder worked at the same companies. And there was a reason that was because Orlando recruited Harvinder into those companies. So related to that, people keep coming back to work with you and I think that's the mark of an excellent executive and manager. So as a leader, how do you foster this growth and achievement and get people to want to come and work with you once more?
I think one of the things that I try to do is always adapt and try to work out what the next thing is that I need to do to help the team flourish and the team succeed. And I think what I also try to do is create the conditions for the teams to operate effectively themselves. And so a good example of that actually is at MoneySuperMarket. So I left MoneySuperMarket in 2016, Harvinder has remained at MoneySuperMarket and he's taken that team to bigger and better things and he's written a fantastic book about it. So a shout out to his book, Practical DataOps. It's an incredibly impressive book, I'm a big fan of it. And he's continued to flourish and grow and adopt and deliver for that team. So that's really what I try to do, I try to create the conditions for people to succeed. And if people like that, then maybe they come to work for me again.
We'll see. One thing that you've touched on a few times is people coming in with buzz words, people coming in with really high expectations. So here you are, you're at a new role at LEGO with a lot of buzz words behind you, machine learning and data engineering, data teams. How do you manage that - those expectations - so that they don't just overwhelm you or overwhelm the team with expectations that are impossible?
Yeah, I mean, it's funny. I have been privileged enough to have worked in the data world for a very long time and I've watched these buzzwords grow up around me actually, as the industry has evolved. When I did a PhD in statistical modeling, it wasn't an established career path, it was a slightly weird, niche thing to do that I just happened to be interested in. And so the buzz words have evolved around me, they've created an industry and I'm kind of conflicted on this because in some ways they're good. They're a good recognition that business owners and people that are running businesses understand the value in these new technologies and there's enormous value in some of these technologies.
On the flip side, they can create confusion. Artificial intelligence is a great example of a buzzword that has enormous value behind it, enormous interest, but it can be confusing because it's such a broad term and it's a catchall term. So it encompasses anything from writing a short algorithm that automates a mundane task, all the way through to sentient machines that are going to take over the world. And so that's not always helpful.
So I tend to see the role that I end up playing is helping demystify some of this jargon, whether that's to an executive audience, or whether that's to a team member who wants to understand how to use some of this jargon in a way that's maybe responsible, or maybe a correct reflection of the work that we're doing. So I try to demystify it. I don't like using jargon generally. I'm aware that I get sucked into it sometimes. But really just trying to demystify it and trying to concentrate on the problem we're trying to solve and the specific tool or technology that we're using to solve it, to me is the key.
So let's reverse that. What are you excited about that's a new technology, a new modeling technique, something along those lines?
Well, one thing I'm excited about is the way that academia is thinking about some of the adjacent issues around the use of algorithms. And I'm thinking about things like algorithmic transparency or algorithmic fairness, because these are things that have been baffling to people or concerning people. And there's a very fast moving movement in academia to try to produce really practical tools to help data scientists build algorithms that are a little bit more explainable or a little bit more transparent, and to help data scientists understand some of the fairness issues or bias issues that might happen when they build an algorithm. So I think that as an area of fast moving development is really, really interesting.
I think historically, there's been a bit of conflict in some data science circles about the predictiveness of algorithms versus the transparency of algorithms. And I think to my mind, transparency and explainability is extremely important. It's important to help business users understand what we're doing, and it's important in some regulated industries to help regulators understand what we're doing. So I think it's a crucial part of the mix and I'm really pleased to see a lot of development in academia around both of those issues.
Awesome. Let me ask you one last question. What do you never compromise on?
I guess I'd say I don't compromise on being myself. So I think I like to have open, honest conversations. I like to think about things in a way that's maybe slightly irreverent, but I like to take my responsibilities very seriously. So I try to bring my personality to the work that I'm doing. I try to bring myself to the work that I'm doing.
I also think that I don't want to compromise on standards, but that's a slightly less blunt thing than it might sound. I think it's actually very related to your point, Jesse, about unicorns. When I say, I don't want to compromise on standards, I want to build teams that operate very effectively together. That doesn't mean that each individual person has to have everything.
And so when I think about the team, I want the team to be a very effective operating unit and I'm pretty flexible in terms of the combination of skills that any one individual might bring to the mix. It's kind of related to diversity and diversity of thought. I like to have different people bringing different things to the mix. When I say, I don't want to compromise on standards, each person can compromise on anything as long as they're bringing something that's going to add to the standard of the team as a whole.
So that was an awesome interview, Orlando. Thank you so much for being here. I really appreciate your insights and how deeply and how honestly you shared your experience with us. Thank you so much for being here.
Thank you. It was a pleasure.
Another great story, another perspective shared on data, and the tools, technologies, methodologies, and people that use it every day. I loved it. It was informative, refreshing, and just the right dose of inspiration. Remember to check dreamteam.soda.io for additional resources and more great episodes. We’ll meet you back here soon at the Soda Podcast.
