Ownership with Eric Brooke

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely Maybe Agile with your hosts, Peter Maddison, Dave Sharrock. And today Eric Brooke joins us and for an exciting conversation all about ownership. And I'm really looking forward to this because having heard Eric's talk before, I really enjoyed it, and uh he's very kindly uh offered to come along and uh have this uh chat with us and we can share it with all of you. So uh how about Eric? We start off with you telling us a little bit about yourself and how you got here and uh why this topic interests you.

My career is all over the place if you look at it, and it's partly driven by curiosity. I love complex things, I love things that are just not easy to figure out at the beginning. So you'll see my career has bounced between kind of like marketing, politics, computers, education. So how I got here was really a reflection of my career is that when I look at all the different sectors I worked in, both public, private, and government, the same things seem to reoccur when you're talking about humans at scale. And that one of the areas that I'm currently exploring, a hypothesis if you like, is the importance of ownership. Not saying ownership is perfect. You do too much of it, it can become a problem. Um, you do too little of it, it can become a problem. Um, so this is really a reflection of where I've got to in my career and thinking about how do I help people in the executive grow and become leaders, as well as directors, as well as say staff and principal engineers.

So, um Eric, can you just take a second there? When you're talking about ownership, how do you define that ownership? Because it's not control, is it? It's something deeper than that.

Yeah, I think ownership is like the dictionary definition is you own a thing. And actually, the complex thing um about that is what is the definition? What is it and what is it not? What are the boundaries for that? And realizing that you start off with a hypothesis about ownership, a domain, if you think of domain-driven design, or a system, or a process, or even an OKR, um is starting somewhere. And usually you think about what makes a business successful? What really matters for this business to be successful? And using that as your broad concept of understanding domains. The learning domain-driven design book by O'Reilly is really good. I found the early ones more dense, but in there they really talk about how do you establish what are domains. So I would absolutely recommend that book as a way of thinking about it. But it really is what matters to the business. And that's the way that you should think about it. Ownership shouldn't be just a technology thing, it's how it reflects in the business and how it reflects on your customers.

So, and and is that almost like a responsibility for the experience your customers have or the how the business is able to leverage, use whatever it is that you own.

That's definitely one way of doing it. I'm not that there could be other ways to do it, but that's often how I think about it. Is how do you serve your customers unless they want you to solve their problems in a certain way? I like that also because it starts the customer journey from one end to all the way all the way into how does this affect your team. So that's absolutely one way to do it. Yes.

And then it's about so how do leaders go about creating that culture of ownership within their organization?

I think that one of the things that, again, hypothesis that I'm thinking about is you have to type into the corporate values. There is probably a corporate value already that describes it, and that maybe you hook it as a secondary value under that corporate value, or you may even have a corporate value that says ownership or has those keywords into it. I think that's important because it describes the culture. It helps everybody when they think about the onboarding. But then how do you actually make that behavior happen? Because culture is really just a set of behaviors, is you need to have it as part of your onboarding. You need the stories that your company has already got about um Jill. When she did this, this is how she owned it. The more stories you have, the more myths, the more that then impacts in culture. And of course, then you need it to be shown in how do you do appreciation, in performance reviews, in your job descriptions. How is a language reflected there as well? So it's not just one place, it's got to be multiple places. The last thought I have is one example, one when I think of ownership and the things that I always want to keep doing better is also how do you make sure they stay the owner? So you may have heard of drive-by management. They can cause a lot of problems in terms of ownership, but it's also a great opportunity for you to mentoring or coaching behind the scenes to support that owner. So the owner is seen to stay with both the responsibility and the power or the authority to lead that area.

I I really like what so, Eric, it's it's almost like there's the public and the private visual of ownership. In the there's often a learning, there's a mentoring, there's a okay, exactly I'm not exactly sure what my next steps are, but that's almost that private side where coaching and mentoring and you know the the people that we talk to and so on becomes important. And then there's the public clear, you know, clear line of authority, if you like. I know this individual is responsible for or owns this particular thing, domain. And so they're going to speak to it. They're not drowned out by a second voice, or there's, you know, there's two heads to that hydro where there's multiple people to go to by the sound of it. So there's that public perspective, but a private perspective behind the scenes where there's plenty of advice and direction. It's not ownership in isolation.

