And Why Lean Helps Organizations Keep the Same Intention

“All four values of the Agile Manifesto have a scale issue.”

That sentence, from my conversation with Fabrice Bernhard, co-founder and CTO of Theodo, is deliberately unsettling. Not because it dismisses Agile. But because it names something many leaders quietly experience as their organizations grow.

Agile works beautifully for small teams.
And then, at some point, it doesn’t anymore.

This episode of Le Podcast on Emerging Leadership explores that moment. The moment when what once created clarity, speed, and engagement starts producing friction, confusion, and fatigue. And more importantly, what comes next.

Agile explains small teams very well

The Agile Manifesto did something remarkable. It captured, in a few lines, what makes a software team effective: close collaboration, fast feedback, trust in individuals, and a focus on working outcomes.

When teams are small, these principles are powerful. Many of us have lived that experience. Agile helped teams regain ownership of their work, shorten feedback loops, and dramatically improve how they delivered value.

But the manifesto was never designed as an operating model for large organizations.

What breaks when organizations scale

As Fabrice explains in the episode, all four values of the Agile Manifesto run into scale issues.

Take customer collaboration. In a small team, having a customer embedded in the team can create magic. At scale, it becomes impossible. There isn’t one customer anymore, but many stakeholders, often with contradictory needs. Collaboration alone doesn’t help leaders make trade-offs.

Or take individuals and interactions over processes and tools. Direct interactions work when the number of people is limited. As organizations grow, the number of possible interactions explodes. Relying on conversations alone quickly becomes unmanageable.

This is where many organizations get stuck. They try to “do more Agile” to solve problems that Agile was never meant to address.

Lean is not a rejection of Agile. It’s a reframing

The key question Fabrice and his co-authors asked themselves was not “what’s wrong with Agile?” but something more subtle:

Does Lean bring principles with the same intention as Agile, but that actually work at scale?

Lean keeps the spirit of Agile, but shifts the focus.

Instead of customer collaboration, Lean starts with value for the customer. That may sound similar, but the implication is very different. At scale, leaders must constantly clarify what value means, make priorities explicit, and ensure teams can see when they are drifting away from what truly matters.

Instead of relying on interactions everywhere, Lean organizations structure themselves as networks of autonomous teams, enabled by clear boundaries and strong technical foundations. Autonomy doesn’t come from more communication, but from better interfaces, both human and technical.

Leadership looks different at scale

One of the most concrete parts of the conversation is the example of a latency target: a product needed to stay below 50 milliseconds to be viable.

Leadership believed this was clear. Teams, faced with technical difficulty, quietly aimed for 80 milliseconds instead.

Nothing dramatic happened. No one pushed back loudly. The organization simply deprioritized what was hard.

This is a classic scaling failure. Value was communicated once, but not made obvious, unavoidable, and discussable. Lean leadership, in contrast, requires leaders to go and see, to confront their assumptions with reality on the ground, and to create the conditions where teams raise their hands when things get hard instead of silently adjusting priorities.

Scaling is also a technical challenge

Another important point Fabrice makes is that agility cannot be restored through leadership and culture alone.

You can reorganize teams endlessly. If the underlying architecture remains tightly coupled, autonomy will always be an illusion.

That is why Lean Tech puts so much emphasis on technical enablers: deployment pipelines, automated testing, feature flags, modular architectures. These are not implementation details. They are conditions for responsibility and flow at scale.

Learning organizations don’t look for best practices

Perhaps the most important shift Lean introduces is how organizations relate to problems.

In many companies, problems are seen as failures to hide. In learning organizations, problems are signals to explore.

Toyota did not invent a perfect system. It invented a culture of continuous improvement. Every visit reveals something new, because the organization is always learning.

At Theodo, this shows up in weekly problem-solving dojos, where teams share real problems and collectively improve how they analyze and address them. Problem-solving becomes a shared capability, not an individual talent.

Why this matters now

With AI, distributed work, and increasing organizational complexity, the cost of pretending that small-team practices scale indefinitely is growing.

Lean offers a way forward that does not abandon what Agile taught us. It preserves the intention: respect for people, focus on value, learning through feedback. But it grounds that intention in principles and practices that hold when organizations grow.

This is not about choosing sides. It is about recognizing limits, and evolving leadership accordingly.

If you are leading an organization that is scaling, or supporting teams that feel stuck between agility and bureaucracy, this conversation is for you.

You can listen to the full episode with Fabrice Bernhard on Le Podcast on Emerging Leadership.

References

