Data Operating Models patterns with Dylan Anderson - Episode #60

Foreign.

Welcome to the Agile Data Podcast. When we talk about the merging of agile product and data patterns in a simply magical way. Welcome to the Agile Data Podcast. I'm Shane Gibson.

And I'm Dylan Anderson.

Hey Dylan, thanks for coming on the show. We've got another exciting one today. So today we're going to talk about this thing called an operating model. So you wrote a brilliant article on substack that broke an operating model down into its core patterns. And because I see a lot of data teams and organizations struggle with operating models, I thought let's have a chat about each of those areas that you've identified, what they are, what we can do to help data teams be good at them and work through that model of an operating model. But before we do that, why don't you give the audience a bit of a background about yourself for sure.

So my name is Dylan Anderson. I'm a data strategy consultant. So I'm the head of data strategy at a boutique consulting firm called Profusion, operating in London, uk. My background is actually strategy consulting, so pure strategy consulting. Hence that's where the operating model finesse and due diligence comes from. And I came over from pure strategy consulting to data strategy consulting after I realized, hey, I think data is the future. Every strategy that I create has data involved in IT and a key portion of it. And I also code in R, so I have that technical know how to do that as well. Most of my career has been spent on the consulting side and it's about for me bridging that gap between data and strategy and really understanding what data can do for your business and the value it can provide. And a huge part of that, as you've mentioned, is making sure that it's operating in the right places and the model is fit to deliver, which for a lot of companies, it's really not. Aside from my, my work, I also post quite a bit on LinkedIn and so you'll probably have seen me there. And as you mentioned, my substack, which I launched last April, So that was April 2024, has been around for a year and growing quite a bit. And that is called the data ecosystem and worth checking out, but that is me trying to explain every aspect of the data ecosystem. And when I say data ecosystem, I'm not meaning just the technology side, but what else is involved, for example, the operating model or the business strategy or data literacy, things that people often forget about because they're not technology, but are essential to making your data team work effectively and efficiently.

Everybody seems to focus on the technology, they don't focus on the people, the process, or those other really important things that sit around a team and their technology to deliver. Yeah, it's interesting moving from organizational business strategy into data strategy, because typically there's a massive gap in the data strategy market. And even then when I look at a lot of data strategies, they're more technical architectures. Before we get into the operating model, let's start with a little spicy conversation, because when people say to me they would like me to do a data strategy for them, first thing I ask for is the organizational strategy. Because my view is the data strategy is to support the business strategy to be successful using data. And so if we don't have a business strategy or if we're a product company, we don't have a product strategy, then it's incredibly difficult to create a data strategy because it's dependent on it. What are the goals of the organization and how will data support them? Whereas what I often see is a lot of people writing a data strategy in isolation, a couple of pretty slides or technical architecture or combination of both. What about you? What do you see? Is that how you think of it? That's what a data strategy is there for?

Yeah, I completely agree. I, I think I have the same perspective as you. The data strategy is really there to support the business strategy and enable that. And, and how does data factor into what you do as a business and make what you do as a business better? And typically what I see, and this is a problem with the domain and a reason why a lot of companies don't want to pay for a data strategy is there's two things that you usually get. And, and I think that the big consulting firms do this as well because they split their teams in certain silos. But one way is a pure business focused data strategy. So you get the data strategy to support the business, you get the use cases, you get the conversations with the stakeholders, but what you don't get is the technical architecture, the data dependencies, and the understanding of how to actually carry that out. So you get a fancy PowerPoint, but without the realistic intangible options to make it work. On the other side, to your point, you get the technical data strategy, which is very focused on what data do we have and what can we do with that data and what technologies do we have. But without talking to the business and not really understanding what the business wants to do with it, they're like, oh, you want to do customer segmentation? Here's a customer segmentation model. And they're like, we didn't really ask for that, so we don't want to do it, kind of bridging the gap and doing both. And it takes a lot of effort to think from both sides. And which is one reason why I love having the fact that I have my experience coding in R and productionizing tools and apps in R and doing analysis via that. Because what it gives me is the opportunity to understand how you build these products. But also I have the business sense to know what products need to be built and having those conversations with stakeholders. And then in the end, I think a data strategy, what it really comes down to is working with those stakeholders so that they understand what you're trying to aspire to. They feel involved, they're bought into that change because change management is the biggest thing holding a lot of these organizations back. And I'm sure we'll get into that with the operating model. But if you don't think about this as a journey and if you don't involve the people who are going to be impacted by it, then it's not going to work. So a data strategy needs to encompass those three things to be successful.

I agree. What are the goals and then what are the actions we can take in the near term, medium term, long term, potentially to achieve those goals? And often I'll get bought in to do to an architecture review. And what I tend to do is a thing I call a blueprint, where I actually go back to what's the measures of success for the organization if data was delivered, what is the team design? So things that align for me and what you talk about in the operating model. But the other thing I'll always do is ask to see the previous strategies because I don't know what it's like in your part of the world. But sure, as over here with large organizations, I'll see three data strategies, dx, three different consultancies that have been done over the last five years and not executed. And so that always begs the question of let's not do another one of those because we've proven they have no value. Let's focus on something that maybe will make change. And as you said, operating models are about invoking change in my head. All right, let's get started. For everybody listening along, I'll post a link to the article that I'm following and especially the diagram. So you've started out with this idea of the components of an operating model, and I think normally I'd ask you to define what an operating model is, but I'm going to get you to do that at the end because I think let's take the patterns first and then summarize it at the end. And so you've broken it down into three circles. What you call what people do structural delivery and oversight and direction. So do you want to go through the core patterns that describe the differences between each of those circles?

Yeah, sure. So the oversight and delivery I think is the highest level. It's where leadership steps in, sets a strategy, ensures that the organization set up to succeed and that they're hitting on the right levels to deliver against those goals that we talked about in the business strategy or the data strategy, whichever kind of is most important. And also be frank, a lot of this operating model stuff mirrors over to regular business operations. It doesn't have to be just data focused. The second layer is that kind of structure of delivery. So now getting more into the specifics and call this the actual more tangible processes and structures within the organization that help enable what those goals are, what that overall strategy is, and then finally the what people do, which is the inner circle there, which is the tangible job descriptions that people need to do on a day to day basis to execute against what you have. And again, those three things are all connected because you need that oversight delivery, that leadership, that direction to help give people that ownership of what they need to do to get to that outcome. Otherwise they're going to be doing stuff that's completely within their job description and not veer from the side to side. And one problem I think with a lot of data teams is that they do what's right in front of them rather than thinking what's right for the business. And so they aren't actually operating in the right way that you want them to achieve success. They're operating in the way that they've been told to achieve their job description. And that's not necessarily what leaders want from their data teams. And why a lot of leaders are so frustrated with out getting value from their data teams. So that's the kind of overall for those three buckets.