100%. I agree with everything you said, is that the private part is as important as the public part. When I think about the public part, like good things to do around it is like have a change log. This this kind of domain or whatever it is, when things change, let's record it so that people understand what's going on. And as I absolutely say, the private side is the great way of turning followers into leaders, um, because then you're not taking their power away. And so I absolutely agree. There is two sides to that, and there's probably multiple sides to explore as well. Yeah, great summary, Dave.

Yeah, there's a there's an interesting piece here that we we touched on in your your last talk too. I think this is this around if we've got these public and private sides. So, what role does transparency play in fostering that sense of ownership amongst uh employees?

Yeah, so um transparency is definitely a principle I would say that I personally think is very, very important. I like more people to know more things. And I'm just gonna give one very quick example. When I did my MBA in the UK, um, there was this case study about the National Health Service of one hospital that was deeply in debt. And in a lot of cases, people at the executive level will say, this is a severe problem. If we talk to our team about it, the team's gonna get worried. But in this particular case, the CEO said, we are deeply in debt, and I need all of your help to figure out how do we get out of that debt. And they, by talking to every member of staff and saying this is the problem, actually made so many savings that they actually turned into profit within a couple of years. And that what that says to me is bringing more people in allows more creative solutions. There are more things to manage. I'm not saying it's easy, but I think it's a very powerful sentiment that transparency helps. In terms of ownership, everybody should know who owns what. Everybody should know when things change. I think that there are some areas when it's a coaching or mentoring that you want the um you want people to be able to grow and learn from their mistakes. And I think the other thing that comes in part with um transparency is how does the organization allow people to fail? How does the organization allow people to kind of like change and grow and learn? So I often think a good test of an organization is when something goes wrong, say an incident, what happens? If you take the DevOps perspective, like the handbook, you want to make sure you've got blameless post-mortems or blameless retros so people can talk. That transparency not only allows the team to learn, but if you share that with a greater organization, then everyone can learn. And then we don't have to make the same mistake. We can learn to make different mistakes and then learn how to solve that. So I think transparency is key to this. Do you have to be transparent about everything? I don't think so. Because sometimes you have to protect people when they do fail to some degree, because there may be something going on on their lives that they should be the person to share about. So I'm a strong believer in transparency, but I wouldn't go as far as like radical transparency that we've seen. Um, was it Ray Delali who talk about where you record every single meeting and everybody can see that? I think that can bring in a different dimension of shame, and shame can stop people growing and learn. So I'm a great believer in transparency as long as it doesn't um trigger people and their emotions. Sometimes you may have to, but you can prepare them for that.

It's it's really interesting what you're saying, Eric, there, because the uh when when we're all happy to own things when it's going great. Like we all like to sit and wave the flag and say, hey, you know, that's my thing that I own, whatever it is. But the rubber really hits the road when things don't go great. They're either stagnant, that that's they're just not making progress the way everybody is expecting of it, or when something goes wrong, how that gets handled. And I I think that to your point, that this is one of those classic things where as a leader working with somebody who owns a particular piece, when something goes wrong, that's when the leader steps in and takes takes the blame effectively, takes the shields that individual so that the individual can grow and change and get better at what they're up to. So there's a guidance piece there, and that bit should be private. I mean, absolutely, you don't want radical transparency into that level of things. But there that when things go wrong is is like the true test of, for example, is there ownership? Because if you go, okay, who owns this? And nobody's putting their hand up to say, you know, I own this particular area or domain, that tells you a lot about the ownership you may have thought you had beforehand.