• The Lean Tech Manifesto by Fabrice Bernhard and Benoît Charles-Lavauzelle
• Beyond the hype, industrializing legacy modernization with AI and Lean by Alexis Monville

Here is the transcript of the episode:

Alexis:
I’m very happy to welcome Fabrice Bernhard. Fabrice is the CTO and co-founder of Theodo, the technology company co-founded with Benoît Charles-Lavauzelles. Over the past decade, they scaled Theodo from 10 people and 1 million dollars in 2012 to more than 700 people and 100 million in 2022. They are the authors of The Lean Tech Manifesto, a book that captures their experience of scaling an organization without sacrificing quality, engagement, or responsibility.

Fabrice, welcome to Le Podcast on Emerging Leadership. How do you usually introduce yourself to someone you just met?

Fabrice:
I would say that my name is Fabrice Bernhard and I’m the co-founder of Theodo. And if it’s in a working environment, which I guess this is the case here, I would say that Theodo is an international tech consultancy based in London, Paris, Casablanca, and Cape Town.

Alexis:
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?

Fabrice:
Yeah, it’s a very interesting question. I think we wanted the book to be about Lean Tech, about our learnings and experience around adapting lean wisdom to the tech industry and tech organizations. 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 a necessary part. So that’s what we wanted to convey, to really explain that you don’t need to read our story to learn about Lean Tech.

That being said, I completely understand your point. The story is a very good introduction and I think it provides valuable context to the book.

Alexis:
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?

Fabrice:
Yeah. I think in the scaling story, if you look at our bottlenecks to scaling, the first one was finding product-market fit. And finding product-market fit happened when we really deeply understood agility, agile methodologies, and we were able to bring them to larger corporates who were definitely struggling to adopt them on their own.

So that’s been the first step. And once we had product-market fit, 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, had tried to apply it in a large organization and realized the limitations, the problems that Agile doesn’t address when you’re a large organization.

He 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 will be amazing. And so that’s why we’ve been on a Lean journey ever since. That was back in 2012, and we’re now, what, in 2026. So that’s already 14 years now.

Alexis:
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 about that first part?

Fabrice:
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 the shared understanding of what made an agile software development team agile.

So you can always go back to this manifesto to understand what they meant by agility, which is very good. And so when you look at the principles, I think they make a lot of sense and they 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 a large organization? And when you take each value, 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 these four ideas just don’t scale.

Two very simple examples. One is customer collaboration over contract negotiation. It makes a lot of sense, but in large organizations 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 Theodo. It was amazing. 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 or 20 teams.

That’s one side of the coin. And the other side of the coin is when you are working for large organizations, there’s not one customer who really knows what they need. You start having multiple stakeholders with contradictory requirements, contradictory 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 conveys the same kind of intention, but actually works at scale? And we found it.

The first principle of 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 Toyota is very good at this and they have 300,000 employees. Amazon is 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 agile and are very large. So that was one example. And then, depending on how long you want me to speak, I can give a second example.

Alexis:
Good.

Fabrice:
Yeah. I could give you all four examples, but I’ll just give two. And the second one, and I’ll be shorter, is the core principle of 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 start having 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 a tech-enabled network of teams. And as examples, we give Linux and we give Amazon, which we could talk a lot more about if you want, or you can read the book if you want to know more about it.

Alexis:
Yeah. We have value for the customer, 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 customer for a second, what does that mean for a leader in an organization, whatever the size? What are the questions they should ask themselves?

Fabrice:
Lean Tech is basically our own secret sauce. 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 with the reality of it. Because as soon as the organization grows, what you start having is 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 and see,” or going to the gemba. Gemba being a Japanese word for where work really happens.

And so that’s a key practice of a leadership team in a Lean Tech organization, 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 with the reality on the ground.

So that’s the 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 an Obeya. Obeya is another Japanese word that means a big room. And the key idea is that you display in your office, and it’s much better if it’s physical, you display your understanding of the value, your understanding of the key challenges 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 widespread sharing of what value means to the whole organization.

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 or redesigning the organization 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 teams know to which customer they’re contributing and what kind of value they’re contributing to that customer.

So that everyone can be empowered on what is the value that they actually need to build and to deliver. And if they have the autonomy to do that, then they engineer themselves the solution to creating that value.

Alexis:
Do you have an example when you felt you articulated properly the value for the customer at a very high level, but when teams were maybe a little bit struggling with understanding the value, and you’ve seen that moving from not understanding to already understanding?

Fabrice:
Ah, it’s a very interesting one. The first example that comes to my mind is not us, but somebody else.

