#154 - Scale a Fast and Resilient Company With Lean - Catherine Chabiron & Fabrice Bernhard

[00:01:19] Episode Introduction

Henry Suryawirawan: Hello again, to all of you my TLJ listeners. You’re listening to the Tech Lead Journal podcast, the podcast where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. If you haven’t, please subscribe on your favorite podcast app to get notified for future episodes. Also subscribe to Tech Lead Journal’s various other contents on LinkedIn, Twitter, Instagram, YouTube, and TikTok. And please consider supporting this podcast by either buying me a coffee at techleadjournal.dev/tip or becoming a patron at techleadjournal.dev/patron.

My guests for today’s episode are Catherine Chabiron and Fabrice Bernhard. Catherine is a Lean expert and the co-author of “Learning to Scale at Theodo Group”, while Fabrice is the co-founder and CTO of Theodo. In this episode, Catherine and Fabrice shared their lessons learned from implementing Lean at a fast growing scale-up company, and that is Theodo. Catherine and Fabrice first started by sharing the big company disease challenge and how Theodo started its Lean journey. We then discussed Lean essentials that include some of its principles, such as obsession with customer value and lead time. We also talked about Lean practices adopted from the Toyota Production System, that include Gemba, Jidoka, Andon, and Kaizen. Along the way, Catherine and Fabrice also emphasized the importance of always building quality right the first time.

I hope you enjoy listening to this episode and learn many insights on Lean and how to implement it at a large scale and fast growing organization. If you enjoy listening to this episode, please share it with your colleagues, your friends, and your communities, and leave a five-star rating and review on Apple Podcasts and Spotify. Your small help will help me a lot in getting more people to discover and listen to this podcast. And I really, really appreciate it. So let’s now go to my conversation with Catherine and Fabrice.

[00:03:17] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have Catherine and Fabrice. Today, we are going to discuss about Lean, specifically how Fabrice’s company, Theodo Group, implemented Lean during their fast growing scale. So yeah, really looking forward for this conversation. Thank you so much for the time here.

Catherine Chabiron: Great. Welcome.

Fabrice Bernhard: Thank you for having us.

[00:03:41] Career Journey

Henry Suryawirawan: Right. So I always love to ask my guests first to share about themselves. Maybe if you can highlight some of the major turning points in your career or maybe just tell us more about yourself, that would be great.

Catherine Chabiron: To make it very simple, I’ve been in the industry all my life, and particularly at the end of my career in the automotive industry. This is where I met Lean. Because the automotive industry could not try and do what Toyota was doing, because they really showed us another way of doing productivity in manufacturing, but also in innovation. It’s not just manufacturing, it’s also how they address innovation as well. So I was in the automotive equipment, I discovered Lean, I actually discovered it also applied to quite a number of other activities. And I’ve made my job of it to go and help other companies to try Lean as a framework for their company.

Fabrice Bernhard: And my name is Fabrice Bernhard, so I’m the co-founder and CTO of Theodo. I started coding when I was about 10, and I’m very lucky to have grown up in a little village called Sissy, which is where Tim Berners-Lee lived when he invented the World Wide Web. So I got very early access to the World Wide Web. Fast forward, I studied computer science at university and met Benoit, my co-founder, and we launched our first startup called allomatch.com which was the website to find all the pubs, cafes, and restaurants where you can watch sports. So that was our first startup, a product like a typical internet product startup. It was a lot of fun. We reached break even, so that was, that was really cool. But we also realized that, you know, in terms of ambitions, it was limited, so we created a second company called Theodo, which is a company we’re talking about today. So tech consultancy. And now we’ve been doing this for 15 years, helping clients design code and deploy tech solutions to their business problems. And we are based in Paris, London, New York, and Casablanca.

Henry Suryawirawan: Thank you to both of you for sharing your journey, right? I think, one, Catherine is from the Lean background, learning it maybe from the first place where this all, like Toyota Production System became like the trend these days, right? And also, Fabrice, from the Theodo group perspective, right. Like 15 years, that’s a pretty long journey for a company.

[00:07:26] Big Company Disease

Henry Suryawirawan: And today we’re going to talk about how Theodo actually implemented Lean, right? So 15 years is a long journey, I’m sure you have gone through many, many major stages in the company’s life, right? And one in particular is about when you grow really, really fast. Because I think there are many companies, even startups today that went through the same growth stages. But they face maybe the same challenge like what you had last time, which is, you know, like how to scale this rapid growth in the more effective way. So maybe in the first place, I would like to discuss about this thing you mentioned in the book called big company disease. So maybe one of you can elaborate, what do you mean by that?

Catherine Chabiron: Maybe I can do that. It’s not our invention. It’s something that flows around on the web. But it’s usually summarized with four ideas. The number one idea is eventually when you grow, you grow complex. So you will import in your startup CTO, COO, CIO, CFO, and so on. Each of them are needed for their expertise, but they will build silos and eventually they will try to improve their own silo of expertise at the expense of teamwork. The first symptom will be that you will be defending silo (rather) than (promoting) teamwork.

The second is as the complexity grows, and Fabrice will be able to tell you about that, you start developing processes, because you want to align people on the rules, on the ways of doing, and things. But eventually the process wins over the customer. You know, when you get a hotline and you give them a call, you’ve got a problem and you hear them answer, this is not me, you should call this or that number. And this is typically process telling you, you’re not in the right channel. And then you have to do the effort yourself. So it’s process over customer.