Yeah, you see this a lot as you were saying, uh Eric, in the like incident space, and when things go wrong, when some system breaks, and and the best leaders I've seen when they you've had a major outage that's locked off multiple different systems, everybody in the business is screaming at uh, but the the leader is the one who's calmly like, okay, just work through the process. Like, let's focus on the facts, let's focus on what what's going on, let's see what we need to do, and making sure that everybody's calm and everything's going well there, and meanwhile, dealing with all the people who are screaming.

Yeah, and and uh to add on can transparency, communication is a two-way process, and transparency means it'll be a two-way process. So, um, yeah, I think it's very fundamental to coming back to Dave's point about failure, understanding failure in an organization will teach you more about that organization than any other thing. Yeah, yeah.

And and understanding, I mean, it's it's really quite a powerful thing because I think we I have not I'm not exactly sure where this comes from, but we we often look for the individual to hold accountable. I mean, people often talk about the single ringable neck and things like this. And there's that mindset of looking for the individual. And I think the true leaders and the coaches that we bump into look at the system. They recognize that the individuals are passengers and the system somehow has generated this particular incident, whatever it might be. So that you know, it's almost certainly the case that the individual is actually a passenger in that, unless, you know, responsible for it. And how do we look at the system? Uh, but that's it's not the natural way of looking at things like that.

No, I think one of the words I've been, I guess, fighting as I've been exploring this topic is accountability versus ownership. And I'm not sure I need to because everyone has different experiences of it. But when I think of accountability, it's often done to you. It's often punitive, it's often punishment. Whereas what I want to get to a place is ownership where you proactively own something and that you can see your value to the organization. Does it mean you've got accountability or responsibility? Of course you have. And maybe for me, that's just how I react to that kind of the words. Particularly at exec level, you have accountability for whatever your team does, even if you didn't know about it, regardless. There's still accountability on you for your observability into the organization, but not trying to get to that place where you're micromanaging, which is broadly a technique that's good in some circumstances, but very short term. And most of us don't want to work for a micromanager.

Yeah, it's a it's an interesting one because the the that being accountable, I've seen a lot of executives where their understanding of they'll use the accountability to micromanage.

Yeah.

Because they say, I don't want to micromanage, but ultimately I'm accountable. Therefore, I need to know and make effectively every decision that goes on. And I think that ownership piece, and it's it's an element of control or accountability or something, but there's something that as a leader, we have to give up in order to allow people that we're working with to take ownership for something. If we don't give up accountability or ownership and control, maybe not sure exactly what that word is, then the others cannot take ownership of that.

Great. I mean, this is uh, and we've talked in the past, and when you're doing that presentation, was there was this focus on a startup, and this is might be a good way of thinking of this, is where you've got the somebody sets up a new business, uh, they are the owner. By de facto uh standards, they have ownership of uh everything. Uh, they they now have a role of uh uh there's a couple of pieces here. How do I distribute that feeling of ownership to the other members of the organization, the people that I'm working with, the people I hire as a part to be a part of that organization? Uh, and then how do I get them to go on that shared journey with me and have that shared sense of ownership? Uh, and I think that can often be a challenge as to how do I then because the person who is the owner who set this all up is not necessarily comfortable with that uh letting go of that ownership because it was all on them.

Yeah, and I think when you extend ownership to the organization, um, founders have quite a journey, and like I've heard founders in my past say, but I'm giving you my baby, and I'm saying, it's not really a baby anymore, it's now a toddler, or maybe it's a teenager, and you know, that's a different kind of set of skills that you need to look after. But I think um that is part of the journey of growing an organization, and sometimes we have to shrink it, and that's equally painful in very different ways. But when you look at that journey of giving away control, it is a fundamental aspect of being an executive.

So can you talk a little bit about that one, Eric? Because I think that's something that many executives struggle with. And I'm reminded, and you're talking about entrepreneurs, I'm reminded of many entrepreneurs that I've known and worked with, where there's this mindset that the your employees never own the business the way you do. So, at what how do you, because clearly to scale, you cannot own everything as an entrepreneur, as a founder. So, how is it that those executives can get ownership out, like you said, to let somebody else take care of their baby? What are the stepping stones that they have to go through?