A very interesting organization asked us to come in and evaluate them using the Lean Tech framework.

And one thing we realized is that for leadership, there was a very clear technical requirement around the latency of the product. The latency had to be below 50 milliseconds to be sellable as a home cinema product.

All the studies had shown that if it was above 50 milliseconds, customers would notice it and would 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. We’re aiming for 80 milliseconds. Fifty 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’ve realized by going around is that the teams didn’t know that it was a key part of the value for you to deliver under 50 milliseconds.

The leadership team got a bit frustrated because for them they had made it very clear. And they hadn’t made it very clear.

What we said is: definitely not clear enough. Not obvious enough. Not unavoidable enough that the teams would have needed to raise the issue and say, “Guys, we’re not achieving these 50 milliseconds. What can we do?”

Instead, the disconnect between leadership and teams on the ground made it possible for teams who found achieving 50 milliseconds super hard to deprioritize that challenge.

And that, I think, is a very interesting example that we see in every large organization. Some challenges are very hard. If they’re not made super clear and obvious, quite naturally the organization will deprioritize them for easier things that they can do.

And that, I think, is 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 reprioritize and work on something else.

Alexis:
Yeah, it’s an excellent example of communication not being a one-way street. You need to enable the other way, so people can raise their hand.

I’ve heard that a lot of times. When people are actually doing the work, it’s very different. And you can be frustrated on both sides.

Fabrice:
And I think it was a very good example of frustrations on both sides. Leadership said, “We had made it clear.” Teams on the ground said, “Yes, we heard it once, we raised the issue that it was hard, and nobody came to us.”

And therefore this conversation that should have happened on a regular basis happened maybe once and then never happened again.

Alexis:
Yeah. Yeah. I’m curious: did they succeed in either changing the goal or succeeding in the goal?

Fabrice:
I don’t have the exact answer, so I have some guesses, but I prefer not to share them.

Alexis:
Okay. That’s good.

We discussed a little bit high-level value for the customer. 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 team topologies and the idea of stream-aligned teams, and aligning teams on the value. A lot of people are trying to do that, and you can see how difficult it is when you’re really trying.

What is that tech-enabled network of teams you mentioned?

Fabrice:
Yes. So it all started with trying to find how do you keep the magic of the agile principle, individuals and interactions, at scale.

And clearly when we look at Amazon, what they did back in about 2000, they had the same issue that every large organization has. They had one big monolithic code base. Everyone that was contributing to it was treading on each other teams’ feet.

And therefore there was a huge challenge on how do we synchronize when one team needs to change something that impacts another team. How do we synchronize these changes?

So they had these big synchronization meetings every quarter. And it was a big mess. And very good developers were starting to leave because they couldn’t be bothered with so much bureaucracy.

We’ve seen that in large organizations, we’ve seen that everywhere.

What they did at Amazon at that moment is that there was this debate around maybe we need more communication or better communication.

And Jeff Bezos had a very good intuition and said, 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 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 the API mandate. It required a year and 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. Each team had their own module. And every module, when it needed to interact with other modules, did it through very well-defined, very stable, reliable, intuitive APIs.

And that completely transformed Amazon. It gave them this agility back and was definitely a foundation to their super fast growth for the following years and the following 20 years.

And it was also the foundation 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 say, “Please, I want a new server,” and get it.

So this is basically the story behind the principle of tech-enabled network of teams.

And in this principle, we really mix two ideas. One is that 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: 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 that’s also what we see in traditional organizations, is that it’s not just a people problem. 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 rework of your underlying technology, you will never get the agility that you are aiming for.

Alexis:
Okay. This is the part I believe 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-architect everything. Where do I start?

Fabrice:
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 monolith modular, because we have a few examples where one of the key transformations was actually the deployment pipeline.

Alexis:
Mm-hmm.

Fabrice:
So moving to a deployment process that is much closer to trunk-based development. Investing heavily in automated testing. Investing in feature flagging.

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.

And then the re-architecting would happen, but you can’t do it all at once. I believe, and we’ve done it quite a few times, you re-architect in a progressive way.

Alexis:
Yeah.

Fabrice:
And 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 that they have to put energy on that.

And yeah, I guess if there’s one key message here, it’s that you cannot achieve agility just by addressing the people challenge. You also need to address the technical challenge.

And that does require getting your hands dirty and trying to understand why the current tech landscape is not working.

Alexis:
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 real engineering skills. You cannot fake it on that part.

Fabrice:
Yeah, no, of course. And to be honest, the outcome can be much better than what most people believe.