Just play that back. So oversight and direction, what's the goal of the organization? What's the goal of the team? How do we know we're successful? How do we set them up for success? Structure of delivery, how are we going to structure the teams, the people, the groups to actually achieve that? And then what are they actually going to do to achieve it? Pattern I'm a big fan of called mission command. Come down to the forces where we talk about having Squads of people, we set them up with a goal. Here's where you got to go, here's what you've got to achieve. We set them up with a small number of boundaries, constraints, what they can and can't do, or typically what they can't do. We then structure the teams to give them success. Then we give them the tools and the skills and let them go and do it. And one of the things that I tend to do to work out whether the team understand what the oversight and direction of the organization is, ask the team, how does the organization make money? And for me, that is a really simple question that will give you really good insight to how connected the data teams are to the rest of the organization. Because what I find is I'm often bought in a team level and to help the team, but nobody's thought about the structure of delivery, nobody's thought about the organization goals and how what the team's doing is going to support it. Say what you find or do you typically get bought in at that goal setting direction, level and then cascade down?

Yeah, I really like that question, by the way. I think it's a great question because often teams aren't necessarily in line with how the organization makes money or how the organization actually operates. And they don't know that and they're not told that. And we think maybe it's common sense in a lot of things and business leaders think it's common sense, but it's not to everybody. And to your question, I get brought in at both levels. So often I get brought in at the more executive level, but then operate and do the project with the team. So it is about communicating that and making the goals relevant across both parties. Because while the organization or the leadership level's thing is to make money, the team level goals are probably different. They have different aspirations and they have a different way of delivering value to the organization. So how does that factor in to either the data strategy or the operating model? It's important to take that level. And I like the mission control perspective as well. It really is what constraints are you Working is a huge thing that a lot of teams don't think about.

Would you do anything different in the way you approach this if you were dealing with a team that was internally focused, so they are working with data to help the internal stakeholders of the organization versus a team that is externally focused is looking at the organization's customers and supporting them with data or monetization externally of the data? Would you do anything different in terms of the way you go through and define the operating model.

I would say yes. So I think this goes back to another article I wrote and something that's often very closely related to operating model, which is organizational structure. And a lot of people put them together, they're similar, but they're not the same. And organizational structure, in my perspective, it fits into this kind of element too, because org leadership and roles and responsibilities, that all fits into it. But a lot of organizations, their data teams are to support internal businesses. They don't have data products, they're not selling data products. And anything they build, for example, like an algorithm or a machine learning model, would probably fit into marketing or sales and help marketing and sales do their job. So most data teams are internally supporting, yet most companies set the data team up as another vertical because it's another team we're going to set up as another vertical. But whereas it should actually be a horizontal and it should be under and across teams, supporting each one based on what their needs are and based on what their function are. And this is why a lot of data teams are silent is because they're set up as a vertical and they're saying, okay, go do the work on the side and then feed in once in a while. Whereas they should be a supporting lever for a lot of different teams within the organization. And that's a nuance that's difficult to achieve because it's okay, you want the data team to be a connected team. You don't want them to be necessarily within marketing or within sales, but you also want them to have those dotted lines to enable and to function that way. And that's one reason why I think within that operating model picture that we have, that structure of delivery is so crucial. You have the reporting lines, where do people report to and how do they interact with other business functions and domains. You have the delivery model. How do you set up to deliver on these data initiatives, whether they be internal or external, bringing in the stakeholders necessary, and then you have those workflow and delivery processes. So what is actually happening? What processes are in place to collaborate, to promote communication and facilitate the delivery of those data initiatives? And going back to your original question, because I don't want to forget about it, but external versus internal in a way, how you deliver it and that structured delivery will be different because internal, you'll be working with a lot more teams, there'll be a lot more cross collaboration, but you still have to think about those things if you're external as well, because even if you're an external facing data team, and you're building a data product for, I don't know, you're monetizing your customer data to sell to a bunch of third parties. You still need to interact with sales and marketing and such. And you're still likely going to need those business experts to handhold the data team and tell them what they need and what the customer wants. So there's still an element of that. It will just be designed in a slightly different way. And I think the final thing I'll say on that kind of question is companies don't think about that. They think, okay, let's just set up a team and have them do it. They don't think about the nuances of how we set up this team with other teams that already exist to deliver these projects that we want them to deliver. And those nuances often get left unsaid. And that creates inefficiency within how the organization operates.

Part of it is historically, data teams were under was seen as a separate department, and that's how they behaved, but also how they were expected to behave. It wasn't quite a shared service like finance or hr. So it was this kind of external groups that weren't embedded in the organization really, but weren't really providing a shared service like some of the other groups. So they became this weird business model. And then data teams tend to adopt that. All right, so let's go back to the core patterns you've got. So oversight and direction. There's five reading leftist to rightish, performance management, data strategy and team goals, Governance forums, Program and org leadership and operating model principles generally. Which one would you start with first? If you parachuted into an organization and you were going to fill all the boxes, which box would you normally start with?