The third one is usually that we will be more thankful for compliance than initiative. In other words, we will promote people who are very compliant with our rules and processes and will say yes to the boss rather than promote people who are exploring other ways.

And possibly the last one, more difficult to understand, but maybe we can take an example is legacy versus heritage. Maybe everybody remembers when Coca Cola wanted to change their recipe. Because they thought it was just a legacy they had and they could change the product as needed to just go along with the new ways. It turns out that people didn’t want the new recipe. They just fought against it and Coca Cola had to step back. And this is typically confusing legacy with heritage. The recipe was actually the heritage, not a legacy that it could dispense of. That’s roughly the story about the big company disease.

[00:10:19] Theodo’s Lean Journey

Henry Suryawirawan: Right. So I think, maybe from Fabrice’s point of view, right, I’m sure you have gone through this stage where you think Theodo is having this big company disease, right? So tell us more at that point in time, what was the challenge that you actually encounter and what makes you think, you know, like this is a problem that the company should try to solve and hence you will try Lean afterwards?

Fabrice Bernhard: Yeah, I think, you know, to understand my journey and the journey of Theodo, like a big turning point is, it’s about 2011-2012. We started the company because we didn’t want to join a corporate. So really like the whole premise from Benoit and I was, we don’t want to work in a bureaucratic environment, you know, that stifles innovation, that is risk averse, and you know, where your creativity is not welcome. So we start our own startups, so Allomatch and Theodo, and we realized that actually very quickly when you start having quality issues, that the standard way of dealing with them is adding processes and hierarchy. So we’re like, wow, with a small company and we’re already back to square one, so this is not okay.

And so the turning point is we get so frustrated by this that we think, okay, maybe what we’re not doing right is we’re not doing Agile correctly. So we had been kind of playing around with Agile, but we were quite young and probably not mature enough at the beginning. And so there’s this really turning point where we say, okay, we’re going to try Agile by the book, you know, disciplined. And either it works or, you know, we’re going to reconsider what we’re doing. And it was really like, and it was a game changer. Like, really doing Agile in a disciplined way, you know, really implementing Scrum and eXtreme Programming best practices got us into this stage where the clients were much happier, the teams were much happier, the profitability was much better, and we could really scale all of a sudden horizontally. Because for every new project, we could have a fully empowered Agile team working directly with the client embedded in the team. And it just worked, you know, before that I used to be the chief firefighter, as the CTO, always trying to solve problems. And all of a sudden I was, you know, I almost had no job, because the teams were doing all the firefighting themselves. So that was really the first game changing moment.

And I think what happened very quickly after that is we were like, okay, if there are things, frameworks like Agile that can change your life at a team level, what can we do scaling the company level? And this was way before, you know, SAFe had been invented and stuff like that. And so we realized that, you know, if you just try to implement Scrum on very large projects or even worse at like the whole company scaling level, you realize it was not designed for that. So Agile methodologies like Scrum and Extreme Programming have really been designed for empowering a small team of super talented engineers. But at the same time, we’d seen that, you know, you can be working in a way that is like the standard way and then discover a new way, which is much better.

So we thought, come on, it can’t be possible that nowhere in the world, you know, no one has like found a solution to that. And to be fair, you know, you can feel that companies like, you know, Google or Amazon or Apple work differently. So it was all about trying to understand what they did differently. And that’s when we met our first Lean coach who said, you know, actually that he had a similar experience because he said, you know, I tried to do Agile in a large company, in a large telco, and you know, it was just structurally impossible to get the full benefits of Agile. And I discovered Lean and that brought me like the answers to the problems I couldn’t solve with Agile.

So we got very, very excited and that was really the turning point of adopting Lean. And, you know, to come back to your question, the big company disease, even with Agile, what you realize is, you know, you can’t deal with teamwork of multiple teams easily. And actually you have very empowered teams. So everyone wants to do, you know, their best, but at the team level. Agile doesn’t really tell you how to structure the fast scaling of an organization, but in a smart way. So you’ve got all these issues that, you know, that typically arrive as soon as you grow and that Agile alone is not enough to solve.

Henry Suryawirawan: It’s very, very interesting what you mentioned, right? So you have tried Agile fully and it worked really, really well at the team level. But when you try to scale it at the company level, although these days, they have many flavors of Agile out there, right? But I think when you try to scale it to the company level, I think it has some challenges, right?

[00:14:35] Implementing Agile at Scale

Henry Suryawirawan: I think for many companies now that are going through this journey, they feel like they want to innovate faster. They want to maybe transform themselves, and they’re still looking for like Agile as the solution, what would be your advice maybe for companies to probably don’t try this, we have tried before. And maybe this is a better way of approaching the problem. Maybe any kind of advice here.

Fabrice Bernhard: But maybe just to conclude on that experience, I think Agile is amazing. Let’s be really clear. Scrum and Extreme Programming which for me are like the two methodologies we worked with the most, are really an amazing framework and amazing guidelines for teams. And yes, I mean, my experience having tried the different flavors of Agile at scale is that they’re not the right path. I mean, some of them are better than others. Don’t get me wrong. But the whole problem is you want to scale the Agile Manifesto. You know, you want to scale this essence of adaptability and, you know, customer first approach, and delivering fast and high quality.