We’ve just delivered the new professional bank of LCL, which is a very large French bank. 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. But 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. Most of them also have legacy code they have to deal with. So they’re not that much faster.

With the right technical expertise and the right delivery discipline, you can deliver a whole new digital experience for a bank in 10 months.

Alexis:
You spoke a little bit about learning. That’s one of the foundations you talk about in the book, about building a learning organization. Can you tell us what you mean by that?

Fabrice:
Yes. The way I restructured the Agile Manifesto, and this is a quick introduction, is that 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 organization aspect. How do you make teams able to contribute? So that’s tech-enabled network of teams.

And then there’s a whole body of knowledge around delivery and quality at scale. And this is what we call right first time and just in time, 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?

There’s an anecdote I love, and it’s probably a bit imagined, but let’s imagine Americans arriving in Japan in the eighties and asking Toyota, “Can we visit your factories? Apparently you are so much more productive than us and we want to know why.”

And the Japanese would be like, “Yeah, sure, whatever.” And the guys would come and they would try to understand everything. And then they would come back to the US, copy-paste it, and they would get some benefits, but they would also have issues.

And they would go back to Japan and say, “We tried 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. They didn’t invent a great way of doing things. They invented the culture of continuous improvement. So whenever you come, the better way of doing things is changing.

And that’s the building a learning organization aspect. And that’s, of course, the most exciting aspect of all. It’s the one that has to do with innovation.

If we want to dig a bit into what building a learning organization means, it means one key thing. If there’s one thing to remember, it’s creating a culture of problem solving.

A culture where raising problems, identifying problems, is welcomed 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 to people hiding problems.

You are turning around the usual reaction to a problem. Showing a problem is positive. Hiding a problem is negative. And not analyzing a problem is potentially discouraged.

What is encouraged is analyzing the problem. And if you don’t have the skills, that’s actually a skill. You can learn it. You can teach it.

And that’s really a key aspect. And that’s something we do at Theodo ever since, I would say, 2012, when this lean coach started coaching us.

We started having dojos on problem solving. And every week, the whole organization would meet on Monday at 12. One team would present a recent problem solving, and we would challenge them and give 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 probably the key foundation of a learning culture.

Alexis:
Excellent. I really encourage people to think about what happens when we ask that kind of question: “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. And going to that culture is really something.

Fabrice:
It is. It’s very interesting because “problem” has two definitions. And one of them is a scientific definition. And clearly what Theodo 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, etcetera. 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 both 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 need that there’s a lot of waste along the way.

How can I identify this waste, and how can I remove it?

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 are generating profit while not changing anything for the customer.

And what is even more interesting is that if reducing those wastes means you have done a lot of problem solving, which means you have actually found issues in the way you 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, all that in a seamless way for the customer.

So this vision of business is very beautiful.

Alexis:
Yeah. And I believe that core idea of already changing the mindset we have about how we already do the work, you alluded to that before.

There are two big pillars that you are looking at: right first time and just in time. Could you give us examples of what it means?

Fabrice:
There’s a really good example at the moment in AI coding. Actually, I posted about it on LinkedIn this morning.

Typically now, if you do a bit of AI coding, the easy approach is to start chatting to code and say, “Can you do this?” “No, not exactly 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 at once to Claude. And Claude then delivers the perfect result.

And right first time would, 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.

So you’ll start analyzing, okay, what did I miss in my instructions that made the AI not understand what I meant?

Alexis:
Yeah.

Fabrice:
And so you’re building intuitions on what works, what doesn’t work, what AI needs, what are maybe the assumptions that you believe the AI would have but doesn’t have, etcetera.

So right first time is the idea that you aim 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, you deliver much better quality in the process.

What we’ve observed is that the more we detect and analyze defects super early on, and that is typically a very good promotion of unit testing and test-driven development, 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 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 large 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. Some of them are single-piece flow and takt time and pull systems and kanban.

But yeah, maybe I’m going a bit further than your initial question.

Alexis:
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 things.

So it’s the description of the opposite of the one-piece flow, and right?

Fabrice:
Yeah, no, you’re right. It’s completely the opposite.

An easy solution to single-piece flow, and they’re not that easy, but typically Agile helps by having cross-disciplinary teams. And if the team is good and they’re able to help each other, then in a way you have single-piece flow in the sense that the request arrives in the team and then it gets delivered by the team.

Alexis:
Mm-hmm.

Fabrice:
But that’s important because it means that people within the team are able to help each other.

And if, I don’t know, 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 a 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 in sprints, and you have one epic, 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 tread on each other’s feet.

