[MUSIC PLAYING] The Agile Focal Point Podcast with Mike Leber and Harald Wild. Org topologies is our topic today, and it's our pleasure to have the authors in our show today. Welcome, Alexei and Roland. We're going to learn about org topologies. We're going to learn about YouTube, probably, too. That's an interesting one, too. But a shameless plug. I think we came together recently, and we want to run the workshop you're offering in many cities all across Europe and in other countries. Also in Vienna, end of this year. There's a lot of time to decide yet. And before, I want to learn more about org topologies, too. So this is the opportunity in this episode. Before we dive into the topic, Alexei and Roland, give us a little bit of a background of yours. Where are you coming from? What do you do for a living? And how did you get into the fields where you're into today? Yeah, thanks. Alexei here speaking. So we have quite similar backgrounds in terms of that we entered the field of Agile and org change and org design through the doors of software development. And then we got converted to the Agile methods and the Agile values quite early in our careers. And a recent part of our careers is that we both are scrum trainers. As we say, we go to different churches, but we pray to the same gods. So Roland is a scrum trainer with Scrum Org, and I'm a scrum trainer with Scrum Alliance. Different churches, but the same god of, I guess, adaptability. And this topic of building adaptive organizations and adaptive org design is a passion that we figured that we share about seven, eight years ago when we start meeting each other regularly at different conferences. And yeah, I even call myself an organizational geek these days. Roland doesn't agree. He doesn't want to be a geek. He wants to be a professor. I don't know, man. Professor or something. But we're both geeky in regards that we love organizations. We love their messiness and their complexity, and we love people who work in these organizations, and we want to help them. And I guess we share a belief that most of the organizations are not built to fulfill the maximum potential, the human potential that they have. And that's where we believe our ideas that we call org topologies can become handy, because they can help an organization to reach its full potential of human creativity and intelligence. Beautiful words. Wow. Let's take three seconds to let that sink in. I am Roland from Holland, as we discussed earlier. I'm broadcasting from Utrecht, the beautiful smaller version of Amsterdam. And yeah. And yeah, so the history has been explained already by Alexei. We share common interests and passion. What I do for a daily business or in daily life is anything varying from scrum master to advising people in the board on how to improve their organization or the performance of their organization. And these are maybe a little bit already difficult words. What is the performance of an organization? But I think Alexei has put it right that the ultimate goal, whatever performance you're describing, is to reduce waste and release human potential. So I really want to get rid of Taylorism, and I want to contribute to creating more modern organizations where people can really collaborate together. And we all use this brainpower that people have to decide on taking babies, on buying a car or a house, or immigrate. That same brainpower needs to be used to contribute to delivering customer value. And what I see still happening, although it's 2024, people going to the office, and they turn into someone else. So that's my mission, my calling. So that is very interesting. Your background, both sides, is Scrum. And as far as I'm concerned, Scrum doesn't talk a lot about organizational design other than just saying here is a minimum viable type of-- some call it bureaucracy or organization, whatever. What brought you finally into the field of organizational structures, org design, organizational development? I would actually disagree with you, Mike, in regards that Scrum is not about org design. Well, for a lot of people, Scrum, it's about the process you put on top of an existing organization. And maybe that's why we see decline of Scrum and Agile ideas in general. Some people even claim Agile is dead-- my favorite hashtag these days-- in social networks. But actually, Scrum requires org change. Because, I mean, just to give you one example, if you think of a role of a Scrum product owner and you really go and try to understand what they really mean or meant 30 years ago by this term, this role, this position, typically doesn't exist in organizations before they apply Scrum. You have business analysts, yes. You have product managers doing different things, maybe yes. You have different stakeholders who come once in a while to push a new project onto a team. But the role of a product owner is something completely different. So actually, in order to introduce Scrum properly, I would say, it's not enough just to call any of these people product owner. You need to introduce this role structurally in an organization, which is hard to do. So Scrum is actually about org design. But I agree that the problem, though, with Scrum is that these Scrum creators were not really-- they have never been really clear and precise how would you scale Scrum. And because they probably wanted to develop their own scaling businesses individually somehow, they never agreed to do it together. That's my just interpretation of why it's not so clearly done in Scrum. So Scrum, by most people, seen by a team level agile framework or agile process, which is sad and which didn't have to be like this. But we are where we are, 2024. And a lot of companies just implanted Scrum poorly at the team level. And they didn't get the promised benefits of Scrum and agility. And now they are in search for something else, something different. I agree, actually, very much with what you say, Alexei. And maybe even the notion, like Mike just put it, Scrum is not really org design. If everybody believes this, then that's the main reason why it is not delivering on its promise. It's not a process change. It really requires restructuring your organization instead of just adding that way of doing a team into your organization. Yeah, and another example, actually, would be why Scrum is about org change. It's the notion of a Scrum team, right? I mean, there is something that you might not have in your existing organization. You need to create it. But even if you think you have teams, actually, they might not be the Scrum teams, which I described in Scrum. So Scrum is based, for example, on this idea of multi-learning, where people in a Scrum team need to stop thinking themselves as a skill. So there should be no Java developer in a Scrum team. There might be people with Java development as a skill, but there is no Java developer in a Scrum team. So everybody can learn Java, and now you can have multiple people representing that skill, which is actually a very big paradigm shift. And it requires change of your org design. Because, for example, if your HR, HR, human resource processes, are motivating people to go deeper and stay narrow specializing, a Scrum team actually would not fulfill its hidden potential. So Scrum is actually is about org design. The problem is that org design is not a topic raised by any of the Scrum creators somehow. Clearly, org design is not a term mentioned in the Scrum guides, I believe. They talk about lean. They talk about a complex adaptive system. So nobody actually is talking about org design. And we, Roald and myself, we have discovered this big, vast field of org design, which is a science, which is not a new science. It's been around for 30, 50 years. There are books from '70s on org design, which are still relevant. And so we, our mission somehow, is to make org design accessible and approachable by everybody who essentially is doing org development. And essentially, every manager in the company, every influencer, every change agent, every team member, essentially influencing org design in organizations. So we all are org development. All are org developers. But we have not been trained doing that. That's why the designs that we build suck at times, in most cases. I want to emphasize that we're not all about Scrum. We believe in the power of Scrum. But if you look at the org topologies map, to bridge to the subject of this talk, there is no Scrum on the map. So we're talking about capabilities of organizational units. And they can be individual, or they can be teams. And one way of having a great team is by making it a Scrum team. But we don't say you have to have Scrum teams. We just want you to create multi-skilled teams, or multi-learning teams, creating fast flow teams. So Scrum is not on a map. But of course, we're biased. We know this example of well-oiled Scrum teams that really perform excellent. So that is a thing that we have in the back of our minds. And we had it in the back of our minds when we were developing the map, or rather discovering the map. So the map contains 16 archetypes, which are examples of organizational design elements that you can see building blocks for creating an organizational system, of which one of them might be a multi-skilled team. And there's 15 others. And we organized those elements, those 16 elements, on two axes. As we found them, we saw-- we were thinking about, what is it? What is the difference between this project-driven organization, where all these individuals need to be planned and coordinated, in comparison to an organization where they do large-scale Scrum? Less. Wow, it's so different. But how come? And what are the differences? So the main characteristics that we used to categorize the 16 elements that we discovered is, horizontally, the completeness of capabilities, where the lowest completeness is a single individual-- they're one person, OK? They're limited to a single skill. And then on the other extreme is people put together who are able to do a lot of learning all the time, a lot of time taking up new challenges. They're multi-learning. And they're end-to-end. And they have this capability of being fast flow. So it's growing capabilities from left to right and horizontally-- just horizontally. And vertically, we look at the scope of work. So how much scope of work do these organizational elements share with each other to collaborate on, OK? So share to collaborate on, which means when you go up, starting at the bottom, the lowest element that we see to work on is a task. And then as you go up, you can work on bigger problems, which are features. And putting features together might be a part of the business offering or the product, OK? And ultimately, knowing everything that the company is concerned with so the whole business focus would be at the top of the vertical axis. And by combining the different levels of those characteristics, you can order these 16 archetypes where we put in the upper right corner our vision for perfection, which is a company where there is zero distance to customers. There's collaboration with the customer. And the people that work there, they are really-- they know everything about the product. And they can do everything on the product. We will dive deeper into these concepts. But maybe before zooming out for a second, elevate a pitch. What is org topologies in a nutshell? You mentioned this map now, and patterns, and the differentiation within. But what is it, if you put it out as an offering today, in your view? Or maybe in your clients' views as you get feedback nowadays? Because I think it's pretty new, right? It came out during the past month and one, two years. And it's probably evolving. Well, the one-liner is-- and I still like it-- it's a thinking tool. It's a visual thinking tool. It will help you to think systemically about developing your org design for creating value. Yeah, you can say it's a map with a certain direction to help organizations navigate in the journey of transformation or of an improvement initiative or in general. So it's a map that will help you understand where you are now in terms of your org development without using fancy terms like Agile, and Scrum, and whatnot. So you're looking under the hood of a company, and you're trying to really understand which blocks it comprises on. And so you'll be able to understand where you are. And then you'll be able to have meaningful discussions with your colleagues in the company in terms of what's our vector of org development. So yes, it's a thinking tool. It's a visual tool. It's a shared language. It's a map. It's a map with a compass. All of these together, and hopefully, you'll be more equipped to be a more skillful org designer than you currently are. Because as we said above, everybody, essentially, is influencing the org design decisions, although might not be thoughtful about it. And this map is a hope, right? We have this hope that having this map, people will be able to make more thoughtful org design decisions and hopefully, eventually, will unleash that hidden potential of their organizations. Well, you know, it's always helpful to understand the personal context and where concepts come from. And as you mentioned, you are both Scrum trainers. And how did you both come together working on this? I'm not sure if that's actually super interesting for our audience. But like what you said, we are Scrum trainers, yes? And we have this one of our biases. I think it's important to be aware of your biases, right? So one bias we have is Scrum teams is a great place to be. Scrum teams, despite all this hate and dislike and lack of love to Scrum, actually, I think both of us, we saw good Scrum and well-run Scrum teams. So we are anchored and biased about this idea of stable, long-living teams. And I guess that's where we met with Aroland. We shared that belief. And then by talking to each other and deciding to work together, we've realized we're also biased by other things. And for example, we are biased believing that high adaptability of organizations is a good direction every company, every business needs to be working towards. So we refer to the initial definition of Agile, which is not about doing things faster. Actually, if you search context, search Agile manifesto for the word "fast," you'll find zero occurrences of this word. So Agile is not about fast. Agile is about being able to build organizations which are more adaptive, which can learn faster, and which can react faster, and which can find and deliver customer value easier, cheaper, and in this case, faster. So we are both anchored with Scrum teams. And we're both anchored with this belief of high adaptability as a target. Because actually, adaptability is not just we like it because it's nice. No, we believe that every organization essentially wants to stay relevant for its clients and stakeholders for as long as possible. That's essentially the goal of any business, to stay in business. But in order to be able to stay for as long as you want in business, you need to learn, and you need to change, and you need to react. And for this reason, you need to keep discovering the value and the changing habits and tastes of your customers. For this reason, being adaptive is a good thing, because you'll be able to do it faster than your competitors. So these two things that we find ourselves being biased and anchored with, and we thought, hey, we like each other so much. We also play guitars a little bit, and we hang out. And we thought, yeah, we like each other so much that we should be working on something together. And we started to work some years ago on these ideas of topologies. And here we are. We have a website, we're in a book. We've spoken at dozens of conferences on these ideas. We have an active community of hundreds of people who are using these ideas on a daily basis. So we think we found something that people find valuable. And there's an interesting thing, because we talked already a little bit about Scrum. This is not at all about Scrum. There is some of these patterns involved. But as you mentioned, the org design has come before. And there are many organizations out there somehow running a little bit of Scrum. And some of us might say, that is not what it was meant to be. So the question is, is org topologies then addressing clients or people who've already embarked on an agile approach? Or is it totally independent from, and then might lead to, is there any path? I think initially, when we started to build the map, we discovered these organizational archetypes. And they were all agile, or in some form of agile state. So that's where we started to map. But then later on, we discovered, but actually, what if you haven't implemented any agile at all in your organization? Shouldn't those people also find themselves a place on the map so they know where to navigate to? So the lowest archetypes are definitely not agile. Therefore, organizations who are still to start and embark on their agile journey can benefit from the map to see what their steps would be to develop an agile organization. For those organizations who are already on a journey and maybe had a couple of transformations under their belt already, this tool might be very interesting to start with to contemplate on, where are we now? Where do we come from? And where is it exactly that we want to go to? And why is this a valuable addition when you're already way up in implementing some kind of framework? You might argue, well, we know our framework. So why do we need another framework? Well, Org Topologies is not a framework to start with. It's a complementary thinking tool. And it will help you to create a common vocabulary to talk about the organization as it really is. So we're not saying, yeah, we're doing safe, or we implemented unfix, or whatever. We just look at the core building blocks that are underneath. Maybe there are some elements in your organization that are just single specialists that do a lot of valuable work. And they're still in projects. Well, there's also some other area where there are agile teams with a lot of dependencies, and another area with teams that don't have dependencies at all. That might be. We can map that, all that, make it visual as one big ecosystem. And that will give insights in where the existing organizational design can be improved for creating a more agile organization. Yeah, so it's not just for companies which are already on the agile journey, not. We even don't use the term agile anywhere for the Org Topologies, because it's not about being agile, not being agile. It's not black and white. It's about knowing where you want to be when you grow up, kind of, as an organization. When you grow up. And yeah, well, essentially, this will be somewhat in line with some of the agile values and principles. But even if you believe you're already on the agile journey, on the agile transformation as a company, in large companies, there still will be these work units which are not teams, or which are not cross-functional teams. You always have a mix of different things until you reach that nirvana state, right, where all teams are. It's not sometimes even possible. So that's why this map has this variety of 16 archetypes, where some of them are more recognizable agile building blocks, like cross-functional, end-to-end, fast-flow teams. And some of them are functional groups, or individual, single-skill workers. All of them have a place on the map. We want to be inclusive. And it's not about dividing the world into agile, non-agile. It's about giving a map where everybody can find a dot, saying you are here. And from here, you can decide where you want to go into. So super inclusive, super easy to understand. And it's not about agile or non-agile. I think we, in 2024, we should actually stop, quit that dualistic language, scrum, non-scrum, agile, non-agile, and start actually talking about real stuff, like where you are, how you work, what's work, what's customer, what's product, what's adaptability, what do you want to optimize for. And once these things become clear, these simple 16 building blocks that we're offering as a map can be helpful to realize how we should be structured in order to have those emerging qualities. - Yeah, I was just exactly thinking about this. I mean, thinking about larger organizations, and as far as I know you, you've been working with really large ones. We mentioned scrum, and I remember, Alexei, you've been involved with the very first, I think, large-scale scrum initiatives, less for some who don't know it. And large organizations love matrix organizations, right? That's where they are coming from. That's where they feel they can optimize. Optimize for what? And that's the question. Where do I find my customer? Where do I find my products, my product, and what is the product? And who's going to collaborate on what? Is that something where people would utilize the map? I mean, starting with to say, hey, we're here, and this is, I mean, figuring out what are actually the orientation points, I would call it. - And I understand the map is just one tool to start looking at, right? I can imagine there is a process then to deal with it in a way that you would suggest. - Yeah, it's just one way of looking at some of the dimension that we find interesting. You're talking about the matrix organizations in which every individual has multiple managers, which can lead to a lot of confusion, and many lists, and many conflicting orders and directions every individual receives, although the goal was actually to minimize complexity. So matrix organizations can be, I guess, both well-managed and ill-managed. We don't have the dimension of management style on a map because we believe that's easier to change than your org structure. So we want to kind of put outside the discussion on which managerial culture and tactics we use. First, we want people to understand, like go back to the basics, right? Like, so what's value? Who's your customer? What do you do as a business? How are you making money? And after you understand that, you'll be able to understand how high or low the work units are on the map. You know, if every team understands a customer and has the same understanding of product as the customer, they will be super high on the map. If they are super far, very distanciated, distance from customer, they will be low on the map. And then discussing that and discussing how you want to, you know, bridge that gap, then I guess you can go into the discussions of which new management structures and tactics we need to apply here. And I guess it's not about being metrics or not metrics because I think, you know, you can be very agile within a metrics organization, or you can be very rigid in a metrics organization. So this is another dimension, which is not maybe that important in the beginning of this analysis that we're offering with org topologies mapping. - So how do you align the work via org topologies like the org structure with the operational flow of work? And how do these sides probably of the same coin go together? - If we look at the organizational units that we find, we observe the organization and we look at who's working in there to deliver value, we can go to the teams and the people that do the work and observe with them and ask with like, what are you working on? And they will give you a very clear answer. They might be working on some security feature, or they might be working on multiple tasks they get from lots of other projects because they have a certain skill that needs to be given to all kinds of projects. So we learn from talking to the people, what they observe as being what they often call their product, between quotes. Because when a team says their product is the billing engine, then actually the billing engine is a component or maybe an application that is needed together with other applications for the company to really create customer value. I hope you see my point. So internal product definition is often scattered and the smaller elements of the whole product as observed from the customer outside in. As customer stands outside the company, they know what their need is and they want something on their phone to, I don't know, transfer money. So that outside in view, you can compare and contrast it with the inside scattered small product visions. That creates what we call the product gap. Now that is a good starting point for having a discussion. If you talk to a team and they think they're very busy working on their billing engine, but how much value do they really create from a customer perspective? Now we're talking about almost about money. How well is that money invested in finding more billing solutions? If the customer is fine with the way he's getting his invoices. So this brings really the subject of how is a company trying to deliver value and using the visual representation of teams and people collaborating together that you need to be able to deliver that outside in view of value. - It reminds me somehow on value stream mapping. That's what I was always thinking about, right? And I think that's where Harald came with the one coin, two sides, because with value stream mapping, we never talk about structures. I mean, we talk about structures, but basically we map them out, right? We try to focus on the flow, but we usually don't get immediately back to, okay, what's the structure driving or prohibiting flow? - Maybe that's, so the flow would be the horizontal dimension to explore how we create value. And you can optimize that. That's always been my problem with lean. They optimize the existing processes, but my idea is if the process isn't any good, then you should step out of that and recreate a new process. Now, you can do that better if you look at the second dimension, which is the vertical dimension, the difference between the smaller team level or individual level definition of what value or product is and the outside in definition of what product or value is. - And this value streams in lean, they work well because, well, in lean, you put your customer first, right? You always talk about customers pulling value. So first you talk about the customer and then you start analyzing your value streams. But in our agile or post-agile, whatever you call it, movement DevOps era, we sometimes don't really remember who our customers really are. And that's why all this value area, value streams, whatever people call, in most cases, they have nothing to do with value for the customers. We were at a conference the other week where we had a discussion with a participant where they say, "Hey, our department has product teams and how do we optimize the work?" And then after 20 minutes of discussion, we realized their department is just infrastructure service in a larger organization and they are not product teams at all. They don't really understand what the product is and who they call customer are just other teams in other rooms or other floors of the same company. And the real customers are not even on the picture in the mind. And if you are so far away from remembering who your paying customer is, right? Then all these exercises with value streams, there'll be just a better local optimizations somehow, but you're not actually breaking those silos and shortening the distance to the customer. So the Orc Topologist map, it works only when you remember who your customers are and what the value is for them. And if you keep that reference to the customer, then now you can ask, "Okay, so what are my teams are working on? Are they working on the same understanding of the value that the customers have?" Which means if yes, they'll be pretty high enough on the map, B and C levels. Or if not, if they are working on components like a billing system, like Roland's example, and the customer is not buying a billing system, the customer just wants to have something else and there is a billing process in place, but it's not really what the customer is seeing and paying for, then those teams who see only billing system will be too far from the customer and will use this fake idea of other team being a customer. And those teams will be pretty low on the map. So doing Orc Topologist mapping, I have to say is maybe a pretty, if not painful, but insightful activity. I'm going to frame it positively because you'll be able, you actually, you will see that, hey, despite all these agile transformations and improvements that we've done, our teams are super low on the map. They are not really understanding what the customer value is and they optimizing something that is part of the bigger value, but not directly. So, and most organizations that we work with and we help with Orc Topologist mapping, they found this big product gap, as Roland mentioned above, between the inner understanding of the value and external customer. And we believe bridging this gap by different means is a very noble act. And this is where this, you know, human potential will be realized and waste will be removed. - I'm thinking just about, because you mentioned adaptive organization before a couple of times, which is this sort of direction organizations might or should, you know, I'm too careful about should, what anybody should do or not do, but look after in 24++. But as we know, there are usually a lot of hurdles. Things were, despite all the competence in the organization and, you know, all the tools and all the consultants, McKinsey's and Accenture's, sorry, I didn't want to name anyone, but it doesn't really move further. And I'm not sure if this is at all, I mean, change part of Orc Topologist, but if not, I'm pretty confident and I know this is part of your competence and background. So the question, what finally is needed that organizations become adaptive in your experience or how you would work with them? What could help? What do you see as helpers? Other than saying, "Love it, change it or leave it." - Yeah, where to start? It's a big question, right? So how to help organization be more adaptive? Well, first of all, we need to ask them, like, what's stopping them from being adaptive, right? And why are you not adaptive now? And what happens if you learn there's a need to change your product strategy? How long will it take? And what needs to happen in your organization to be able to adapt, you know, change your course towards this new thing? Like a Titanic, you know, like how many miles do you need to continue going towards that iceberg, you know, before you'll be able to actually steer your ship away from the iceberg. And in every company, it will be very something contextual. Maybe there is an annual big batch investment process in place, which stops this company from being adaptive. Like if you can steer your ship only once a year to a certain direction, good luck not crashing onto some of the icebergs, right? Another example would be, well, we are focusing too much on fast flow and keeping the teams super fast locally and busy and owning small parts of our product. Like maybe every team owns a microservice because we believe that's the best way to make sure people, you know, take responsibility of the work. But essentially, if everybody is holding on to a very small thing, again, you know, it's like rearranging the decks on a sinking Titanic, you know, it will not help you to move away from the iceberg. So it's very contextual. There will be like different things. That's why this, you know, Agile, or in general, org transformations, you're gonna have to find any recipes. They all, you need to go Gemba. You really need to talk to people. You really need to understand, study what's happening there. And there, you know, find things that are easier to change than the others and start with them. And maybe your annual budgeting process is not the first one you are going to start with. Maybe first you would introduce CI/CD and make sure at least at the team level, at the engineering level, the teams can be more adaptive at least locally. And then this will accumulate into high level of adaptability. - I would say that, sorry, yeah. So I would say that the primary goal of using the org topologies map is to create transparency, okay? So of course we would love to see that people take action based on what they see transparently in front of them. But that's like, you know, coaching. You know, the client has the answers and we cannot tell them what to do. They will need to make up their minds. And we really think that we have created a tool that can create a transparency awareness for people inside the organization to understand how powerful the tool of org design is for achieving certain goals. It's not about painting the place blue for safe or in an agile color, right? It's about understanding the way we do it now costs us so much. Our transactions costs are so high. Our time to market is X. Oh, wait a minute. So this is why, because when you look at the map, I've got all these scattered little elements that I need to coordinate. Maybe, how can I, you know, resolve that? And then now comes the most important message of my small, how do you call it? I think that thing in Dutch. I don't know the word in English. Well, my small talk. There's also space between the boxes on the map. And it's important to understand that every space between a box represents learning and shift in a mental model of people. So moving from one level horizontally or vertically to another requires deep understanding and beliefs of new things that you would thought were impossible before. Maybe the idea of, you know, when you're trying to manage many, many deep specialists with projects, moving away from that idea towards creating, you know, cross-functional teams that can solve problems, that requires tremendous mental shifts horizontally and vertically. - Yeah, just so to give an example, like there's a big gap between A and B levels, which is a vertical move on the map. I think that's the biggest gap we can have in the industry. So at A level and below, you really believe in this idea of that the teams and the workers need to be autonomous and independent. And you're doing whatever you can. You know, to create those famously known autonomous agile teams. That's your A level. Actually, that's why it's called A level because agile autonomous. Autonomous starts with A, although it sounds like O, right? And then, I mean, for some of us, that sounds like the end of the agile journey, but we figured that's only the beginning. That's the first step. That's the first agile wave, as you call it, is to create those work units which can be autonomous if you want them. But the gap between the A and B going up will be actually to drop this idea of illusionary autonomy and embrace inter-team collaboration. And this is where a lot of companies currently, I think, are struggling and our prediction will be struggling in the next five years to go from A level to the B level on the map if they want to go up, right? If they want that unattainable level of highest adaptability. And let me explain to you why it's important to bridge this gap. So if you have like 10, so to say, autonomous teams in your organization where every team owns a small part of your product or technological stack, like there would be a mobile team, maybe even one Android, one iOS. There will be a search team. There'll be a catalog team. There'll be a basket team, a payment team, right? You know, all these teams. By the way, a very clear signal that you are below this A and B gap, you are A or below, is when your team names represent the work they do. So if you have a search team, you know, who's gonna work on search features. But the goal is not to do more of search or more of iOS. The goal is to do what the business was meant to be, right? So the goal is somewhat higher. Imagine there's a business stakeholder and it's a part of our class, right? We have this simulation in our class. Imagine you have a business stakeholder who wants to increase retention in the company. By retention, we mean, so the existing clients are become returning clients and they buy more and more often. Well, and then imagine there is this hypothesis that in order to increase retention, you need to show recommendations of what people bought before. So you need to enrich and enhance your search to be able to put in some previously bought products. You would need to, you know, embed this recommendation engine all along the catalog, the basket. When people are about to pay, you might want to remind them whether they've forgotten to buy a paper for the printer they had bought before. Like all of these parts of the product must be enriched with this retention features. Now the question, who of these teams which are listed above for this search, iOS, et cetera, can do this retention work? This retention epic or project or whatever you call it, right? It doesn't fit into any of those teams' backlogs. All these teams need to work together somehow to reach that goal of increased retention. And this is this gap that we are trying to show you, right? Because none of these teams are able to think even in those high level terms, in business goals or in customer goals. And if you are remained this low level organization, let's say A-level organization and you have this so-called autonomous teams, but your business stakeholder wants retention, you'll have to create some kind of a project. You will need to cut this big epic into pieces, put those pieces into different backlogs, you know, and make sure those pieces come together for this. You need some extra managers. At a B-level and above, you do not have any more search feature. You don't have any more of those special features. You still have search though, and IOS, but the teams are learning to work across those components as much as they can. And now retention can be either worked by one of these teams who will need to implement those recommendation things across all the components, which might be hard, or at least several teams will be able to do it synchronously. So in one sprint, all these five teams will get together and will implement these changes across all the components. So being able to work more synchronously, like at the same time on what matters for customers and business stakeholders is this characteristic of this higher level archetype. And this gap is very hard to bridge because, you know, people listening to this podcast, probably you have some bells now ringing in your heads. Like how about cognitive load? How about ownership of repositories? How about quality if everybody is coding in different repositories? How about, how about, how about? So we all have this buts, buts, buts, buts, buts. And of course, this is not easy. That's why it's a big gap on the map. But if you are able to bridge that gap, and it's not a fantasy, we work with organizations, we saw organizations, we research them, we interview them who were able to do this. You are so much faster than any of your competitors because like in one sprint, you can change the product across like all the components. You don't have to plan it in one sprint, search next sprint iOS, and it will last forever. You are much more condensed. You are much more working at the same time to finish what I'm trying to say all your teams work as one big team. So this idea of this high level archetypes, as we call them, you go back to the idea that the company is one big team. Yes, you have this smaller scrum teams, if you like, because somehow we like this idea of five people working at one table, it's nice. But everybody, you know, is able to contribute to what's important for the customer. So this idea of team of teams come into place. This is an example of this big gap we have on the map between the boxes. - So just for those people who have those bells ringing in their head with all those objections, this is good because that's just a list of impediments you need to fix to be able to grow towards more collaboration between teams. And that's a different way than adding more coordination between those teams, right? This is about collaboration. So it means really going into the code together, refining together, building it together, reviewing it together. Now, this brings a lot of advantages. You know, there might be disadvantages in your heads. Maybe that's because you still need to get used to those other concepts. But the advantages, you probably will see that it will simplify your organization because it will reduce the amount of coordination you need because people work synchronously on the problems and not asynchronously on a smaller element of that problem. Okay, so that's what we call descaling. - Yeah, so if you can take this big epic from your stakeholder and do it in one go, there are no projects. It's just an item on your backlog that these teams share. So only when you bridge this gap from A to B and above on the map, you can really drop projects and really talk about product development. You know, we talk a lot about this product development in Agile space, like let's stop doing projects. It's a concept of all times. Let's do real product development. Well, it's easy to say that, but if your teams are locked into working on just some parts of your product, you will always need this kind of artificial constellation. You might call it a project or initiative or an epic or a bet that will unite all those teams that will have to somehow work together and coordinate with each other. But if you go up, you can really drop projects because you will simplify. And again, it's not a journey for everybody. It's not the journey for every company, but if you're really taking Agile or adaptability seriously or if business agility is the thing you're aiming for. - Business agility, yeah. - Yeah, we actually believe that there's no other way than to go diagonal on the map from left bottom to top right. You will need to create better teams and you'll need to improve collaboration between the teams so it becomes more synchronous. - Well, we have heard a lot of interesting insights of what you can achieve with org topologies, but there's one question that came to my mind that I'd like to squeeze in. What should the upper management or maybe the board, especially, provide for org topologies to be successful and how can it help the board in its role? Because out of my experience, and that might sound weird, but organizational development and design is not something that is always available in boards or upper management. It should be, but there's a lack of knowledge in that area, at least out of my experience. How do you think org topologies can help the board or board members to get insights about their own company or the company they are running? Because they are responsible for designing the system of the company. - Yeah, good question. What we know from the smart people in the less community is that step zero for any transformation is to educate everyone. And one of the things they do with board members is to engage with them into systems thinking. Now, I think that's a very good idea, but I also think that teaching systems thinking is not really on the top five list of what a board member wants to learn. I think that with our map, we can get smart people that are in the board of directors within 15 minutes into understanding what the map is about and how to start mapping. And they will be thinking systemically about changes in their organization while they do that. - Yes, and I have this image in my head, like there's a table and a big map laid on the table. And you see people standing around this table and pointing fingers on the map. And who are those people? These are C-level people, mid-level managers, and team members all working together to really understand where we are. And only team members actually can clarify this because you will need to ask a question like, "So what is in your backlog? "Are these tasks or are these features "or are these business goals?" And C-level people will think differently than the reality is. So the team members will be able to clarify where we are currently. And the C-level people will be able to explain where they want the organization to be in say, two, three, five years. And together, they can start plotting and discussing. So what needs to be done? What would be the biggest impediment going from this to that? And that's why you'll have agile coaches, cram masters also around the table who pencil down those impediments and start working on that. So hopefully, and it's a dream, it's a hope, but this can become that unifying tool to have those powerful discussions. Of course, you can have them without a map, but somehow people don't have those discussions as much as we want them to have. So we have this hope for them that with a map, maybe it's just easier to point your finger at something on the map and say, "Actually, we are here." - But board members probably are very much concerned about financial stuff. They have targets, financial. They need to do things. Now, what's not on the map is a financial mapping. But there's a lot of stuff you can do with a map that is not on the map. We have extended boards available for people who join our trainings and our group to watch them and to see them and to learn more. But what I can, financially, what I can explain is moving horizontally from left to right means that you're reducing your transaction costs. Moving vertically from bottom to top will reduce your switching costs. So for a member who has maybe a strategic desire or a need to reduce costs, they can use this map to navigate, to see where they could get most of the reduction going, for instance. Or if they don't need some, I don't have a big appetite for changing direction all the time, they at least know they're sacrificing certain investments at the benefit of something else that they need, well, located lower on the map. So there is this other dimension for people that are having the responsibility of steering the company. And this other dimension, we need to teach and explain to the board members to make them see what these dimensions are. But it all boils down to, how do we set up the elements to collaborate together? Because that will create some kind of, yeah, good or bad working system, which will be cheaper or more expensive to run or change. That's what it boils down to, yeah. - So like a real map, it provides safety with direction. - Yeah. - And so an insight in which direction you should or you could proceed. - Yep, yeah. And you can experiment trying options without implementing them. You can just discuss the options and the pros and cons. - Yeah, this is actually another great example of using octopologies, because typically people see one solution to existing problem. And this is like a default solution. They didn't spend time thinking, but this is what everybody's doing. And they're doing this because it's safer on the mind, this default option. And default option is very rarely a good option for in complex problems. So on the octopologies map, you can simulate, you can visualize and compare and contrast different options. And only once you really understand every option of your org design, then I think you are more skilled now to decide, actually, which of these options we would like to go for. So yeah, it's a tool which supports generating more options, exploring them, comparing and contrasting them. Also based on real stuff, like org design is super real. I mean, if there is a team in a company, it's real. You can go and you can see, and these people will be in the same place at the same time. You know, these are real things. So we're not talking just about processes or some tools. We're talking about real building blocks of organizations that you can study and you can change. And we believe it's important for every board member, every change agent to do. And yes, as you said, it's not on the top of the mind of board members to do systems thinking and to engage in org design, which is kind of ironic. You can not see us, but we're actually now smiling, all of us. It's ironic because there's nothing more important if you're building an organization than to think systemically and try to create org design which will last. - And to tie back to those hurdles that all the large consultancy firms run into, you know, when they try to advise, these hurdles will become more visible as you plot out different scenarios on the map. And you can envision to bridge those gaps or take the hurdles or not. And you can, you know, like we said, explore options. So yeah, in summary, I think it's definitely going to help leaders to be able to connect what they have on their agenda with what's happening inside the company. And you don't need to do it all. And it doesn't need to happen immediately because once you start mapping and you would do it frequently, also with people from the board, every half year or quarter, I don't care, you can monitor progress, you know, because this is an incremental approach. It's not like we need to prepare everything, big bang, flip, and we're done. You know, you can go tailor-made per department. Maybe different changes need to be done. And you can gradually plot the route for this department and monitor whether they're still on track. And you can explain the direction with the common language to the people that are in it. So they get better understanding of why we're driving in a certain direction. And they can take ownership of moving towards the direction. So, and I think those are also important things for leaders to understand that if they can, you know, they don't need to spend millions and millions. Well, maybe that's too much of an exaggeration, but on internal campaigns for getting everybody on board for the next transformation. This is all about creating transparency with a language and sharing the responsibility for creating the target design and helping to further develop it. - Yeah, and we've studied why org change is usually such a risky endeavor, which might not result in the outcomes that you expect, even after you spend these millions and millions, as Ron say. And one reason people refer to, and there are studies based on this, is it's lack of ownership. You know, you might spend as many millions as you want on a nice slide deck from a consulting firm, but if you don't really understand what needs to be changed, if you are not ready to do it with your own hands as a manager, likely the change will not happen. You cannot outsource org change, you know, you can't buy it, you need to do it. So this lack of ownership is a problem. I think it's a big problem, especially these days, where people want to buy like, you know, ready-made, you know, a turnkey agile transformations, they don't exist. And this map, and another pitch, why this map is useful, we believe, is that it will help you to better understand where you are and where you want to go, and essentially own that change journey. And then you can invite consultants and tell them, hey, we want to go from here to here, help us because you have skills, but first you need to want it, and you need to understand what exactly you want. And not agile, not safe, not framework, but real stuff. For example, we would like to be more adaptive, or we like to be more customer-centric, or we like to be more innovative, or we like to be faster on team level. All of these are valid things to want. But I think it's important to say them first, want them first, articulate them first, and then find options to get there. And then a framework becomes a vehicle to go from one place to the other. We see these days how frameworks actually, like implementing a framework becomes a goal on its own, which is another weird thing happening currently in the industry. But if you know where you are and where you want to go, and if you can make those snapshots every once in a while, then you can also change your frameworks if they're not helping you to go from one place to the other. Yes, so we believe there are a lot of different benefits you can get from using that, so to say, simple visual language we've come to develop. And we're not trying to be naive. You know, just having a map is not going to turn your work change magically from a disaster to success. No, but I think having ownership, having clarity, having joint discussion across organization board members and developers, scrum masters, having clear understanding where you want to go, having some kind of midterm states, being able to try different things in different parts of organizations, all these things, I think, are increasing the chances of a successful real work change, which will not be then a project, but an ongoing continuous improvement towards perfection kind of a thing. - Now, I can't imagine to put another layer on top of these maps and call it power structure, because for me, org structures are actually ingrained power structures. I rarely think about it like, hey, this is the logical reasoning of an organization. We designed it because we want it to, you know, become more of this and that. But it's, you know, for most grown organizations, like, oh, these are little kingdoms and queendoms and everything. And I think it's always this challenge. Are we ready to face the mirror and just look at what it is? And then, you know, what Roland said before about the gaps in between, which are probably fillable with power elements. Are we ready to talk about it and then talk about what else could be useful for what we said? You know, sometimes organizations say, we wanna be innovative, but they do everything that's not getting them there. That's what Stephen Perry once called authenticity gap in organizations. We talk about A, but we do always B, and we never become clear about that, right? That's very interesting. - I think it's not, you talk about power structures. I agree, it exists, of course, it's everywhere, but it's not always intentionally, as in I need power or I am, you know, in search of more power. I think in many, many cases, it looked like that from the outside, but as I was going in with people and really reason with them and talk about what they were doing and what they were trying to achieve, most of the time, I discovered people that simply from their point in the organization where they were looking at their reality, they were doing the best thing they thought they could do to contribute to the whole organization. But looking at it from the whole organization point of view, they were not, you know? And that's what this discussion now can be about. Like, are you systemically contributing or not? Or is this really just a power play? I mean, I won't say it's gonna change, you know, but if it's the case where people are unaware of what they're doing because of their bounded rationality or their bounded view of the whole system, they just do whatever it is good for optimizing locally for their department, not seeing how poorly they are performing from a whole company perspective. - Yeah, and that's why the working subtitle for the book that we're currently writing is "Focus on the Big Picture." You know, we, and it's, I think it plays nicely with the name of this podcast, Agile Focal Point. It's about being focused, but not on a small piece, but on the whole picture. You can be focused on the whole picture, right? And it's important, and we, it's very easy to lose this whole picture, a big picture view, and start optimizing local things like decks on a Titanic. And in our today class that we would like to invite everybody, of course, to join when they are ready for it, we take people through this immersive series of workshops where we help them discover. So from knowing what the company strategy is to the capabilities they want to develop to the org design, we're helping them realize what organization really needs to change in order to become successful. Like Mike, you just said, you know, like, they would like to be innovative, but they optimize, you know, business of, you know, functional groups. So this clash between what they are saying they want to be and what they're doing, hopefully will become more obvious in these workshops. And then people, after doing this for themselves in a today class, in a kind of a super safe and fun environment, they can take these workshops to the companies and do them again with, you know, the real leadership teams or, you know, change agents, and then have a shared discussion. Okay, we're saying that, but we're doing this. What the hell? What's actually true? And hopefully it will be a little bit painful, but not too painful to, you know, close that mirror, but painful enough to start saying, okay, probably there is some truth here. Let's discover options or why we're not doing that, you know? - So I wanna add one more last thing to this, which is, yes, people can do things differently from what they say. You know, they do things differently than what we agreed. There's this gap, authenticity gap, you said, but why is it? Maybe, yes, because they cannot really understand what the whole system looks like, but also because of structural elements that are in place that force them to do whatever they do. You know what I mean? Culture follows structure. So what we try to do with this map, with this structure element, right? The structural tool is to try to get that dialogue in the direction of understanding why we do the things we do. There's a certain KPI I need to comply to and have to run, run, run, run, run. Wait a minute. Okay, well, let's change that. So then you can change your behavior. We really believe in larger organizations, culture follows structure. So working on a structure and making that structure a better fit for delivering value is what it's all about. - Wonderful. I mean, there is tons of things probably interesting to continue discussing about the future because, I mean, a lot of organizations will have a hard time even to embark on this conversation we just had. And we know AI, we don't know exactly is changing everything in the near future or maybe far future, I believe more in the closer future. And I think you're pointing with your work to companies like hair and everything who are a lot ahead of what many others could think about. But I would suggest to let people meet you, the both of you, and have the personal discussions in your academy events. I think you have a couple of public events. You're also going in-house, I imagine, for making people aware of basically touching, getting their hands dirty with what you just, we talked in theory, right? So a couple of things coming, right? This year, next year, a couple of events, conferences. I think you're permanently somewhere talking with groups, people. - Yeah, we're still young and energized and happy to travel. And that's why we are doing this tour in Istanbul, Ghent, Prague, Munich, Vienna, you name a city. And we're gonna be there with the class eventually. And we really would like to see people in our class who are experienced, you know, change agents who've done some, you know, basic stuff and now they are ready for something real and serious. We would like to see, you know, seasoned change agents, either, you know, consultants/agile coaches who have these interesting missions in the clients to really do real work change, or people within companies with a mandate to actually be able to change work design. So this class will be painful if you cannot actually implement things after it, because you will have very clear understanding what needs to be changed. And if you cannot, it'll be just a very big loss of opportunity. These days, we see these people, you know, experienced coaches, consultants, and C level and C minus one level execs who would like to change and they're discovering options how to do it. And for them, this tool becomes something to keep on the table, not in the pocket, but, you know, on the table to work with. - There is one final thing I wanted to mention. I didn't dare to ask during our conversation because I was, I fear that we would, you would immediately drop out, but I would love to have you together with the team topologies and the unfixed guys in one episode talking about similarities, differences, views. - Yeah, we'll use them. Now we are ready to quit the episode. - No, this would be a great opportunity. And we've been thinking about this before as well. We have clear ideas on how well team topologies and unfixed, for instance, how well they can perform and what the caveats are, what the problems are. And we think, you know, using frameworks, you know, the DIY frameworks like team topologies and unfixed, do it yourself, need a vector. They need some guidance on what the result will be of a configuration that you are creating. And we think our topologies there will help those people who chose these frameworks. So yes, we'll be more than happy to have a podcast with those people on that. - And maybe it should be even more alive so that people could also tune in. Again, this is, I believe you all doing something very valuable for thinking you referenced yourself as a, you know, the work as a thinking model and there might be different paths and ideas and thinking can never be wrong as long as, you know, you respectfully meant and then just as Alex just said, finally doing something because only thinking will, you know, not make anybody happy. - Yeah, so to finalize that thought that you've just started, right? We are not trying to oppose any of those framework or non-frameworks that you've mentioned. We are actually trying to clarify the playing field. We like to provide a map of a terrain where different companies will find something that they're looking for. And if you are, we'd like to create a fast flow teams with narrow ownership to reduce cognitive load this way. Team topologies is a great place to be team topologies, right? Is a great place to be. Whereas if you like to create a highly adaptive business at the business level organization, probably you will need to look into some other ways or you'll have to expand beyond the ideas of team topologies and create a stream aligned teams on some broader concepts, not just a narrow value stream but a broader understanding of value. So we are not trying to be against or beating any of these ideas. We are just trying to provide more clarity for the users of these ideas. Because if you have created a method like unfix or team topologies or safe, you typically are not saying about the loss of opportunities when applying your idea. You're saying to everybody how good your ideas are, buy me, buy me, buy me. But you have this blind spot of seeing where it's not helping. And we are trying to cover those blind spots and saying, hey, well, the world is not black and white, the world is multicolored. You might wanna do this, this or this or combine things but in a thoughtful way. So we are always happy to have thoughtful discussions from everybody with anybody. So far, we haven't been on good terms with people from team topologies. They are not really engaging in a meaningful discussion with us. Maybe you guys will be able to facilitate that on a better term that currently LinkedIn posts and comments are allowing. But some communities are willing to learn and open up to others more than some others. And mutual interest and mutual openness to learn from each other. We are ready to learn and we are learning from everybody. - Yeah. Alone, this would be a topic on its own, right? Communities and how to be a community which is useful for people and not locking up somewhere. But anyway, we're very happy. We were happy that we had both of you as guests today. Thanks so much for all the insights. And again, people might want to dive and dig deeper. We'll put out all the information with the show notes. There is a book, what we heard coming, probably not next week, but we're working on it. - So people who are listening to this podcast, please go to our website and download a free primer. Or topologies.com. You can download what a 30 page PDF with different maps. And then maybe if you do it in the beginning of the podcast, maybe it's too late, all I didn't know. But if you're able to do it in the beginning. - Will be easier to know what we're talking about. - If you can listen to the podcast, looking at those maps, I think you'll have a better understanding what we're talking about. - I can recommend it. I downloaded it because I wanted to be a little bit more prepared for the conversation. Again, there is useful material already in there. And people again, can meet you in deeper dive courses and whatever else format they want to go into with you. Thanks again for having been here and talk soon. - Thank you so much. - Thanks for having us, Harold, Mike. (upbeat music) you (silence)