Yeah, I think um I don't have all the answers here. I can tell you the experience of my journey and some that I've learned from others. But clear expectations, being really, really thorough on what do you expect from me, how do you want me to communicate to you, and understanding each other's triggers. So if you're the C you've got a CEO and a CTO, the C E CTO should know what triggers the CEO. What is, and particularly if they're a founder, because there's a much more, I would say, emotional journey with founders versus non-founders when I when I think about the journey that I've had. But I think good communication is fundamental to it. And being careful not to fall into operational speak every single time that you have a one-to-one. Or the strategic things you're earning, are you getting the information you need? Is the other thing. I've definitely seen that as a journey of whereby founders and co-founders will dig into the nth level, doing effectively a drive-by, which causes lots of extra work and stress amongst the organization simply because they didn't have a single piece of information. If you can work out how you do observability at that level, so the CEO has the information they need, you understand the board well enough to know what kind of questions they're going to ask the CEO, so you're preparing the CEO. So I often think about supporting a CEO is often about being ahead, having like dashboards, having a good metrics that you both kind of align on. And the projects that matter to them, sometimes we consider them pet projects, they still matter to them. And you shouldn't dismiss them. If that's important emotionally to them, paying attention to that and helping the rest of the organization being an ally to the CEO so they understand why. Um and sometimes why can be their gut instinct is to try this thing out. Now they're an entrepreneur. Now, if you've got a big business behind them, they've also been successful. So I think good communication, packed to transparency, clear expectations, good metrics and dashboard to manage circumstances when it's more emotional are very, very helpful. But the last thing I'd say on that is you don't fight emotion with rational logical arguments. You let the emotion play out, and then you bring in like you acknowledge the emotions, you appreciate the emotions, and then you talk about the rational. You can't fight rational with, and you see this in politics as much as anything else. You can't, when somebody's on a particular topic, you sometimes need to let it play out. And sometimes then you give the facts and the details so that you can do that. But many of us as CTOs come from technical, sometimes introverted backgrounds. So sometimes we want to avoid that emotion. When I think of my journey of moving to Canada many decades ago, I learned very different things from a culture where in Britain there's a lot of banter. Um, in Canada, you're a lot more accountable for how you impact others, which is a good thing. It's a different culture. And there's very different sense sensitivities when you're in America versus Canada versus Britain. So the culture, the language, um all very important to pay attention to. And you're gonna get it wrong sometimes, and then you're gonna have to ask for forgiveness. There's a lot of stress at executive level, and you don't have the information most of the time that you need to make decisions. I feel like the higher you go up in terms of decision making, usually the less information you have to make that call.

Which is ironic, isn't it? Because that's actually the exactly the opposite of what is maybe taught in, I don't know if it's taught in business schools necessarily. Trying to think my MBA, maybe it didn't describe it quite that way, but it's certainly the way we interpret hierarchies, right? Yeah.

You you end up with different scales of debts, as you may get. Yes. There's a there's an interesting part there that you're alluded to. I love the way you described that. Uh, there's this this piece where the um the executive goes out and plays golf with their buddy, who's the sales guy for this other organization that he's just joined, and he comes back and says, Well, I I want to go play this product, and it it sounds way better than this other thing that I've heard that we might have somewhere deep in the organization over here. So could you go spend your time looking at that? And then the the uh pushback, whereas if you have the the ownership of like, well, I I own this solution, we've got the money, we've got the investment, the the cost of us potentially going down that direction and changing that strategy is much larger than you might initially perceive. Uh and but the to your point, the rationally explaining that uh could be a little difficult if the the personal, yeah, but my buddy says it's awesome, and we can replace the whole other system, and it'll take seconds to do. Uh, hopefully you've got somebody at the top level who's um had enough experience to understand that these things are usually more complicated than they seem. But quite often in a CTO type role, you find yourself in that rock and a hard place between, hey, I I I understand the what the technical implementations of this are and what it will actually take to implement based on the organization and the capabilities that we have. And now I've got to translate this into um your understanding from business perspective to help you understand, well, we have these capabilities already implementing this new technology, it may or may not actually help. And is this, let's have a more rational conversation around what that might look like.