At the end of the sprint, 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 and doing half of 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, is that they’re doing much more.

Because at least at the end of the week, yes, it’s hard, yes, they’ve had to tread on each other’s feet a bit, but they’ve delivered one thing in production.

They can get feedback. They can say, “By the way, for the next feature, you know what? I completely changed my mind.”

And 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 of doing things in parallel to feel more productive, which actually destroys global productivity.

Alexis:
Yeah. What I really like with those two principles you highlighted is that basically it forces those conversations. It forces people to learn. It forces people to collaborate. It forces people to know how to work on the code all at the same time.

It forces 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.

Fabrice:
I guess you’ve summarized a key idea of Lean thinking, which is showing the problems that are uncomfortable, but that are key to being a better company.

And then not seeing them as threats or depressing ideas, but seeing them as opportunities to problem solve 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 it could definitely be improved, and it would definitely be better for the customer and the organization.

Alexis:
I really enjoyed the book, and I encourage people to read it.

We brushed a few things about the book, but there’s a lot more to say and a lot more value in it.

I love the way you explain the principles and provide examples from the tech industry, for those high-level principles that are not so obvious.

What are the things you want to close with? You’ve worked with Theodo for quite a long time now. Is it still exciting? Do you see things continue to evolve? Are you still a learning organization?

Fabrice:
To be completely transparent, one challenge we’ve had has been COVID.

COVID destroyed visual management because all of a sudden we were all working from home.

And of course we had to find ways to work remotely. But 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 by Notion and Miro.

And we lost some of the impact of visual management.

So that’s been one of the learnings from the last few years. And that’s not captured in the book because the book was finished in 2021–2022.

But I think we really realized the impact in the last one or two years. And we’ve been working hard on bringing visual management back.

Alexis:
Yeah.

Fabrice:
So that’s a current, very specific but quite strategic challenge.

And of course, the learnings now are how do you maintain this culture at even a larger scale.

A lot of what I write happens when we were scaling from 100 to about 500, and now we’re 700 and growing more. So that’s going to be a very interesting challenge.

It’s very exciting.

And the good thing about a learning culture and a lean culture where you find problems everywhere is that there’s enough problems to learn from for centuries. So I’m not worried about that.

And AI, of course, adds another layer. Not only do you have all these promises, but you also have the market throwing innovations at you that change the game.

Having a learning culture means you can adapt much faster than your competitors.

Clearly, I can see how our Lean Tech culture has given us a huge advantage with the arrival of AI.

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.

And a good thing about using AI where it brings value is that you can measure the impact of your experiments.

So now we already go three times faster than before, and we’re aiming for ten times faster.

So no, exciting times. I’m not bored.

Alexis:
Yeah, that’s very cool.

I’ll put a link to my attempt to explain what Quentin Pleplé explained at Tech.Rocks about the factory you built using AI agents to modernize applications, because it’s fascinating, and the learning loop that’s built in to really improve the way it works.

It’s exciting times indeed.

What is one question I should have asked you that I did not, that you would like to answer?

Fabrice:
You didn’t ask too much about AI, and I answered about AI nonetheless.

That’s fine.

I guess one interesting question when you talk about agility and Lean and things like that is to talk about business.

I think that’s one thing that has weakened the agile community, not talking enough about business.

At the end of the day, for a 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 1 million in revenue back in 2012. We’re doing over 100 million this year.

The industry has been suffering the last few years, but we’ve had a good year last year, and we’re on track to have another good year this year.

So yes, Lean Tech is great in terms of learning and people development, but it’s also great for business.

That’s what makes it a very sustainable approach to adopt.

Alexis:
And that’s probably where people can really focus. If you can do it, maybe they can learn how to do it.

That’s very interesting.

Fabrice:
We are happy to share.

Alexis:
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.

Fabrice:
Thank you very much. Talk to you soon too.

Alexis (outro):
If this conversation resonated with you, I’d really encourage you to share this episode with one or two people in your life. Someone you work with, someone you lead, or someone you are learning alongside.

Your recommendations truly matter. They help this podcast reach people who could learn from these conversations and apply them in their own context.

You can also find the full transcript of this episode in the companion blog post linked in the description. It’s available on alexis.monville.com if you’d like to revisit a specific moment or share it in written form.

Le Podcast on Emerging Leadership is supported by Pearlside. At Pearlside, we work with leaders and teams to create the conditions for responsibility, clarity, and impact to emerge.

You can learn more at pearlside.fr. Thank you for listening.