And the people who’ve thought about doing that at scale the best are Toyota. And that’s why Lean is so popular because there’s been for the last, you know, 70 years, or let’s say 50 years, people have been trying to understand what Toyota has done so well. And trying then to, you know, adapt it to their own companies. And that’s Lean. I mean, the definition of Lean in a way is the body of knowledge of people trying to understand and adapt Toyota practices to their industry. And to give you a few examples. And that’s, I think, really key for your audience.

When you look at the history, for example, of Steve Jobs, you realize that when he gets fired from Apple, and creates his next company called actually NeXT, he’s actually wondering how could I, you know, scale quality. Because he, you know, he’s been replaced by John Scully at Apple and they start having quality issues. And he realizes that, you know, the way he did quality at Apple was like not very scalable. And so he hires, Juran to help him. And Juran is one of the founding professors that influenced Toyota in the fifties. So you realize that Steve Jobs actually had first level source of Lean and that really influenced him. And there’s a video of him like sharing how much it’s influenced him and you can see a lot of these principles then that, you know, got adopted at Apple once he came back.

Another amazing example is Jeff Bezos. There’s this amazing book called Working Backwards and there’s this clear anecdote that in, I think, ‘99, 2000, around this time, Jeff Bezos starts getting very interested in the Toyota Production System and starts implementing a lot of the, you know, principles and ideas on Amazon. And to the point where he actually then hires Mark Onetto to really deploy Lean at scale in the whole operations. So it’s a very long answer to your question, which is if somebody wants to do Agile at scale, well, Lean is probably the best place to start.

Catherine Chabiron: Maybe a little point that I can add, Agile stems from Lean. It picked up a number of the concepts of Lean. Forgot others. So, going back to Lean is going back to the original framework, which is just added experience piled up by Toyota on innovation on the one hand, on customer focus on the other. On lead time obsession, customer lead time obsession. It’s not just pushing forward to go faster, it’s just to make sure that the customer gets his product in time. It’s finding out also experience about quality and how to unleash the creativity of everybody in the company, not just some experts. And how to build trust and respect and mutual trust to keep the engagement everywhere. Because you don’t serve customers well unless you are treated well yourself.

So first, make sure that you build trust and you develop trust and develop engagement. And then, you can take care of your customers. So there is a whole framework which we try to explain in the book how Theodo is using this original Lean framework. Maybe we’ll go through some of the items later.

[00:18:41] The Essence of Lean

Henry Suryawirawan: Very fascinating, hearing what both of you said, right? So I think it’s a good segue to go into the Lean itself, right? First, I must admit, so I also know very shallow in terms of Lean, right? Whenever we encounter Lean resources, they always talk about Kanban, or maybe push versus pull. And maybe all these tools or maybe processes on how we can optimize stuff, right?

But I think the first few things that I encountered by reading the book is that the first thing you said that Lean is actually is not to organize work, but it’s actually to organize how we think about problem. And the second thing, it’s not a production system, just like Toyota production system, but it’s actually an education system. I think these two things are key for me when I read the book. Maybe if you can elaborate a little bit more, so that people are enlightened what Lean is all about.

Catherine Chabiron: Maybe I can try and outline a few items. Why we say it’s a thinking people system, and I’m pretty sure Fabrice will elaborate on that, is, again, the underlying assumption that you will not be as efficient if only ten experts think. Whereas you can have thousands of frontline people think with their hands, their heads, their eyes, and bring improvement together.

So how do you get people to think? This means you have to open up exploration, not just execution. The bigger you grow nowadays, all the big companies tend to promote execution. How to make sure that we execute a deliverable, a project, a task, whatever, well and in time. And we need to do execution, of course. But what Toyota has been pushing really, really strongly, is how each one in the company is also exploring better ways of working. Better ways of doing a technical gesture, better ways of understanding the material, the product. Better understanding of what the customer is doing with our products.

So this ever ongoing thinking system is really the difference that Toyota has been promoting. And this is how it leads to the education system, because if you want to have people think, if you start thinking and observing, you start doing problem solving, you start learning from your solutions or from the problem solving. And therefore you start sharing the learnings and educating the others. That’s roughly the idea. And it’s a big, big difference versus what we see elsewhere. Fabrice, you may want to elaborate on that.

Fabrice Bernhard: No, it’s, it’s interesting. Hearing your words kind of reminded me. And the word is not used very much, but I think what you want in Agile is to really leverage the talent of everyone in the team. And what you want in Lean is to leverage the talent of everyone in your organization. Because the idea is better thinking by everyone will lead to better products for the customers.

Catherine Chabiron: Let me give you maybe just one illustration, because it’s not so easy to understand what this all means. Just to tell you, when I was writing the book, I was visiting Theodo and doing a number of what we call Gemba visits, visits on the field with some key people. And there was one of the guys who told me of a story, he was the CTO of one of the entities of Theodo.

And he said he had encountered a guy who was developing a mobile app. He was ready to test it. He had to test it on a number of smartphone devices, so he had different models of smartphones. But he didn’t know where those devices were in the office. He didn’t know how to upload the test app as well. He was losing or wasting a lot of time doing so. So the CTO could have come and told him: okay there’s this guy here (who knows) or I can tell you how to do it and I have got a sheet of paper where it’s all marked down and you just follow the rules.

What he did instead is tell him why don’t you think about it? Look, those are not normal conditions. You agree you spent 17 minutes looking for devices and how to upload the app. Why don’t you think about it and find another way? And the guy went, found another way, saved half the time in looking for devices and uploading apps, and shared the findings with others, saving, I don’t know, minutes per day for everybody in the company. So this is what we call learning or education. It’s not telling people what to do, it’s raising questions on what’s normal, not normal, and making them think about it.