So I would start with program and organizational leadership. And the reason you do this is because that sets the accountability and who is actually responsible to deliver that and accountable for it. And I think a lot of companies don't even take this step. And so accountability is all lost. And you just get a lot of people doing nothing because they don't know which direction and who to follow or who's actually setting the direction of where to go. So it really starts with who has that ownership of where we want to go and what we want to do. And then it is the data strategy and the team goals. What do we want to do? What's the what and where? Where do we want to go with that? And that kind of needs to be set from the top because people need to believe in that direction. So those Two work very closely to set the direction and make sure that where you're going is the right. The next two that kind of flow and follow are the governance forums and the Operating Model principles. And I think if I was to rank a third, I'd probably go Operating model principles. And that's the culture of how we work and how do we ensure collaboration and effectiveness in how we operate. And a lot of teams, especially in data, really like, they jump to agile. They're like, oh, we're going to be agile about how we do this and that's great. There's pros to agile and stuff, but a lot of teams say that they're going to be agile and then don't actually set up any agile processes. They just think agile means no processes. So we're going to be flexible and do all these fun things and really it's an excuse. So Operating model principles is about understanding how we deliver, how we work together, how. And it's setting the culture. And I think culture is so important to building an effective team. We talk about flexible working or which is in the news now, Operating model principles, that kind of makes a point of it. So are we working the right way to get the right design and to get the right outcome? Governance forums is an add on to it. And I add this in because I think again, similar to what I mentioned about Agile is how do you govern it and how do you make sure that it's actually operating the right. I'm not a huge fan of meetings. I actually think they're usually a waste of time, especially given how many there are with many organizations. But you do need some meetings once in a while bringing together stakeholders, being like, okay, what did we do this week or what did we do on this project and where are we at and how are we moving forward? But keep it structured. My old consulting firm use posts and now I love it. Purpose, objective, structure and time in each meeting. So set that agenda, make sure you follow it, make sure you know why you're in there. It's the same thing with when you're doing a data program. Make sure you know why you're doing this and what you're doing to get there and set some sort of program management within it. There's a reason why PMs exist across organizations and why you'll always find them. So that kind of is the governance form of bringing people together and making sure that they're on the same page. And then finally, performance management. I say in the article performance management and measuring progress really does often fall through the cracks in organizations. So you do have to make a point of implementing at the start. And it can feed into the governance forums, it can feed into the data strategy too. What goals do you want? Let's make them measurable. But it is so hard with data to make things measurable and to track performance that a lot of teams just be like, you know what we're going to do, we're not going to measure. And I think that's one reason why it's hard to show the value of data is because we don't take that extra day or two to figure out what we're measuring and why and how we do that. And I think that's important to really show the effectiveness of what we're doing in the space. Especially because a lot of the metrics in data aren't revenue generating directly or they're not externally facing. So that performance management piece is crucial, but it's also crucially set at this outer level, this directional level, by leadership, by those who are accountable, because otherwise it won't be recognized by other departments and other pieces of the business.

All right, lot to unpack there. Let's go back to program org leadership. Do you typically see that as the data leadership or the organizational leadership?

It's both that cop out answer. So it needs to be both. Sometimes it's just the data leadership, but they don't have clear direction about how they're supporting the organization. I'll consult with the data leadership and then two months later something changes because they got direction down from if they're reporting into it, their CTO or if they're into the cfo, the CFO or even the CEO. Right. So there needs to be alignment there. From a directional perspective, the accountability needs to come down to the data leader and even the leaders under the data leader. So if there's a head of engineering, they need to be accountable for the engineering tasks. If there's a head of analytics, the analytics tasks. So it just needs to flow and that needs to be dependent on what you want to get out of that perspective. Is it that organizational direction or is it the accountability to make sure the teams deliver on what they're supposed to do?

Lots of large organizations, enterprises, love to have rescues. And we see the word accountability and responsibility all over the place, but we don't see that action, that behavior. And my view is over the years, most successful data teams I've worked with, there was an internal coach, there was somebody with power, with mana, with the ability to influence senior leaders in the organization. Sometimes it was the data leader, sometimes it was somebody below them in the team, sometimes it was a senior leader outside of the data team. But there was always somebody that could actually make things happen. When they seem to be hard outside of the team, they unblocked. When I'm working with teams, I encourage them to find that change agent, that person that can make things that look immutable go away. Because that's a political capability. In large organization, you can't just go the data leaders, you can't just go the senior leadership team. Every organization has context. Hunt down those change agents that are going to support you. And particularly if you are greenfielding, if you're making massive change in the organization, find one of those change agents and make them your first customer. Because by delivering to them success, they're then going to support you as you try and roll it out to the rest of the organization. So I think that's a really important one that we sometimes succumb to that organizational hierarchy. We look at the org chart and we go, it's that person. When often it's not, they're not the leader of the data capability, it's somebody else in that organization. Organization.

I really like that you brought up change agents and you use that word. And I like how you said you need one internally to find them externally as well. It really is from an internal perspective. This is one reason why purely technical people have such a hard time being a data leader is because often they're given a remit and that's the remit as they grow up and they're focused on delivering great tech and they do a great job of that. But they aren't necessarily able to inspire change to create and think big picture and holistically of how they move past that. Some technical people learn that and they thrive at it. And it's great to see. But that's the inherent complexity of finding a data leader is you need someone with some technical prowess but can also be a change agent and drive that change. And to your point, finding that external first use case, who wants to, oh, we want to use AI better. We want to be involved in this new process that is huge. And it's actually a really good point. I don't even know if I have it on here in terms of the operating model, but finding that leadership or the guinea pig of sorts, it's a huge thing of proving success externally.

If you look at the adoption curve for software, we talk about early adopters, it's a bell curve. We talk about people Far on the left. Those are the people that we want to find in the organization if we're starting this change from the beginning. And then the next one you talked about was data strategy and team goals. And what I see is they're either given to the team or created by the team. I always encourage the team, if they can, to create their own goals, align them with the strategy. And the other trick is if the organization has a certain way of describing the strategy and the goals for the business, the product, or whatever else they do as a data team, copy that format. Make your strategy and your goals in the same format as the rest of the organization, because it'll just meld in. It just looks like everybody else. It doesn't stand out like dogs balls, and so it'll get adopted easier. That fits the culture of the organization on the way they articulate it. But be careful that actually that is the format that the organization likes, not something that a consulting company did and everybody hates. So there is a little bit of validation before you copy the what is it this week? Pyramid, triangle, Rubik's Cube, whatever diagram is the latest flavor of strategy diagrams.

Yeah. Often my first question when I do data strategy, of course, it's like, what's your business strategy? And they're like, we don't have one. Or it's what is it on a page? And they're like, oh, here, check out our investor report. I'm like, that's not really what I'm looking for. But sure. But it's so true. You need to make sure there's alignment because the teams don't know how they're involved in delivering those goals. And they often don't. You ask them, what do you do a day? You ask them, what's the strategy of the organization? And if you talk to different teams, they'll all have different answers. And that's not a good thing. So within the data strategy and team goals, what we typically try to focus on is what's the business strategy? Okay, let's create a data vision based on that business strategy. Your direction within the vision should be, we want to build revenue in this way or cut costs in this way, align with the business, and then what are those strategic pillars that underpin that direction? And that strategic pillar might be create a robust technical architecture and foundation or deliver cool and cutting edge business analytics data products. And that is then how you link it. So you're like, okay, engineering team, you said your goal was to create a robust technical foundation. Now you see your part in the overall Strategy and that's how you start to link the two. But often teams don't spend the time linking the two and that is so important.

