Developing an agile leadership mindset - with Andrea Tomasini, CSO @agile42

Welcome everyone to another episode of the Product Bakery Podcast. My name is Alex and I'm here today with my co-host Christian and we have a lovely guest, Andrea Tomasini. Hi, Andrea. Hi, guys. Nice to be here. Cool. So before we jump into the conversation, as usual, I quickly wanted to share that if you have any questions or if you have feedback to one of our episodes, you can always go to our website. It's product-bakery.com where we first of all list all of our episodes and you also have the possibility to leave comments directly there. With the benefit that comments are read by myself and Christian as well as also our guests, so we can take all the conversations there. For everything else, you can also find us on our social media channels and get all the latest updates and news there. And with this, Christian handing it over to you. Amazing. As you said, Andrea is our guest today and I know Andrea since more than five years now. I remember when I was very young and very junior, he was coaching and consulting me as well as your team. And I have to say, I was really happy that I had coaches on site when I was working as a product manager with my teams because it helped me to first of all become better as a product manager. And at the same time, it definitely had a big impact on my career. Before we jump into the topics around Agile, I would like to share a little bit background, Andrea, because originally you started your career as an engineer in the 90s and moved your way up to VP engineering, VP product, CTO. And at some point you decided to work and start founding the company Agile 42. So I would love to know how did you gather the Agile knowledge and what motivated you to start an Agile consultancy? Oh, that's an interesting question. It's a bit of history, but I try to keep it short. As you said, my background is software engineering and I love software because it was for me a way to be creative and help people at the same time. So I always consider it an art. And I had my own startup already out of the university where I had a few people and we were so crazy that in 1994, we decided to do internet application and nobody was even knowing what the internet was, but we were so much ahead and people were still connecting with the U.S. robotics 9600 board to the internet. There were different times, but then I grew up, as you said, and I pretty much had the old middle management until CTO career in technology. And I was always intrigued by complexity. In fact, I'm being passionate about complex adaptive system. And also part of my study was dedicated to that. And what I learned is actually in the human system, there's a lot more of complexity than in software system. And that is the moment where as a CTO, I started focusing on understanding how can I help people working better together? How can I help them integrate, even if they are from different background, different function, and even different companies sometimes. And then I started looking at approaches to integrate and increase collaboration. And I stumbled upon agility, thanks to some of my friends, still today are friends and colleagues who were passionate about engineering technique. And they started looking at Agile and I looked at extreme programming already in 98, 99. And we started adopting some of those practices. And then in 2001, I came across Scrum, which gave me a little bit more of an organizational perspective, at least from a team level to what agility can bring. And then primarily, I focus myself on understanding at which level can we combine all of the output that these people generate because forcing processes on people. And you know, when you do merge to organization, or you try to create a cross functional team is always a problem. You always get the compromises and you always get mediocre result at the end. And so I said, well, there must be a better way than that. And then I decided to explore more with some friends and research into the whole idea of empirical process control and understanding it doesn't matter how you do it. As long as we agree how often we want to review and integrate our output so that we can create outcome which is value, then it's fine. You can work the way you want, we can work the way we want. As long as you can commit and deliver to a certain amount of value within a certain amount of time, do it your way. So I don't want to get into that way. So we started looking at systems in a more from a complex perspective, and we started looking at how can we combine the output of all the system, even if the system are not coordinated and not synchronized, which is what instead we try to do with the project. And I got very passionate about it, so much that at a certain point in my career, I realized that 50% of my time was politics and 50% was fun. And so I said, well, I might decide to have a little bit more of fun than politics. And so I decided to actually step down as a CTO and have one year of sabbatical to think about what to do and because I actually had to take a garden leave. So I was paid salary, but I couldn't do any work in software for one year. And then in this year, I had the chance to find new partners and new collaborators, and we experimented a few different business models. And at the end of 2007, together with Marion and at the time, old friend Alexander Aptus, which used to be the VP engineering of Togethersoft, bought by Borland then, and together with him, we founded Agile 42 in Berlin. And the main driver for that was that we experienced on ourself that working in a traditional work environment, very strict with rule processes and hierarchy, and this feeling of top down wasn't honoring the potential and the power that may be the potential of people in the workplace and forcing everybody to follow process was also not a good thing. So we started with the idea of creating a company which would work different, which would be more agile per se. And so we came to the decision of creating our own company. And we always been against implementing the traditional structure with management lines and HR and finance and all these things. So even today at Agile 42, we don't have HR, we don't have finance, we don't need those function because we do have some people who know something about those stuff. We agree on how we want to make contracts. We agree on how we want to pay salaries. We agree on how we want to pay bonus. We agree how to split things. We agreed which metrics are relevant for us to track in order to be effective at our business. So we do all these things ourself and continuously we challenge ourself to improve, to get better. And we aspire to become a company which is a good example for others to follow. Because at the end of the day, we have an international business in 13 different countries with employees and partners. We have a running business with software, education and transformation projects. We do have a lot of what large companies already have in place. And when people ask us, how many are you guys? And I say in the north of 50, probably 60, we have been 70 also at some point. So we had ups and downs. But overall, it's 50 people. We can run basically three very large revenue streams in 13 countries. So that's already agile in itself, I think. That sounds crazy for me when I hear these numbers. Usually I would think of, okay, already with the 13 countries, that's like at least 10 people per country or something to run these revenue streams. So if you manage to do all this with 50, 60 people, that's impressive. But do you know what's coming to my mind here? There is a great book I've read two years ago. It's called Exponential Organizations. By the way, startups are always 10 times faster and better than your company. And many things you mentioned right now are directly or exactly tying into what it is about. Instead of focusing on processes or also on hyper growth, which is, in my opinion, the next big thing people believe in somehow, rather focusing on quality and making sure that you get your stuff straight and make the best out of it. Since we're talking about people and also processes and structures, I know that Scrum requires following some rules, for example, or generally certain leadership practices and styles. But on the other hand, it also doesn't make sense to force it on people. So where do you draw the line here? First of all, let me introduce one concept or if you want a statement, might be bold, but the biggest mistake people do when it comes to organization and change is they think at the organization and at the change as a single entity. It isn't right. When we're talking about change and organization, we are talking about people, every one of them as a name, every one of them as an history, every one of them. as a character, as values. And whenever we impact them, we are not impacting them as a single entity. We are impacting them as many individuals. And this is the first problem. So Scrum, like many agile approaches, provide a set of constraints of rules, as you said, which are called in complexity term are called enabling constraint. Some of those are enabling because it allows you to collaborate better. Some of those is what we call governing constraint, because for example, you can't release if you don't fulfill the definition of done. You can't pull something in your sprint if you don't fulfill the definition of ready. So those are governing constraint, a rule you shouldn't violate. If you violate them is your own problem, because we told you we agreed and you disagree. But then there are things like working agreements, which are behavioral rules that the team can agree and between themselves. And those are more like enabling constraint is how the team thinks is better to do things. And this is what enable them to do. So the question is, what is the precondition? When we consider a group of people, a complex system, we need to think that it's more important to learn what are the natural disposition of this group of people in the present than trying to think about what is the best model in the future and trying to implement that model by making a gap analysis and changing things because people might not be ready for the change. Some people might not have the right culture and mindset to adopt the change. So the famous say that a fool with a tool is still a fool is true. And this is one of the major reasons why also Scrum and Agile implementation fail, because we're trying to impose constraint on people without first understanding where they are at, which level of culture do they have, which level of expectation do they have? Yeah. And I spend a lot of time in the past five years also with the help of Dave Snowden and Cognitive Edge to work out a framework, which is called Organic Agility, in which we really deeply try to understand what is the relationship between people? How do you expect the leader to act? How do they expect the work to be shared and distributed? So if there are people who are already, we call them archetype. At an archetype level, which is peer, means they are used to work peer to peer with one another. So they are used that when there is work to do, they put it on the table and they start discussing about it and they start sharing it equally probably. And everybody pulls their own part because they know they are a peer group and they need to create value together. But if you and in this type of peer group, which is an archetype, which has a certain collaborative underlying culture, there is a certain level of autonomy. People have expectation on how to do work, how to make decision. Then if you put Scrum in that type of culture, it's going to work in a good way because it's based on collaboration. But what if instead you have a group of people which is used to work in what we call an expert archetype, where there is one person who is the expert, who is telling the other what to do and is regulating the workflow, regulating the communication, becoming the central point for aggregating work result into value. How can you implement Scrum there? You can't. And that's the problem. First, you need to let these people grow their level of autonomy. You need to let them understand how the Scrum mindset or the Agile mindset adapts to the current existing situation. But you also have to help them grow beyond, A, I'm sitting here, just tell me what to do. And I make my estimates in our, that's all the responsibility I have, to A, I need to grow to a point where I need to actually become responsible for the outcome, for the value I generate. And because I can't create the value myself, I need to start trusting someone else. And so it means we need to start to build a trust relationship and create that concept of synergy, which is we can deliver more value than the sum of the individuals within a team, which requires us to establish those relationship of trust. And without a team, we have a working group and a working group is not the same thing. And without a team, we can't work in an Agile way. And I think this is one of the biggest barrier for Agile transformation or moving to Agile. I think for organization, the other piece to understand is not that the methods and the tools and the mindset is different, but that they have to change their equation from considering individual to considering team as the smallest organizational unit inside their, you know, company. And that's a big, big hurdle for many people to understand. And if we speak about organic agility, how do you usually approach this when you get to a company to, to like really assess the different teams and the different team members to understand how the team works? Well, if we think about companies more as organism, right, a network of individuals, everybody has their own interest, everybody has their own value system somehow, and they are all trying to do good because we have to believe that people in general wants to create value. They want to do good. So what is happening is you are not going to company and telling them this is the model you should implement. That is appealing to CEO and manager because it's a project, we have a target, we have a budget, off you go, let's do it, right? But it doesn't work on people, not really. So we always say you forget the human factor. And when you forget the human factor, you have that culture, it's strategy for breakfast. So you can have the best plan ever, but your people will just withdraw it, ignore it, do whatever or pretend they're following your idea, but they don't. So the best way to actually approach change in general, and this is not just for Agile purposes, but in general, is always to look at the culture of an organization. So the culture exists, whether we want it or not. We can ignore it, but it will become the biggest impediments in our whole organization. Or we can try to make it explicit and try to visualize, become more aware of what this culture looks like, and then work in trying to create more cultural coherence. What does it mean? Let's say you have a large organization or not even large, let's say a smaller one, 150 people, 200 people. And how likely is that all these people share a common value system? It's very limited. Yeah, very limited because they didn't work together long enough to understand what is it that you value? What is it that you consider? What is it that the customer wants and how we deliver it? So they didn't have enough time probably because they work in silos, they work in containers, which separate the possibility for them to create what we call informal networks. So people who trust other people who have the chance to communicate with one another and establish those relationships beyond the structure of an organization. So there's a lot of potential in every organization. The problem is we can, if we want to change that potential or implement something better, we need to leverage what the organization can already do, what people can already do. So what their natural disposition. So because the culture and the organization then is a complex system, so there's a lot of multiple small interaction happening every minute of every day, which we can't really control. So the best way is to assess, start by assessing what is the dynamic of the organization. And because it's a complex system, we need multiple feedback loops. So we can't do one thing and say, this is the picture of your organization because we'll probably create a false image. So what we need to do, we need to do multiple parallel thing to have an overview on how the organization might recognize the repeating patterns that we see. So the way we do it, we do a scan initially, which is a sort of, I'm saying survey so people understand, but it's actually not a survey, it's more of a journaling system where individuals are prompted to capture in the journaling system every time a decision that is made in the organization is affecting their work, whether positively or negatively, or maybe is a neutral, but still, hey, what happened here? Why someone decided this and I don't know about it. And we ask them to signify, which means to interpret their own decision against the framework that we have been developing since 2015 with the help of psychologists and sociologists to understand human dynamics very well. And by doing this, by capturing all of the decision, we are starting identifying what patterns emerge out of the normal organization interaction. And we can see how fast our decision made, who's making most of the decision, the level of delegation, the level of diversity, the level of resilience, the predominant leadership structure in the organization, which leadership styles is more in vogue or which one is accepted and which is not, what creates most engagement, what creates disengagement in terms of behavior and story of success and failure. So we have all of this information which help us engaging with the client even before we actually go on premises when we could or we connect to them now virtually. But basically, we have a load of information on what is the potential underlying culture of that organization. Then to validate that, of course, we are creating hypotheses ourselves. And we interview people and we confront them with the pattern we identify. And we ask them to tell us, hey, what do you read in it? Why do you think this is happening? Why you think 20 people out of 50 are reacting negatively to this type of decisions? And we are their story. Because at the end of the day, if you want to know how an organization ticks, you need to listen to their story. And with the help of their story, we can validate some of those hypotheses and also formulate idea on how could we improve this behavior and how can. we bring people more closer together. So we are starting creating experiments that we then share with the rest of the organization and we ask volunteer to join those experiment with the aim at trying to influence some of those behavior in a positive direction so that we are creating a more coherent culture, which is the underlying cradle, if you want, in which all of the rest of the things happen inside an organization. And we strongly believe in that because at the end of the day, in the times we are living with very high variability, very high complexity, very high volatility, directions help, but oftentimes direction change very quickly, like every three months, every six months, because the market change and shift. So there is no way we can define a structure for an organization which outlast market changes because if the way people work is only driven by structure, then we will probably encounter situation in the market very quickly in three, four months time for which our structure is not supportive. And then either we worked in creating a coherent culture and we hope that the right level of autonomy of people will allow them to make decision independent of the structure because the structure doesn't help them or what is gonna happen and many company are suffering for this is that people rise up their end, escalate to their direct report or manager and they wait for them to make a decision. So if this happen all the time and the market shifts or the environment is a stable and every three to four months, the organization again start accumulating a lot of this unmade decision, what happens is the organization is going to be slower than the competition, is going to stop the delivery, is going to accumulating waste, is going to disengage people also because everybody's waiting for someone else to make a decision. So there's a lot of implication in not understanding how your culture is and how it behaves. On the other hand though, there are many people who tries understand emotionally the importance of culture, but they try to design it like if it was a product, you can't design culture because culture is how we are, how we behave. So, and creating a list of values and principle and hanging it on the floor and say, this is our culture, it's just, yeah, it's creating new type of behavior. Number one, people will go, yes, boss, I'm going to comply to your expectation, but I will never internalize those value, I just pretend to do it. And other people will go, who the hell are you to tell me what should I believe in and how should I behave? And naturally, if you think about it, when you have a child and he enters your family, you're not confronting him with the list of value of the family and telling him either you comply or you will become an orphan. So, what we try to do instead. That would be an interesting way. Exactly, I mean, what we try to do instead, we mentor them basically. When we have a child, we mentor, we follow them, we try to give them feedback, but hey, how many times you tell the kids, don't put your hand on the fire, it burns, but until they put their hand on the fire and they emotionally connect to what it means it burns, they will do it. But then after they did it, they go, oh, this behavior is not good, so I'm not doing it again. And this is where organization are not understanding there is no shortcut. You need to spend time to align your leadership team toward the culture you want more, understand which behavior you want to foster, which behavior you want to dampen, and then every leader should spend more time mentoring people, supporting them to understand what is the common strategic direction and trying to nudge the culture. I'm saying nudge rather than design or implement in the direction that you want more. So whenever some behavior emerge that you don't like, you try to dampen them. When some behavior emerge that you like, you try to emphasize and amplify them so that overall, if the leadership team is coherent in doing this type of behavior, there will be a culture emerging which converge toward something which is overall more coherent, which allow us to steer the organization a bit better because we know whatever we throw in the middle, there will be somehow a coherent response instead of having people pulling in all possible direction and not bringing any result at the end. One question that I have here is that, obviously, you have so much knowledge and background also that goes into these kind of assessments and into the journaling that you use and so on. So do you think a company on their own, could they do something similar? Do you think it's possible for an organization to approach this, let's say, because you're obviously coming from outside and you're having this outsider perspective, you can obviously also go in very neutral when analyzing culture and we're looking at how decisions are made, but how can a leader on its own approach such a topic? And actually, you will be surprised and people coming from outside your company are not able to evaluate your culture because I would read your culture with my glasses and my glasses are biased by my own culture or my expectation of the culture because I'm not living in that culture. This is why I emphasized before that we capture data and those data are first-hand, self-interpreted by the people who capture them, so not by us or by any external. And when we identify a hypothesis that might be valid, we ask the people to tell us what they think. We are not telling them, do you agree or not? But we tell them, look, these are the pattern that emerge. Why do you think they are like that? And their answer help us understand if our hypothesis is valid. So going back to your question, of course, actually it's better if an organization tries to assess themselves. There are some simple tools that also leader can learn using a model reference and simply asking, for example, their team to capture stories of success and failure every, maybe every two months or something like that. And see, and then just sitting together regularly and asking them, okay, what made this story a success for you? And what can we do to make more story like this and less story like that? If we look at the one of failure. So the culture, it is not fluffy. It is not cloudy. It's a very clear thing. You can measure it. You can see it through the behavior, through the stories, through the habits, through the rituals, which emerge in every organization. The problem is we can't design it. We cannot say now to do this. Everybody does that because we will create an army of Borg. And if we define it beforehand, then it becomes a process. It's not anymore a ritual. Rituals are natively lived. Rituals are emerging, are developed, co-created by the people who actually do the work. And the risk if everybody is fully aligned and the culture is completely aligned, you lost all the diversity, then the likelihood that when something unexpected happen, you will fail is much higher because the reaction of the whole organization will be in a common direction. And what if that is wrong? What if it's not the right thing to do? Then the whole organization fails and you have no option left. So the trick is always keeping the right balance between how do I create enough diversity, but at the same time, not too much, otherwise we have anarchy, but also not too much alignment, otherwise we become too fragile because everybody thinks the same way. And in order to do that, internal leadership teams or leaders are much more suited because working on culture is an ongoing continuous job. It's not that you can call in consultant, they come in, they wave the magic wand and all of a sudden your culture is coherent. So what we do actually, we help leader understand what is it that they have in their hand that can influence the culture. And we mentor them on how to experience and use this tool so that they can do the job. Does that make sense? It almost sounds like therapy, right? Of helping people understand or bringing them to see their culture and so on. I think you're absolutely right. So the change must come within the company. It cannot happen from the outside apart from very big market changes, for example. But overall, the culture needs to be driven or as you said, like nudged or framed internally. But I also see a connection between the culture and the work that needs to be done. And I see a strong connection here. And what I would like to better understand is how to mentor people in the right way. Because you said, if things are getting done right, you can celebrate. If things are getting wrong, you need to emphasize. To me, and I'm explaining it a little bit worse than you said, it's also like training a dog, right? If a dog does something wrong, you give him a piece of a little snack or something. And if he does something wrong, you tell him. But with humans, it works a little bit different. So I try to understand what is the right way or the right balance to not only build up a culture that helps people to move into the direction that you just explained, but also to prevent mistakes that eventually would hurt the company. It's a bit of a complicated question because you can't actually prevent mistakes. But what you can do is to embed in your culture the understanding and the capability of people to become more resilient, which means to be able to recover faster from failure and to adapt faster to changes. And in order to do that, we always hear platitude, which is we should have an error culture, a mistake culture, which means we allow mistake to happen. But that's a little bit of a platitude. So how does it work? mean and why you need to do that? Well, the real rationale behind it is that if we want to become a more resilient organization, we need to train the brain of the people working with us to react faster to unexpected things. And the best way to do that, if you want to control the amount of damage that can eventually emerge, is to create the space or container to have what we call safe to fail experiments. So whenever you want to introduce a change, you said, hey, that's a good idea. How about we make an experiment before we throw everybody in our company at it without knowing what the outcome will be? And then you start thinking about what is the smallest amount of people that I could involve for the shortest possible amount of time to figure out if this idea you have is working. And how much time would you need to test that idea? So you're basically creating a time box with limited budget, limited space, limited capabilities, but real. So the damage can still happen, but is recoverable at a cost, which means you are not dooming your organization because a change failed. You are doing it iterative and incrementally. And the more changes succeed, the more you start gaining confidence of making more parallel experiment. The more experiment fail, the more you're getting concerned that something in the way you are experimenting is not right. And probably many time is that the expectation of what will come out of that experiment are so high that the experiment cannot fail. And then you are shooting on your own foot because the whole idea of having experiment is that they should fail because if they always succeed, it means you are not trying hard enough. And you don't get data. And you don't get enough data. So if you always make experiment and they always succeed, it means you are not probing your limit. You are not going at the edge. You are not really challenging things. So there are ways in which you can control that and reduce the fear that things happen, but you can't really eliminate. The advantage of doing this, especially if you ask a volunteer to join experiment all the time based on their interest, their passion, is that everybody will be implicitly trained in reacting quicker to changes and adapting quicker to things that are unexpected. So you are training the mind of everybody to react to this type of situation. So then when they really happen to the organization as a whole, and everybody has this mindset, instead of desperately dropping the ball and starting crying and running around like headless chicken, people will go, wait a minute, what can we do? What is the alternative? What can we react? So if we never allow people to experiment and fail, they will never ask that psychological reaction to the unexpected, to the unknown, when they really happen in real life. And what they will do will go, oh, this is not my thing. It's not my responsibility. It's not my problem. Does that make sense? Yeah, absolutely. And I love that you just reminded me about this safe to fail experiments that you should do, because as you said, if people intrinsically join such a group, you can definitely do much better damage control. And the whole point is not to avoid the failure to happen, is actually to enable failure to happen faster and more often. So the damage is limited, the impact is reduced, and you have the byproduct that people are trained to react quicker to changes. Beautiful. I do have another question because earlier you mentioned about CEOs or management sometimes wanting this to be thrown on a team. And I see it also comes sometimes with planning. I think probably in a lot of high positions, there is this idea of they love to plan in advance. They love to have things written down. They are probably less resilient as the smaller teams working on the projects. So how do you actually work with senior leadership to get them into the right mindset and into understanding this, let's say, fail fast or this agile way of working? I go with magic wand. So there's a lot of aspects. I want that magic wand. It's quite expensive anyway. There's a couple of things I talked about, a couple of things that I want to specify a little bit. First of all, the need for certainty is not only for CEOs, it's human, right? We are all wanting to plan. We all want to know what will happen next because it creates a sense of safety, creates a sense that we are in control. And this makes us feel better. The level of fear is reduced in this situation. This is a reason why Corona is driving many people crazy or is driving them to a level of stress that they never experienced because we can't plan anything. We can't plan ahead one week. We can't plan vacation anymore. We can't do anything. And this is what creates an immense amount of stress. That's the number one. So it's not just the CEO and the companies. It's just a normal human need to have a little bit of understanding of what will happen in the future. The second thing, planning and defining thing is not necessarily easy. Actually, it's a way of having a conversation to explain what is it that we are trying to achieve. The fact that the plan will be busted two minutes after you made it, it's a different story. And that's okay. But at least we agreed on something. We had a plan. We had an understanding of what we wanted to do to achieve a goal. And then what you do in another way, you just say, okay, I know it plans are wrong and I'm trying to inspect and adapt to do this iterative and incremental adaptation while you go. Because the most important thing that people underestimate or they assume to be true is that before you start everything that needs to be done and you know exactly how it will happen. Wrong. It has never been the case in history. What changed is that in former time, the amount of complexity and variability that we had when we wrote software was definitely much limited because everything was tendentially self-contained, was much lower complexity. We had to interface much less devices and we had control on the whole system. Now we are operating in an environment where everything is connected, is networked. 99% of what we do is probably outside of our control anyway. So all this feeling of planning and defining beforehand that we still have is much less effective than it used to be in the past, but it's still useful because it helps us share that intent in going in a common direction. So what I do with CEO is to make them understand that while it makes sense to provide a direction and to set a goal, I also tell them, guys, this is wishful thinking. This is your desired outcome. It is not a target because there is no way to predict if it will happen or not until we are very close to it. And I also demonstrate them that their level of accuracy in determining how far or how close they might come to that goal increases over time. So the closer they get to the goal, their level of error might remain the same in percentage-wise. Let's say you still make mistake around 20% in terms of predictability, but when you have 10,000 mandates of effort in front of you, 20% of that is 2,000 mandates. So if you tell me when it's going to be finished, well, I'm not very accurate in doing that. But when I consume the 700 or 800 of those days and only 2,000 are left, then my 20% error is about 400 mandates, plus or minus. So overall, I'm much more in control if I come to that point quicker than if I try to make the perfect plan before I push the button start. And this is what many people don't understand. There's another aspect that connects to what Christian asked before, which is about the behavior of the people on the market. So not all the market segments are responding to a product or a new thing in the same way. We know also from Geoffrey Moore with Crossing the Chasm that there are roughly five different categories, he calls them, in terms of market audience. There are the innovators, there are the visionaries, there are the pragmatists, there are the conservatives, and then there are the skeptics at the end of the laggards. And that's also the reflection that you have to do. If you are the CEO of a startup and your startup has an innovative product, you're talking to early adopters, which are visionaries and innovators, and probably some pragmatists are in percentage-wise in your target group. So when you talk to them, they do have a culture, which is not about quality. They care a lot about speed. They care a lot about possibility to provide you with feedback. So you as an organization need to adapt to the culture of the target group you are addressing if you want to talk at the same eye-height with them, if you want to understand what they really need and how to implement it. And so our culture in the organization tends to adapt to the culture of the clients we are dealing with. And then eventually this group grows and becomes a larger group of pragmatists because they are happy with the solution you have. And when we cross that chasm, when we pass over the people who are just interested in the potential of our idea, we start meeting people who don't care about the potential. They want the solution now. And so either you have it or you're out of the window. And so in that situation, your level of expectation, the way you talk, the level of precision that you have to put in your plans, in your announcement, in your... expectation is extremely different from the one you might have when you are playing still with people who are looking at the potential for the future rather than what you have now. And that's another thing that leaders from a product perspective need to understand. The third and last one is the culture, as we already discussed before. If I'm not aware what is the culture in my organization, or even worse, it's completely fragmented. So in every corner of my organization, there are people who have different ideas about what is right and what is wrong, what we are aiming for, who is our target group, and how we need to serve them, then good luck with that. You can have the best strategy in the world, but when you throw it to this group of people, what will happen as humans do? I will listen to you, I will read the strategy, but I will filter it through my value system. So I will decide what is important or not to me, and I will focus primarily on those stuff. So if all of us in a company have a different value system, how is it that we are going to move the company in a common direction? It's impossible. Even if we go to the obsession of, instead of sharing a strategy, making a master plan, where it's exactly written what needs to happen every month of every year on our master plan for the next five years, we will still have the problem. It's not going away. So it's a good exercise because it helps us decompose the complexity of a problem into smaller chunks. But we are not getting away with complexity because we are making a plan. Complexity is still there. And even if we made the plans, things will go wrong. But the good thing is, at least we have created a certain amount of coherence and people, if they have the right culture, will have also the capability to inspect and adapt and move forward. And as leader, we need to encourage them to move forward, because without moving forward, we stop learning. And we only learn to validate our assumption by testing them in the field. So doing all the upfront planning and upfront loading of design and product, which is traditional in system engineering company, doesn't work anymore, because we don't know everything at the beginning. And the only way to learn more is to try to do something, right? And there is no going around. If I'm a company, whether I'm working with a consultant or without, where do I start initiating the agile transformation? Do I first go with implementing Scrum? Or do I start on leadership level? Or do I both in parallel? Good question. Our experience shows that you have to start in many places. I'm not sure parallel is the right thing. But we are working on three different planes. So one is the operational level, one is the cultural level, and one is the strategic level. Right? So culture is like the context in which everything happens. Operation is more detailed, or now we do things every day, the tools we use, the processes. And strategic is about which type of organization we want to become. What are we aiming for? What is our business goal? What is our vision, our purpose? And how can we design a strategy to help us move toward becoming that organization and fulfilling our purpose? So we are working basically on three different levels. Then depending on the organization, as if you have a pain point now in a certain area, in your production environment, in your creative environment, in marketing or in sales, then you're not going to tell that company, okay, forget about it. First, we need to sit down and make a strategy because they're going to go, no, we have the problem there. So you need to be very flexible. Transformation is also not the right word, because transformation assumes you would know what is your end state. And most of the time you don't. So what you're doing, you are continuously transitioning to a new stable state, which is better than the one you're coming from, hopefully. And the way to increase the rate of success that the new transitional state in which you come is better than the one before is to experiment before you actually move the organization, make as many experiments as you can. So you increase your level of confidence that moving in that place is a better choice. And as I said at the beginning, it's all about understanding how complexity works, because in a complex domain, it's more important to understand the natural disposition. So what you can already do and try to aim to leverage what you can already do to create a better future, near future, rather than idealistically design the ideal future and then being frustrated because you don't have the capability to get there. So we work on operational level, solve the problem you are having right now. Also important to get quick wins, because they create momentum, they create motivation. People see, hey, something is happening. Great. Changes going on. Yeah. Yeah. And then you go on strategic level, how does this little change connect to everything we did? And then in parallel, you work on creating more culture coherence in the organization. So you need to work on all three levels. Great. Andrea, so I think we got a very good picture, especially around how to approach things and the different important topics to keep an eye on. But I think to wrap this conversation up, my final question would be, what are the three biggest mistakes that one should avoid when trying to transition in such a better state? That's a million dollar question. So let's say I can give you three examples of three mistakes. I'm not sure they are the biggest one, because depending on organizational culture, they might differ. But definitely one thing, number one, that comes to my mind, underestimating culture. So people focus on operation, focus on structure, but they forget the human factor. And that's one of the biggest drag in all transformation. Then the usual thing that you hear about the lack of sponsorship, the lack of supporting people and caring and taking them from where they are. All of this means that you are not attempting to actually transition or transform your whole organization, but you are interpreting the transformation as a change project. So it's not your thing, someone will be responsible, there is a budget, there is a time, end of the story. So every time we think that change is a project, and is contained, and there's a beginning and an end, this is the biggest mistake, or one of the biggest mistake company do. Last but not least, is understanding that the effectiveness of change is strongly connected to the level of engagement of the people within the organization. So it's leadership responsibility to engage them very early from the beginning, if possible, create together a story, co-create a story about why you want to change and what is important about the change, because you will have a lot less of resistance, if you approach change in that way, rather than having someone defining how you should change, and then telling everybody starting Monday, read this 1365 slides, this is how we're going to be as an organization on Monday, right. So those are the three things which I would like everybody to remember. And probably as an umbrella, make everybody clear, don't be too much worried about what you want to become, be more worried about what you are, and try to learn what is good about what you are and try to leverage that to become better. Amazing. Great. I think that totally answered the question. And I think probably it are the three biggest mistakes. Thank you very much for joining our show and sharing all your knowledge and insights. You're welcome, guys. We wish you a very great evening, and hoping to talking to you soon again. Same to you. And let me know if there is any question coming up so I can join the conversation. Absolutely. Thanks a lot. Feel free to reach out to our website and drop a comment. Bye bye. Christian, looking back, we've been there, we went through an age of transformation, or we started the age of transformation trying to transition in a better state. I think that's important. I remember back in the days, also our CEO thought it's something that we can do in a couple of days. I remember Andrea saying, it will take a couple of years to get to the point where we can actually do it. And I think that's a really good point. It will take a couple of years. So looking back, would you say you would do things differently today? Did you manage to avoid all the mistakes back in the day? Or did you make some of them? There's so many information that I'm just trying to digest now. First of all, yeah, I would say I'm still doing those mistakes. Sometimes I think we all do in a safe to fail environment. It's okay to do those. But one thing that was really important was to me the whole cultural aspect and also realizing that you can have the best plan on earth written down with a timeframe. As long as you don't have the buy in from the people, it won't work. And building up this emphasis and training and mentoring people towards a better mindset or different mindset, first of all, and also appreciating what you have instead of focusing too much on what you have seen on the internet or in whatever kind of YouTube video or TED talk. This is an aspect that I may have thought of somehow subconsciously, but today it came really up and into my conscious mind. That was definitely a biggie for me. How about you? We just need to have a look at the agent manifesto, right? Individuals and interactions over processes and tools. This explains it already. I think far too often we look Or you read about certain processes that someone implemented or about certain structures. And I feel like by now the Spotify model is a little bit over, but still far too many companies talk about the Spotify model over and over again and to try to force it on all sorts of different organizations. And here it's important to look at the cultures. And I think I always love having or trying to interpret a little bit the things that I hear as well. And I think that one thing that I've seen also from Andrea's explanation, especially around the assessment, is around how much you can read out of decision making in a company. I think a lot of his examples started with looking at how decisions were made, who makes them, when they make them, and so on. So I think that's definitely something that I will keep in mind for my work, looking at, okay, how do I make decisions? How do people around me make decisions? And how does this reflect or affect culture? And whether you are starting a new job or you are already working in the company, just taking some dedicated and focused time to analyze decision making is definitely something big. And I remember also in one of our episodes regarding establishing a product and engineering mindset with Urbi, he said a very nice sentence, which was, Agile is easy to understand, but hard to implement. And I think Andrea clearly showed us today that this is the case. Absolutely. Christian, I think nothing more to add. Thanks to everyone for listening in, for joining us. We already mentioned it at the beginning, but feel free to click the follow button in your favorite podcast tool, follow us on social media. We are trying to be agile. We are constantly iterating a little bit like on the things that we do. But if you want to stay on top of all our updates, that's the right place to go. Don't be a fool, press the like button on your tool. All right. Okay. With that joke, there's nothing more to say. Bye everyone.