[00:23:16] Gemba

Henry Suryawirawan: Wow, I think that’s a very good example, as an illustration, right? And you also mentioned this term called Gemba. So when I read your book, the word is kind of like spread all over the chapters, right? Because I think this is one of the key practice in Lean. So tell us more, what is this Gemba or Gemba walk? So maybe that we can all learn about this important concept.

Catherine Chabiron: I’ll just give the definition and then I’ll let Fabrice answer this one. The Gemba in Japanese, we keep using this term because it just means the place where the things happen, and more particularly the frontline things happen for the customers. It can be a production area. It can be a team doing a project and developing an app, in the case of Theodo. It can be a place where we are handling invoices, or dealing with customers or answering customer calls, and so on. So, front line areas where things happen to produce value for the customer. Fabrice, I’m sure you want to elaborate.

Fabrice Bernhard: Yeah. I think, you know, as you mentioned before, when people speak about Lean, they will come up with like aspects of Lean. Lean is such a wide and rich body of knowledge that, you know, it’s a journey of learning. We’ve been on this journey for now, you know, 12-13 years. And we’re still learning stuff all the time.

But if there’s one thing that is, I think, so critical to Lean and to this mentality of thinking of the workplace as a place to learn, is for leadership, leaders in the organization to actually go and see how things are done.

And it’s fascinating because you realize that as simple as the instruction is, it’s like whenever you tell that to like a big bureaucratic corporation, the leaders look at you and say weird things like, oh, it takes too much time and too much money. And you’re like what does take too much time and too much money? And just, you know, walking and going to see. But there is a lot of like issues and reasons, probably not to do it.

But anyway, the point is, Gemba is, if you’re a tech leader, it’s simple. It could be like, you know, you pair program with your team on a regular basis, at least once a week. If you’re the CTO, well, you could pair program with one person every week, for example, or every day. Or you could just, you know, observe someone coding or… but basically it’s always the same idea. It’s having this very regular discipline of saying, okay, I might have, you know, more responsibilities now. But I have to regularly look at how things are done back on the ground. You know, what does a junior engineer in my organization do?

Henry Suryawirawan: Yep. So if I understand correctly, right, so Gemba is like the practice, the discipline where the leaders, like maybe the executives or the leaders, always go to the place where the real things happen. You mentioned about frontline, right. So not always in the ivory tower, maybe some people call it, right. But you actually go down and, you know, work together and collaborate with the frontline people, right. The one who actually does the actual work. And I think in the book you also mentioned that the performance of the whole company is kind of like limited by the way we think, right? Just like the example mentioned by Catherine, right? So instead of giving solutions you actually ask questions. You actually try to challenge what is normal and what is not normal so that people can think differently, so that they can solve the problems better.

[00:26:26] Normal vs Not Normal

Henry Suryawirawan: I think that’s also another key trick of this Gemba, right? You don’t just go and give people orders, but you actually give them the orientation and support. So, which is another thing that you mentioned, right? So about these normal conditions, you know, what is normal, what is not normal, maybe if you can elaborate a little bit more, right? So, how can people understand much, much better what is normal and what is not normal, so that they can actually raise the question or the escalation to the leaders, right?

Catherine Chabiron: You’re pointing at a really key issue in our complex world, because if we don’t know what’s normal versus not normal in terms of value for the customer, in terms of time spent on the task, in terms of quality of what we’re producing, of course, there’s no reason why we should alert and get help. Because we don’t figure we are in an abnormal condition and we continue our work. And this is where the customer starts waiting or this is where the customer starts getting bad quality, because we have no clue what good quality or bad quality is. And the whole Lean journey is to try and define at each step, everywhere, every time, in each team, what normal versus abnormal conditions are.

And you mentioned Gemba. Gemba is really not giving solutions. It’s asking questions about the conditions. Do you understand whether those are normal or abnormal conditions? Is there another way of doing it? Have you thought about it? It’s really questioning all the time, not giving answers, but pointing out to things that are not clear in terms of normal conditions. In manufacturing, you will find, for example, pictures of what is a good part versus a bad part. In code, you could have the same.

So how do you make it very intuitive and very clear what is normal from not normal? Which means investigating in detail every single task and gesture. So it’s a big challenge. But it pays off fantastically, because when people start seeing the abnormal, they stop pushing bad quality to the next step and they repair.

Fabrice Bernhard: Yeah, no, but on the very practical level, what is interesting is, what is good and what is not good comes from different sources. You’ve got one, which is top leadership saying, okay, this is what we need to achieve as an organization. And so to be on track, this is where we need to be. Then there’s the part which is, you know, what the team decides. So typically, you know, when you’re in tech, it can be like coding standards that the team agrees together. And then there’s the notion of quality which can be partly defined by top leadership, but it’s also very much usually carried by the tech lead.

And I love the example on that of Linux, where, you know, what is the definition of okay code? They call it good taste. And basically the Linux organization is about promoting to the maintainer role, people who really understand what good taste is, whatever that is. And it’s really key, like, you know, defining what okay and not okay is, can be sometimes easy, can be sometimes hard. But it’s necessary or you get like weird organization where people don’t actually know how they contribute.

[00:29:40] Doing More Gemba Walks