Yeah, absolutely. I think sometimes buying time for your team as a CTO is incredibly important. And sometimes you have to ask that question of the CEO is this urgent? Does it need to be done now? And understanding what their level of urgency is compared to other things and what other things are they willing to give up? Because most of us don't have the software engineers, the data scientists that we need to do all of the things. So there has to be kind of like prioritization. And of course, then you if you've got product involved, they should be a key part of that conversation. I feel like product and um software engineering need to be strong partners, but also be really respectful and listen all of the time in that context to others and what they want.

It's a mutually beneficial partnership, right? It's not one serving the other, it's actually you know two working together to achieve the organization's goals. Yes. If I say yes to this, what do I say no to? And that's the strategy question. So so can I ask Eric, have you seen or come across uh any sort of guidance as to uh if you are a leader, what to continue to own and what to encourage that gets owned in your organization? Are there things that you should always own? Or how would you make those decisions?

I think it depends on a lot of factors. Um when I was thinking of the last large long-term engineering strategy I did is there's lots of different kinds of approaches to this, but I wrote down my thoughts, brought in, like, say, all of the technical leaders, the highest level experience of each of the stacks, got their experience, got products experience, and then shared it with the whole of products and engineering. What have we missed for the next three years? And then, so in that case, example, when it comes to strategy, I think you should, if you've got time, involve as many people as possible. Because I think all of us, one, want to be heard, regardless if we're a junior engineer or a senior engineer or an engineering manager. Um, and giving people the opportunity to be heard is very powerful because, you know, always someone cares about what I think. How long are you gonna stay at that organization? A little bit longer than some organization you don't. But we don't always have time. So it depends on what you're doing. I think the long-term things, you should involve as many people. When I think of our journey, say for career ladders, the last company I was at, we basically looked at, say, backend, took the basis of Circle CIs because it was a strong kind of like, and it's out there, it's public source, and then asked all the back end engineers, what's missing from this? What should we play with? What are the areas we don't know? And so they were involved in the whole process. At the time, the people team was kind of scared what would happen from this, but actually it became much stronger about what we expect to say from a senior engineer versus a staff engineer or an engineer one, which meant the interviewing process became a lot more consistent and our promotion process. So I think that where you can, you have the conversations in a wider audience because it will last longer. Can you go in as an executive and tell people what to do? I think you can do that a couple of times. And sometimes you're gonna have to do that. Like, say for example, around computer languages. Maybe everybody wants to do a different language for a different stack. You can't afford that. Like, and you have to help people understand the circle of life. Okay, so if there's an incident, will you support it? I'll go, yes. Oh, cool. What if you're on vacation? Um, well, okay. Um, what if you're sick? What if you have a kid? Like all of these things kind of impact. So I think there's a lot of circle of life conversations. But broadly, where possible, having going back to the journey of ownership is often the journey and the conversations are more important than the destination. Because you honestly never reach your destination. Because if you're growing, you get more ownership, more things to own, more things to do. And occasionally you contract it because you automate it, which is exciting in itself. So I'm a big fan of as much involvement, allow people to feel heard as possible because I think that gives you a longer term for whatever's decided. But it should always be reviewed occasionally, obviously, annually or bi-annually or every three years.

Yep, always good to uh to go back and look at these things and have that. It's the checking, it's the feedback loop, is what we've set out the right uh direction. Is this actually serving us now? Uh this is actually, I think, something that organizations and leaders sometimes forget to do, sometimes often, maybe. It's to actually go back and say, okay, well, we set here's our three-year strategy. Okay, we're never gonna look at that again. And what are we doing? Uh are we actually aligned? Are we actually going in the right direction? Are we still on track? Is that still serving us, or do we need to change? As these are all important factors of it for sure.