And also because we're data people, we love to do things in detail. So we'll typically want to data lineage for our strategy. We want to see that this measure goes to this KPI, goes to the this okr and it has a one to many relationship. And I can trace it all the way through to our strategic pillars and see the number go up and actually it's never going to happen. So the trick is get the pillars, then have a bunch of bullet points, make those bullet points seem to relate and treat it as a many to many problem. Yes, this bullet point could go against strategic theme one, two and three. It doesn't matter. Pick the one that you think is the most important. If you've got it wrong, somebody will tell you move it right, move it left, move it. All you got to do is in alignment because you're doing work that's moving the organization towards its goals. And actually one thing you do won't shift it. It'll be a combination of all the things you do that shift that dial. Is that how you see it or do you actually try and get a little bit more mapping and alignment at the detail level of those measures indicators through to goals.

You got to do a bit of a mix. The many to many relationship analogy works perfectly because you can't for example build this data product without the help of a technical robust foundation or a data governance team or an engineering platform, whatever it might be. So there is many that are involved in the building of it. So you do have to map it out and I see it as a logical mapping. So you'll have your phase one use cases that you have to start doing their higher priority, they provide more value, but they're also needed to do your phase two use cases and your phase two initiatives. So how do you create that roadmap of what needs to be done based off of what needs to underpin other initiatives? And I think we talked about the two areas of creating a data strategy and this is where both areas fall down on their own. So the business focus one doesn't know what actually needs to be done from a fundamentals perspective to stand up the other things. And the technical focus one doesn't get creative enough in figuring out what the business needs and what needs to be built later on the phases. And so that approach is take that many to many relationships but also think about okay, how do we stand this up in a logical way moving forward and how do we tie things to certain things so we know what needs to be done before the next one is built?

And I think the other good point in there is that the data team and the experts, you're not asking permission to build these foundational components in your data platform. You're not asking permission to do that to support the strategy and the goals of the organization. What you're saying is as a data expert, this needs to happen to support those goals and the data leadership should be sitting there backing you to everybody else going, hey, we've got the best data people in the world, they know what they're doing. We had a quick look, it makes sense, let's go ahead. Whereas what we seem to do is we seem to treat it as a project that requires a business case. And then often people say no. And they don't say no because they don't want to fund it. They're saying no because they don't understand it. And then we'll go down to some horrendous level of detail and talk about slowly changing dimensions. Type 2 BI temporal data or Spark Python databricks. Right. And they don't care. It's not their job. So trust yourself as data professionals to do that bottom bit and just align it and point to the things you're going to help with and then deliver. And then the other thing I loved was when you talk about operating model principles, you flip between team culture and process. And often we don't. Often if we talk about principles, we're going to start getting data governance principles. Data is a nest, data will be backed up, data will be secure and they're important. Not as important as everybody thinks they are, but they are important to have some of those. But this culture, this idea of often I'll get teams to work on a team charter or we call this person that person. There's a bunch of patterns out there that you can use to help start crafting the team culture as a team. And the principles are what's important to the team and the organization. So for me, focusing on both the principles for the team and the principles for the way the team works. So are you going to adopt some form of agility? Are you then going to look at some of the agile patterns and see if they have value for you or not? Again, agile is not ad hoc, but it doesn't have to be following a fixed mantra like Scrum. But if I look at Scrum and I go daily check ins, if the team aren't communicating on a daily basis about what they're working on. I think you called the post format is a great way of doing it. If they're not checking in and talking to each other on a daily basis, then we're going to have a problem. So I don't care whether it's a daily standup or whatever the format is, as long as the team are talking about where they're going and giving feedback, that's great. So I think those operating model principles are really important to get on day one and also to constantly refine and change. As you learn new things, iterate them because you're learning, your culture's changing, new people come into the team, the culture changes. And then performance management's an interesting one. I think we opt out a lot in the data domain from measuring ourselves and it is hard. But I think there are some things we can do. We can look at our cycle times. How long is it from when a stakeholder asks us to do some work before it's delivered? And when we're doing that, it's when they ask, not when the JIRA ticket hits our queue because it's sitting in some backlog prioritization bullshit for six months. As a stakeholder, as soon as I ask for it, I'm expected. The clock started, somebody's working on it. What's our cycle time, what's our deployment time, what's our rework? There are some really simple things as a team that we can measure amongst ourselves and see what we can do to make it slightly better. And the other one that's really interesting is how's the team compensated? So I worked with a team once where they were really focused on one team. They were focused on skills, not roles. They were really focused on that goal. But they had a problem because a certain percentage of their pay was bonused every year and it used to be bonused on the team, an individual's performance reviews. And so somebody in the team, quite rightly called out, was saying, actually, if we're all working towards delivering these things as one team, how do we have individual performance reviews now? Because that's encouraging the wrong cultural behavior. And they really wanted to put their bonus into a team bucket. Unfortunately, when we get to governance, the HR organization of that company wouldn't allow them to do that because that's not the way it worked here. So again, I think the performance has to be in line with the culture of the organization. And that is hard. That is a hard problem to solve. So what you've seen that performance management for data teams is managing the way they work, managing that successful change, getting better is a really hard thing to instrument.

Yeah, I think I've never seen the ideal optimal method. I think it all depends on the organization. To your point, I think you brought two really good points there, which I liked was one was the overall performance of the team and what they're driving towards. And I think that's why the data strategy is necessary. There's. You need the business input to be like, hey, if you do this project, this is going to deliver this kind of value. And then that factors down into what you're measuring for the team. So you mentioned a lot of operational measurements for the actual data team. But then there's also the impact to the business and the KPIs they're driving. So for example, if it's Netflix, let's say, and it's the engineering team on the viewing data team and they're creating the platform for viewing data, everything that is built off of that relies on that data stream. And so therefore there must be KPIs that are tied to the greater business. And that's what you're holding up. And that's what you're standardizing and creating by doing this initiative, creating that realization of, look, you're not just delivering a data product. You're not just coding to build these pipelines or build this platform. You're actually enabling our product work to work as a whole for our customers. And I think that kind of connection needs to be built into the performance management in addition to those operating principles and elements too. And then I really like that you brought up the idea of performance management trackers or what you're compensated as. I think a lot of companies don't really think about that. And people are so motivated by their compensation structure or how they realize benefits. I'll give an example. I remember someone mentioning that they found a way to increase sales by 50%, but they would only be compensated for the first 20% that they did. So they waited until the next financial year to do that remaining percentage. And so that they got maxed out for both years, but they waited half a year to sell that additional amount because they weren't compensated anymore. And that's just proof in the pudding of we need to think about how we structure our teams and how we structure our people to make sure that they are working the best way possible in that they are rewarded for working the best way possible, because that's then how you get the most from them. And I think that also sets the culture for what you want to do. Do you want to be a team that just sticks to what it's doing, or do you want to be a team that prioritizes growth and really puts people on the pedestal that they deserve to be or moves them in the right direction while promoting and creating a collaborative team culture? I want to get into that performance management, but there's a lot of different aspects of that, of how you track and measure and compensate performance.