Henry Suryawirawan: I think it all makes sense what you just explained, right? But I think the key challenge, still, to what Fabrice mentioned earlier, right? Leaders may not have time to spend for doing all this Gemba. So maybe from your firsthand experience doing this Gemba now for multiple years, what will be your invitation to leaders who hear this episode, right? Why they should do more Gemba walks, like really schedule time or maybe dedicate effort to actually do this Gemba walk.

Fabrice Bernhard: Yeah, I think, I mean, there’s no way you can argue that you don’t have one hour a week in your calendar. That’s one answer. And the other answer is, I was in Japan on a Lean study trip visiting a factory. So I was talking to the CEO of the factory and said, so how many Gembas a week do you do? And he had this really, this kind of face of that, you know, Japanese people can have when they don’t want to humiliate you, but they feel a bit bad. And then he is like, “Hmm, I do 10 minutes every hour.”

And so, I’m telling the audience you can do it once a week. This CEO of a factory was telling me you can do it once an hour. So I, I am like, what? I can’t do every hour. But this is what good looks like. And, you know, companies that really do Lean seriously. So yeah, I, that’s probably my, I’m sharing the experience of I’ve not succeeded at doing it every hour. But we can all probably succeed at doing it at least like once or twice a week.

Catherine Chabiron: I was reading some remark about one of the founders of Toyota, Kiichiro Toyoda, and he used to say, you should, he was talking manufacturing, obviously, but he’s, and he was the engineer designing the cars, but he was very much into the manufacturing plant. And he said, if you don’t wash your hands at least three times a day, once before breakfast, once before lunch, once before dinner, it means you haven’t been in the plant long enough.

For Toyota, and this is what they’re teaching us, it’s a really, really important culture for sales people to come and see how the product is designed, for designers of the product, how it is manufactured and the difficulties that they have created for manufacturing, for manufacturers to check on the delivery and the customer services and so on.

It’s a really, really important value for Toyota. And actually it solves the problem of the everlasting meetings where you, you don’t, you need meetings in the company obviously, but Gemba will eliminate the need for some of them. Because you will be there on the Gemba preventing big issues. Because you’re there, because we’re discussing abnormal conditions, because we’re discussing quality. And therefore the firefighting will decrease or will be, as Fabrice said, segmented. Brought inside the teams. The teams will take care of the problem solving and the firefighting. So no need for big meetings to discuss the consequences of a big issue.

Henry Suryawirawan: Right. So I think we hear both of you loud and clear, right? Do more Gemba walks. Maybe we cannot do just like the CEO of the Toyota, right? Like once an hour, like 10 minutes every hour, he will spend the time with the frontliners. But I think do schedule a time to actually work with your team. So again, the idea here is not to give the solutions, like to understand every details and give the solutions, but actually to maybe ask questions and clarify their thinking, right? If there’s something that we can rectify from their thinking process.

[00:32:59] Obsession With Customer Value

Henry Suryawirawan: So maybe let’s go to some of the Lean principles, right? We have heard multiple times about obsession with customer value. So I think that must be the first thing that we have to cover. So anything that you want to mention about this obsession to customer value, going through Lean principles.

Fabrice Bernhard: I can maybe give, you know, the transition from Agile. I think in Agile, what’s very interesting, you’ve got the value of customer collaboration over contract negotiation. And I think what doesn’t scale is that once you become a larger organization, it’s very hard to get everyone direct access to the customer. And, you know, in Agile, Extreme Programming says, yes, put the customer in the team. But you know, well, how do you do that at scale? And also sometimes the customer is not one leader but multiple leaders. So then you actually need to understand what the different stakeholders want and what is best for them. And I guess, in Lean, you’re saying no, it’s not just customer collaboration. It’s really obsession for value for the customer.

And that has two aspects. Like again, the Gemba, so you can see the small problems and you can problem solve them. And you know, you can encourage the team to problem solve the little problems on the ground. And because you’re always like, you know, on the ground, you start having a really good mental model of what you can achieve and what you cannot achieve. And this is what can actually inspire breakthroughs in terms of value. You can be like, oh now that I see what the teams want, and now because I also like talk to the customers a lot, I started understanding how I could really improve my product. And a great example of this, I think, is Elon Musk, who’s really, really good at both always being on the Gemba, seeing, you know, what are the engineering limits, challenging the engineering limits very hard all the time. And then really being clear on what the outcome is, and therefore coming with the breakthroughs.

Catherine Chabiron: Fabrice’s answer was pretty comprehensive, but we can add the fact that most customers will express themselves with a need. It’s very often the need for a solution. They’ve heard that such and such company or such and such department has done this or used that or bought this software or purchased this app and so on. And they want the same. So they will express themselves in terms of solutions. And the big challenge is really to go back to what the customer actually needs. What is the actual need the customer wants to cover? And this is really a challenging experience because you have to ask questions. You have to try and observe the customer using this product or a similar product and find out what are the limits when using those.

So it’s really an investigation before the sale, which not everybody is ready to do. But it’s so much more effective than when you come and say, oh, you want these solutions. We know those solutions. We’ve done that for so and so, and this brand and so on. You know, the story about pushing solutions with all the brands that have already adopted it. So everybody can do that. But if you start having a real rich conversation with the customer on the usage and the actual need, wow, that’s great. And this is what Lean teaches us is how to go and check the value and understand the value and keep the value all the time.

