Why Agile Struggles at Scale and How Lean Helps Organizations Grow

I'm very happy to welcome Fabrice Bernard. Fabrice is the CEO and co-founder of Theodor, a technology company co-founder with Bono-CharlavaZel. Over the past decade, the scaled Theodor from 10 people on one million dollars in 2012 to more than 700 people and 100 million in 2022. They are the authors of the Lintech manifesto, a book that captures their experience of scaling an organization without sacrificing quality, engagement or responsibility. Fabrice, welcome to the podcast of Emerging Leadership. How do you usually introduce yourself to someone you just met? I would say that my name is Fabrice Bernhards and I'm the co-founder of Theodor. And if it's in a working environment, which I guess this is the case here, I would say that Theodor is an international tech consultancy based in London, Paris, because of Blankheim Cape Town. When I read the book, I was very surprised by one of the comments, just at the beginning of the book, that clearly encourages people to skip a chapter, not to read about that story. And I was very curious. Of course, I read the story. And I found that very interesting. So why that comment? Yeah, it's a very interesting question. I think we wanted to book to be about Lintech, about our learnings and experience around adapting Lint wisdom to the tech industry and the tech organization. We found that our story was a good introduction to that, to better understand the context and where we had arrived there. But we didn't think it was necessary part. So that's what I think we wanted to convey with this to really explain. You don't need to read our story to learn about Lintech. That being said, I completely understand your point that the story is a very good introduction and I think provides valuable context to the book. When you look back, you were already a small company and you scaled quite a lot. What are the main points of the story you want to tell? Yeah, I think in the scaling story, if you look at our bottlenecks to scaling, the first one was finding Prog Marketfit. And finding Prog Marketfit happened when we really deeply understood agility, agile methodologies, and we were able to bring them to larger cooperates, who were definitely struggling to adopt them on their own. So that's been the first step. And once we had Prog Marketfit, that's when the scaling really started. And then the key bottleneck was how can we scale our organization and maintain this agile culture that we love and that makes our difference to our clients while becoming much bigger and therefore facing all the challenges that typical large organizations face, which lead them to becoming big bureaucratic organizations. And that's when we met a lean coach who had been through a similar journey, who had loved agile, I tried to play it in a large organization and realized the limitations, the problems that agile doesn't address when you're in large organization, found lean afterwards, found answers to all his questions in lean thinking and told us, you know what, I can also bring them to you and you'll see it be amazing. And so that's why we've been on a lean journey ever since, so that was back in 2012. And we're now what, in 2026, so that's sorry, 14 years now. Yeah, it's very impressive because you mentioned something that a lot of people faced in the agile community, they were able to use the agile principles and the agile values as a team, as a small team. They were able to really improve the way they were working, but in the larger organization, it was not necessarily working. And you explained that very well, going back to the agile manifesto and looking at the pieces that are able to scale and the pieces that need a little bit of something else. Can you tell us a little bit the first part of it? What is very interesting is the first question is what is agility and what the pioneers who wrote the agile manifesto did very well is give an answer. They wrote the agile manifesto, which was their shared understanding of what made an agile software development team agile. So you can always go back to its manifesto to understand what the man was agility, which is very good. So when you look at the principle, I think they make a lot of sense in the capture very well the essence of what it means to be agile. And then the analysis for us was to think, okay, why can't these principles work in an agile organization? And when you take each of the four values of the agile manifesto and you try to imagine yourself as a leader of a large organization trying to lead with these principles, you realize all four of them have a scale issue. They all really capture what makes a small team very effective and the idea is good, but all these four values just don't scare. Two very simple examples. One is customer collaboration of a contract negotiation makes a lot of sense. But in large organization, you start having two issues. One is you can't have the customer in every team as extreme programming encourages to do. And which we did at Theodore and it was amazing. We just like extreme programming says you should. We had the customer in the team and that created magic, but you can't have the customer in every team when the project starts requiring 10, 20 teams. That's one side of the coin. And the other side of the coin is when you're working for large organizations, there's not one customer who knows really well what they need. In large organizations, you start having multiple stakeholders who have contradictory requirements, contradicting needs and building a great product is really taking all of these into account, understanding the trade-offs and then making hard decisions. And customer collaboration just doesn't tell you how to address both of these issues at scale. And what we thought is does lean thinking actually bring a principle that you conveys the same kind of intention, but actually works at scale. And we found it because the first principle of the book lean thinking is called value for the customer. And for us, it addresses exactly that thing. It addresses the fact that as a leader of a large organization, you need to work very hard on clarifying and communicating all the time what value for the customer means for the whole organization and for each individual team in the organization. And that is very helpful. That is very powerful. That is in line with the intention of the Agile manifesto. And it works at any scale because typically, to your time, it's very good at this and they have 300,000 employees. Other than it's very good at this and they've got a million employees. So being obsessed with the customer is a very good principle that you will find in most organizations that feel agi and are very large. So I was one example. And then depending on how long you want me to speak, good. Yeah, I could give you all four examples, but only just two. And the second one, and I'll be shorter, is the very core principle about the Agile manifesto, which is individuals and interactions over processes and tools. And again, this idea that as a team, you can rely on direct interactions to make things work is very important and very useful, but only possible at small scales. Because as soon as you grow the number of people that need to interact, the number of possible interactions grows to the square of the number of people. And you saw you start having like thousands or millions of possible interactions, which makes no sense. What we found in organizations that had managed to scale and keep some kind of agility is that they had been able to reorganize as a network of teams. So they had basically kept this team spirit by organizing themselves as autonomous teams. And then the question becomes how do you manage to create an organization that works as a network of teams in a seamless way where teams are able to have a strong form of autonomy despite being part of a very large organization. And we realized that all of the examples we looked at had technology as a key enabler of distributing the work and then reassembling it in a seamless way. So that's why we called the principle tech enabled network of teams. And as an example, as examples, we give Linux and we give Amazon, which could talk a lot more about if you want. Or you can read the book if you want to know more about it. We have value for the customers that's basically our guiding star. Tech enabled network of teams. That's the foundation to make all those things work. If we go back to value for the customers for a second, what does that mean for a leader in an organization? Whatever the size. Question they should ask themselves. Lean Tech is basically our own secret source. So what do we do internally? It means taking the time as a leadership team on a regular basis to actually think about that. What is value? At the whole level of the organization. So that's one thing. Another thing is to confront that idea of value that you have to the reality of it because as soon as the organization grows, when you start having a disconnect between what you think customers want and what customers actually want on the ground and what teams on the ground are faced with. And so there's a key practice in lean thinking called Go NC or going to the Gamba, Gamba being a Japanese world for where work really happens. And so that's a key practice of a leadership team in a lean tech organization is to often go and visit teams and be very curious, not judgmental, not reactive to issues, just really to observe how things work and confront your vision of what value is to the reality on the ground. That's a second very important thing. And then there's a lot about communicating and empowering teams on value. A great way to communicate value is to build a no-bayar. So a bayar is another Japanese word that means like a big room and the key idea with this word is to say, you display in your face, it's much better if it's physical and you display your understanding of the value, your understanding of the key changes to provide that value. The key learnings, the key recent learnings around that, the key next steps that need to be tackled. And that creates a lot of clarity and instant white spread sharing of what value means to the whole organization. So that's in terms of communication. And then there's a whole aspect and that's a very popular aspect in the tech world which is called team topology. So creating, redesigning the organizations so that teams are aligned on the value. So identifying the value streams and making sure that the organization is organized around these value streams so that the teams know to which customer they're contributing and what kind of value they're contributing to that customer. But everyone can be empowered on what is the value that they actually need to build and to deliver if they have the autonomy to do that then engineer themselves the solution to creating that value. Do you have an example when you felt you articulated properly the value for the customer at a very high level, but one team was maybe a little bit struggling with understanding the value and you've seen that moving from not understanding to already understanding. Ah, it's a very interesting one. The first example that comes to my mind is not us but like somebody else. Not good. A very interesting organization and asks us to come in and evaluate them using the lean tech framework. And one thing we realized is for leadership there was a very clear requirement, technical requirement around the latency of their product. The latency had to be below 50 milliseconds to be sellable as a home cinema product. Okay. I'm going to give more details but that's the context. And clearly all the studies are shown that if it was above 50 milliseconds the customers would notice it and not be happy with it. When we went on the ground and we asked the teams if they knew about it, they said not really were aiming for 80 milliseconds, not 50. 50 is impossible anyway. That's why we're aiming for 80. So we went back to the leadership team and we said by the way one thing we realized by going a bit around is that the teams were didn't know that it was a key part of the value for you to like deliver under 50 milliseconds. The leadership team got a bit frustrated because for them they had made it very clear and they had made it very clear and what we said is definitely not clear enough, not obvious enough, not unavoidable enough that the teams would have needed to like raise the issue and say guys were not achieving these 50 milliseconds. What can we do? No, instead the disconnect between the leadership and the teams on the ground made it possible for the teams who found achieving 50 milliseconds super hard to deprioritize that challenge. And that I think is a very interesting and example that we see in every large organizations. Some changes are very hard. If they're not made super clear and obvious, of course, quite naturally the organization will deprioritize them for easier things that they can do. And that's a I think a harsh example of value for the customer. It's not just communicating but it's also clarifying the priorities and making sure that when things get hard people know they need to raise their hands and say okay, we need help rather than just be prioritized and work on something else. Yeah, it's an excellent example of communication is not one way straight but you need still to enable the other way. People can raise their hands. Yeah, I've heard that a lot of times when they are actually doing it is very different and you can be frustrated on both sides. And I think it was a very good example of frustrations on both sides. Leadership is said we hadn't made it clear. People on the ground who said yes, we heard it once. We raised the issue that was hard and the body like came to us. And therefore this conversation that should have happened on a regular basis happened maybe once and then never happened again. Yeah, I'm curious of this of the succeeded in either changing the goal or succeeding in the goal. What happened? I don't have the exact answer. So I have some guesses but I prefer not to share them. Okay, that's good. We discussed a little bit. I leveled value for the customers. That's great. You mentioned the tech enabled network of teams. Can you unpack that for a second to define that? I know that you discussed the team topologies and the idea of stream aligned teams and aligning teams on the value. A lot of people are trying to do that. You can see how difficult it is when you are really trying. What is that tech enabled network of teams you mentioned? Yes. So it all started with trying to find how do you keep the magic of agile principle individuals and interactions at scale. And clearly when we look at Amazon, what they did back in about 2000 is they had the same issue that every organization has. They had one big monolithic code base. Everyone that was contributing to it was like treading on each on other teams' feet. And therefore there was a huge challenge on how do we synchronize when one teams need to change like something that impacts another team. How do we synchronize these changes? And so they had these big synchronization meetings every quarter and it was a big mess. And very good devs were starting to leave because they couldn't be bothered with so much bureaucracy. So we've seen that in large organizations. We've seen that everywhere. But they did Amazon at that moment is realize that there was this debate around maybe we need more communication or better communication. And Jeff Busos had a very good intuition with he had no we need less communication. The problem is that the teams are not autonomous enough. So we need to find a way for them to re to find that autonomy again. And so they started this very large program of creating APIs. So that each team would not need to meet with another team. They would be able to interact with them through self-explanatory APIs. So very intuitive APIs, very reliable APIs. So that's often called API mandates. And it required a half of investment for the first teams and then probably became faster and faster for all the teams afterwards. And the end result was that the Amazon code base was completely broken down into modules. And each team had their own module and every module that needed to interact with other modules did it through very well defined, very stable, reliable, intuitive APIs. And that completely transformed Amazon and it gave them this agility back. And definitely was a foundation to the super fast growth for the following years and the foundation also for the invention of the cloud. Because once they realized that every dependency could be transformed into an API, the obvious idea was to say, okay, can we transform our dependency to getting a new server into an API where you just need to line. So they please, I want a new server and get it. So this is basically the story behind the principle tech enable network of teams. And in this principle, we really mix two ideas. One, which is the team needs to be autonomous. And from a people perspective, this means having a competent team leader able to help them when they have problems. And a key way to help is not to solve the problem, but to actually teach problem solving skills. And so that's a key lean idea is that a great team leader is a team leader that is competent and great at coaching problem solving skills. So that was one aspect, the people aspect. And then there was a technical aspect because what we realized, and typically that's what also we see in traditional organizations, is it's not just a people problem or people challenge, let's say, it's also a technical challenge. You can try to reorganize as much as you want. If the underlying architecture is not modular enough, then you will still be stuck, whatever your organization. And that's why we added the tech enabled part because we think without a big re-architecturing of your underlying technology, you will never get the agility that your organization aiming for. Okay, this is the part I believe that a lot of people listening will be a little bit annoyed with because they will not know where to start. Let's say I have a big monolith, I need to grow the team. Now the team is too big, the monolith is too big. What can I do? I don't have the time to re-architecture everything. Where to start? I don't have a simple answer to that question, but we do have a lot of experience around that question. I think I'm simplifying slightly when I say making the monolithic modular because we have a few examples where one of the key transformations was actually the deployment pipeline. So moving to a deployment process that is much closer to trunk-based development, investing heavily in automated testing, investing in feature flanging, that is typically, I would say, the first thing I would start with, and I'm not the only one to think that continuous deployment is clearly one great way to get there. Then the re-architecting would happen, but you can't do it, I believe, and we've done it quite a few times re-architect, but in a progressive way. That's why it's hard because it requires very good architecting skills, tech design skills, and usually the leaders who are complaining about the lack of agility are often non-technical. So they don't understand they have to put energy on that. And yeah, I guess if there's one key message here is you cannot achieve agility just by addressing the people's challenge, you also need to address the technical challenge. That does require getting your hands dirty and trying to understand why the current tech landscape is not working. I like that because it gives a sense that it's possible. It will be step by step. There's a real investment and you need a real engineering skills. It's not, you cannot fake it on that part. Yeah, no, of course. And to be honest, the outcome, the possible outcome is much better than I think, but most people believe. We've just delivered the new professional bank of LCL, a very large French bank, and we did it in 10 months. And we had about 150 dependencies to the existing IT system. So it was a difficult project with 150 dependencies. Once you know how to design the thing once you have the delivery discipline, you can actually achieve the kind of speeds that you see in startups. And one good reason for that is that startups are not new anymore. And most of them also have legacy code they have to deal with. So they're not that much faster. Yeah, you can with the right, with the right technical expertise and the right delivery discipline, you can achieve, you can deliver a whole new digital experience for a bank in 10 months. You spoke a little bit about learning. That's one of the foundations that you're talking about in the book about building a learning organization. Can you tell us what you mean by that? Yes, the way I restructure the agile manifesto, and this is a quick introduction. There's a leadership aspect, and this is value for the customer, lead with value for the customer. Then there's a management and working condition aspect. How do you make teams able to contribute? That's take an able network of teams. And then there's like a whole body of knowledge around delivery and quality at scale. And this is what we call right first time and just in time and really leveraging the decades of experience of Toyota in producing much higher quality cars super fast. But once you've said all that, the key missing aspect is how did Toyota get there, for example? Yeah, but I don't know what I love. And it's probably a bit in imagined, but let's imagine the Americans arriving at in Japan in the 80s, and asking to Toyota, can we visit your factories because apparently you're so much more productive than us and we want to know why in the Japanese would be like, sure, whatever. And the guys would come and they would like try to understand everything and then they would come back to the US, copy paste it. And they would get some benefits, but they also like have issues and they would go back to Japan and say, it would try to do the same as you, we had issues here and here, can you show us how you do it? And then they would look and everything had changed. And that's the key aspect of Toyota is that it's not, they didn't invent a great way of doing things. They invented the culture of continuous improvements so that whenever you come, the better way of doing things is changing. And that's the building and learning organization aspect. And that's of course the most, I think the most exciting aspect of all, it's the one that has to do with innovation, how do you keep innovating? I want to dig a bit into what building and learning organization means. It means one key thing. I think we're going to remember it's creating a culture of problem solving. A culture where raising problems, identifying problems is welcome positively. And people are then supported and trained into problem solving them. And that's a very cultural aspect. And it starts at the top with leaders showing that they will not react negatively to being told about problems. They might react negatively about people hiding problems. You're turning around, let's say the usual reaction to a problem, showing a problem is positive, hiding a problem is negative. And not analyzing a problem is potentially discouraged. But his encourage is analyzing the problem. And if you don't have the skills, that's actually a skill. So you can learn it, you can teach it. And so that's really a key aspect. That's something we do at CO2 ever since I would say 2012. When this lean coach started coaching us, we started having dojos on problem solving. And we started really every week sharing a problem solving. And people to the whole organization would meet on Monday at 12. And one team would present a current recent problem solving and we would change and give them hints and advice on how to improve it. So the skill of problem solving became really at the heart of our culture. And I think that's part of that's probably the key foundation to your learning culture. Excellent. So I have really encouraged people to think about what happened when we ask that kind of questions. What is the problem you are working on? And my first reaction to that was, I don't have any problem. The first reaction we have is to try to put aside all those things and say we are very successful and everything is going well. Except that means we are not improving and we are not learning. Going to that culture is really something. It's very interesting because problem has two definitions. And one of them is a scientific definition. And clearly what to it has done is adopt this scientific definition of problem, which is completely neutral or rather positive. And that's important. There's also a very interesting reframe of what business means. It's as if you can look at business as trying to transform the world and bring a new solution to the world, etc. Or you can see it as things that were meant to happen but are not happening in the best way because there's still a lot of waste. And it's a very different way of looking at business. And I think booths are interesting and valid. And of course the other way makes you start thinking, okay, customers have needs. Whether I'm here or not, they would probably need that. And the question is how can I provide it? And how can I provide it in a better way? And it's probably in the way I provide a solution to their needs. There's probably a lot of waste along the way. How can I identify these ways? And how can I remove them? And of course, that's the most beautiful way of generating profit because if you respond to the need and seamlessly start reducing all the waste in responding to that need, you're generating profit while not changing anything for the customer. And what is even more interesting is if reducing those waste means you have done a lot of problem solving, which means you have actually found issues in the way to provide your work, then you probably improve the value for the customer at the same time. So you generate profit and improve value for the customer and all that in a seamless way for the customers. It's a division of business that is very beautiful. Yeah. And I believe that core idea of really changing the mindset we have about how we already do the work. You added it to that before. There's a two big pillars that you're looking at the right first time and just in time. Could you give us examples of what it means? There's a really good example at the moment in AI coding. I actually posted about it on LinkedIn this morning. Typically now, if you do a bit of AI coding, the the easy approach is to start chatting to code code. And say, can you do this? No, nothing like this. No, not exactly this. More like that. And there's another way, which is to actually work hard on the plan, on the specifications. And then give it all that well said to code and include then delivers the perfect result. - Mm-hmm. - And right first time will of course be the second option. And why is it so interesting? The second approach means you will have to learn a lot more. Because of course it will not be right the first times. You will start analyzing, okay, what did I miss in my instructions that made the AI not understand what I meant? - Mm-hmm. - Okay. And so you're building intuitions on what works, what doesn't work, what AI needs, what are maybe like, the assumptions that you believe the AI would have, it doesn't have, et cetera. And that to, right first time is the idea that you name for perfect quality, so it's an ideal. And to do that, you look for problems as early as possible and then you analyze them in a systematic way to think, okay, how could I have avoided that defect? How could I have detected it earlier? How could I have avoided it? And this means you become much, much stronger. And of course, deliver much better quality in the process. Because what we've observed is the more we detect and analyze defects super early on. And it is typically a very good promotion of unit testing and test driven development. The more you detect defects early, the more you analyze them, the less defects you have in production down the line. So that's one leg. And then of course you mentioned the other leg, which is just in time, the reality is the more, the better your quality, the less rework and the more the value flows to the customer. So aiming for great quality means you will go faster. But then of course there's a whole aspect in a larger organization how do you deal with the complexity of multiple teams contributing to the same work. And this is where Toyota brings decades of experience in an approach called just in time, with a few key ideas. And some of them are single piece flow and tax time and pull system and come back. But yeah, maybe I'm going a bit further than your initial question. That's good. Let's go there. That idea of the one piece flow, for example, is a very simple one. But often I see teams who are not really working as a team. Everybody works on his own thing. To the point where they develop very specific skills for those particular thing. So it's the description of the opposite of the one piece flow, right? Yeah, no, you're right. It's completely opposite. An easy solution to-- there's two easy solutions to one piece flow. They're not that easy. But typically an agile by having a cross disciplinary team and if the team is good and they're able to help each other, then you have in a way you have one piece flow in the sense that the request arrives in the team and then it gets delivered by the team. But that's important because it means that people within the team are able to help each other. And I don't know if there's someone who's much better at UX, but there's no UX work at the moment. They might come and pair program with the software engineer to help the software engineer go faster. The other idea, which I think is simple to understand and very powerful and actually not often implemented, is the idea to make sure that you deliver increments of value. So typically imagine you're doing Scrum, you're working-- you're doing agile with the Scrum methodology. And so you're doing sprints. And you have one epic, so one full feature that could deliver value to the customer. But the team decides to work on two or three epics at the same time because they don't want to try down each other's feet. At the end of the sprints, you have three features that are half done. So you have no value for the customer. You have no learning. You can't deploy anything in production. So your week has been from a value point of view, completely wasted. If instead of three people working on three features each and doing half of the features each, the three had worked on only one feature. You could say if you sum three times half, they will do less. But the reality in terms of value for the customer and for the organization, they're doing much more. Because at least at the end of the week, yes, it's hard. Yes, they've had to try down each other's feet a bit. They've delivered one value in production that the client can use. They can make feedback. They can say, by the way, for the next feature, what I can really change my mind. And so that's a key idea of single-piece flow. But how many teams are working on three, four, five features in parallel? I would say most of the teams I've ever met. And therefore, single-piece flow is really a principle to fight against that urge, doing things in parallel, to feel more productive, actually destroy global productivity. What I really like is those two principles you highlighted is that basically it forces those conversations. It will force people to learn. It will force people to collaborate. And it will force people to know how to work on the code all at the same time. It will force a lot of those conversations we can avoid. But when we avoid them, we create a lot of waste. So it's very interesting to look at it in that way. I guess you've summarized a key idea of lean thinking, which is showing the problems that are uncomfortable, but are key to being a better company. And then not seeing them as threats or depressing ideas, but seeing them as opportunities to promise all and learn and do a bit better and then a bit more better and a bit more. Not try to solve everything at once, except that things are the way they are and the business is not dead yet. But they could definitely be improved. And I would definitely be better for the customer and the organization. I really enjoyed the book. And I will encourage people to read it. We brushed a few things about the book. But there's a lot more to say and there's a lot more value in the book. And I love the way you explain the principles and you provided examples from the tech industry of those I love our principles that are not so obvious. What are the things that you want to close with? You've worked with Theo though for quite a long time now. Is it still exciting? Do you see things continue to evolve? You are still a learning organization. To be completely transparent, one challenge we've had has been COVID. COVID has destroyed visual management. Because all of a sudden we were all working from home. And of course, we had to find ways to work all of us remotely. And our culture of really having all the indicators on the walls and giving a lot of visibility on what really mattered on every project was replaced, of course, by Nouchin and Miro. But we lost some of the impact of visual management. So that's been one of the learnings from the last few years. And that is not captured in the book, because the book was finished writing at say in 2021-22. It took a long time. But I'd say the main content was there. And it's one of the things we've realized. We've just, I think, we realized the impact in the last one, two years. And so we've been working hard on bringing visual management back. So that's the current very specific, but quite strategic change. And of course, the learnings now are how do you maintain this culture at even a larger scale? Because a lot of what I write happens when we're scanning from 100 to about 500. And now we're 700. And we're even growing more. So that's going to be a very interesting change in the future. It's very exciting. And the good thing about a learning culture and a lean culture where you find problems everywhere is I can tell you there's enough problems to learn for another few centuries. So I'm not worried about that. And AI is-- and then not only do you have all these problems, but then you have, of course, the market throwing at you innovations that change the game. And having a learning culture means you can adapt to them, pretty much faster than your competitors. So these are exciting times. Clearly, I can see how our lean culture has given us a huge advantage in with the arrival of AI. We've been-- I think we were better equipped as a large organization to frame that as an interesting problem, find places where AI could bring value right away and experiment around them. And of course, the good thing about using AI will bring value is that you can measure the impact of your experiments. So you can measure how much you're improving. And so that's why, for example, we've developed real expertise in modernizing legacy IT systems with AI much faster. And so now we already go three times faster than before. And we're now aiming for 10 times faster. So no exciting times. I'm not bored. That's very cool. I will put a link to what Maya attempt to explain what quantum play explained at Tech Rocks about the factor you built using AI agent to modernize application. Because it's fascinating. And the learning loop that is built in to really improve the way it works. It's an exciting time indeed. What is one question I should have asked you that I did not, that you would like to answer? You didn't ask too much about AI and I answered about AI, nonetheless. You did. Fine. No, I guess one interesting question and when you talk about agility and lean. and things like that is to talk also about business. I think that's one thing that has weakened the agile community is to not talk enough about business. Yeah. And yeah, it's at the end of the day for business, for company, the key thing is, does that actually help us be a better business? So that's one question you could have asked. And the answer would be, we were doing one million revenue back in 2012. We're doing now over 100 million revenue this year. The industry has been suffering the last few years, but we've had a good year and last year and on track to have another good year this year. But yeah, I think this lean tank, it's great in terms of learning, it's great in terms of people development, but it's also great for business. That's what makes it a very sustainable approach to adopt. Yeah, and that's probably where people can really focus on. That's very interesting that can do it. Maybe they can learn how to do it. But very interesting. Where happy to share. Glad to hear that. Thank you very much for making the time to join me for this episode and I'll talk to you soon. Thank you very much, talk to you soon too. If this conversation resonated with you, I'd really encourage you to share this episode with one or two people in your life. So when you work with, so when you lead or so, when you are learning alongside your recommendations, totally matter. The help this podcast writes people who could learn from these conversations and apply them in their own context. You also find the full transcript of this episode in the companion blog post linked in the description. It's available on Alexis.mondayl.com. If you'd like to revisit a specific moment, or share it in written form. The podcast on emerging leadership is supported by per side. At per side, we work with leaders and teams to create the conditions for responsibility, clarity and impact to emerge. You can norm more at perside.fr. Thank you for listening.