Typically a massive amount of change. People don't look about how they can change the performance management rules of the organization to enable the team. I've seen ones where team members are only allowed $3,000 a year on training, but they're going to go and implement highly technical platform databricks, snowflake, something like that. And certain members of the team need to be upskilled. And that upskilling that training, that education costs more than the budget per person. If you're the leader of that group, you have to go in and fight. You have to change the organization's view of performance and management to help your team succeed. So I think people underestimate the amount of change in that box. Which takes me to the last one. Governance forums. I hate them. Of a passion. Anything that says forum group committee is basically nine times out of ten, a bunch of people with opinions and no action. And so my view often is figure out what the minimum viable amount of forums you can attend is, how quickly you can get in and out and do it that way. Lately I've been thinking about principles, policies and patterns. And the way I describe it is principles are the things the team or the organization's broad brushes of how we'll behave. Policies are the rules. They are things that you will get fired if you do or don't do them. If you emailed out a list of our customers in Excel to a mate of yours and got paid for it, you'll probably get fired. Or you should. That is a policy. But there should be very few policies. And my view is governance forums are the place that if they can't do it programmatically, they police those policies. But there should be very few. They should be immutable, they should be very clear. So the team should be asking those governance forums, what are the rules and where are they in a language that I can understand and apply myself and then come to you and confirm that I complied. So if the policy is all data will be geolocated within the states. That should be a clear policy. And then the team should Police themselves and effectively prove that the data is geolocated in the states and then they present that to the forum, get the tick and they go on. And then patterns, what we focus on, that's where there are ways of working. There are things that have value in a certain context, they make things faster. But they're not part of your governance forums unless you're a high performing organization. And then your governance forum is actually more coaching and goes out and harvests the patterns and then becomes a center of excellence. That's my view on it. What's your view around governance forums? Kind of balance me out here a little bit.

No, I think that makes sense. I add two things. I think I also see governance forums as probably a higher level time for people to get together across teams and discuss kind of direction and discuss the high level of how we're doing about these different things. So a governance forum around data quality, for example, getting the key people in the room being like, have we set the standard and give a team a bit more direction on doing those things every once in a while. I worked with a company once that had a hundred day sprints and so they meet every 100 days to discuss that thing. I'm like, that's not a sprint, first of all. Second of all, if that's your cadence for setting direction, then it's, you're wasting a lot of months if the direction's wrong. So what is the governance of these programs? How do we make sure that these things are on the right track? But to your point, I do think you shouldn't have a, a forum or a meeting for the sake of having a meeting. It should be a minimum viable thing. And I think that's where the second thing piece comes in. I, I liked your policies, processes and I forget the third one, but that is crucial. The thing I think that needs to maintain that is who's accountable for running that forum, who is accountable for that program and keeping things on track? Because that's where things really fall apart. Did you get a governance forum but no one's leading it. It's a consensus based forum and you get a lot of talking where everyone wants to make their point and nothing is decided. And that's just the classic of corporate meetings that don't add any value. So you need someone being, okay, we're setting the data quality for them. This person presents and this person presents and this person presents. And this is the objective and what we're going to get out of it, boom, done an hour, you've got the Direction for the next month or so and you're good to go. That how it needs to happen. But you need someone to take ownership of that. While you do involve people and you do make sure people are collaborative in it, but that ownership of making sure that the governance is governed in the right way.

Actually, that's why I love doing these podcasts, because I learn so much and then somebody just goes ping in my brain because I hate the word governance, because it's not governance. We don't govern like a board does. We don't govern like a risk committee is. We don't govern like the CFO does, chief financial officer, where they govern and take money off us. What I've just got from that conversation is actually these two types of forums. There's the policy forum, which is the group, the police people ensuring that the policies have been followed. There's a checklist. Okay, just a health check being done. Carry on, or that one's a problem. And then there's collaboration forums where we're taking the knowledge of all the stuff everybody's doing and we're putting it in one place so everybody can see what's happening and get alignment through those conversations. And that is a form of collaboration. So I'm going to. I'm going to test that one out because I really like that idea of a forum to review and enforce the policies or check them, and then a forum to collaborate to make sure we're in alignment and syncing. I'm going to play with that one a lot.

I think that word's a bit better than governance. I agree. Collaboration. I think that's why people love the agile thing. They call them ceremonies. Right. So who doesn't want to go to a ceremony to discuss their feelings and the process?

Yeah, okay. All right. So that's oversight and direction. So let's jump down to structured delivery, which in my head, when I read it, was around team design, design and what I call the value stream stuff. But you've got three boxes there. You've got delivery model, reporting lines, and workflow and delivery processes. So take me away. Whichever one you normally start with.

Usually I would start with the reporting lines because they're usually set. You don't have as much flexibility with who reports to who and teams. And people love to have as many reportees as possible. So you can't really play around with that too much. But what people do exist within the organization? What's that kind of org structure, as I mentioned earlier, in the sense of where do people sit and who they report to crazily. A lot of organizations don't even have this mapped out and they don't really know what their org structure is and they know who they report to but it's all wishy washy and sometimes the reporting doesn't make sense. This goes back to what you said about understanding what people's compensation and who their feeding into and what their direction is. You need to understand the people who are going to be part of the change to first map out that delivery structure. Then it goes into delivery model which I see as the higher level value of how you deliver. So what is the approach as an agile waterfall? What are the processes to make this happen? For example, I had one client where they had these gigantic monolithic strategic projects that they needed to do and they also have these short term high value projects, quick wins let's say and they tend to take a quick ticketing approach or a waterfall approach to these. Some of these things sometimes they do the shorter quick wins ones on the side of the monolithic one, but they wouldn't necessarily communicate it. So what is their approach? To work with other teams on both those projects and how do you maintain communication within both them to make sure that the other teams are happy and they're up to date with what they're doing? Because if you're only working on those huge projects like the business team is like I haven't heard from the data team in six months. That delivery model is broken because you are not working in a way that benefits other stakeholders and they see you as a black box. So make sure that they know that this one will take time, but this one will take less time and we'll provide you updates on both as things happen. So that delivery model also gets into team structure too. So depending on what you're doing, just making sure you're setting up the team in the right way, you have the right amount of engineers or the analysts or project managers and the right amount of business input and collaboration working in and that goes into that more detailed level of the delivery which is the workflow and delivery process. So how do you work across teams? How do you get things done, what needs to be done? And this goes back to governance forums, but probably those collaboration forums that you mentioned, this is the more detailed in the weeds, let's have a stand up every day or three times a week or let's every two weeks touch base to figure out where we are across the wider team. Mapping this out across, I see three main stakeholders. Your data team, obviously your business Stakeholder and then your tech stakeholders and just making sure that you have those three involved. And there might be sub teams within each of those. But how do they get involved at different stages of the process? So when do they get involved from a scoping perspective, when do they get involved from a dev perspective, when they get involved from a testing perspective. And then also let's not forget feedback and performance management at the end of the project. How is it operating, how are we training people, all that kind of stuff. So really mapping out that, that delivery process and, and to be honest, like I've done this a lot for clients and you map it out on a page and work in a swim lane kind of diagram and they're like, this is great, this is amazing. How did we not think about this before? And it's translatable. They really shouldn't differ between use cases. You should have a very similar delivery process. And as soon as everybody understands that they understand their place in how to do things and therefore they don't get involved when they don't need to or they and they're part of the process when they need to be. And I think you mentioned the raci before about how a lot of organizations have those and people hate the word racy and the concept of it, but those kinds of things are helpful to just set some sort of structure to deliver the projects you set out. And this is the idea of that.