Yeah, feedback loops are vital or check-ins on when you did things, like we said we're gonna do this this quarter. Did we do it? Why didn't we do it? And what did we do instead? Give us greater opportunities to learn, as opposed to here's the free year strategy, never gonna look at it again. And I think that's a definite journey of how much you can do when you're a small company, how much checking can you do, um, versus when you're a larger company, it gets, I would say, potentially easier. Maybe it doesn't because of many other dimensions, say, like politics, for example, may get played at larger organizations.

What what um uh what's your experience in sort of like the things that stop ownership happening? Because I I mean, I think we're you know, all three of us are kind of strongly in agreement. We'd love the idea of ownership and of of uh allowing that control to go deeper into the organization, get decisions made closer to the coalface where maybe the right information is available and things like this. But there are many barriers to that. What do you see as those barriers?

I'd say, first of all, at the beginning, when you're a small company, like one person may own something and they may be a critical blocker for anybody else touching that thing. You also see in medium-sized organizations as you're growing out of that and you've got more people, so maybe you can have some of the shadows or even a team behind a critical system. Does that person give up that control of that? Are they onboarding people? Or is it what's called sometimes tribal knowledge, whereby that person leaves and you've lost all of that knowledge, and then you effectively have to restart. I think losing people, absolutely, and their knowledge uh are kind of big things in that, but sometimes that's also an opportunity in that ownership is now restarted, and then you can look at and what does that understand? Micromanagement is definitely gets in the way. A leader that has to have say on every single thing can get in the way. I would say that there isn't shared responsibility if you're in an engineering team for on-call. You see this in a lot of smaller organizations that the VP of engineering or the co-founder plus a small group of people are doing on-call. What does that mean? It means those people, your most talented people, are now not thinking longer term because they're in the now. And so if you share that, then you've got more kind of capability. Other things, when I think about what stops ownership, it's micromanagement, lack of trust, toxic culture, a lack of transparency, which can lead to lots of gossip. And then gossip starts to kind of like um kick back. What else would I say? Leadership by the CEO. Do they lead by example, by actually allowing the exec to have some say? And then does the executive give away theirs to the directors and managers and then the highly technical principals or staff engineers? So I think like a lot of things, it starts with the top. Are they willing to let go? And for most co-founders, there's a journey for that. And so the answer to the question is often cases they will, particularly those that have done the journey a couple times, but um, at the beginning it's harder. And that's when they need good support from their executive to help them travel that journey and to build that trust. But when I think about it, a lot of technology things come down to who are the people.

And that trust is uh is all critical, as we as we know. It's uh yeah, it's the without it, so many other things fall apart, and it's so easy to destroy and so hard to rebuild once you have. And uh so when you s when you're looking at things like well, even like micromanagement and other pieces where you're you're coming in, you're not allowing empowering people to be able to act on their own. And they'll they've they can very much end up also in a situation where they they don't feel empowered to do so, so they just well, you haven't told me to do anything, so I'm not gonna go think on my own, because why would I? Because anything I say doesn't matter, so I'm not really bought into anything that I'm doing, and uh it very quickly escalates from there. So it's um it's important that uh all of these pieces sort of uh roll into each other. I mean I I I see that one often at larger organizations, unfortunately, and uh where you've got uh a lot of sort of downward pressure and people don't feel like they're being supported and able to act, so they there's a lack of ownership and and a lack of clear understanding of the direction you're going in.

Yeah, I think the other thing is how do you show appreciation? Is it for the individual? Um, an anti-pattern if you only appreciate individuals is that those that are really driven are going to do what's best for themselves. And whereas opposed to if you give appreciation to groups of people that own something, you're much more likely to see, I would say, a collaborative culture. So uh I would also say sometimes secretive cultures can actually also lead into who owns something. Like some organizations, particularly in big tech, will actually have multiple teams working on the same thing. So a competitive culture can sometimes be helpful, but sometimes it can go too far. And how do I grow as an individual? If the person cares about, say, a job title, does that mean they care about collaboration just as much? Understanding what motivates people and hiring the people that are motivated in healthy ways is really, really helpful. And when people go toxic, which most people do, even if it's for a second, is how do you help them get back? So coming back to the other thing that will hinder it, if there's punitive punishment for failure, then you're not gonna see anybody wanting to own anything.