The reason why we have Kanban, just to mention this word. Everybody has heard about Kanban. But the Kanban is not so much to try and speed up the process throughout the funnel of different features and people. It’s really to keep the customer inside the company, in the team, as Fabrice said. The Kanban is a specific customer need that we need to address. So it tells us, hey guys, I’ve been sitting there 65 days and you’ve done nothing for me. This is what the Kanban is all about. Customer obsession.

Henry Suryawirawan: I think that’s a very interesting insight. So I think for many people who know about Kanban, right? I think they just treat it just a way of, you know, organizing the work, right? You have to do, in progress, done, right? That’s the simplest Kanban, probably. So maybe that’s also a good segue for us to understand about this second principle, right?

[00:37:07] Obsession With Lead Time

Henry Suryawirawan: So earlier you also mentioned about obsession to lead time. And I think Kanban, apart from what you just mentioned, right? Like understanding the customer need that we have to deliver, but it’s also to help us visualize the lead time, right? So tell us a little bit more about this Kanban concept, how we can use it to be more obsessed with the lead time.

Catherine Chabiron: The story we tell in the book is very explicit. They switched from a Kanban exactly as you discussed on the todo list, under work or work in progress, and done. And they switched from that orientation, which was very much output oriented - you know, how fast can we produce - to another one, which was, I have a real customer on my Kanban. I have the dates of his first contact to our group. And I have those Kanbans affected to people in the production cell.

In this case, in Theodo group, a team doing code or doing features or whatever. And I can look at it and say, one, this person in the cell is overloaded. They have too many Kanbans, they can’t make it. Second, this customer has been waiting far too long without the solutions or an answer or feedback. It can help me launch rich conversations with people. What’s going on? Why are we stuck? Have we explored all the solutions? Don’t we have a solution for that customer? What should we say? Did we feedback to him that we’re working on this problem but not being able to deliver as fast as we thought?

The feedback is very important. Customers will tell you. They admit very well that their problem can be complex, but they hate not receiving any feedback about why it takes so long. This is really what this is all about, a discussion in a production cell about what’s normal, abnormal again. Is it flowing or is it not flowing? Are we stuck? Why? How can I help? That kind of thing.

And it’s when we say obsession with lead time, it’s really obsession with the customer lead time. And this is the challenge part for the people. How do we manage a decent lead time for the customer while producing good quality? And this is really what Lean is all about. Creating the challenge with the lead time and working on the quality with what we call Jidoka. We’ll be speaking about those later, I’m sure.

Henry Suryawirawan: Right. So I think that’s the first insight as well that I gathered from your explanation just now, right? So the idea is not to organize work, like knowing how many cards you pick up and you can finish, right? But it’s actually to figure out from the customer lead time point of view, right? Where are the areas where we are stuck, right? Where are the areas where the flow is not going? And also make it visible, by using the Kanban to make it more visible so that the leaders and the team can also understand, oh, there’s something where we should probably look about and resolve the issue so that the flow is not stuck.

So I think Kanban, if you are using it still for, you know, just organizing work, maybe you should dive deeper, right? Like how we can actually make problems more visible. And actually also the customer lead time. Don’t forget about that, right? It’s not about finishing the task but also delivering the customer value.

[00:40:25] Jidoka & Andon

Henry Suryawirawan: So you mentioned about Jidoka. I think some people also are very interested about this concept. Some people might have heard about Andon, right? The concept of Andon. So tell us more about this and how should we use it in our day to day life.

Catherine Chabiron: I’ll just give a short introduction. The word Andon is extremely used in Theodo. They’ve actually turned it into a verb. They say, hey, Andon me, or did you Andon me? The concept of Andon initially on the manufacturing line is just pulling a chord to tell somebody that there’s something wrong. And the concept was really to stop the line. Imagine a continuous line in a plant, in a car making factory. This is a very new concept, because before Toyota, when we had a quality issue, the front line operator would just write down on a piece of paper, hey, there’s a problem here, we didn’t install the windscreen correctly, so check it at a later stage. The Toyota way is, we stop the line now and then to understand why we can’t set up the windscreen, and in the end, they have very limited repairs at the end of the line, because they have addressed the problem all the time.

So in the digital or tech world, what does it mean? It means that if I can detect any abnormal condition that we were discussing before: bad quality, long lead time, don’t understand the feature, don’t understand the value we have to bring to the customer, don’t understand what we’re trying to do here. Too late, can’t make it. I don’t understand the technical gesture I have to make. By Andon, in the tech world, it’s just calling somebody on the phone, on the messaging app, whatever. But calling for help now and then so that we can see the problem immediately. Fabrice, I’m sure you have plenty more to add.

Fabrice Bernhard: I think in a tech environment, Jidoka, which means right first time, and which includes the concept of Andon. You could summarize it by saying, okay, I want to detect defects as early as possible. And so that’s one big idea we’ve implemented at Theodo is to say, okay, we’re going to categorize defects by stage of detection. So the last stage is when the customer is complaining. That’s stage E. When you found it in production before the customer complained, that’s stage D. When you found it during, you know, Q&A or the product owner, so let’s say the internal customer, stage C. When, you know, somebody else in the team found it, so like, you know, CI/CD, code review, so that’s stage B. And we’ve even introduced stage A, is when you as a dev, you coded something and it didn’t work out as expected.

To make it like very clear, what we say is you are allowed one refresh in the browser or in the phone simulator. And if it doesn’t work the first time, so you’re allowed TDD, you’re allowed to do test driven development. But what you’re saying is if it doesn’t work at the first time I tried it in the browser, then it’s a defect. So that’s the idea like. Learning to detect defects as early as possible so that you can actually track the number of defects. And your goal is not to hide defects, but really to try to increase the number you detect very early.