Okay, there's a lot of pens embedded in there and, and I can map the patterns that I normally use to each of those boxes as you talked. But I'm jumping all over the place because there's a many to many relationship in my head. So one of the things I do is when I think about reporting lines, I've got to a pattern where I articulate the reporting line about who is the person that's directing the work that's going to be done. And it may be different from the person who looks after the people doing the work. So I use the word pastoral care now to say there may be a person who's guiding the work to be done. And typically often got called the product owner or product manager now or a delivery lead. But they're going, here's the work that needs to be done in this iteration or this amount of time with the team versus somebody that's actually looking after the team, making sure that the team are happy. Make sure that they're taking in your leave, they're getting upskilled, they're getting into salary negotiations, they're taking care of people as humans. And often now I'm seeing that those roles are split. So the reporting line may be a reporting line for looking after a team and then there may be a reporting line for the work that's been done. So I look at that when I drop into organization and then we look at the team design. And I'm a great fan of team topologies and Unfix as a way of. And the Spotify model was a version of that. Actually, I've drawn boxes and saying, people sit here for this work and people sit here for this work, and ideally everybody's in the box for get work done. But in most organizations they're not, they're split. And when we split the team, we cause a whole lot of problems. So where we have team of data engineers and a team of analytics engineers or business analysts or reporting people, that split causes us a whole lot of problems. And our delivery model and our workflow needs to cater for that. And so one of the things that you picked up is one that I've always struggled with and I've never really solved, is the idea of fast and slow late arriving requests that have to be done quickly or just one small change or oh, that was a bug, we need to fix it. So if we were software people, then typically we get to build in big chunks and not get interrupted too much, probably because they're so good at DevOps now that they've got rid of all the drossy stuff that kills their work in the data where we're not and we have this fast and slow and we tend to have to do both sets of work with the same team. And I think that's an unsolved problem for me. Have you ever solved that one? This idea of big chunks of work that take a couple of weeks for the team to concentrate and then all that interrupting work that needs to be done because it's important, but seems to hit the same team at the same time and interrupt their flow.

I can't say I've solved it because that is a Pandora's box of issues. I mean, you put together a solution and things will arise that don't work. But what I can say is that setting some sort of structure and guidance to address that is the right way to go in this kind of same piece of work, where the first thing was to identify that those two pieces of work existed and identifying what initiative fit into those two types of typologies and communicating that to business and technology stakeholders and being like, this is what exists. And this is how long this is going to exist and this is how long this is going to take. And then the next thing is setting up the team structure to deliver that. These people are going to be focused on these initiatives, these people are going to be focused on these short term initiatives and also having a couple, let's say free agents in the middle who can work their expertise with both sides. And it's similar to a consulting model where you have the partner or the senior lead across multiple projects because they had that perspective. And so an example within a data team that a person might have that role would be a data architect, for example, or a principal engineer. So who have a kind of, okay, this needs to be logically built in this way and this is the high level and this is how I can help with these projects. Whereas you have the more junior people on it full time. And then the biggest thing within that whole structure is just communication. So making sure to communicate when things are done and as they finish and timelines with business stakeholders so they know what's happening and they know when they need to be involved. And I think that's what we really miss because like when we're doing a monolithic platform migration, people don't hear from the data team for five months because there's a lot of work going on, but they've done a lot of, they just don't know how to communicate it and they don't think the need is. They're like, oh, I'm still focusing on building these four data tables, so I'm not going to tell people that I'm still working on that. But if you tell them, then they don't think it's a black box anymore. So I think there's no perfect structure, but there is ways that you can override the lack of perfection, which is really communication and clear responsibilities. And that's.

And just chunk it down. If you're bringing in four tables, if you've bought the first one and show everybody it's not usable here. If you've got a layer architecture and it's just coming in on the left and it has little value yet because you haven't conformed it or integrated it, it hasn't been presented, it's not usable, but you've done that work, then just tell people you've done that work and.

That'S okay, and show them where it's going to go and where it's going to lead. Oh, we brought over this table and in three months it will help us build this new data product and Dashboard that will give you visibility into this and they'll be okay, cool. I now see your progress and thinking.

Like a door to door salesperson. Imagine you had to get funding for that work you've just done. What's something interesting? You've probably run some data profiling stats across it. You've probably found a data quality issue with the phone number. Go and say to somebody, hey, we brought this data in, got to do a lot more work to it. Interesting that 40% of our phone numbers don't have area codes on them. You probably already knew that, right? And they'll go, what?

Really?

No, hold on. We're giving that to a contact center and getting them to ring. They may get surprised or they may just confirm and go, yeah, we knew that. But again, it's a conversation that has value and it's also interesting. People are interested in data, so just go show them, have a chat. It's got some value.

If you don't do that too, you'll end up wasting a lot of time. Yeah, like it's the same if, if you don't communicate back and forth, they'll, you'll spend a month, pull over this table and they're like, oh, we don't actually use that table. And you'll be like, okay, what the hell.

