Regis Medina - Entraîner les Avengers - Oubliez tout ce que vous savez sur le management tech (FR)

[00:00:05] So, where I come from, I graduated in '95. So I'm an engineer, programmer. And I entered the working world with a quite violent encounter regarding what a software project's reality is. The first year, actually, of work for me, I did 50 days of weekends and public holidays, all told. I lived the moment when I arrive on Monday morning at 9 am, I leave, I finish my day on Tuesday at 5 pm, after having coded all night to fix bugs. And so, it won't always have been as violent as that. But roughly speaking, it made me see right away this challenge we have, which is how do we do quality while going very, very fast? So, therefore, it's as an old fart that I'm speaking to you. And what I what I, I keep staying in the tech world. And what I've seen is that the only thing that has changed since that time is the form and size of screens. So, the reality, in fact, of development is always, in fact, we don't have time, we don't have time. We have to go fast, we have to go fast, we have to go fast. We don't have time, we'll do quality later. Does that speak to you? Vaguely? And it actually creates a kind of dynamic that I modeled like that, that I modeled in my head at least very, very early on. Which is, in fact, we start, there's a new project. So it's great, it's a new team, it's a new technology, we start on a clean slate, it's really going to be a joy. Then we build, we build, we're very, very happy with what we're making. And then at some point, we start telling us, "Well, yes, but now, guys, you're nice, but you'll have to accelerate." And then we'll have to accelerate. And then, well, listen, we don't have time to do it cleanly, it has to come out. Does that speak to you? And suddenly, well, we have to take shortcuts. And then it's okay, we'll do it cleanly later. And what happens is that, well, we're in trouble. There are some old timers who start to leave. Since it's going too fast, we recruit, we bring in a lot of devs who don't understand anything in the team. Does that speak to you? Yes? And at some point, we end up with a rotten codebase. The good news is that... those who had initially conceived it have left. And a moment will come when someone will say, "Listen, regarding this, it's an old technology, you understand, we should restart." There. So I spent, I'd say, the first 12, 15 years of my career feeding on that. It's a bit cynical, but I'll come to it. But I always wondered, can't we do a little better?
[00:02:39] And, and broadly speaking, it's a subject of research for me for 27 years, so it's been 27 years that I've been sailing IT projects. I've seen a few. And what I did is that over the course of my career, at the beginning it was a stroke of luck, now it's really deliberate. In fact, I set white stones to show my level of understanding that was evolving. So I'm going to quickly tell you about my journey to explain how I got there. There was a whole phase of extreme programming, so I was one of the first three or four French people to discover it in the late 90s. And I lived at that time, well, in that period, I did my first XP project, I'd say, maybe in 2000. And I lived a little later, you know, the moment when we coded a small thing, there were three of us. Suddenly, the big bosses say, "Well, there's all this to do, how much does it cost?" We send the estimates, and the next day it comes back saying, "Listen, it's simple, you have to be 22."
[00:03:41] So I lived the moment when we are three in the team at the end of the year, at the end of December, and we are 22 in mid-March, with half of the developers, by the way, who have never coded. And so I went very, very far in this understanding of what later became agility, but which I had taken from a technical angle. Until I realized that at some point, having tech teams that work was vaguely feasible, but that the real problem was the rest of the company. That is, it's useless to have a team of devs who are great. If we, we don't talk to the client, if we don't understand the needs, do you see what I mean? And that thing meant that around, I would say, around 2007, 2008, I made a deliberate decision to do control alt sup and to get out of tech to go see elsewhere. And going to see elsewhere, actually, I had met people at the time who were very interested in Lean. And I made the decision to explore Lean within a consulting firm. I had to follow closely or from afar, I don't know, 100, 150 improvement projects, as a Lean consultant, you know, with the tie, the suit. And initially, what I imagined was that Lean was a slightly better agile. And I was looking in Lean... a slightly more universal recipe that would allow me to do agile everywhere in the company. Agile in sales, etc. After that, I went through a phase where I thought it was a process or a mechanism for process improvement. And the slap I took at that time...
[00:05:27] And to understand where the slap comes from, my mission, in fact, was to constantly go back and forth between the IT professions, all the IT professions, support, maintenance, data centers, projects, and to go back and forth between that and what I call today hardcore Lean a la Japonaise, that is, going to the bottom of what Toyota did.
[00:05:46] To try to understand what we could learn from that world that had nothing to do with tech. I think I first stepped into a factory at 38. But I was constantly going back and forth to understand what we can learn from these people. Because in fact, initially I thought they were in our past, and more and more now I'm convinced that these people are in our future, for us who are in tech. And the slap I took was to understand that Lean is not a way to improve processes, it's not a continuous improvement method, in fact, it's a personal practice. It's a personal practice for the leader. And that's something I described in a book called Learning to Scale. And at the time when I started to do Lean, it was really projects in big companies. And in that journey where I understood that it was a method for people, what I realized, what I was taught too...
[00:06:40] is that Lean is a practice for the leader. There is one person who does Lean in the company, before all the others, it's the leader. I'll come back later to what that means. So that's what I documented in Learning to Scale, which is a kind of book of the method. The next step was to understand, that was two or three years ago now.
[00:06:58] To understand that this method is not a method, it's not an improvement of processes, it's a personal practice, but in fact beyond that, it's a new business model. And it is for me and for my co-authors, the only credible alternative model to the financial terrorist model that is wiping out all our companies and which makes us all trying to flee big companies to take refuge in startups, which, when they become scale-ups, are eager to become big companies again. and which make it so that, well, all of us are trying to flee big companies to take refuge in startups, which, when they become scale-ups, are eager to become big companies again. Do you see? And so the idea is to, so that's to learn, to learn with Lean, is to understand that, in fact, there really is another business model that is possible. The next step was to work with people to really do it, so I've been doing that since 2016. I'm not the only one, I'm part of the France Institute, there are several of us who practice that and try to carry the torch. I'm not the only one, I'm part of the Lean France Institute, we are several to practice that, try to carry the torch. We wrote, we published not too long ago a book called Raise the Bar, which is actually, it's the two founders of Aramis Auto, Nicolas Chartier, Guillaume Pauli, who tell their adventure and who tell their appropriation of this management method, but really from the point of view of the whole company. We're talking about a real company, a company that went public not long ago, which makes over a billion in revenue.
[00:08:15] So there's a trick in Raise the Bar, in the title. In the same way that there's a trick in Learning to Scale. And it will help me for what follows. The trick in Learning to Scale in the title is that we often imagine that it's I'm going to learn how to scale. And in fact, no, that's not at all the intention, it's the learning, it's the learning that is a lever for scale. And so the question of how I grow, how a company grows without becoming a big rotten company, is that we manage to maintain living learning. What big companies do is that they kill learning because they try to put everyone in small boxes. You see? And so what's exciting in Raise the Bar is that we see leaders who adopt this as a business model to create a company that is based on everyone learning every day. And there's a second second trick in the title. It's that Raise the Bar, we imagine it's Raise the Bar on the company, and in fact what the Lean practitioner really does is that he's constantly raising the bar himself. So it's a method of self-improvement. So there's a small, there's one that's cooking. We're finalizing it, it should be out by the end of the year. A book, not equivalent, but in the same vein, on the Lean practices of the leaders of the entire Theodo group, which you know, who are regulars here. And again, the idea is not to show how Theodo has implemented the Lean practice. The discussion is how the leaders of Theodo appropriate this way of thinking or this way of being as a manager. And again, the idea is not to show how Theodo has implemented the Lean practice. The discussion is how the leaders of Theodo appropriate this way of thinking or this way of being as a manager, to succeed in their company. Which brings me to the thing.
[00:09:51] So what is Lean? There's a lot of talk around it. What we call Lean is the study of the Toyota management model outside of Toyota. But what we also call Lean is the practice of what we call the TPS, so the Thinking People System. And so it's a deliberate practice for the manager. So the idea is that it's not something I impose on the company. It's I accelerate my progression as a manager by forcing myself to think under the prism of TPS. So, a way to see it is imagine that you spend, from now on, you start a stopwatch and you're going to start seriously thinking, documenting yourself, testing a lot of things, to try to build a company that is customer-centric and that is centered on everyone's learning, every day, everywhere. Imagine you do that for 10 years, 20 years, 30 years. TPS is what you'll want to tell yourself when you talk to your present self. Do you see or not? And so it has nothing to do with the factory, it works everywhere. We haven't found a human activity where the model didn't work. And you have to see it really, it's what I call it, it's the karate of business, or it's horse riding. When we look at management, management is an activity of incredible, incredible complexity.
[00:11:15] That is, if I am a tech lead, if I am a CTO, I must master technologies. I must master the business. I must know how to build an organization. I must have knowledge in operational management, of performance. I must have theories on quality. I must have theories on motivating people, on psychology, on conflict management, on negotiation. Do you see or not? Now, once we've seen that, look at how we're trained to become managers. Does that make you laugh or not? No? Am I the only one it makes laugh? They're sad, people.
[00:11:48] And the idea is to say, well, either we practice TPS, either I tell myself, "Well, I'm going to tinker, ah, I read a great thing, they do that at Netflix, I'm going to try." So I do it like that, I grope. Or, in fact, I understand that management is a, humans have been doing this for a very, very long time, there are things we know, there's a physics of management, and so I'm going to train myself to accelerate my training. So, it's a way of thinking that, as we train to see through TPS, changes the way we see things. And, I'm going to give you a demonstration. You recognize things like that? You've seen them before?
[00:12:27] So it's interesting to ask what do I see in there?
[00:12:33] So I, I'm sorry, but I'm going to tell you what I really think when I see this. The first thing I tell myself is that the timid one is a bastard exploiter.
[00:12:45] No?
[00:12:48] In fact, I tell myself that because when I look at the structure of the Kanban, the priority is given to things moving forward in the process because we have to ship, we have to ship. However, we don't see the people.
[00:12:59] Yes, there's a small little thing there. But the thing is not made to see people, in fact, it's made to ship pieces. And I say to myself, well, that's an exploiter, we're laughing, when I say that, I don't know him and I can, but I imagine he's a very good person. But, but in fact what I see is that it's a system where the thought, in fact, is, it has to come out, it has to come out. Explain to me why it doesn't come out, and I'll explain to you why you're going to get it out anyway. I'm pushing it a bit, of course, I'm trying to make you see something. The second thing I tell myself is, well, they really don't want to be good. They don't want to progress. It's obvious, do you see or not?
[00:13:35] So what makes me say that is that, in fact, we don't see the lead time.
[00:13:40] So, in fact, we're looking at flow, but we're not looking at whether we're going fast. And so we don't know, are we going faster than before, are we not going faster than before? No, because in fact, we're not interested in measuring the delay. Now, the delay is the metric that means that, well, if I'm stronger, I go faster, it's not a problem.
[00:13:57] The third thing I tell myself is that, in fact, in this team, they really absolutely have no intention of doing quality one day. Why do I say that? Why do I say that?
[00:14:08] I tell myself, in fact, they have a screwed-up theory of quality. That is, they tell themselves that to do quality, I have to add inspection phases. And so they're doing exactly what Ford was doing in the 50s. But except that, as we don't study the past, we reproduce, you know, the story of those who don't study history are condemned to repeat it.
[00:14:30] I'm not going to explain the why of quality right away. Are you holding up or not? Who's left?
[00:14:35] Yes, you stay, okay, okay. I'll continue. I planned to be taken out, but I don't know when in the conference. I planned to be taken out, but I don't know when in the conference. So that's why I'm looking at the organizers. And what I tell myself especially is that these people, in fact, they may have made a mistake, which is to take just a piece of the TPS, they called it Kanban, without understanding two things, without understanding that it's part of a global system, and so if you remove a piece of the system, you know, if I take a mouse and I open it and I remove the heart, it doesn't work anymore. So the idea, the mistake there is to take a piece of the system without understanding the whole. But above all, the mistake in my window, but I have the microphone. The mistake is to imagine, to use this system without understanding its intention. So suddenly, the question arises, what is the intention of the famous Kanban? What is this thing for? So suddenly, the question arises, what is the intention of the famous Kanban? What is this thing for? And so Kanban is not a method for accelerating flow, it's not a method for improving production. I'm teasing you, I'm teasing you.
[00:15:38] It's a method for what? So to explain that to you, I have to go back to some nonsense I used to say in the book Extreme Programming Project Management. I take responsibility for it, but I was young, it was for the money. So I had written, I think in 2000, maybe 2001, I had written something in one of the chapters, I had said, in fact...
[00:15:59] From the client's point of view, in fact, for a dev team, in fact, we can give you quality, something perfect that works well, we can do it quickly. Or you can have a large functional envelope. But, my friend, you can't have all three. So that's the kind of nonsense I used to say when I was young. So that's the kind of nonsense I used to say when I was young. In fact, I changed my way of thinking about this. The fact of being lulled by Lean a little too close to the wall, leads me to see things a little differently now, that is, I understand, I model the previous equation as...
[00:16:36] In fact, value is quality, in the sense of how much I serve the client, divided by the total cost. And so I prefer this notion of total cost rather than delay. Because if I oppose quality and delay... It gives me the impression that the game is to go fast. But in fact, going fast is just one of the components of doing it cheaply. Do you see what I mean? And if I capture it from the angle of going fast, it pushes me to make mistakes, in the sense that I will try to take shortcuts without seeing the total cost. And what I mean by total cost is, okay, how much will it cost to do? Can we do it quickly for the cost? Are we going to reduce maintenance costs? Are we going to reduce the cost of training the people who will use it? Are we going to reduce the cost of support in the company? Do you see? And so the mistake, in my opinion, when we reason in terms of quality and delay, only on development, is that mechanically it leads us to create problems, to make believe that we are going fast to actually just create other problems in the company, which makes us very proud because with 10 people we shipped the thing very quickly, but we didn't see that we forced the company to recruit 50 people for support because nothing works. Which makes us very proud because with 10 people we shipped the thing very quickly, but we didn't see that we forced the company to recruit 50 people for support because nothing works.
[00:17:49] Once we've seen that, what I ended up understanding is that cost control, cost reduction, that's the expertise. And what an engineer does is that he does cost reduction all the time.
[00:18:00] So it might be shocking, presented like that. But now, take the discussion you have when you do estimation sessions.
[00:18:07] When you do technical design sessions, the nature of the conversation is how do we make something that works, that works for a long time, and cheaply. You see, that tension, you have to understand that it's the nature of the design activity. So we're constantly fighting over how I serve the client, and how, by serving the client, I reduce the cost. And that's the, somewhere, the metric of a dev team. You see? You see? What's interesting about that, by the way, is that it also gives us a professional development orientation. That is, I become better because I increase my productivity, in fact, that's the real term. And I do it because I understand the client's need more and more finely. Because if I haven't understood what he wants, I make things that are a bit too broad, which cost a lot and which remain, you see what I mean? So I develop as an engineer because I understand more and more finely what is important and what is less important. And on the other hand, I develop my ability to find ingenious methods to reduce the total cost. And so that gives us a roadmap for what a CTO does. And so that gives us a roadmap for what a CTO does. So the mistake is to imagine that, in fact, you can't have quality, speed, functionality. In fact, it's false, we can have all three. We can make a super quality thing, very, very quickly, that covers all the needs of the client, in fact, you just have to be very, very strong. I'm just going to be really strong. and I do it because I understand the client's need more and more precisely. Because if I haven't understood what he wants, I do things that are a bit too broad, that would cost a lot and that would stay, you know what I mean? So I develop myself as an engineer. So I develop myself as an engineer because I understand more and more precisely what is important, what is less important. And on the other hand, I develop my ability to find ingenious methods to reduce the overall cost. And so, this gives us a roadmap for what a CTO does. So the error is to imagine that, in fact, we can't have quality, speed, functionality. In fact, it's false. It means we can have all three. We can do something of super quality, very, very quickly, that covers all the client's needs. In fact, you just have to be very, very strong. Uh, I have one of my best friends, who is a former colleague too, whom I met in '98. That's 24 years, I don't know if you have many friends for 24 years, but uh, who in fact, uh, he joined a publisher in the financial world. They had done a first project with six people for six months to do something a bit complicated, risk calculation on very, very large volumes of data in almost real time. A first team of six had failed. They had thrown everything away, they had stopped. They reassembled a team of four, who tried for two months, they stopped. They recruited Mark, who did it with another guy in two months. So productivity, in fact, it's measurable. You see? And so what is it when we've understood that? What is the role of the manager, the lean manager? The role of the lean manager, sorry, the tech lead manager, who does lean. it's to train these guys so that they develop their ability, their productivity, their ability to really understand the customer, to reduce costs. You see? Now the question is how do we do that? And what we usually see when people start doing Lean, start creating standards, is that they write things that look like this. So how do you do a peer review, a code review? First, you have to do that. What's really interesting is the formulation. You have to do, you have to do that, you have to do that, you have to do that. You see what I mean? It's by the tool. So I am in the process, these people don't understand that they are training. They are forcing people to do things. Do you feel that or not? You do this, you do that, you do that. And what's interesting when we look at this standard, is that the interesting part isn't there. For example, verify that the code meets a functional need and that it is well organized accordingly. Well, but that's the game, that's the game. You see? And so what we see there is people and it's nice that they try to do that, they are at the beginning of the road, I don't blame them. But what happens is that they are at a stage of their understanding where in fact, they tell us, well, in fact, I don't know how to train the guys, I don't know how to do it. So what I manage to do is just dictate rules. Because it's a bit of a mess in the teams and I hope that if there are a few standards, a few rules, people will stop doing whatever. You see? And so, the idea is that if we want to go beyond that, once we've understood that the key to productivity in the noble sense of the term is competence. Well, the idea of the tech leader is that what distinguishes him, what distinguishes the individual contributor from the manager, is that the individual contributor knows how to code, the manager knows how to train individual contributors to code. You see? Because otherwise, if I just find myself as a tech lead or CTO, but I don't know how to train, I'm just an individual contributor who has a right of life and death over others.
[00:22:22] But I don't really bring value. Do you see the thing? Of course I bring some because I'm more advanced, but But in fact, the idea is that I learn to be a better tech manager because I develop ways of thinking about how I empower people. So the first thing to have for that, hence the title.
[00:22:42] So the first false idea that needs to be killed is the idea that we're going to transform teams into little robots that all do the same thing. We're going to find the best practices, ensure that everyone does the same best practices and finally, that's the terrorist delusion, finally, everyone will do the same thing everywhere all the time. But you have to understand that this is not how training works. It works outside of knowledge work. For very repetitive activities where you don't need to think, yes, we can put a lid on people, control their hands. But in fact, this thing doesn't work for intellectual work. For intellectual work, the idea is that it's a progression that happens within. For intellectual work, the idea is that it's a progression that happens from within, and everyone will become the best version of themselves. And so the idea is to have as a model that as a tech manager, my role is to help people develop, being completely comfortable with the fact that they will all develop differently. because I'm building my Avengers team. They are all weird, you agree that they are all weird. They are all broken from a certain point of view, they all have their own neurosis, but it's a different neurosis per person. You see? So the first thing is to stop imagining that we put people in boxes and force them to all do the same thing. And then the idea is to make them progress. So how are we going to make them progress? So we have a model for that. The master craftsman model, you know,
[00:23:57] of craft. So when I say that, I wouldn't want to fall into the rut of software craftsmanship, even though they are friends. But what I'm trying to show is more that, in fact, we have a way of transmitting an expert gesture. And what I would like to do is to go into a bit more detail about how it works. The key is to do what is called deliberate practice. So if you want to learn to play guitar or tennis, the idea is that you learn because you, by repetition, but a repetition, trying to do it well. You see the tension a bit, you have to imagine the guy who serves, who serves.
[00:24:32] It's not just any repetition. If I, if I serve randomly, I won't learn, I can do hundreds of hours. The thing that works is when I do my famous serves, trying to do it well.
[00:24:44] So, if we decompose the different components of good deliberate practice, there are several elements. The first element is production. So the idea is that I learn by doing. So a mistake we often make is to say to ourselves, a good engineer, he knows how to do things, he has theories, stuff, and then there are good ones, there are bad ones. We can't do anything with that. We can't train someone by saying, go on, be better. The trick is that I learn by craft, that is, I learn by producing. And the beauty of the thing is that I see in what I have produced, my level.
[00:25:22] You see? And so what the master craftsman does is he produces things and he looks at them, saying, I see in that what I know how to do. So how do we become a great writer? Well, a great writer writes books. How do I become a great musician? Well, I compose damn pieces and I play pieces and I do shows. You see? And so, how do I become a good engineer? Well, I code. However, you have to go a bit into the detail of what code is. So it's not about making user stories or coding in general, to develop yourself, you're going to have to start having a precise enough list of what I produce. You see? So the beginning of taking ownership of your own progression is to start telling yourself, I'm making API routes. So the beginning of taking this in hand, its own progression, is to start telling yourself, I make API routes, I make unit tests, I make estimations, I make technical designs. And the idea is to start seeing your progression in the quality of the things that are produced.
[00:26:21] The second thing is that I'm going to practice by producing, by constantly comparing myself to what we call a standard. So there's a tragedy in Lean, it's that people interpret the Lean standard as we're all going to work the same way, it's the best practice that we have to impose on everyone, that's not the case at all. What we call a standard in Lean, you have to see it, it's a bit of a benchmark. A standard is, I have a reference point that allows me to know if I'm doing something wrong or not.
[00:26:43] You see? So the idea is that we agree not on what needs to be done, we agree on what is okay. By accepting that each time we try to find compromises. You see or not? For example, today there were transport problems, the organizing team, it has to start at such and such a time, it has to start at such and such a time, but the reality is that there are strikes. You see what I mean? We can't tell them what to do. We can't tell them what to do. We can give them benchmarks, saying, well, people still need a break. You see? So we think of standards as references. that allow people to keep their wits about them and keep their spirit of adaptation, without having a fantasy of making them all work the same way. And so, the standards, I showed one, with this famous intention. And so, the standards, I showed one, with this famous intention. And so, the way I'm telling it today is that this one doesn't work because it tries to control the person's hands. It says, do, that's what you have to do with your hands. And to understand what the alternative would be, you have to go back a bit to how expertise works, and how we produce with the thing up there. and how we produce with the thing up there. So the basic machine, of the way we think, is what we call mental models. So for example, when you see the image, when the person is going to release their index finger, you all see what's going to happen. Do you agree or not? And in addition to that, depending on the angle with which he's going to hit the domino, you can almost imagine if it's going to go like this, like that. You see or not? If he does it gently, if he does it hard, if he does it very hard, the thing will bounce. You see? What we all agree on, nothing happened, do you agree?
[00:28:22] It's the same, if I do that, I spread my fingers, you know what's going to happen. If I do that, it will bounce, you see? And so the idea is that the way we think is that we have models.
[00:28:30] that represent the way the world works. And so the notion of standard, the notion of gesture that allows us to understand Lean in the world of tech, in fact, only works if we manage to come back to a logic of, I understand the expert gesture which is the way in which the person thinks. And an example in tech, is to say for example, well, someone is going to say, well, on the app there, when I click to post the form.
[00:28:56] In fact, the engineer, he knows that this thing is going to be interpreted by the navigator, who is going to send an HTTP request, etc. You see what I mean? So he has his ego, his mechanisms that are running in his head.
[00:29:09] the mechanisms that run in his head. Uh, moreover, what we call a bug, and these are very scientific studies that demonstrate it. What we call a bug, is that I coded something because I thought that, but in fact no, that's not how it works at all. You see? So that means what we call a bug. You see? So that means what we call a bug is that I had a flawed mental model that didn't represent reality. That is, I let go of the fingers, the thing went up. You see? So that's important to understand. So that's important to understand because training people is, we can't do it from the outside, they train themselves, and in fact, it's about developing mental models that are increasingly rich. And so the idea is that once I've understood what I produce, very precise pieces, my learning consists of building more and more rich mental models on each of the pieces, looking for different things. What will interest me in particular is all the constraints, or even better, what we call trade-offs. Uh, for you to understand this notion of trade-off, I have a very simple example. Uh, I don't know if it still happens, but I lived in my youth when we used to say, you shouldn't make methods of more than 25 lines, you have to break them down. And then it's too long. And in fact, what's interesting is that at the beginning, I have a very big function, then I'm going to break it down into lots of small functions, and then in fact, as I spend my time moving around in each small function to try to understand what's happening, in fact, the code has become more and more messy, more and more difficult to understand.
[00:30:35] So I have a trade-off. You see or not? I explore the thing. There was a guy on one of the projects, I was working with a friend who was on a project, he said, we started on something, we did microservices, we went to the very bottom. we started on something, we did microservices, we went to the very bottom, but after that we discovered something, which is that in fact the network is saturated. I said, well, yes. You could know that beforehand, no? You see what I mean? So the idea is that I manage my learning because I capture what I know, not what I have to do, but I capture how things work. And the idea is that, broadly speaking, what an engineer who really wants to be strong does is that he starts to consciously collect his mental models of what works, what doesn't work, what is well done, what is not well done. what an engineer who really wants to be strong does is that he starts to consciously collect his mental models of what works, what doesn't work, what is well done, what is not well done. And in fact, a team that really wants to learn is a team in which it's not the team that does it, it's everyone who is having their little notebook where they collect as they go what they have learned about how things work, about their own interpretation of the trade-offs. So they capture mental models. Uh, I capture authentication models, the strengths and weaknesses of each other, you see what I mean? I manage my knowledge. You take a look.
[00:31:52] The other thing is that once I'm managing my knowledge, I'm going to train myself to enrich it and to incorporate it, in fact, through repetition. And in fact, that's what Kanban is for. It's that the Kanban is that I receive requests, pieces, and that they will show me, and they will tell me, well, there's craft to do in this area. And so I look at the trick with the Kanban in a sense, when each person in the box or in the team, doesn't see the thing as just another to-do, but sees each task that comes as an opportunity to deepen these mental models, to understand how to solve this problem in this particular context. to understand how to solve this problem in this particular context. The last fourth element that is needed to do deliberate practice is that you need the coach's feedback. Because if I learn to do a new gesture, but I don't have external feedback, I'm going to develop bad habits very quickly. but if I don't have external feedback, I will very quickly develop bad habits and I won't see myself doing it. And so, to learn quickly, if that's my intention, I need someone opposite me. who can tell me, well, lower your shoulders, lift your nose. You see? So for that, you need a certain type of manager. So I don't know if you're familiar with this model. It's a model, roughly speaking, of learning, I arrive in any field, I start by being unconsciously incompetent. That is, that's what typically happens for management. That is, I know so little about management that I think I'm doing well. You see what I mean? And so when I'm there, well, I need to see a real manager, so I say, oh crap, this is a real job! And so when I'm there, I need to see a real manager and say, oh crap, this is a real job! But in fact, I'm useless. Yeah, bravo, because then you can start working to move on to step two, which is I'm going to train, train, train until I, well, and so that's unconsciously incompetent. That is, I know I'm useless, but I'm taking care of myself, it's much better, the worst are the unconsciously incompetent. If I know I'm not very good and I'm training, that's very, very good. And eventually, I'm going to reach a stage where I am competent but unconscious.
[00:33:45] That is, I manage to do things with great dexterity, but I can't explain why. And that's the state in which most tech leads, technical managers, CTOs find themselves. And that's the state in which most tech leads, technical managers, CTOs find themselves. That is, they know how to do it, but they can't explain it. Which means that when they are in front of people, they say, wait, I explained it to you five times, you're too stupid, what's wrong with you? Get out!
[00:34:03] No, in fact, it's that I don't know how to train. And so the idea is that the system of deliberate practice works. And so the idea is that the system of deliberate practice works when I have understood as a manager that my job is to learn to train. And that the level of the people in my team is my level as a trainer. You see what I mean? And so to do that, there's a phase that is very, very, very difficult, which is that you're going to have to go from unconsciously competent to consciously competent. That is, I know how to code and I know how to explain why. That is, I know how to code and I know how to explain why. The figure of a pro of extreme programming in the 90s, it was Ken Beck. It took me a long time to understand that in fact. I didn't understand why agility gave rather mediocre results at scale. In fact, extreme programming worked with Kenbeck, with Martin Fowler, with Bob Martin. That is, when you have people who are very, very strong, well, yes, agility works. The question is how do we become very, very strong? But if you look at the people I just mentioned, what do they do? In fact, they write their knowledge. They think. You see? So when you read Martin Fowler's Refactoring, you actually see a master craftsman who is trying to explicate his theory to learn to teach it. So he is inflicting upon himself the practice that will allow him to make himself someone who knows how to train others. So he is inflicting upon himself the practice that will allow him to make himself someone who knows how to train others. So he's on a track to become a manager. And it's the same, that's where we understand what Kanban is for. So the idea of Kanban is that I am the manager, I have a mental image of all the people in my team, I know their strengths, their weaknesses, I know at what point I am making each one work. And so I send Kanbans to this person, to that person. And so I send Kanbans to this person, to that person, because I know what I expect from them. You see what I mean? I know that I'm sending it there because it's going to develop them on that. I know that I'm sending it there because it's going to develop them on that.
[00:35:50] The last component of a deliberate practice system is the desire to learn. Because all this, I can repeat, I can repeat, I can repeat, if I don't want to. Well, nothing will just happen.
[00:36:02] And what will also happen is that I will experience my work. If I arrive at work without the desire to learn, I will experience my work as a kind of repetitive routine that will make me look for strange addictions, new technologies, better salaries. You see what I mean? We have to try to fill the gap of what my days are. And so, once we've understood that, it also clarifies the manager's role. The idea is that the tech manager, he has, roughly speaking, three challenges. The first is to awaken in each person on the team the desire to learn. And that's his job. It's his job at least not to extinguish it, it's his job to make people want to progress, to surpass themselves. To do that, the most powerful way is to do it by demonstrating his own tenacity to progress. To do that, the most powerful way is to do it by demonstrating his own tenacity to progress. I'm reading, I'm writing, I'm training, I'm updating my standards. The idea is that I show it as a leader to the people in my team because I want to inspire them. And also because uh, I can't see myself teaching things that I don't practice myself. That's called charlatanism. You see?
[00:37:09] So the idea is that I don't have the legitimacy to ask the people on the team to train hard if I'm not doing it myself. So second element is that I show that I am a role model for learning and for mastery. is that I show that I am a role model for learning and for mastery. And the third subject is that I gain a deal, and often that's something people don't see. And the third subject is that I gain a deal, and often that's something people don't see. It's that for the system to work, the person in front, the person on the team, must accept me as a coach. And when you look at teams, very often in fact, developers don't accept their tech lead or their manager as a coach. Which creates enormous tension. You should do it like this, you should do it like that, the person resists because in fact, what we haven't cracked is the agreement, which can be implicit, this agreement which is that in fact, I am your teacher. this agreement which is that in fact, I am your teacher. You see? One of the things we went into with agility. today I think it's nonsense, but it's really a personal opinion, it's to imagine that learning is done in a team. We discuss, things happen. But that's not how humans work. Of course, it generates learning. But the royal road to learning is I find someone who has been doing this for 10 years longer than me, I watch what he does, and he helps me improve. But the royal road to learning is I find someone who has been doing this for 10 years longer than me, I watch what he does, and he helps me improve. We do that in all areas. Uh.
[00:38:22] And so the idea is that as a leader, I have to be accepted by everyone as a coach. I have to earn the fact that the person wants to work, and I have to earn the desire for them to accept me as a source of progress. Ah!
[00:38:37] We're going to talk about Lean.
[00:38:42] So I asked the question at the very beginning, what is Kanban for? So Kanban, it's for something in the context of TPS, and what is TPS? So TPS, it's a mental model that I use as a leader to develop learning in my activity, in my organization. And it's something that I do, that I apply to myself, I think through TPS. And it's something that I do, that I apply to myself, I think through TPS, and it actually helps me transform everyday delivery into a learning opportunity for everyone. You see, that's the final intention. You see, that's the final intention. It's a method to do that. So very quickly, what it consists of. Well, the first thing is that I understand that. The ultimate goal of all this is that we become better because we create more value.
[00:39:30] So you see what I mean? We have a metric, we have a heuristic, that is, we are a better team if we create more value. At least the North Star is set. And what does it mean to create more value? It means that I, first, understand the quality more and more precisely, because in fact, we're going to make code, we're going to make products that hit exactly where they need to, and that don't waste energy elsewhere. And at the same time, on the other side, I am constantly reducing costs. Uh, and when I say reduce costs, it's shocking in our world, which is sad, but because it's clever, in fact, I find clever solutions. that with three lines of code, I create enormous value for the client. And the idea is that I do that at the global level of the app, but I learn to do it little by little on each test. And the idea is that I do that at the global level of the app, but I learn to do it little by little on each test. Where is the value in a test? Where is the value in a screen? Where is the value, you see what I mean? So it's a deliberate practice that is oriented towards customer satisfaction through value improvement. Where is the value, you see what I mean? So it's a deliberate practice that is oriented towards customer satisfaction through value improvement.
[00:40:23] Once I understand that, I have to train myself and I train myself on pieces. You see? So I do tasks. I do tasks because that's my way of training. And these tasks, that's why I was talking about lead time earlier. And these tasks, that's why I was talking about lead time earlier, well, I learn to do them faster and faster from the client's point of view, because that's how I see if I'm progressing. And so, that's where I need Kanban, but not a Kanban organized like that, I need a Kanban that is organized by person. Since I am the team coach, what I look at is the team, not the pieces. Since I am the team coach, what I look at is the team, not the pieces. I first look at the team, each member of the team, and then I look at which piece I sent to which member of the team. And I'm going to go even further, so it's a pull, it's a pull system. So pull is about taking. The error in the model that I presented before, in general, it's a push, we push the thing to the next stage, we push the thing to the next stage. Pull is a bit different, it's that in fact, we're going to come and take. it's that in fact, we're going to come and take. What it looks like very, very concretely, everyday in the team, we have three developers there. Pardon. We have three developers. We have, concretely on the right, we have Justine. So I know as a tech lead that Justine is working on this task. We worked upstream together, where we analyzed everything she was going to do, everything that would need to be done to do this task. So we exercised our mental models, we discussed to try to find the least costly way to achieve the thing, less costly right away and in the future to achieve the thing. So we exercised our mental models, we discussed to try to find the least costly way to achieve the thing, less costly right away and in the future to achieve the thing. And we agreed on the fact that normally this thing, I don't know, it's 2 PM, it's for three hours, so at 5 PM it's finished. So to do pull is that I'm going to tell Justine, well, it's great, go ahead, I'll be back at 5 PM. And I'll come back at 5 PM to pick up the piece in the sense of seeing what you've done and so that we can have a discussion about the quality of what you've produced. Because that will be a coaching opportunity. And what I'm asking you is. What I ask of you is, and so it's the other side, it's the counterpart of the just-in-time, of the speed, it's the self-quality, the Jidoka. What I ask of you is that if you have the slightest difficulty. What I ask of you is that if you have the slightest difficulty.
[00:42:24] but really, I'll come at 5 PM, don't worry about it. However, if you have the slightest difficulty, it's your responsibility to call me so I can come and see what's happening and give you a hand. You see? And I don't know if you see the elegance of the system, it's that when I do that, I am creating a system in which I receive, I am solicited on all the things where I have something to teach people. You see? You see?
[00:42:49] So I remain available to the team because I have put in place this pull system, I have people who call me constantly, they call me exactly where they have difficulties. Which means I don't need to be on their back telling them where are you, what are you doing? You see? I just have to be there. to be available when the person is going to stumble over a problem. There, what we're going to do is we're going to cross the thing. There, what we're going to do is we're going to cross the thing. We're going to, sorry, we're going to. Uh, do some problem solving. Problem solving in Lean, in fact, is central. Problem solving in Lean, in fact, is central because what we know from a scientific point of view is that adults learn by problem solving. We talk a lot about pedagogy to teach, pedagogy is the science of teaching children. So adults don't learn in a room looking at slides. So adults don't learn in a room looking at slides, adults learn by solving operational problems on the ground. So what we see here is how the system allows problems to emerge. to allow problems to emerge so that people solve problems and learn by solving problems. And we're going to be interested in two types of problem solving. And we're going to be interested in two types of problem solving. We're going to look at, first of all, if Justine has a difficulty, we're going to have a reflection on the conditions. That is, roughly speaking, the role of the individual contributor. roughly speaking, the role of the individual contributor is to produce value for clients. As soon as I leave this layer and become a manager, I become a tech lead or above. As soon as I leave this layer and become a manager, I become a tech lead or above, in fact, it's no longer me who does that, or when I do it, it's just that I, you see what I mean? If I am a tech lead and I code, it's not serious. It's just that I'm not a tech lead there, I'm doing an individual contributor. But when I'm wearing my tech lead hat, my role is to create the conditions for people to go fast. But when I'm wearing my tech lead hat, my role is to create the conditions for people to go fast, and my role is to train them. So the first thing is that when Justine has a difficulty, I try to tell myself in the conditions. what she received as input, the tools she uses, the configuration of her environment, are there things we didn't understand? Do we have something to learn about how to create the conditions so that Justine can work calmly without effort? Do we have something to learn about how to create the conditions so that Justine can work calmly without effort? Second thing, which we're going to look at, is, well, is it more a question in the world of standards, or is it, is it that Justine has something she hasn't understood? Is it something we haven't understood, we're not clear on our standard? Is it something we haven't understood, we're not clear on our standard, or is it her who hasn't appropriated it? And so, I make all of this my training system. And so what we see here is how the TPS, and therefore Lean in general, is a perfectly proven method that works everywhere to consciously, in fact, transform production activity into learning activity to make master craftsmen who have the ability to go faster and faster to create value. And that's what Toyota has been trying to tell us for years and years and years, and in fact we refuse to listen. Because we are so caught up in our terrorist delusion that we all intend to put people in a small box. But that's not what he's telling us, he's telling us, to make good products, you need people to think well. But that's not what he's telling us, he's telling us, to make good products, you need people to think well. And so you need to design a company that is made in such a way that people are constantly learning to master their work better, to think better. to master their work better, to think better and to become stronger. And that's why I think the great tragedy of Lean in our world is to have taken just a piece to imagine it was a flow management system and I think it's tragic personally because in fact we miss out on a human adventure that is really worth living. and I think it's tragic personally because in fact we miss out on a human adventure that is really worth living. And so, what can I tell you? And so, what can I tell you? Well, if you work, I don't know if there are people who work with humans, but but if you work with humans, if you are a manager, I actually have two proposals to make to you. The first is to raise the bar on yourself and to look at yourself as a manager and say, where am I and what am I doing to progress? And uh, if you're interested, a second track is to get into this thing that today I call hardcore Lean, Japanese style, so that together we can try to get out of these somewhat crappy projects. so that together we can try to get out of these somewhat crappy projects that don't give anyone the desire to change jobs. Thank you very much!

Transcript (Translated)