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 understanding of what the customer is doing with
our products. And this is how it leads to the
education system, because if you want to have people think you
Start learning from your solutions or from the problem
solving. Hey everyone, my name is Henry
Surya Virawan and you're listening to the Technique
Journal Podcast, the show where I'll be bringing you the
greatest technical leaders. Practitioners and thought
leaders in the industry to discuss about their journey,
ideas and practices that we all can learn and apply to build a
highly performing technical team and to make an impact in your
personal work. So let's dive into our journal.
Hello again to all of you, my TLJ listeners.
You are 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 Techlegional dot Dev
Tip or becoming a patron at Techlegional dot Dev Patron.
My guests for today's episode are Catherine Chalbiron and
Fabrice Bernhardt. Catherine is a lean expert and
the co-author of Learning to Scale at Theodu Group, while
Fabrice is the cofounder and CTO of THEODU.
In this episode, Catherine and Fabrice shared their lessons
learned from implementing Lean at a fast growing scale up
company and that is Theodu. Catherine and Fabrice first
started by sharing the Big Company Disease challenge and
how Theodu 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 talk about lean
practices adopted from the Toyota Production System that
include Gamba Jiroka. Ron, Don, and Kaizen.
Along the way, Katherine 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 5 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. Hello everyone, Welcome back to
the new episode of the Techni Journal Podcast.
Today I have Catherine and Fabrice.
Today we're going to discuss about Lean, specifically how
Fabrice's company Theodu Group implemented Lean during their
fast growing scale. So yeah, really looking forward
for this conversation. Thank you so much for the time
here. Great.
Welcome. Thank you for having us.
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. 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 and this is where I met
lean because the automotive industry could not try and do
what Toyota is was doing because they really showed us another
way of doing productivity in in manufacturing but also in
innovation. It's not just manufacturing,
it's also how they they address innovation as well.
So I was in the Automativity equipment.
I discovered Lean, 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. And my name is Fabrice
Bernhardt, so I'm the Co founder in city of Theodore.
I start 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 Benesley lived when he invented
the World Wide Web. So I got very early access to to
the World Wide Web. Fast forward, I studied computer
Science at university and met Benoit, my Co founder.
And we launched our first start up called anomatch.com which was
the website to find all the pubs, cafes and restaurants
where you can watch sports. So that was our first start up,
a product like typical Internet product start up, it was a lot
of fun. We reached break Even so that
was that was really cool. But we also realised that the,
you know in terms of ambitions it was limited.
So we created a second company called Tsiulu which is a company
we're talking about today, so a 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, York and Casablanca. This episode is brought to you
by Miro. As you will learn in this
episode later about Lean methodology.
One of the core principles of Lean is about visual workflow
management. You may have heard techniques
such as value stream mapping and Kanban.
Although there are maybe plenty of tools available that support
these techniques. One tool I find that allows us
to do awesome visual workflow management and to do so in a fun
and collaborative way is Miro. Miro At a first glance, it might
seem just like a simple digital whiteboard, but Miro's
capabilities run far beyond that.
It's a visual collaboration tool where the whole team can build
on each other's ideas and create something innovative together
from anywhere. Brainstorming and strategic
planning becomes easier when it's visual and accessible, and
it all can happen across teams. In Miro, you can quickly start
collaborating within 90 seconds without having everyone
registered as a mirror user before.
There are also more than 300 predefined templates you can use
to kick start your collaboration within seconds.
So the next time you're looking for a digital tool to support
your visual workflow management, brainstorming, planning, and
online collaboration, do give Mirror a try.
You can Sign up today at mirror.com Podcast miro.com
Podcast and your first three mirror boards are free forever
when you signed up now. And now let's get back to our
episode. Thank you to both of you for
sharing your journey, right. I think 1.
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 the Theodo Group perspective, right,
like 15 years, that's a pretty long journey for a company.
And today we're gonna 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 1st 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?
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 IDs. The the number one ID is
eventually when you grew you grew complex so you will import
in your startup CTOSCOSCIOSCFOS and so on.
Each of them are needed for the expertise, but they will build
silos and eventually they will try to improve their own silo of
expertise to the expense of teamwork.
The the first symptom will be that you will be defending silo
than teamwork. The 2nd is as the complexity
grows and families 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. In other words, we will promote
people who are very compliant with our rules and processes and
we'll 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 dispend on. That's roughly the story about
the big company disease. Right.
So I think maybe from Fabrice point of view, right, I'm sure
you have gone through this stage where you think they'll do is
having this big company disease, right.
So tell us more at that point in time, what was the challenge
that you actually encountered and what makes you think this is
a problem that the company should try to solve and hence
you will try lean afterwards? Yeah, I think to understand.
My journey and the journey of Theodo like a big turning point
is 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 the bureaucratic environment, you know, that
stifles innovation. There is risk of us and you know
where your creativity is not welcome.
So we start our own start-ups, Anna Manche and then Theodo, and
we realised that actually very quickly.
When you start having quality issues, the, the standard way of
dealing with them is adding processes in Yara Key.
So we're like, wow, with a small company and we're already back
to square ones. This is not OK.
And so the turning point is we get so frustrated by this that
we think, OK, 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 it's OK, we're going to try Agile.
Buy 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 it and it was a game changer like really
doing Agile in the 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 and we could really scale all of a sudden
horizontally because for every new project.
We could have fully empowered agile team working directly with
the client embedded in the team and it just worked.
You know, I before that I used to be the chief firefighter as
the CTO who is 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. That was really the first game
changing moment and I think what happened very quickly after that
is we were like OK. 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 realised that you know
if you just try to implement Scrum on very large projects or
even was at like the whole company scaling level, you
realise 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 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 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. It's very, very interesting what
you mentioned, right. So you have tried Agile fully
and it work really, really well at the team level.
But when you try to scale it at the company level, although
these days 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?
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 will 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?
Or maybe just to conclude on on that experience, I think Agile
is amazing. Let's be really clear.
Scrum and Extreme Programming. Which for me are like the two
mythologies we 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
flavours 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 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 to, you know,
adapted 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 to
the 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
realise 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 like they, they start having
quality issues and he realises that, you know, the way he did
quality at Apple was like not very scalable.
And so he hires Duran to help him.
And Jurin is one of the founding professors that influenced
Toyota in the 50s. So you realize that Steve Jobs
actually had first level source of lean and that really
influenced him. And he does a video of him like
sharing how much it's influenced him and he 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 there's this amazing
book called Working Backwards and there's this clear anecdote
that in I think 99, two thousand 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 Marco Leto to really deploy lean at scale
in their 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. Maybe a little point that I can
add. Agile stems from Lean.
It picked up a number of the concepts of Lean for good
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 you develop engagement and then you can take care of
your customers. So there is a whole framework
which we're trying to explain in the book how Fyodor is using
this original lean framework. Maybe we'll go through some of
the items later. 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 encounter 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 is 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, maybe I can try and
outline a few items. Why we say it's thinking people
system. And I'm pretty sure if I always
will elaborate on that is again the underlying assumption that
you will not be as efficient if only 10 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 grew.
Nowadays all the big companies tend to promote execution.
We want 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 ID and it's a
big, big difference versus what we see elsewhere.
Somebody's here, you may want to elaborate on it.
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 to lean is to
leverage the talent of everyone in the organization, because the
idea is better thinking by everyone will lead to better
products or customers. 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 Theodore and doing a number of
what we call gamba visits, visits on the field with some
key people. And there was one of the guys
told me of a story. He had a city of one of the
entities of them, 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 so well.
He was losing or wasting a lot of time doing so.
So the CEO could have come and told him, OK, there's this guy
here, 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 spend 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 is raising questions on
what's normal, not normal, and making them think about it.
Well, I think that's a very good example as an illustration,
right. And you also mentioned this term
called Gamba. So when I read your book that
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 Gamba or Gamba walk?
So maybe that we can all learn about this important concept.
I'll just give the definition and then I'll let fabulous
answer this. So the Gamba in Japanese, we
keep using this term because it just means the place where the
things happen and more particularly the front line
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 Theodore, it can be a place where we are handling
your invoices, or dealing with customers, or answering customer
calls and so on, say from line areas where things happen to
produce value for the customer family.
So I'm sure you want to elaborate.
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, 1213 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 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. You're like what does take too
much time and too much money and just, you know, walking and and
going to see. But there is a lot of like,
issues and reasons probably not not to do it.
But anyway, the point is Gamba 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 as having this very
regular discipline of saying, OK, 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?
Yeah. So if I understand correctly,
right, so Gamba 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 Katherine,
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.
I think that's also another key trick of this game bar, right.
You don't just go and give people orders, but they 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? You, you, 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 a normal condition and we continue our
work. And this is where the customer
starts waging or this is where the customer starts getting bad
quality because we have no clue what's good quality or versus
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 GIMBA. GIMBA is really not giving
solutions, it's asking questions about the conditions.
Do you understand whether those are normal or normal conditions?
Is there another way of doing it?
As you thought about it, it's really questioning all the time,
not giving answers but pointing out two things that are not
clear in terms of normal conditions in manufacturing.
You will find for example pictures or what is a good
palette, dresses and bad parts encourage.
You could have the same. So how do you make it very
intuitive and very clear what is normal from the 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.
Yeah, no. But on a 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, OK, 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 quantity, 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 OK code.
They call it good taste. And basically the Linux
organization is about promoting to the maintain a role.
People really understand what good taste is whenever that is.
And it's really key, like, you know, defining what OK and not
OK 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. 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 game bar.
So maybe from your first hand experience doing this game bar
now for multiple years, what will be your invitation to
leaders who hear this episode right?
Why they should do more game bar walks like release schedule time
or maybe dedicate effort to actually do this game bar work.
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, oh, so how
many game bars a week do you do? And you 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 he's like, I do 10 minutes every hour.
And so I'm telling the audience, you can do once a week.
This CEO of factory was telling me you can do 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 are really dirty.
And 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. I was reading some remarkable
one of the founders of Toyota, Kiichiro Toyota, and he used to
say you should. He was talking manufacturing,
obviously, but he's he was the engineer designing the cars, but
he was very much into the manufacturing plants.
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 plants long enough
for Toyota. And this is what they're
teaching us. It's a real, really important
culture for sales people to come and see how the product is
designed for designers of the product, how it is manufacturers
and the difficulties that they have created for manufacturing
for manufacturers to check on the delivery and the customer
services. And so it's a really, really
important value for Toyota and and actually it solves the
problem of the the everlasting meetings where you you don't,
you leave meetings in the comedy obviously.
But Gamba will will eliminate the need for some of them
because you will be there on the game by preventing big issues,
because you're there because we're discussing abnormal
conditions, because we're discussing quality.
And then therefore the firefighting will decrease or
will be as if I was said segmented brought inside the
teams. The teams will take care of the
problem solving and the fire fighting, so no need for big
meetings to discuss the consequences of a big issue.
Right. So I think we hear both of you
loud and clear, right. Do more gamble works.
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 front liners.
But I think do schedule a time to actually work with your team.
So again, the idea here is not to give the solutions, right, 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. 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? 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 how do you do that scale.
And also sometimes a customer is not one leader but multiple
leaders. So then you actually need to
understand what the different stakeholders.
Ones 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 gambal, so you can see
the small problems and you can problem solve them and you know
you can encourage the team to 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.
It 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 And both always being on the Gambo,
seeing you know what all 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.
So this 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 have 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 that 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 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 willing 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, 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 is worried about Kanban.
But the Kanban is not so much to try and speed up the process
throughout our our funnel of different features and people.
It's really to keep the customer inside the company, in the team.
That's what we 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.
I think that's a very interesting insight.
So I think for many people who know about Kanban, right, I
think they just treated 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.
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.
And the story we tell in the book is very explicit.
They switched from Accountban exactly as you discussed on the
To Do List and the 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 account
ban. I have the dates of his first
contact to our group and I have those kin bands affected to
people in the production cell, in this case in field, a group
A-Team doing code or doing feature and so whatever.
And I can look at it and say one, this person in the cell is
overloaded, they have too many kin bands, 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 ship back 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 stunned?
Why? How can I help that country?
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 Jedoka.
We'll be speaking about those later, I'm sure.
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
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 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.
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?
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, he handled me or did you handle me?
The concept of handle initially on the manufacturing line is
just putting a cord to tell somebody that there's something
wrong and the concept was ready to stop the line.
Imagine a continuous line in a shop in a car making factory.
This is a very new concept because before Toyota, when we
had the equality issue, the the. From line operator, we just
write down on a piece of paper, hey, there's a program here we
we didn't install the windscreen correctly.
So technically at a later stage, the Toyota way is we stop the
line now and then to understand why we called Syllab the
windscreen. And in the end they have very
limited repairs of 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 my abnormal conditions that we were
discussing before bad quality, long lead time don't understand
the feature. I don't understand the the value
we have to bring to the customer.
I don't understand what we're trying to do here too late could
make it don't understand the technical gesture I have to
make. I am done in in tech world it's
just. Calling somebody on the phone,
all the messaging app, whatever, but calling for help now and
then so that we can see the problem immediately.
Family. So I'm sure you have plenty more
to add. I think in the in the tech
environment Jidoka which means the right first time and which
includes the concept of random. You could summarise it by saying
OK, I want to detect defects as early as possible.
And so that's one big idea we've implemented at Theodore is to
say, OK, we're going to categorise 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 complaints, that's stage D when
you found it during, you know, Q&A or the product owner.
So let's say the Intel customer, Stage C when you know somebody
else in the team found it. So, like, you know, CICD code
reviews. That's Stage V.
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're 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
I try it in the browser then it's a 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 2nd is indeed when you have a defect,
I'm done. So asking for help, if you need
help, I'm 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. Wow, it's a really fascinating
concept when I read this ABCDE stages, right.
So I think the way you classify and categorize, where do you
actually find the box or the defect and try to actually
minimize the D&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.
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?
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 behaviour, so defensiveness.
So I'll give you an example I love.
A customer complaints 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 deaf 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 deaf team was like,
that's not a bug. Our responsibility is not
checking that every word gets perfectly translated, etcetera,
etcetera. So that's 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 an unmet 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 OK, 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 manage to agree on on this definition.
Yeah, I think it's a very simplified way of defining
quality, right, As long as you don't meet customers
expectation. 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. So another important aspect of
lean is actually about people, right?
So I think trust is 1 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 Theodore so that maybe people are more engaged and much
more thriving in their behaviors and they wanna improve both
personally and also for the company?
Maybe a bit of explanation from the lean point of view, the
Kaizen is hearts 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 and not 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.
So 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 and on their boss
or the 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 ready try to improve all the time.
It's a mindset first, try to improve all the time on any
little things. And I remember discussion with
families and Bruno, the other Co founder of Theodo.
They wanted 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
Kaizen 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.
Yeah, I love Katherine'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 the state of flu, and Kaizen is all
the efforts to address the issues when you're not in flu.
So you want to be as a developer, you want to be in the
state of flu. And every time you're not in the
state of flu, 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
Theodore, you could do Kaizen whenever you want.
But to make sure that teams really take a step back, we
organise 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 5 minutes and then you know, using
the six steps, analyse all the potential issues?
And really think about new ideas.
But what is very important in the guys end, the goal is not
the 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 and better understand the frameworks
and you know the project complexity etcetera.
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 just for the sake of
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 learn.
So as we go to the end of our conversation, is there anything
that you want to highlight from, you know, Theodore 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. There's one thing I can say
about Cajun and making the job people easier.
Fabulous mentioned earlier the login feature.
When you develop apps, the login feature is the recurrent the
most recurrent feature. Everybody starts with the login.
And one of the things they've done to help people work in the
flow is to actually find a a standard approach to log in
before everybody was reinvented the wheel on the log in part and
they have now designed standard approach, they call that
enablers in the things that facilitate the life of 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 you have anything. No, but you you were asking
about the highlights. I think clearly going on the
Game Bar is is the one highlight I will insist on.
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. Maybe I can start with one is in
the book we tried #1. 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 you try and use the customer lethal
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 end on 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 adjusting 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 the tech world where your
assets are people, how do you make the most of your people as
assets to deliver 1st 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 undone and abnormal
conditions for the CEOCTO, for Fabrica and Renoir and all the
team leaders. It's a perfect way to understand
where the organization is stuck. All those and on pools will tell
you exactly what the company doesn't know how to do, you know
where 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 Boris Bernal and
Farris are very much on to the end on thing and the problem
solving, because they this is where they're stuck and this is
what they need to address. And 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 gamba, gamba booths on your teams to like see
their working conditions. And you mentioned it not not to
micromanage them, but really to ask questions, to observe the
conditions and therefore you know, be there to help them when
they need it. But also came back 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, 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 Theodore Journey, is there a place where they can
reach out online? They can reach both of us on
LinkedIn. I think this is the most
efficient way and and of course they can read the book because
they'll understand much more what we've tried to explain
today with the book. LinkedIn and Twitter.
I'm Fabris B on Twitter, 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 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 Katrine for your time.
Really enjoy this conversation and learn a lot about LEAN
today. So thank you again for that.
Thank you for having us. Yes, thank you.
That was fun. That was interesting.
Thank you for listening to this episode and for staying right
until the end if you highly enjoyed it.
I would appreciate if you share it with your friends and
colleagues who you think would also benefit from listening to
this episode. And if you're new to the
podcast, make sure to subscribe and leave me your valuable
review and feedback. It helps me a lot in order to
grow this podcast better. You can also find the full show
notes of this conversation on the episode page at Technically
journal dot dev website, including the full transcript,
interesting quotes and links to the resources mentioned from the
conversation. And lastly.
Make sure to subscribe to the shows mailing list on
technojunnel dot dev to get notified for any future
episodes. Stay tuned for the next
Technojunnel episode, and until then, goodbye.