Yeah, pretty much. So we we've been talking for a little while. Should we think of some ways we can perhaps uh wrap this up into a few points for our uh listeners?

I'm gonna ask Eric just to summarize a few things in a second. But one of the things that struck me as we're just kind of bringing the conversation to a close in the in the last few minutes, is we started the conversation around ownership, which feels very almost transactional. You own this or you don't own this. And in fact, I think Eric, you've described it as what is ownership, what it is not, in terms of that piece. But most of the conversation now has been all about basically people and emotion and culture. And that's what I think this is one of the reasons we're all fascinated and and continuously learning the leadership side of things, because it isn't you know something that we can just draw up a job description and say this is what you want. It's something that is is an emotional conversation, it's a journey that people are going to go through and it's organic, I think, in the way that it is so driven by the people side of things. And I think that's really come out in the last few minutes of the conversation in particular.

Yeah, I'd agree. Um, I think there are things that you can assist those people with because when defining culture, you need to have the frameworks, whether it be the cultural value, how you do appreciation, how you do performance review, how you react to kind of failure. And then all of that really also how do you do a good onboarding process so other people understand your culture? But the other thing that I would add into that is we don't want to all like I personally don't want to work at an organization where I work with clones of Eric. I want to work with people with many different perspectives so that I can learn from them and they can teach me things. So when you do cultural ad as opposed to cultural fit, you're often bringing people that may think and feel and want to belong in a different way. That is a great opportunity, but you then need to think about how do you do conflict resolution, how do you do communication, how are you sensitive to different cultural values? I think all of that interplays and cultural ad creates more work. It does, but it has the greater potential to also lead to greater business, greater service, whatever you're doing in your particular organization. But I would agree that this is a lot about culture, but you have to reinforce culture because otherwise people will behave in whatever way they want to. And then you technically have anarchy at that point.

So, what would be your number one takeaway from the conversation, Eric?

Um, when I when I'm researching this, the thing that I step away from really is the most important thing about ownership is understanding the journey and talking about it as an organization. Um, it will be different in every organization, the words, the language, everything will differ. So worry more about listening to the journey rather than getting it done. Now, you obviously you've got steps to do, but that's the step one. The second thing is as you grow your organization, because this is not always possible at the small stage, share. Have teams that support critical systems and processes and domains. Don't just have an individual. It's not fair on the individual, and also the organization wants protection for when the individual leaves. And the last thing, coming back to what Dave said, is this is organic. It's going to keep changing. As much as you want to fix it and hope it'll stick, if you're growing as an organization, those boundaries are going to change. So be open-minded if you are an owner to change and welcome it, welcome feedback, and then you won't get stuck because that's the worst thing to do for yourself as an individual and as a career and for the organization.

Awesome. I I love it. I love the way you summed that up uh for us. And uh, Dave, have you got anything you'd like to add?

Oh, I think I've already added a few things. I really like to enjoy the conversation, Eric. It was really um great. I was making notes as I'm going through going. I've got to remember that as we're going through, so it's been fantastic.

Thanks, Eric. Awesome. Well, well, thank you very much, Eric, and thank you, Dave, as always. It's uh it's wonderful to have you here. I really enjoyed the conversation too. I thought we got to cover a lot of really interesting topics. Uh, if anybody'd like to reach out, they can at uh feedback at definitely maybeagile.com. And don't forget to subscribe because we always like to have uh new people listening. So thank you very much.

Thanks, Peter. Thanks, Dave.

Thanks again. You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and Dave Sharrock focus on the art and science of digital, agile, and DevOps at scale.