You hope you'd use it later. Right. But you never know. And then this idea of communications, interesting for me. So at the moment I'm playing around with the pattern of a playbook and again, it's aligned with your thinking from what I can tell. So it's the data team creating a visual document that describes to somebody else how the data team works. And there's two really interesting use cases for that. When a new person joins the data team, you can give it to them and say, here's a short guide at a very high level that gives you some context about how we work when you talk about your delivery models. Are we waterfall? Are we scrum, Are we flow? Are we lean? Are we a hybrid model with a whole lot of stuff? Do we use a Kanban board? Do we not? It describes your ways of working, what's the natural flow of work? What's your value stream? What's important? It's not a big wordy document, it's just a bunch of pointers that give them context. And then as part of that, that should describe when the data team will engage in some work. So what's the gate? When do you talk to the data team? And it'll be different if you're going to go away and do massive strategic initiative that's about monetization of your internal data. Talk to the data team early. If you're going to go and maybe do something that's a little bit smaller, you could probably talk to them slightly later. And then the second thing that playbook should do, like you said, is articulate to a stakeholder when they need to be involved. Like you said, if you can show a visual flow of how the work's getting done and then you can peg to the stakeholder, you need to be involved here. We're going to be busy, not talk to you as much here. You need to come in and be really available here because we're going to need this feedback and show them where in that flow of work they're going to add the most value. They're probably going to come in at those times and do the thing you need them to do. So again, it's a communication tool that's really valuable and I don't see it being done a lot, which is interesting.

You hear the word playbook a lot, but then you don't actually see a lot of playbooks. And I am a big fan of that kind of stuff. The problem is people are like, okay, people don't look at them. I mean, you have to instruct them to look, you have to provide that. But people start in a job and they're like, I have no idea what's going on. And I think those visuals that the process, it's so important and it's so helpful, especially in data where things get complex very quickly and especially when you're cross collaborating. One thing, it's related. But one thing I really have started doing now with a lot of my data product delivery projects or even data strategy projects, is creating a data lineage architecture solutions architecture of these data products and mapping out how the data gets from source to consumption. Because that visual then just opens everybody's eyes and be like, okay, that's how it works. Cool. And they're on the same page. Going back to your point about communication is making sure everyone's on the same page. And if you can do that, I think it's well worth the investment, especially with a playbook or something like that, because it saves so much time in the long run.

Don't look for the perfect playbook. It doesn't matter. It's waste. What people sometimes don't understand is a map is a great way of getting understanding. And what's interesting is when you actually try and draw a simple map for something that's happening and it becomes overly complex, it should force you to look at it and go, why is it so complex? Actually, how can we simplify that? Map out your value stream, map out your process, map out how a request comes into your team and at a high level, the number of steps that you're going to do before it goes out and adds value back to the organization and just draw it as a picture. Map out your team design. If you've got separate teams of engineers versus report engineers versus analytics engineers, draw them as boxes so people understand that there are different teams doing part of the work in semi isolation. Map out your ceremonies. If you decide that you are going to do a daily stand up or you're going to do a demo or you're going to do a retro or any other ceremony where people are going to get together for a reason. Like you say, it has an intent, it has value about getting together because you are taking time out of the work being done. Just write down what they are and why you're doing them. And if you can't write any value, question, why the hell you're actually doing it. Define a definition of ready, which is what is the rules the team have about work coming into their flow, that if it's not met, they won't do it, they won't pick it up, it's not ready. And have a definition of done, which is what do the team say to each other as their peers? This has to be done before we're ready to hand the work out, deliver it as something that a valuable data product, those things being articulated really simply have value. And then the last one is focus on the handoffs. As you said, if a team is doing part of the work and another team is doing another part of the work, the biggest problem I see is the handoff between those two teams. And because we're not working on it together, so we have to create this form of shared understanding. So focus on the nodes and links and where you're handing off to another node, another team. Focus on the thing you're handing over. Is it a conversation, is it a document, is it a template, is it a picture? What are you giving them to give the context of all the work you've already done and document that in your playbook so that the receiving team, it's a form of, dare I say it, data contract, but not for the team. It's a work contract. They're all valuable things and then once you know that they're useful, just put them in the playbook.

Yeah, I really like all those. I think that's. It's something that needs to be done more often by data teams and other teams as well.

And so go back to your diagram. The playbook could have a section on reporting lines where it just describes what the reporting lines are. Can have the section on delivery model where it describes what the middle. And then the section on workflow and delivery processes. They're three chapters, short chapters of the playbook for that data team. Really useful. And then getting into the last one, what people do. This is probably where it's going to get even more spicy because you've got the words roles and responsibilities. And I bang on about skills over roles all day long. Take me through what you mean by roles and responsibilities.

Skills can fit in there too. I have nothing against the word skills, but yeah, roles and responsibilities is. It's just what are you doing? What's the purpose of what you do and why do you exist in this organization and what decisions do you make? What accountabilities do you have? What do you do from a day to day basis? And I think the big thing within this, it is your job description. And I think we talked about it before, people often follow their job description to a T or they follow what they need to do to a T and they don't have as much flexibility. I think within what people do in, in this section of the operating model, you do have to have a bit of leeway and you have to have a bit of growth baked in as well. What do they want to accomplish in their career? Where do they want to go with their life and career, even past the company that they're currently working in because no one actually works at a company for the rest of their career anymore. That doesn't really happen. So really understand their direction and trajectory and what they want to do and bake that into their role and bake that into their responsibility. And I think when you map that out, people are more bought in and they see what they do on a basis helping towards their career. Oh, I'm learning how to do this, so it's great. I'm doing this aspect. Or they're like, I don't love this as much, even though it's my role. Is there a way that we can work around that? Okay, you still have to do that, but you can do this other thing that you do love so that you're not just in a job that you hate. So it's molding it in a way that's a bit more flexible than I Think your standard typical, this is your job nine to five, go do it. It's how do you get that Buy in and develop the skills. So skills are in there to really execute against your job on a daily basis. Fitting in to everything else that we covered already in terms of the structure of delivery and the direction and the leadership.

Okay, so if I play that back to you, it's basically about defining what role they're doing now and what responsibility they have now and then potentially what role they can move into or the increasing responsibility in their role and therefore how we help them grow into doing a bigger role or getting more responsibility. That's a great way of thinking about it. It's not defining very specific job descriptions and saying this is what you do. That's not what you mean when you say roles and responsibilities possibilities.

I think it's probably the most black and white one on there, but it's black and white for a reason. It's because organizations have done this for forever and I think there's a mix. You have the startup mentality where I do everything. That's one end of the spectrum. And then you've got like the corporate 9 to 5 mentality of I do one thing, I do it really well, the Henry Ford kind of thing. I think most companies need to take something that's in the middle of. We have an idea of what you need to do, you need to do that, but we want you to grow within that area and potentially take on more if you want to, or take on less, but feel inspired to deliver as much value as you can to the organization.