So detection in Jidoka, so to do right first time. And the second is, indeed, when you have a defect, Andon. So asking for help if you need help. Really not hesitating to ask, you know, your tech lead, or, you know, escalating even more when there’s issues you don’t know how to address.

Henry Suryawirawan: Wow! It’s a really fascinating concept when I read this A, B, C, D, E stages, right? So I think the way you classify and categorize where do you actually find the bugs or the defect. And try to actually minimize the D and E stages and try to push it, maybe like people call it shift left, right? Where you can detect the issues and problems early as much as possible.

[00:44:16] Built-In Quality Right First Time

Henry Suryawirawan: So I think this goes back to understanding what is quality, right? Like I’m sure we have a big team. Not everyone has the same idea of quality, right? And in Lean, I think you mentioned the right first time or maybe built in quality, right? How can we actually spread the same understanding of quality amongst the team. And what does it mean by built in quality and right for the first time?

Fabrice Bernhard: Well, it’s, it’s interesting, but I think the biggest resistance when you define quality or rather when you define a defect is, you know, usual human behavior, so defensiveness. So I’ll give you an example I love. A customer complains because there’s a button and the button says login. And that customer doesn’t speak English so he’s like, what does that mean? And so you go to the dev team and you say, there’s a bug because, you know, we left the login word for the login button. And it should be, you know, translated. And the dev team was like, that’s not a bug. Our responsibility is not checking that every word gets perfectly translated, etc, etc. So that’s the defensiveness.

So the answer is it’s not a bug because it’s not us. And one thing I’ve learned is to really say it is a bug, because it is a non-met expectation for the customer and for the user. But let’s be clear that it’s not a dev bug. It’s a content bug, for example. And then you can agree, once you say, okay, there’s different like sources of bugs. You know, you can have an issue on the content, you can have an issue on the production servers, you can have an issue on the dev side. But as soon as the customer has like a quite clear unmet expectation, then let’s call it a bug. And that’s how we managed to agree on this definition.

Henry Suryawirawan: Yeah, I think it’s a very simplified way of defining quality, right? As long as you don’t meet customers’ expectations. So coming back to the customer value, right? You don’t meet their value. I think you can call it a bug regardless, you know, like how do you classify the bugs, right? I think that is very, very important. And I think another important stuff that I picked from the book when I read that part about quality, right? So I just read it here, “The team should not accept bad quality from upstream. They should not create defects in their own work. And they should not pass low quality items along downstream.” So this is like an extreme way of really defining quality. You don’t accept from the source, you also don’t introduce low quality, and you don’t pass it to the downstream as well. So I think if everyone aspires to do this, I’m sure the kind of quality that you produce will be really, really high.

[00:46:39] Kaizen

Henry Suryawirawan: So another important aspect of Lean is actually about people, right? So I think trust is one big thing. The second thing is about people growing and learning every day. So there’s this thing called Kaizen, which I’m sure some people would also have heard about this concept. So tell us more about what is this Kaizen all about? How do you actually implement that in Theodo so that maybe people are more engaged and, you know, much more thriving in their behaviors and they want to improve both personally and also for the company?

Catherine Chabiron: Maybe a bit of explanation from the Lean point of view. Kaizen is the heart of the fun at work. If you are simply in execution all the time and you never change anything and you never think about what you do, your job is pretty spiritless and not very interesting. Before Kaizen is just, first, make sure that all the systems work and people have the tools to work and so on. Once we’ve got that, we’ve got the basics, people have the tools to work, they have understood the customer value that we discussed, they are put under tension through the lead time, and they are given the right ways of understanding what’s normal from abnormal, then they can react to abnormal, and not only Andon their boss or their team leader, but be part of the solution. Be part of the problem solving. Therefore, learn from the problem solving and the exploration.

And this is what the Kaizen is all about. Kaizen is really trying to improve all the time. It’s a mindset first. Try to improve all the time on any little things. And I remember discussions with Fabrice and Benoit, the other co-founder of Theodo. They wanted the Kaizen to be something to help to add value to the customer. They were looking at customer problems initially. And it turned out that the first Kaizens that the team did is improve situations for themselves. They created Kaizen first on the tools and the conditions in which they were working. And then they were able to focus on the customer and do Kaizen for the customer value. But it’s key for the fun.

Fabrice Bernhard: Yeah. I love Catherine’s point about fun. One definition I was given about Kaizen, which I think works really well for software engineers is, what you want is to be in a state of flow. And Kaizen is all the efforts to address the issues when you’re not in flow. So you want to be, as a developer, you want to be in a state of flow, and every time you’re not in a state of flow, you’re like, there was like something that blocked me or stopped me. Let’s do Kaizen to improve that situation. And very concretely speaking, at Theodo, you can do Kaizen whenever you want. But to make sure that teams really take a step back, we organize one day workshops with somebody who’s got a lot of experience acting as a facilitator. And going through a framework called a six step Kaizen framework where we look at the problem.

So it can be like a tooling thing. Like for example, CI is too long. You know, I don’t know why Continuous Integration takes 20 minutes. Could we get it to like 10 or five minutes? And then, you know, using the six steps, analyze all the potential issues and really think about new ideas. But what is very important in the Kaizen, the goal is not the improvement, but it’s also like the learning. Usually when a team does that, it’s not because there’s a easy quick win. It’s because some very complicated things are happening under the hood and, you know, they take that time to really understand it. Better understand the frameworks. And, you know, the project complexity, etc.

