Kenny Baas-Schwegler - Autonomy, is that what we really want? (EN)

[00:00:06] Sorry, um, welcome everyone. I had some technical difficulties, so my computer was really autonomous and just didn't care what I wanted to do. So I borrowed another laptop, so thank you for that. Um, I don't have some of my notes, so I might skip over some things, so just so you know. And let's start. So, welcome. Um, before there's any gossips, you see my dear friend Evelyn's name on this slide. She's not here, I'm taking over from Alberto, um, so that's why I'm doing this one alone. Uh, she's happily having a holiday, and all is fine between us, just so you know. So, welcome. I'm going to talk a bit about autonomy, and is that what we really want? This will be the only Spice Girl quote in this whole talk. So don't worry if you're not a fan of the Spice Girls, but it will be the only one. Um, and I always like to start with a different story from outside the IT and that's with me moving houses two years ago. Now, I bought a house with my wife, um, which looks a bit like this one. It's not particularly the one, my wife was a bit worried about you osinting me. So, uh, that's why it's another house, so, um. Um, but you would have think, oh, buying a house, you own it now, you're autonomous, right? You can do whatever you want with it. Well, unfortunately, here you see the car on the drive in, right, which is a carport, so my house has a carport. Now, in the legal document I signed, it says, you cannot remove it.
[00:01:48] But the land is mine. Yeah, but you cannot remove it because other houses in my area don't have a carport. So there's a few public parking spaces, and if I would use these public parking spaces, there won't be enough public parking spaces, right? So I need a bit of alignment with the rest of my neighborhood. Right? So this is an explicit contract that I'm not autonomous in my own house. Now, secondly, you see these beautiful cats, these are mine. Uh, they also have needs, right? So I, well, I actually drilled a hole in my house so that they can go outside, start hunting, uh, the neighborhood. So again, uh, this is a more implicit contract that, well, I need something with my cats. I'm also in this WhatsApp group, unfortunately, I'd prefer to be in Signal, but with the neighborhood. And there's also a lot of, of these boundary discussions going on that how much autonomy do you have, right? Can I have a party at home until four at night? I could tell you, uh, no, uh, at one o'clock you probably see a lot of WhatsApp group going around, right? So, yeah, me having a house is not really autonomous. And this is pretty much the same thing what we're going to discuss about today, uh, within IT companies, right? We have teams, and the whole thing nowadays with this book is, well, we need to give teams autonomy. And I truly believe in that, we should give them autonomy, we should give them more autonomy, especially in a lot of organizations where this is not the case, we should give them. But there's a thing here, um, How much of it are we going to give it? And what does autonomy means? So let's look first about what autonomy means, right? Autonomy as described by Mr. Pink is the urge to direct one's own life.
[00:03:32] It's it's it's pretty much own, me, thing, right? Without the ability to control what, when and how we work and how and who works with will never be completely motivated to complete the task. This is his definition of autonomy. And there's more in the book than autonomy that most of the people skip about and will talk about. But this is one definition of autonomy, right? And for me, this is already a bit, hmm, it's about me directing one's own life. I couldn't do that with with my neighborhood. I cannot direct my own life. I have certain rules and boundaries to restrict to them. Now there's another talk, you can go a bit deeper, my friend Romeo is here, um, if you want to talk more about psychology and that we can never be autonomous as a human being, please join us after this talk. Uh and that will last probably for a week, just so you know. So I won't talk about the about this definition of Eric Burn about autonomy. Uh, but I will more likely go into this definition, Merriam Webster, right, where we say we direct one's own life. The quality of state of being self-government, especially the right of self-government granted autonomy. Now, who here thinks that this is autonomy, that this is the correct definition of autonomy for you, for teams?
[00:04:53] A few, interesting, yeah. So, and this is the problem when we, me and Evelyn, go to a lot of these organizations. What is autonomy? And I fully agree with what Jape and Mark says here, they hate the word autonomy because it sounds individuating. I don't hate the concept, I hate the word. Right? Because it can sound like I can do whatever I want today. Which is not the case. I just told you. Well, if you're with one team, well, maybe. Right? So autonomy can be really compulsive, it can be a means to an end. We want autonomy because we don't have it. And yes, we should listen to that and yes, we should look at the concept. But what does it actually mean being autonomous? Right? If it's just having autonomy for the autonomy, it won't work, unfortunately.
[00:05:47] It doesn't mean I can do whatever I want today. Right? You will have certain rules to how much autonomy you will have.
[00:05:58] And that's it, that's when you want to discuss the autonomy. It's about what's your story. What in your context, sorry, I'm a consultant, it depends. How much autonomy is good for you? And today in this talk, I'm going to talk about this polarity map that will help you define the boundaries of autonomy on several levels of your organization. Because for me, autonomy means the individual part, while alignment, which is usually the opposite, in this case it's true. The opposite of the polarity, which means the whole. And you need both sides. Right? So usually when I hear we want autonomy, that usually means people are mostly on the whole part at this moment. They're focusing here. Now, the thing about the polarity here is, polarities are not things you can solve. They're ongoing problems, yeah? So tonight I'm going out for dinner, that's one problem, where do I go? Fine here, and we solved it. But the polarity is like, how much autonomy should we give them and should we give them a lot of autonomy, that's more a polarity, it's an ongoing thing. Just like breathing in and breathing out is a thing that's ongoing. I cannot ask you, what do you want? Breathing in?
[00:07:15] Breathing out? Yeah, we both need them. It's the same with autonomy and alignment, you both need them, but how much and where are we on this map? And as you can see, on both sides has what they call positive effects. So for a part, that means uniqueness, an individual or a team can be very unique in what they do.
[00:07:37] But also the whole is the connectedness, which is the alignment, both positive sides. We're going to dive a bit more into this polarity map later on. But both ends of this polarity also have downsides. If you're staying unique for too long, like what I'm going to discuss later, Ivory Tower architects here? I am one. Very unique, very isolated, right? We also don't want that. Or if you stay too long in the alignment, you're all going to be the same. Most bureaucratic companies and cultures turn into sameness and then they wonder, oh, where's the innovation going?
[00:08:14] Yeah. And these are usually the companies that go into the we need autonomy mode, yeah? So we're going to discuss a few of these here. And we do that on several levels. Now, this is not a technical talk, but I will be diving a bit more into code level first. Yeah, I won't be showing you a lot of code or I will show you code, that's not entirely true, sorry. But I won't go into details of the code. I'm going to talk a bit about testing. Yeah? And we're going to see how the polarity and autonomy works on that level. Then I'm going to dive into the team level. So the team as a whole also has parts, right, the individual and the whole team. Then I will go more in between teams.
[00:08:56] And I'll finish today with the organizational level autonomy.
[00:09:01] So this will be uh all my examples and for each one of the examples I will use the polarity map to show you how we mapped that autonomy out and how we created boundaries together for this autonomy.
[00:09:17] So let's start with autonomy in code. Um, I'm a Java developer, sorry for that already. Um, I was a Java developer actually, nowadays it's Ruby.
[00:09:28] Um, but when I started my career, I started doing Java programming. I started going into a team, they were writing software and luckily they had a good practice of doing testing. Unit testing. Uh, hopefully everyone is okay with unit testing.
[00:09:45] Great, great. That's that's already good. So, um, but when I got in there, we were having these classes. And this is the only slide about code here, right? So this is a Java class and you see one class called the calculate class. And then what the common practice was when I joined that team is that we had a calculate test. And for each of the classes in the Java thing, we had a test to accompany with. Whoever used this strategy before, this testing strategy for each class. Yeah. And it's a good practice, there's nothing wrong with it. But sometimes you can also do more what they call sociable test. Right? This is the other end of the spectrum.
[00:10:30] Hopefully already feel the polarity coming in here. So the solitary test, which is the one I just described, is some unit testers prefer to isolate the tested unit, while some often the tested unit relies on other units to fulfill its behavior. And both strategies are fine.
[00:10:49] And this is again the polarity happening, right? Autonomy and code means that solitary test, some that we're going in and isolate that tested unit, but there's downsides to it. And on the left side we have the sociable test.
[00:11:03] And every time we pick up something new, we should decide what to do.
[00:11:09] Because they both have downsides.
[00:11:12] Now, some of the people here already heard a bit about domain or design. And and I put this in here because for me, I always look about what do we want.
[00:11:23] Now, DDD has this bound that concept of a bounded context and it has a model for a specific purpose. For me, testing the code means is my model doing what it's supposed to do? And I don't care if I use sociable test or the solitary test. As long as I'm tested what the model should do.
[00:11:47] And I can decide different on anywhere. See, so that bounded context is a reflection of our language that the business architects, developers, the code, but also the tests speak. And this is often forgotten in a lot of DDD talks because it's around the around the code and around the architecture, but tests are also part of it.
[00:12:08] And how that looks is I have some of these in the top left, I have some of these tests. I tested an object inside my domain model, and that might be my sociable test. I can test it all and if that succeeds, this is what we call acceptance testing, that can be done in unit test, then I'm fine. But sometimes when I drill deeper, you can see it here, if I go deeper inside that one object and it has a lot of complexity. I might use a more uh uh solid test, I forgot the name, sorry. Now, I might I might go deeper because the complexity is harder, so my feedback loop will be harder.
[00:12:46] But every time I tackle a new problem, I decide, do I go for the sociable or the solitary test?
[00:12:53] And how does that look on the map?
[00:12:56] Is if you look at the solitary test, which is, we should test in isolation, we have fast feedback on failure. But changing or cascading changes will happen on the solitary test, who whoever had that with that one-on-one approach that they changed one test and then whoop, you needed to change all the other tests. Yeah, that's a downside. But then what we can do is more go to more sociable test, right, which is more coherent. Less mocking, so you have less of these cascading effect, but a failure of a bug. Can happen in other classes, right? So you go deeper, you have a faster feedback loop.
[00:13:38] And this is what I want to present, this map will help you which of the test will we help you, which will help you the most in that situation. All because that's the goal what you see in the top, what I want is feeling secure to change the code. What I don't want is cascading changes on my unit tests. Yeah?
[00:14:01] In the next code section, or in the next level, I will show you, okay, but how do we decide when to use one or the other, right? But I'm just hopefully you get that each time is a different situation and we don't pick one strategy. We try to blend them both in and stay in balance here.
[00:14:22] Okay, so that was autonomy in code. So let's go a bit to autonomy in teams and the individuals and interaction over processes and tools.
[00:14:32] So,
[00:14:34] one thing. We're social people, we like, in essence, a hierarchy.
[00:14:43] Right? We all want to stay safe, we all want to feel part of a group.
[00:14:49] Which if you hear me say that, hmm, autonomy but also part of a group. Sounds a bit paradoxical.
[00:14:58] Which maybe it is.
[00:15:01] But sometimes we make decisions over a polarity, right? Sometimes we say, we have this
[00:15:10] technical leader, right? We want someone to make our decisions for us because we now need a bit of leadership. So who likes sometimes, who likes it when other people make decisions for you?
[00:15:22] Come on. Have you never been on a holiday where someone just took the decisions on where to go, where to eat? Yeah, it's nice.
[00:15:32] I was in a conference two weeks ago and Steve, uh, did a major job of getting us to a restaurant. I like that, I didn't need to take the decision, so it's a guilty pleasure, sometimes we want to be lead, right? We shouldn't forget that. But the thing is, if we keep that decision in place, then that is where we have the problem. So when you talk about teams having technical leaders or someone doing the software architecture, which is great, right, because you can really thrive with that expertise. But we need to keep vetting and revisiting that decision. Because it's a polarity, you're giving away autonomy to a person for a long, right, as a team, because that person will be doing decisions. But please put in place something to revisit that. Because that polarity will mark more towards, oh, now only this person will take decisions. And what happened is is that autonomy in that case will turn into dictatorship. Because that person was like, yeah, but you wanted me to me to make the decision.
[00:16:37] I sometimes come in as a consultant, as a software architect, and they're asking me, can we need help with software architecture? And then what I do is I'm going to play the benevolent dictator. So I say, okay, you need some person making decisions on software architecture to help you because you don't know how. But also at the same time, I put some feedback in place to see when can they start making the decisions themselves.
[00:17:10] And that's very important. Because at that point, when you don't revisit that decision in your team,
[00:17:19] people will start to hold it against someone.
[00:17:23] Yeah? Who's ever been in that situation where someone took the lead and at some point started messing up with everything? Changing the boundary and start thinking, okay.
[00:17:35] Yeah. And then we try to do something about it and that person was, but you wanted me to do this, right? That is when you're dealing with the polarity, right? It's good that some person takes the leadership, but you need to keep re-affirming these boundaries. And what happens eventually, and this is what I see, uh, again as a very good example. A friend of mine went to a low code conference. And they're experiencing these same problems again. And their problem was an application team grows, delivery slows down because multiple developers compete to change the same code. Sounds to me you're dealing with a polarity here. But instead of dealing with the polarity, they just do branching. I. And I'm like, why? Because you're dealing now with that alignment versus autonomy polarity at that point.
[00:18:27] Right? And that's what I want you to start recognizing is, is this problem a polarity problem? Because a polarity problem is not solvable. It keeps coming back and biting you constantly.
[00:18:43] But if it's a one-off decisions, then it's fine, then you can just take the decision and move on. But in this case, this this competing to change the same code is a polarity because it keeps coming back at you. And you won't solve it with branching. Sorry, you won't.
[00:19:00] You occasionally might need branching. But let's see how that works. Because what happens when you start to do branching, is people start to go into isolation. And they start to work in isolation for maybe a day, which is, well, maybe okay. But if they do it for a week, they start to divert from that alignment.
[00:19:21] Even two weeks, it will be feedback but late. If it doesn't turn up in the main or the trunk line, it is not aligned or integrated. And you're dealing with an autonomous person dealing on a branch that is not aligned with you.
[00:18:52] because it keeps coming back at you. And you won't solve it with branching. Sorry, you won't.
[00:18:58] You occasionally might need branching. But let's see how that works because what happens when you start to do branching is people start to go into isolation.
[00:19:09] And they start to work in isolation for maybe a day, which is, well, maybe okay, but if they do it for a week, they start to divert from that alignment.
[00:19:21] Even two weeks, it will be feedback but late. If it doesn't turn up in the main or the trunk line, it is not aligned or integrated. And you're dealing with an autonomous person dealing on a branch that is not aligned with you.
[00:19:39] And what happens then and this is just the thing I always see, yeah, but I've already spent one, two weeks on my branch coding. Why change now? I've already wasted so much time coding. Right? So there comes a PR and a review and then they're like, okay, let's just duct tape this together and just move on. It never gets fixed. Right? So what happened here is on a branch you have freedom, you have creativity, individual creativity, I applaud that, but a branch has a loss of cohesive mental models. And this is what you don't want, right? We don't want bugs. That happens when you're staying too long on a branch. So, on the other side, we have trunk-based. We care for the whole. We shared a mental model. We have team effort. But one thing, if you all start coding, well, maybe not trunk-based, but mostly aligned, you get excessive conformity. We don't want that. So what I usually see is the whole discussion now on Twitter, no, don't, don't code alone anymore, start mob or ensemble programming. Right? Which is great, which is perfect. But just so you know, ensemble programming is one side of the polarity. So within this polarity map, as you can see, I put some stickies on the outer sides. And these are the important parts of the polarity map because if I fill in the center with a lot of teams, you usually get the same thing. But the left side and the right side are the signals and observations. So I'll ask a team that's sitting on a branch, okay, what are some signals or observation that you're too long on a branch?
[00:21:21] Well, we compete to change the same code. Right? That's what that problem was. Okay, we compete to change the same code. If that happens, what can we do to stay aligned? Well, definitely not more branching. What we can do is actually do mob programming.
[00:21:39] So, and at some point, you will have what are signals observations going to the bottom of the aligned one that we're doing too much of the ensemble programming. And I hear people say, well, we don't have a lot of new insights, right? We didn't get a new insight for 10 minutes. We're just moving along. Ah. Maybe we can split the work and start working alone again. Maybe on a branch for a max a day. That's fine, but not longer. Right? So it's a polarity that you need to keep managing. And these signals and observations are the ones are the boundaries that you need to keep discussing with your team.
[00:22:16] When do we get into that isolation? What can we spot? And agree on these because these will bring you to the other side and keep the polarity in balance. And know what exactly for you does autonomy mean?
[00:22:32] And especially, again, I already told you, using this bounded context pattern to find purposes in the team. Daniel Pink already described it. It wasn't only autonomy, it was also mastery, it was also purpose. Bounded context, can or the bounded context pattern will give you that purpose. Yeah?
[00:22:55] So that's inside a team. So a team maybe at some point has his own purpose. They're staying aligned by themselves, doing this polarity map. But now they also have other teams to deal with. And what I usually see nowadays, and this is something I see in the last two to three years when this autonomy thing became more of a hype. Is that I'm dealing with one team and they need the other team to do something. They maybe need to switch ownership around. Maybe they say, well, instead of them taking the ownership or we taking the ownership of this change, they need to do that. And then I ask him, okay, but what's the problem? And they say, yeah, that other team is autonomous and they, they control their own backlog. Okay? And if we talk to them, yeah, we need to see if they're gonna pick it up. Who's been in that situation where the other team is just, yeah, not on our priority? Sorry, because we're autonomous.
[00:23:51] Yeah. And that's what I see, especially as a DDD person doing a lot of these sessions. The purpose and the autonomy of the bounded context pattern is pretty nice, but it has a compulsiveness to it because you still need to stay aligned. And then this book popped up.
[00:24:13] And there's a lot of great stuff in there and there's also some stuff that DDD already talked about. And that's how do these models interact with each other within domain design, we call this the strategic patterns. Now, strategic patterns aren't any more important than the tactical patterns by the way, they're all equally important depending on your context, but team topology describes a few of them in their own words and I really like that.
[00:24:40] Because if you can see the systems here, you have the stream aligned team, which are the teams that are building value for your business, right? And they usually design their own bounded context.
[00:24:53] And you usually want them more or less autonomous, right? Then, of course, you have your complicated subsystem team, you have your platform team, you have your enabling team, but let's zoom a bit in on that stream-aligned team. Because in that stream-aligned team, we need to be careful, right? Because we don't want to give them too much load. And they talk about this concept of cognitive load. What does that mean? Yeah? So if they're still autonomous and they're getting too much of a cognitive load, where can they dump it then? Where can they dump their load? Nowhere because everyone is autonomous.
[00:25:29] That doesn't work.
[00:25:31] And there's this meme going on there with the teams that need to be autonomous where they say, well, we're now building this whole new product, let's from day one, make sure that the teams are autonomous.
[00:25:47] Well, DDD described this partnership pattern, um, team topology calls it the collaboration style.
[00:25:55] And this lowers autonomy.
[00:25:59] But what it does really well is at the start of a new product and you're building with two teams a new product, I cannot design an API between the teams from start one. Because that's really hard. So what do you do? You let them collaborate for the first sprints. Let them have less autonomy, and over time they create their APIs if designed well and if you take care of that, they will design their APIs and then move towards more of autonomy.
[00:26:32] So again, this compulsiveness of everyone should be autonomous. Well, here's a partnership pattern or the collaboration pattern from team topology that says otherwise. Which is also great. Right? There's more to it than all only teams that are autonomous. Sometimes you want them to work together, especially, especially when you're building or setting up a platform team. What I so often see is that the platform team are just the ones that know the most, they're going in isolation and they're not talking to the teams that are using their platform. It should be the other way around. There should be a partnership and they should be building it together. Right?
[00:27:13] And then that last thing, sorry, I skipped a bit. And then that last thing is that enabling team.
[00:27:20] And now I'm gonna talk about my favorite topic, which is software architecture. So who's ever dealt with this ivory tower person like me? Who's been an ivory tower architect? Don't be shy. Yeah, it's a common thing because um this enabling team is great and we need definitely still need software architects, but there's a problem there. And is that enabling teams need to actively avoid becoming ivory towers of knowledge, dictating technical choice for other teams to follow us and how do they do that is by having a purpose.
[00:27:53] An end date. I'm building a software architecture practice, but the first thing I do is, how can we make sure that the teams are enabled doing software architecture? That is my end date.
[00:28:07] Yeah? Because else you're gonna get uh this thing, the ivory tower architects will stay in their ivory tower or the platform will stay in their ivory tower, they're building components nobody's using. So set up that partnership.
[00:28:24] Yeah? Because one thing in this polarity map is when you stay on one side of a polarity for too long, you get the downside of both, as you can see here. Right? So if I stay in that isolation part, which is on that side, right? I have the freedom, I have the team creativity, which is nice, right? You can set up an enabling team. And that enabling team can innovate, can really set up a platform or software architectural practice. But if they stay there too long, at some point they get a loss of equality, they turn into isolation, they become selfish, right? They, they become, no, this is how you should do software architecture.
[00:29:08] Well, it depends. Depends what do the teams need. How do you enable the teams? And what happens then at some point it turns into excessive conformity because the ivory tower architects will say, this is how you should do it. Conform to my standards. We've built them.
[00:29:27] Yeah? So staying too long on one side of this polarity will get you both negative sides.
[00:29:36] And just map it out there again. If you're building up an enabling team, put up the polarity together and see when do we turn into the downside of isolation? So if I haven't heard from you in one month, dear software architecture team, you've turned into isolation and that's not a good thing. Right? So we, what do we do? We come together again.
[00:30:06] And I always need to put this slide up.
[00:30:10] Because I hate it, because what is this is excessive conformity for me. Right? It's an isolating thing.
[00:30:20] Just so you know, everything in here is focused on that one part, which is structure, but we need to form boundaries as team together context-dependent. And that's not what this tries to do.
[00:30:34] So, we talked about autonomy in code, autonomy in a team, autonomy between teams. And then the last question always is, okay, but what about organizations? If the teams turn more autonomous, what do we as managers, architects, leaders do?
[00:30:56] For me, the thing is they need to set visions with the team.
[00:31:02] They need to set boundaries through doing these polarity maps, right? They usually have the whole of the organization there.
[00:31:11] And then at some point when they say, okay, we implemented, we helped the teams create a vision, we aligned them to the organization. Who calls the shot now?
[00:31:22] This is what I see happening a lot with a lot of teams that are, who's ever had this situation, who calls the shot now at some point in the organization? Yeah, because the lines are a bit more fuzzy because they become instead of explicit boundaries, they become implicit boundaries. And I'm dealing a lot with this.
[00:31:41] And one thing what happens then is people get frustrated and they turn to dictatorship again. For me, is again a part of a polarity called power and they forget the other side. So leadership is not dictatorship, it's not management. Leadership requires us to balance this power and love, this boat situation and go to the teams. And set these boundaries with these polarity maps. That's one aspect. I'm not saying you should only do polarity maps, there's more to it, but polarity maps really help set that boundary between autonomy and alignment. And then at some point we say we gave them autonomy, why aren't they doing anything with it? And this is the second situation, right? As a leader, you really want to start vetting and and understanding what the teams are doing and dealing with. And my wife has a background in anthropology, and I learned a lot from her what they're doing in their social scientist field where they spot patterns, spot patterns in what the team's dealing with. Get quantitative but also qualitative information from your teams.
[00:32:57] And then when there's autonomy everywhere, do we still need managers and architects? Sorry, it depends. Depends on your organization, on the, on the how large of your organization. I don't think we can get rid of them, but we should as well try to go for that, try to make teams as autonomous as possible, but also teach them with polarity maps to stay aligned, enable them. Set dates, make sure to revisit and keep vetting it and do that with that polarity map. So,
[00:33:32] for an organizational wide, it's really about do we do centralized or decentralized decision making? And again,
[00:33:43] we keep changing that balance around here. Where decentralized decision making is empowering the individual, it's spontaneous and um but the downside of course is, as you can see, the group cannot coordinate. It's FOMO and feeling left out. Whoever had that, by the way, if you have decentralized decision making? Oh, they're now making a decision that I'm in the expert on. And you're in another team? Oh, you need to deal with it.
[00:34:12] And then we have the centralized one, right? Empowering the group, group can coordinate, group acting decisively and everyone feels included, but the thing is we're gonna get queues.
[00:34:22] And some people I know are now talking about the way software architects have the advice. Advisory, it's called. I'm, I'm not sure. Andrew talks a lot about that. And that's that thing, right? The problem is how can we deal with the queues? If you're a software architect and you need to dictate everything, you become a queue.
[00:34:46] But if you let teams do decisions themselves, they cannot coordinate.
[00:34:53] And if you want to do it effectively, try to map it on this one and try to see what are the signals.
[00:34:59] To do that advise process for software architecture decision effectively, see for your context, where on this map you are. Because for me, in the end, we don't want autonomy, we really want agency. Which is we want autonomous software systems, but we want to have teams that can decide for themselves, but know what their impact is in the organization. And what we don't want is indecisiveness in the end.
[00:35:30] And the last thing I'm gonna talk about is this patterns of autonomy and isolations, they are fractal in an organization. And for who that you have don't know what fractal is, it means it's on every level I just talked about in your organization.
[00:35:42] You can probably find the same pattern back again. Right? You can bet you can find that on every layer. What do I mean with that? As an example, I've seen autonomy, or I've seen people more on the polarity of action, taking action, so that's also autonomy driven.
[00:36:04] And I see a owner of a company telling a software developer, could you move that button a bit to the right? Right? Now five years later, on every level of that organization, that same pattern is still there. The system does not forget.
[00:36:23] So if I'm now dealing with that same team, I'm trying to do something like event storming. Right? Collaborative designing and more planning. The first feedback I have is this is taking too long. Why can't you just move that button a bit to the right?
[00:36:40] So if you see a pattern in one side of the organization, try to spot if you can see it on every level. Because it is repeating. And just so you know, the highest level, which is usually the sea level, they usually decide what the rest of the organization does, right? So if the organization down tries to go autonomous, but the C-level doesn't want you to be, it's going to be a very hard thing to do.
[00:37:08] So please see if you can spot that. So autonomy is that what we really, really want? Oh yeah, sorry, there's the second spice girl quote. Define and negotiate boundaries continuously and really try to start with managing that polarity, make these signals and observation explicitly with your teams, with your organization, uh and that will help you negotiate how much of autonomy a team needs or requires at their moment in time. It's contextual.
[00:37:42] Thank you very much.

Transcript