One of the things I played around with is grabbing from product and marketing Persona mapping. So typically creating this idea of Personas and organizations, an information consumer is different to an analyst. And so when we're building what I call information products, if we're going to deliver a product to an information consumer versus an analyst, they expect them to behave slightly differently. And then I started getting confused because I started using Persona mapping for the data teams and I was like, ah, no, I haven't gone back and revised the patterns to get clarity. But do you see that happening a lot now where we say there is this Persona of a data engineer and say a Persona of a data platform engineer and they very similar skills, but slightly different Personas, potentially different roles, but definitely different Persona. Their skills are broader or deeper and slightly different things. Have you seen that Persona mapping idea being used? Much in this space depends on the.

Maturity of the organization. So I see mature organizations with larger teams being able to do that. And I think it's important because I hate the term data engineer, because right now people expect data engineers to do everything because they've got that word in their title, engineer. Whereas to your point, you can do platform stuff. You could be DevOps or data ops engineer, or a principal engineer that's more tech focused or ahead of data engineers, more people focused. So what is that split? I think getting that Persona, getting that skill proficiency, what's your primary skill set in your title or in your description of your title, is important for delineation of responsibilities and making sure you have the right people doing the right things. With very immature data teams, I see your standard data roles, and then I also see a much more junior makeup of teams. They might have one senior, but they don't necessarily want to hire a bunch of seniors because they're expensive. So they're hiring a junior data engineers, for example, or junior analysts. And those junior people, they don't have that nuance yet. They don't have that primary skill set yet and that specialty. So you can't really add that to their role. So they're just doing whatever comes their way. So I think as teams get more mature and as people get more senior, there should be a bit more of a distinction of what is your specialty, what is your unique value that you bring to the organization and fit that into your job description, role name, whatever it might be.

Actually, the underlying pattern there is, there's a boundary. You can take a person, you can take their skills, and you can take their maturity skills, their level in that skills, are they proficient, are they an expert, are they coaching? And you can draw a line around them. And when you draw a line around somebody else, it's different. Junior engineer versus a senior engineer. And so what you're saying is, how many of those people with the same boundaries do we want? How many people do we want that can code Python versus how many can code SQL? How many do we have that can deploy? Kubernetes can create a tableau dashboard. They are slightly different things. And what we want to do is create these relatively notional boundaries. So we have groups of roles or Personas. And then we say, right now what we want is we want more people that can do that. Who needs their skills increased to get them into that bucket. So we have more people in that boundary bucket.

Exactly. And I think that's super crucial as well, because the tend, and this is one theme of why I wrote the data ecosystem. But people tend to have very strict domain focus. You don't get many engineers who also know about data governance or they know about platform security and stuff like that. So you really do have to play within people's main specialty and main niche in order to optimize their skills and optimize what you get from them. And it is hard to learn and be more holistic and take a step back with these things if you're not at a leadership level or you're not instructed in that way. And I think that's the crucial aspect of when you're hiring. Make sure that you know exactly what you need even within that role.

So actually, the what people do could almost be a form of a gap analysis, couldn't it? It could almost be what are people currently doing and then what do we need to invest in to get them to change what they do? As in do something different or do something more. And that's what we're looking at is actually the gaps we have across our teams that we need to help fill, either with additional people or upskilling of the team.

Exactly, exactly. Yeah.

And key point for me is an engineer will be very good at policing the policies. They'll be able to look at the work being done and say whether it meets the rules or not. It's one of their great skills. And a lot of them are actually good at, really good at collaboration. So as long as we use policy forum and collaboration forum and not governance forum, they're going to come along and they're going to rock it. Just looking at time. Okay, so we deep dive in each of those. And now I want to come back to the overarching question. How would you define what an operating model is now that we defined all the moving parts that make it up.

Making me take a step back from all the interesting details. An operating model is basically a ways of working that helps you understand how to collaborate across the organization and coordinate to deliver the initiatives and the tasks in front of you. That's it in a nutshell. It's just, how do you do it?

I love ways of working. I'm a great fan of Scott Ambler. He was where I first started reading about ways of working. And the thing I liked about your operating model was not the term operating model, but if I think about ways of working and if I think about teams I've observed that have improved their ways of working, they are constantly jumping between those boxes and iterating something in the way they work to improve something in that box. So they will go and say, actually we don't understand what the organization goals are we feel we're disconnected and working on tickets that turn up. So they will then go and find a way of understanding where the organization is going and they'll find that the team's disconnected. So they'll work on the team goals and say, okay, as a team we need to be working together a little bit better. They'll jump down into delivery model and say, hey, looks like the handoffs aren't working that well. Or the way we're structuring the work across our team, there's a break in the flow in that process, so let's go fix that. Then they'll jump back up and and say to their data leader, hey, we're not being compensated as much as everybody else is and we didn't get the same pay rises, so go stand up for us. Or stakeholders are just dropping their requirements and running and never engaging at the end. So they're bouncing around all the components of the operating model that you've outlined because we can always improve each one and it's just a matter of improving the one that's hurting the most and improving our operating model. So I think for me that was the key is operating models aren't a one and done. That's not write the operating model up and then walk away and never expect it to change. The team should be tweaking their ways of working their operating model on a on a regular basis to make it better.

Totally. No, I completely agree.

Excellent. So if people want to find you and get hold of you or do some more reading about the awesome stuff you're writing about, how do they do that?

My main channel is LinkedIn so feel free to follow me on LinkedIn. Dylan Anderson, the one with the bow tie in the Picture and on LinkedIn I primarily post about data strategy but I also post a lot of tidbits from my newsletter which and also memes because I find data is very relatable through memes. It's a great form of communication. And then my newsletter is called the Data Ecosystem. It's on substack. Every week post about a different subject in the data ecosystem. I'm currently doing a five part series on machine learning and AI. What it is from the basics and exactly explaining it as if you're a 5 year old and you. You don't understand anything about data and actually probably five year olds understand more about data than a lot of people. But how do we explain the data ecosystem in its entirety? And so that's on substack. Feel free to follow subscribe Comments Very open to taking suggestions for new articles and new different things to dive into, but yeah, those are the two best ways. And then if you ever need consulting work, I work at Profusion, which is a firm in London, so feel free to reach out about that as well.

Excellent. All right, thank you for taking me through the components of the operating model. I really enjoyed that one. I thought there's some great patterns there that teams can pick up and try to apply. So go read the article and I hope everybody has a simply magical day.

Yeah, thanks so much Dan. Really appreciate it.

Net Dating Magicians was another Agile Data podcast episode. If you want to learn new patterns that you can apply to craft your own Agile Data way of working, head over to agiledata IO.