Henry Suryawirawan: I really like the way you mentioned that Kaizen is all the things that you do to actually improve the flow, right? So I think based on the recent paper as well, right? Developer experience, developer productivity, flow is definitely one of the key attribute where we should optimize. So I think doing Kaizen, like embodying Kaizen mindset means like you do everything that you could to actually improve the flow for the team and also for the individual, right?

And I think another thing is when you have created this fun environment, right? You actually make the work interesting itself. So just like what Catherine mentioned, you don’t just execute, execute just for the sake of, you know, finishing the task on achieving the company’s target, right? But actually you also make it fun, right. You learn through the process. And you actually figure out something that you could improve all the time. I think that’s also another key that I learned.

So, uh, as we go to the end of our conversation, is there anything that you want to highlight from, you know, Theodo’s journey about implementing Lean? So if there’s something, I don’t know, like fun fact or trivia or anecdotes that you want to share with us.

Catherine Chabiron: There’s one thing I can say about Kaizen and making the job people easier. Fabrice mentioned earlier the login feature. When you develop apps, the login feature is the recurrent, the most recurrent feature. Everybody starts with a login. And one of the things they’ve done to help people work in the flow is to actually find a standard approach to login. Before, everybody was reinventing the wheel on the login part. And they have now designed a standard approach. They call that enablers. You know, things that facilitate the life of the people. So, they do have technical standards that they develop because they know it’s a recurring feature and it will save people time to have something to start with, rather than a blank page. A blank page effect is terrifying sometimes.

Henry Suryawirawan: You have anything?

Fabrice Bernhard: No, but you were asking about the highlights. I think clearly going on the Gemba is the one highlight I will insist on.

[00:52:19] 3 Tech Lead Wisdom

Henry Suryawirawan: Right. So yeah, let’s go to the next section whereby I will ask you this question that I have to ask for all my guests, which is to share what I call the three technical leadership wisdom. So you can think of it just like, you know, advice that you want to impart to the listeners here so that we all can learn from you. So maybe, I don’t know, how do you want to structure this? I’ll leave it up to you. Maybe you can share your version of three technical leadership wisdom.

Catherine Chabiron: Maybe I can start with one is, in the book we tried, number one, not to discuss Lean, but to discuss business situations. Like how do you get new customers and how you retain them? How do you get new employees and you retain them? How do you try and use the customer lead time obsession to create tension and customer visibility inside your teams? How do you remain on the technical edge? So, all those questions that are key in any tech business are addressed by Lean. And Lean is a framework to understand what the next step is.

And in addition to that, the customer focus on the value all the time will bring you more turnover. The focus on the Andon that we discussed – Not passing bad quality, not receiving bad quality, and so on – this is the best way to reduce your costs. Because most of your costs are coming from bad quality, reworks, penalties for delivering a bad product, and so on. And just-in-time is the best way to actually make the best of your assets.

So it’s true in manufacturing, how do you make your machines flexible? But in a tech world where your assets are people, how do you make the most of your people as assets, to deliver fast and to deliver right the first time? So all those are ways to make more money in a sustainable way and to grow efficiently. And this is really important. This is not a book about tools. It’s a book about building a sustainable future for your company and how Lean helps you doing that.

We discussed Andon and abnormal conditions for the CEO, CTO, for Fabrice and Benoit, and all the team leaders. It’s a perfect way to understand where the organization is stuck. All those Andon pulls will tell you exactly what the company doesn’t know how to do. You know, where we’re stuck in terms of feasibility, technicity, capability, and so on. So it’s a very interesting mapping of your problems. And this is why both Benoit and Fabrice are very much onto the Andon thing and the problem solving, because this is where they’re stuck, and this is what they need to address.

Fabrice Bernhard: I think, you know, the tech leadership wisdom, I think your objective and when you’re in tech leadership is to grow your teams to make better products. And I think the lean tool to do that, I hope I’ve insisted enough, is really Gemba. Gemba, both on your teams, to like see their working conditions, and you mentioned it, not to micromanage them, but really to ask questions, observe the conditions. And therefore, you know, be there to help them when they need it. But also Gemba at the users and customers to really understand how the product is built. And then connecting both to, you know, grow your teams on one side. But grow them on the challenges. Encourage them to think harder about the challenges that the users and customers are having.

Henry Suryawirawan: Right. Thank you so much for this joint effort for the wisdom. So I really love all of that. So if people want to connect with you or learn more about Lean and maybe Theodo journey, is there a place where they can reach out online?

Catherine Chabiron: They can reach both of us on LinkedIn. I think this is the most efficient way. And of course, they can read the book, because they’ll understand much more of what we’ve tried to explain today with the book.

Fabrice Bernhard: LinkedIn and Twitter. I’m @fabriceb on Twitter.

Henry Suryawirawan: Right. So I think I find the book really, really interesting and insightful. So for people who are interested to learn more about Lean, I think it’s a good resource where you can actually learn from a real practical use case, right? Not just theory, but also practical use case how this gets implemented in a software consulting company, right? So I think that’s very interesting as well.

So thank you so much Fabrice and Catherine for your time. Really enjoy this conversation and learn a lot about Lean today. So thank you again for that.

Fabrice Bernhard: Thank you for having us.

Catherine Chabiron: Yes, thank you. That was fun. That was interesting.

– End –