Hey, a quick message. For those of you who are listening to this episode on Spotify. I have a small favor to ask Spotify. Now allows mobile users to rate podcasts. I would really appreciate it. If you can take a quick, pause to go to the technique Journal podcast page, and leave your favorite show. Your best rating on Spotify. It will help me a lot to get this podcast to reach more people on the platform. Thanks a lot.
Who'll don't push? Yes. Don't tell people what to do. Tell them what results you want. Point and let them figure it out, that gives them the satisfaction in the responsibility, to figure out how best to achieve the outcome that's needed.
Hey everyone. My name is Henry Surya with Robin. And you're listening to the technology, you know, 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, my friends and listeners. Welcome to the tekhelet journal podcast the show where you can learn about technical leadership and Excellence from my conversations, with great thought, leaders out there, and this is episode number 91. Thanks for tuning in and listening to this episode. For those of you who are listening to technology. You know, for the first time, don't forget to subscribe and follow the show on your podcast app and social media on LinkedIn. Twitter and Instagram.
And if anyone wants to contribute to the creation of this podcast, Let Me by subscribing as a patron at technology. No, Dev slash Patron today, I am excited to share my conversation with another great thought leaders and Pioneers in the software industry.
My guest for today's episode are Mary and Tom poppendieck, they are the causes of several books related to a gel and lean including the award-winning book lean software development and agile toolkit published in 2003 in this episode Mary and Tom shared about lean software development. Element, its principles and mindset and the concept of a pull System including the story. How Mary first learned and implemented a pull system in her work at 3M Mary.
And Tom, then pointed out the problems of having proxies in software development and how it is much better to manage by the outcomes by having the people directly figuring out the best way to achieve those outcomes later on Mary and Tom talked about the concept of flow y. It is important. To optimize flow and how to optimize Flow by analyzing the value stream map and minimizing approval process.
I really enjoyed my conversation with Mary and Tom learning the essence of lean software development from listening to their insightful, stories and Concepts. I specially like our discussion about the to so-called anti-patterns to lean which are having proxies and requiring approvals. If you also enjoyed this episode, please share it with your friends and colleagues.
Who can also Benefit from listening to this episode, leave a rating and review on your podcast app and share your comments or feedback about this episode on social media. It is my ultimate mission to make this podcast available to more people. And I need your help to support me towards fulfilling my mission. Before we continue to the conversation. Let's hear some words from our sponsor. Today's episode is proudly sponsored by skills matter.
The global community and events platform with more than 100,000. And software professionals here members can organize their learning experiences around the technology topics. They care about most you get on-demand access to their latest content thought, leadership insights, as well as the exciting schedule of tech events running across all time zones.
So we're the devops. Our data science is your bus or you are fan of functional programming or all things Cloud, you can make real connections with people who share your interests head on over. The scales method are calm to become part of the tech community that matters most to you. It's free to join and you will find it easy to keep up with the latest tech Trends. Are you looking for a new cool swag package? You know now offers you some swags that you can purchase
online. These wax are printed on demand based on your preference and will be delivered safely to you all over the world where shipping is available. Check out all the cool tracks available by visiting technology, you know, dot, f / shop, and don't forget to break yourself. Once you receive any of those threats, everyone welcome back to another new episode of the tekhelet journal podcast. Today. I have with me to guess in one episode and both are big names.
In software industry. They wrote books on lean software development long time ago and they've been preaching that for quite some time now, and I'm really proud to have both Mary and Tom poppendieck in one episode today. So I really appreciate both of you spending your time here. I'm really looking forward to this. Thing about the in software development or anything that you are working on lately. So, welcome, Mary and Tom, it's
good to be here, indeed. So I always like to start my conversation by asking about your journey or background. If you have any turning points or highlights in your career, that maybe you haven't shared with other people before. Would you be able to share some of those to us here? Sure. I started at my actual first program was in 1967. I was a junior in high school and I went to a science. It's summer camp or one of the things we did was we programmed a computer and it was
programming in zeros and ones. We had an assembly language. We manually translated that in paper into zeros and ones and then we type those into Punch Cards. My program was one of the later ones run, and I watched program after program. We travel by bus to the computer
one. After another, the programs were put in. And they failed, mine went in and it Printed something I was doing either the in Victoria or something because they said you can do a hard one, hears, this one, and then it printed another line, and then it gets lower and then it gets slower. And they said, it's, I guess it must have hung up. They were about to stop the computer, can be printed another light. So it's just taking longer and longer to compute.
I was so excited and pleased that probably made me a software programmer for life, because I was so proud of myself, but note, the, what I had to do in order to make sure that it ran was, I had to be, Sure, that every single punch matched. Every single 0, and 1, and every single 0, and 1 match, the intention in Assembly Language and that the Assembly Language matched the front language the concept that I have.
So a whole lot of inspection. Then I went to programming in Bell, Telephone Laboratories, and we were programming switching computers when I was doing the switching computers. What I was working in is an assembly language, which essentially mimicked electromechanical Actions that the previous generation of telephone computers went through. It was all 70 language without having to do the zeros and ones. So a lot less inspection. I did a lot of coming in on the weekends.
I was doing diagnostic. It was a completely reliable computer. It would throw one out or the other depending upon it was running twins. If something went wrong because we had the goal of a maximum down time of 2 hours and 40 years, and we actually met that goal with this twin computer. Because it was all individual components with known mean times between failure. They had four hours to repair any downtime like programs had to go and find the bad card and tell them to change it.
I did a lot of testing by just pulling a component out of a card and then seeing if my diagnosis could determine which car so I didn't necessarily worry too much about all of the details being perfect because if it didn't compiled and ready to run, I could go in and fix it. The next program I had was working. At the University of Wisconsin, programming physics experiments that were being controlled by a mini-computer. One of the very first
mini-computers predated. Even the Dell mini computers. The company went bankrupt. My boss. Always the kind of scrounge up for money, in a physics department, bought up their whole stack of two or three and then we programmed it. We had to complete the Fortran compiler, which wasn't done yet. So I was working at a council with individual lights that I could Read the code while watching the late scope. I I learned very quickly.
First of all, I started programming Assembly Language, but once we got the compiler more or less working I discovered that if I program in Fortran because the speed was so important. I'm a manually translated that to Assembly Language. I could test the algorithm in Fortran and then I could manually put it to Assembly Language. Therefore knowing that things were right became one step. Easier because I could get all of the logic proven out its portrait.
The next thing I did was I programmed computers. It was typically in basic that did process control systems and we always test that our stuff by having inner engineering lab mock-ups of the equipment and then I would go in and I'm just having an operator control a control Loop by putting in a set point. So, I would test and make sure everything worked. So that, by the time we brought
it to the site to install. All of the logic had been debugged and all we were doing was debugging like race conditions and stuff like that. Most of the stuff that I programmed had to be maintained by the plant engineer. Therefore, I concluded. There was no way I could do any Assembly Language because plant engineer could not be expected to have to learn Assembly Language.
So I did virtually everything in basic and just a few things in Assembly Language, that probably would not have to be changed. Then I went to do stuff for 3m on presses. Controls. Our tool was a mini computer, which is now been a chips. But at that time it was like that big. So then the next thing I did was I worked in a manufacturing plant that's r.e.m. I was the it manager programmed in RPG. So they only had to debug at a pretty high level because that was a pretty high-level language.
And then I started going to a higher and higher level languages. I always knew how the underlying system work because I grew up. You up with the underlying system, but I moved to higher and higher mechanisms to determine whether or not things were right. I met a guy in Norway, Tom Guild. And he told me once that he raised his family by teaching people to inspect every single line of their code in detail before they put it into a computer.
Well, I thought that was silly because first of all, you can't find everything and second of all, as the tools for testing increased, I had to do less and less infection because the Courtney have fun this throughout the all the time that I was programming as you get better and better tools your strategies for software development change. You don't do the same thing. You did 10 years ago. You surely don't do the same thing. You did 20 years you do. What's the current technical
capability allows you to do now? Just as a conclusion after I retired from 3M in if 98 early 1980 and started my own company. I Haven't actually developed code except maybe some controls in their house, but I've observed that the kinds of things that were our concern at the end of the last century, which is when agile were invented, are long gone. People. Don't do those. Great big, massive deploys of two years apart and stuff like
that anymore. So we have developed a strategy for dealing with 1890 problems, and we haven't walked away from it. And said, what are today's problems? What I've been trying to do for the past 20 years. When I wrote my first books, I was talking about 1990s, perhaps as it went on, I started talking about mindset, how you think about things because the things you do in detail, change all the time, but the way you think about how you do things doesn't change.
And so that's kind of what I learned in my career. So one thing that I would probably add first, I appreciate the history, what you said. I couldn't imagine because I wasn't born back then. I could really tell that it's really hard to write a program. In fact, the feedback loop is probably too long, right? Where you have to punch the card and then bring it to the computer and run it. So when you have a willing see that review has to be really
careful. If you put in relatively quick feedbacks and everything, the more feedback you put in the more the feedback will tell you. If you've done something wrong rather than your taking the time to inspect and it'll slap your hand so fast that you'll learn. Do it really quickly and that's really important. And that's actually one of those. Fundamental principles have some Jake. The faster. I as a programmer can get feedback, the better a job. I can do in the more comfortable.
I am. So maybe tell me I've also other fascinating story that you want to share with us from your background or your journey. My first contact with Computing was in the 50s when I was in grade school, I became aware of what computers were and that they needed to add. Have flip-flops Gates. So I tried to build one out of wood and nails and metal clipped from a can, and a battery. And I never did succeed. I went on to be a physics, major
taught High School physics. Again, that was about the time that the Commodore 64 and weighing calculators came into being made a lot of use of that in teaching High School physics for a number of years, but I wanted to No more. So I went to graduate school and when I got to my faceless, I had a bunch of calculation that needed to be done.
There are used for Tran fortunately, the engineering department had a student computer lab that I could write my program including a program to drive a plotter because I didn't like their driver for their bladder. So I wrote my own important thing was that I was able to punch the cards, put them in the card reader, see the print out and in a very a short time, see how I'd screwed up. The rapid feedback is absolutely critical.
Those were back in the days when the computer I have in my pocket that my smartphone was about the size of a University Computer. The same one that Mary's software eventually fit into Tom's High School. One of the things, when they hired him they said, well, we have a new device to put in your classroom. Would you use it to teach? And it was a calculator? I mean, Play-Doh. Later, and it was this big and that wide. And he had a calculator, the size of a desk and he loved it
from there. After I got my degree to teach at a university here, in Annapolis st. Paul area. One of the courses. I taught was Electronics. I also thought Pascal predecessor to Java and got more into the abstract. So programming about the time. And I started here at 3M, that led to Bringing deck computers. Into the university crawling through Steam, tunnels to string wires. So that teletype machines, could be installed in several buildings rather than only the science building.
I used it to teach course in astronomy for a self-paced, astronomy course, so that will is a important step. And at that point, every small University not just, the big state universities had the smartphone level of computing capability that they would Tha out. I went from there to work for Honeywell, do I Helping with the group that supported design of the navigation systems for
commercial airplanes. If you fly a Boeing or an air boss or several other major airplanes, you were probably navigated by the inertial navigation system over the load balancing system that our plant here in Minnesota produced learned. A lot is there. It's absolutely critical that you do things, right? The automated fault detection. Not only for the software but also Also, for Hardware failures that s to be detected and responded to properly. So the same theme there, find
out immediately. When there's a problem and respond in the appropriate way from there. I became a consultant or a company that when I joined was helping companies adopt object-oriented development, initially that was powerbuilder, but it rapidly evolved, my talk, my company. How to use Java, most of them were better programmers. And I were And rapidly outpaced
me, but I got him started. He consulted with a lot of major companies around the world, but Matt position and then retired to join Mary in the business that we have run. Now for 20, some years really, nice story. But one thing that I am curious, when did you both meet Ali met? It Marquette University and 65, followed 65. We became physics Lab Partners. Wow. Okay. 67 was not my first computing. That was my first job Computing at Bell labs.
And we met two years before the thanks for sharing the story. The background. So one thing, if there's any threat that I could see from both of your stories, both of you like to know the inner details of how things work and both of you also like to understand what is going on. Not just from the higher abstraction level, but also deep internals, right? I think that's part of engineering is doing something important and know you're doing it, right. It's not fun to find out a long
time. Later that The drop everything and fix it in from six months ago, or whatever. That's not quite, but being able to do something, think it's going to work. Run a very sophisticated tests to make sure you've got it even if it's only partial of the system. I mean, it just makes you feel so good. I used to sit in my desk area at three and when I was very first programming something would work on a test has a yes, and everybody looked like what's coming up. Does it feel so good to have
done something right? That's important to the system. It's not just feedback that you've done something, right? Right. It's like it's the fun of doing software development in general. So from that background, you wrote the book long time ago. Now, lean software development. How did you start with all these principles but lean software development? Which kind of like borrowed from the manufacturing site, right? So maybe if you can tell us briefly the story or are you came up with that?
Well, I was in rem and I got fired into a plant for which I had done a process control system and it was really successful. It was an Outsourcing project that I manage. The Outsourcing part and made sure that they were on time and on budget other 12 months million dollar project which was unheard of. But they were they hated me in the plan to be the it manager because the it manager had just been promoted to materials
control manager. We actually moved to this house that we're in now and I commuted out there. While I was there, we discovered lean because this was a made magnetic tape and we were suddenly being killed by a Japanese competition. Just Wiped out, they could sell stuff for cheaper than we. Could make it four. So we had to do something, dramatic and fast. So what we started doing was reading the early books on WE that were coming out of Japan. I have one of the early ones.
That's the worst translation of Chicago. Ching goes first book. So we started studying those books including this badly, translated, Green books. And we started saying well, how would this work in our plant? No, we didn't have a discrete Parts when we had a rogue. Explain. So we said to apply the principles, not the stuff. They actually did at one point, we decided to go to a pull system scheduling rather than a
system scheduling. We created a kanban system simply by trial and error and running simulations. When we cut over, we had an amazingly successful cuttable already. My process control systems were getting rid of a lot of waste at million dollar system paid for itself in the first month because they use the data. To do statistical analysis on problems and then they could
find sources of problems. So when we went to a pool system at that point in time, we had about sixty six percent accuracy and pack out against plan per week. That 66 percent success against detailed plan is also pretty typical in project management. If you have a great being detailed plan in an environment where stuff happens, there's variability, you can't stick to it. Everybody said we'll try harder to stick to the plant, but instead. That we decided to not have a
plan. So we made weekly plans and then we just pulled through the plant, from the weekly plans, using a pull system. Just like we read about in the book and we switch. We couldn't figure out how to switch the part of the plant over. So we switch the entire Clan from my computer doing scheduling to a pull system overnight one weekend. We didn't have an overnight. It was 24 hours, but it was down on Sundays. So one Sunday, we switch the
phone. Whole system to a paper-based kanban card, pull system for all scheduling that week. We packed out, like 95% against point and it just got better. Now. The reason it worked was because we designed that pull system, and we gave our simulation, which was lipsticks, and coffee cups to the supervisors.
And then they gave them to the shift supervisors, and the shift supervisors did simulations with their people and the people designed the Assist the people that were doing the work, designed the details of every piece of the system because we don't know how to tell them what to do there, weren't any bling Consultants? Thank God that would tell you what to do. So that plant people designed their system. So let's say something went wrong that first week and I'm sure it did.
Well, they knew what to do because they had designed the system in the first place. It was their work and they understood that reasoning behind everything because they designed
it themselves with simulations. And Oh, it just worked, it got better because the glitches it quickly smoothed out, but the whole system was designed by the people who are on the floor, using it. I became convinced that was the way to go. That post assumes were amazing and that the only way you could actually make a big change in an environment is to have the people who are going to do the change design, the change. Those two things.
I absolutely sure of today. I don't see it widely used that way, but it's the only way I run into so many. People that say well we tried to do this, pull system wouldn't work. I said yeah. Consultants come in, right? Yeah. Well, that's why I did work real simple. Yep. It's not the Consultants were bad because if you needed a consultant that meant you couldn't, do your own jet cool. Don't push. Yes. Don't tell people what to do. Tell them what results you want, and let them figure it out.
That gives them the satisfaction and the responsibility to figure out out how best to achieve the outcome that's needed. That is something that is only now starting to Echo economy-wide. If you look at the great resignation, that everybody is so upset about, there's an awful lot of pull. Don't push being sought by the people who are quitting the jobs that are telling them what to do. Wow. So there's a correlation with the great resignation.
The thing that I also think about lean, sometimes it's counterintuitive for those in the stakeholders site. So, how can We translate this. Okay, please don't push more and more demands involve us at the low level Engineers to actually be involved design the system do more pull based rather than push base. So maybe from your experience doing consulting and helping people any tips that you want to give for stakeholder. Okay. I mean, you can, it's not gonna work unless the upper people.
The more senior people understand what needs to be accomplished and why they need to accomplish it and then let the people We'll figure out how to accomplish. If you don't have that environment. That doesn't get pushed up from the bottom in our environment. When we started doing Lee, the plant manager was all behind it completely. He's the one that sent me to the very first just-in-time seminar in the u.s.
To see what was going on. I said, well, you should come too and he said, no Paul should come because I believe this stuff but Paul who reported to him and who was a general manager of assembly, doesn't get it yet. So you dragged him. They're so he understands.
So he went there and he spent the entire two days side by side with the UPS manager of that plant, talking about how things worked and he came back convinced, not because somebody brainwashed him, but because he saw the results of doing things different and he was impressive. He said we could do this. And if you don't have that at the senior level and the only reason he went, he surely would not have gone if I invited him. He went because his boss told him to go.
So if you don't have the belief at the top, I've never figured out how to get it. But I have figured out how it gets to the top. Okay, the companies I've seen that had wanted to change what they do. First of all, you have to remember the obscene. Your people are there because they've been successful doing things differently than you want them to do. It almost always takes a crisis or an impending crises for people to realize that what we've done up till now isn't
going. Cut it in the future that mean that's what happened. In a point. We invented, videotape, all of the broadcast video tape in the country. And in fact, we're mostly around the world was 3M tape. And yet, we were about to get kicked out of the industry. We realize that and started saying we've got to do something drastic because the incremental approach is that we've had, don't work. If you don't have that. I don't know.
You can just sit down and talk some sense into somebody who's had a whole history of success up till now. And doesn't really want to abandon that, unless something, not you, but something else is forcing them. So they'll think I found. The best thing to do is look for some problem that person has some crisis is clearly going to attack them and see if they believe that. Then is Graces. And then offer a way out of the impending. Doom.
If you can't do that. I haven't seen it a lot of seriously, good changes, so I don't see how Engineers can talk their bosses into thinking. Currently, there are two options. One is change your organization. If you have the capability of doing it, the other more, common one is change your organization. The people that cannot change the organizations that cannot change cannot succeed. The failure rate of even large companies.
It is impressively high. There's no point if you can't change how things are in, your current organization sticking with it because the organization is going to fail, Probably before you hope to retire. And the thing that we have seen over the past, I don't know, 15, 20 years is that Industries move from their past to their future almost as a group when suddenly the industry is attacked or so this until come, we saw this in
medical devices. We saw this in banking, all of a sudden, there's this concept of online banking on a telephone that just She looked up so many banks and the fintech companies started attacking the big Banks fee system, and fees is how Banks make money. Now. The next step was the insurance industry because insurance has all these devices out there that you can hook to iot. You can notice, how does your industry make money Banks make money on fees. Insurance companies.
Make money by minimizing risk. So what they are is a risk. Mitigator. Now, if you have iot, and you can connect it to physical objects that are being insured, you can change your results in Insurance because you can monitor, if it's been used properly.
You can monitor, if there's a fire when you start using the internet of things in conjunction with different concepts that we charge, you can dramatically change the risk game, and your computers, and your smirk scientist that used to do, all the risk calculations, become less, and
less relevant. And if that's what your whole company is built on. Then either you go down, or you see this and say what we've got to change and we have seen companies that have said, what we've got to change and they ones in Asia tended, to be the ones that saw it first because they saw more competition from insurance companies that could deal with risk much more electronically than with
algorithms. So, if you look at your industry and see where is its weak spots, where is it going to get? Where is it current strength going to become much less relevant and you hit that way. You will find that. There are people in Senior Management that get that but they don't know what to do about it. So if you have sympathy for, we're going to be attacked here, what should we do about it? And you can offer a solution, then you can help them do their job better and that can become a
real book. There are however, people whose jobs change or disappear. Appear. When you add any kind of different strategies mean, I could remember talking to a Healthcare company. We had like 15 or 20 people of the management team there, and about a quarter of them, entire job was prioritizing the work of the. IT department hundred percent of their job was in the priority setting process.
We went there and said priority, setting is a waste, you shouldn't do it. You know what they couldn't hear that. They couldn't hear it. Because what we said was the 25% of that audience, your job is irrelevant. You're not going to be able to keep it. You should do something that gets rid of your job. It's impossible for people to hear that which brings to one of the topics that you mentioned is
about proxies. So these days, you have been writing and talking a lot about proxies in the business world. No matter what company is this kind of proxies exist, either. It's business analyst, quality engineer test, engineer product owners. Us and all that. So you have a strong point of view about the existence of this proxies. Maybe you can share with us. What's the problem with having these proxies?
I first got the word in the idea from a letter to shareholders by Jeff Bezos. He talked about what is day one. He's almost saying we're still in day. One day, one means you're in start-up mode. You're still acting like a start-up and then he listed the things. The four things that you had to do to stay in day one because Day to you start dying. One of the things you had to do, was to avoid proxies and I'm
thinking, that's interesting. So, what you need to do is to get the people doing the work and direct connection with the people for whom they are doing the work. And if you look at the way, Amazon teams are structured, they don't have proxies teams have leaders, but they don't have somebody telling the team what to do.
If you look at the way SpaceX and Tesla does engineering, they don't have proxies, they expect to have Have people that are going to be responsible for the results dealing directly with solving the problems. In fact, most engineering. He does not operate with Praxis when I was in an engineering department. We didn't have the concept of a product owner or the concept of a process master or anything
like that. We were responsible for the end results and we were expected to go to the plant and talk to the operators and make sure we understood how they thought before. We designed an interface for them. We didn't have people.
In between us and the problem. And when you have a proxy in there, you take the responsibility off the team through thinking of good ideas and you don't love them to use their smart intelligent capabilities, to design Solutions, based on the technology that they understand. First of all, you'll have multiple people thinking about the problem and secondly, there's no way the intermediary can know all of the different aspects of the problem.
But secondly, that intermediary way too often is not a An engineer in the same field, how can they know enough to come up with the best solution? When they've never programmed any couple would, for example, or they've never done any kind of engineering engineering departments don't have proxies between the engineers and the problem.
So, for example, let's pretend you're a structural engineer, you work for a company and you're in, say, Santiago and there's an earthquake and your structural engineering firm is hired. To evaluate businesses before they get reoccupied because you've got to know if they're safe. Now, the business hires the structural engineering firm. Do you think they treat them like they would treat the same number of software developers.
Do they say you have to be done in this amount of time and here's the results that you have to come up with. Let us tell you exactly how you're going to do that job. They would be crazy because the structural engineers are the experts and similarly, when we design Control Systems. There was nobody in between Join us and the problem because we were the experts in control engineering, not some intermediary, but we have developed in software.
The concept that there needs to be an expert between engineers in the problem. And that's not an engineering concept. That's treating software developers as if they were technicians that couldn't think for themselves, treating them like children. We have a history of doing that because our history was that the first computers were mainframes and big companies.
It was a costume. A put in a cost Center and they were told by the people in the business what kinds of problems that they needed to solve, and they had lots of constraints and that was fine until suddenly many computers can walk, which is where I started programming in the engineering department. We wouldn't hear of that kind of nonsense. Okay. We were the experts, we knew how to use this new tool to solve the problem.
We went to the problem. There were senior engineers at coach Junior Engineers. Yep, okay, but they could do the problem in their sleep and they were teaching. The younger Engineers. How to think about the problem, that's how engineering is typically done, whether it's Structural Engineering control. Engineering. We do not allow our software Engineers to be Engineers to be, that's like losing so much of their capability and also making their life so much less fun than it.
Could was a challenging interesting. So we got to stop this having somebody tell a team went to do setting priorities for a team. That's observed if you want. No, the biggest mistake, the biggest bad thing that's grown has brought to the world. It's the concept of a product owner. I think it's widely adopted these days product owner. Yeah. It's terribly unfortunate because it didn't used to be
like that before scrum. One of the most serious, Hannah for stations here is pursuit of efficiency efficiency. Usually means maximize utilization of your resources. That means that people who are good Engineers should not do. Anything, but the engineering part, but you can't separate the engineering part. The idea is that if you maximize utilization, you're going to get the most value, the reality is that you will not be able to get value.
This idea of utilization, maximization is an accounting type concept that has no relevance to achieving the goals of an engineering effort. The utilization metric itself is a proxy. And it's a highly deceptive proxy. That leads you to make very unintelligent decisions. You have to respect the people. You have to help them grow. You have to give them the satisfaction of solving problems that they care about, if they don't care about it, no satisfaction.
If they simply Implement somebody else's solution, very weak satisfaction. So you also brought up this point. I mean, in parts of your writings, right? It's about giving the outcome
rather than managing the output. So when you mention about maximizing utilization, it's like you're managing them the priorities, the task, what they need to do, what they need to finish, but instead of that, the best way is actually to give them what the outcomes that they should achieve and let them solve the problems by themselves. Let them be capable. Yeah. Maybe you can you explain a little bit about this. How do you actually do it? How do you actually give the
people outcome based? Target or goals rather than managing them by priority, if an effort has been approved, there exists, rationale for why it should be done there, exist. Somebody that has outcome expectations somehow those get translated into proxies, but you stare almost every effort with some expectation of outcome and that's what should be transmitted all the way down till those smart engineers and say Here's an open. This is where we're trying to
keep two. Here is How we're going to know it's good. Like when we were given a process control system to design, we had typically a year. Maybe there would be a team of several Engineers with different Specialties. Here's the deadline. It has to be up by and it has to work. Well, it has to be maintained or whether plant Engineers The Operators have to accept and like it because if they don't, they're going to make product anyway, and they'll defeat your
system. And if they defeat your system, it's your problem. There's no intermediary, you get to blame. It's because you didn't understand them, well enough, if we would just give the software engineering team, the reasons, for which the outcomes, which the people are looking for. Then they could start moving the system towards those outcomes, they exist.
They're they're, they're hidden in all those layers of proxies because at the end it got chartered for a reason and the person chattering it knows that reason and we've separated Rated both that person and that reason from the team that's trying to achieve it. So if there's a theory, if I do these five tasks, then that outcome is going to be a cheap but who proves that before they start, nobody's in really expected to let's take a product manager who wants a certain
capability in a product. If you let them tell the engineering team, here's a capability. I'm looking for then they can figure that out. If you have them till the engineers, here's five tasks that you are supposed. Do and when those tasks get done a hope I get this result, but don't tell him the results. Then how does that person know that those tests are going to give that result when they are not even in the field, the people figuring out the tests. How are they gonna know?
So, how are you going to know with your prax eat that end result which starts out being there is actually going to be achieved by the intermediate results, you know, and so that's another reason why these intermediate results are pretty Adam, I guess this is what I suspect happens, right? We have this concept of product owner the proxies and then the company has a goal, a Target. And then the product owner will
try to translate that. Okay. This is the goal where they going to get the background in The Savvy and Technical knowledge to make the right translation. There will be a few. Yeah, but most of them that's not really what their child was the worst describe but that's what they're supposed to do. And even if they choose the right tests, if they don't
successfully conveyed. The why to the people who are doing it, the decisions that the people doing it, make day-to-day will not be Optimum towards that result. They have to understand why it's not just why overall, although why overall is critical, but what are you going to learn from each step along the way? Because you only learn when you get feedback, when you see the consequences of this Choice versus that choice, you have to break it down into little
pieces. And understand how each of these pieces is going to help you. Learn how to better achieve, the Big Y. And this comes back to one of the big Concept in lean, which is about optimizing flow. So when you have these short feedback loop where you can do something learn, maybe you can tell us a little bit more. Why is it important to optimize this flow? Well, it's this concept of pull have the results, pull the
thing. But after amazing Flo says you want, you don't want to do is start. Stuff, then you can finish work on multiple things. At the same time. What you want to do is go from start to finish quickly with as rapid flow as you can. So in manufacturing. The reason why we wanted flow was because when we knew what we wanted to pack out, we had a system to make sure that that's what we worked on. We did not build up any inventory.
Nothing got in the way, and we spent a whole lot of time making sure that nothing got in the way and it was responsibility of the production workers to go from. At the end of the week. We went up. Pack this O2, what am I going to do right now? So when you have flow, you have an ability to focus to concentrate to do the right thing. Because that's the only thing that is being expected right now because the pole system pulls
towards a goal. Whereas a scheduling system, looks at the great big mound of things, and it makes lots of inventory and piles of maybe documents or whatever in between, but it doesn't get something done when people have one thing to do and concentrate on it it. Was not only faster, but the quality is usually significantly better. So the concept of flow means one of the things you do not want to do is this concept of if I have a demand from a customer, I should put it on a back lot like
that's absurd. And then I start looking at the length of backlogs and then one year or two years and you spend time prioritizing and stuff like that. They lean you wanted what should I been doing right now? And I'm going to pull that. From the result that I'm expecting and I'm going to have a skiing where that pull can Cascade on down, to where the beginning of the process starts and it all points in time. You have more capacity Downstream. So you could always respond to a
pull request. So what happens is if we accept more work than we can do, we just get amount of junk that we can't act on it. By the time we get ever get around to it. It's not fresh anymore. People don't have the A problem anymore. They've gone off to do other things because you made them be distracted because they can accomplish what they want. It's very deceiving to tell somebody. Oh, it's on my back walk. I mean nobody wants their project on your back with nobody.
And so what you really want to do is you want to have a pull system, which says I am not going to accept any more work at any stage. Then that stage is capable of putting out. I'm going to allow myself a little buffer. So so I always have some work to do but not a big bus, only a small buffers long, as I can make it because that determines the speed with which I can respond to a request. So if I have a buffer between start to finish of like, say two weeks of work, I can respond to
requests in two weeks. I have a buffer. When we can work. I could respond to a request in a week. If I have one day of work in a buffer anywhere, I can respond to a request for sure in a day.
Now, would you rather that somebody be able to Respond to your question the day or that they would accept every single request coming at them and then create a five-week long list of things that they might do. Almost, everybody would rather know the rate at which things can be produced, and have the input demand gated to that rate because you can move so much faster. You can focus so much better and you can be so much more honest with the people who are
ordering. So if you make an order from a manufacturing plant, even if I'm Ordering a Lenovo computer if it's going to come from Hong Kong. I still get the ship date the day. I do the order. Okay, because they know the rate at which they could produce stuff, if it's acceptable for them to create a backlog. It's a slotted back. What they are producing at a given rate which they must maintain and they would not over premise. They might under-promise. They might be able to do it a
week faster. But manufacturing Smart Ones. They don't over promise. They never promised. Able to do something that they don't have the capacity for now, if we're producing it and any kind of cadence. We also know our capacity and if you know your capacity, you have absolutely no business, accepting work beyond the capacity. So let's pretend that you for a fact that you are able to do every week.
You release about five things. Okay, these three teams, they work together and every week by give or take a little bit things, come out. There is no way that team should accept. It more than by things a week, five requests and weaker, all that gets accepted because that's what's coming up. And they only have a small buffer in there. So we need to hate our demand and if we gate our demand, then we can respond immediately to it. We can get feedback, much, more
rapidly. We can say to customers. Oh, all right, we could do that and it'll be done in two weeks or we can say, oh, I wish I could do that. But, you know, I don't have the capacity and those are the only two reasonable request. We should be. Will the promised date our work? If we have flow, we understand the rate at which we can get typical sized things done and we should be able to plan around that rate and from estate. And if you can't do that, then your flow is probably accepting.
More work at some stage than is capable of that stage to produce. Almost every Workshop. We've done is focused around a value stream map value stream map is simply to the box and arrow diagram that Shows what tasks are required to do whatever the group does and has in it. The queues of Mary's been talking about all stacks of stuff waiting for the next task to get to it. But there's another critical thing that wastes enormous amounts of time and that is
approvals the approval process. Typically adds no value but it puts the Lays in which are huge often half the time it takes from when you start to when you get Did the production is approval time waiting for somebody to say? Yes, this is good, far better to get direct feedback from the place that is supposed to have goodness from it.
And let that place tell you is this good and if it's not you rapidly change it. So it's both the cues and the decisions, the approvals that are typically between 50 and 90 percent of the elapsed time between, will you? Start on something. And when you actually have it in production in, why do you need approvals?
If you already have a outcome that you are trying to achieve, you're really little is to set up the delivery of the outcome and feedback from the outcome to the team so they can decide what to do next. So, all you're approving is, this is a good outcome goal and it's worth this much money or this much time. And I will Charter a tea to spend that much money or that much time, two months Lively.
Whatever to achieve that goal and it will make it clear, what the goal is. And what steps towards it are? If they in their experience think that they can achieve that goal. And then I'm on a time and they're free, then that's what they work on. Outside of that approvals are necessary. Instead you Charter to achieve a business school. You don't approve a particular task toward that business goal because then you're making a decision.
Which of these texts are going to get us to the best business goal instead. Ed, you approve business goals and with the team figure that out. So, approvals of task-based work is like, again, it's not a good idea. You are interfering with the ability of the engineering team, to make decisions. So when I did a process control system, as I said, we having here, we had a team, some control Engineers with our boss who was basically an expert control engineer.
We had other people doing equipment, we work together, but inside of that year, there was no concept of approval of anything we have The budget, we had senior Engineers, with advice. We knew what we had to achieve. We would have run up the authorization for expenditure.
If it was over a certain amount to the board of directors or other ways to the end of engineering, we would get the approval and that was it. This project is worth doing, it's approved and then it would get scheduled or not and they would try very hard, not to approve stuff that they didn't have the resources beyond that approvals are just another waste of time. It lets people doing that.
Jungle the resources, of course mean that you need a cross-functional team, cross-functional, doesn't mean that you have both front-end and back-end Engineers or that. You also have testers on the team that needs that you have operations, representative means that you have customer support represented. It means that you have all of the things that are going to be impacted whose perspectives are important to merge in coming up with a solution.
And surely if you have brought of people there's nice To be a product person, a solution needs to be negotiated within the team rapidly without waiting for somebody outside who has other responsibilities. The team itself has a single responsibility. So approvals. Inside a team are typically, let's try an experiment and see what the feedback tells us not. Let's go talk to some graveyard and get their permission to proceed. If so, don't get me wrong. There's a great need for good
product people. It's just that their job is not to serve as a proxy. Their job is to bring their product knowledge to a cross-functional team. They are not generally the leader. Now. Remember, we were working with a bank in Amsterdam and they had developed teams. All of their team leaders were designers. They were doing mostly design of new cell phone type. They wanted their interface, both on the web and on the phone. To be very nice for customers to
use. The teams were led by designers, the ones who knew the best. If you've ever worked with a designer and you know, that they don't have one answer to a problem. They try to fix what a concept. Correct. That doesn't mean that there were people who understood, they had people who used an artificial intelligence to examine prominence, and the bank comment system and all that kind of stuff.
So, those channel of information came to the team, but it wasn't this one person responsible for figuring Going out which was important. It was the teen with feedback figuring out how to accomplish the overall goal, best feedback and discussion amongst the different disciplines inside of the team. Why observation is in a team? There's usually three roles that should have conflict and that's quality engineering and product. They represent a different way
of looking at the world. They should not always agree. They should have discussions about to reach the Stole which one of our perspectives on this problem is the most important. They should have good faith discussions and how they're going to proceed to reach the best. Overall result. Typically. None of them are really going to be the right person. In fact, if you look at team leadership, which used to be a good idea until spring me, that a bad idea.
If you look at team leadership, typically really good successful teams have a pair of people. Sometimes this role is in. One person, but typically there's a product or Market role and there is a technical role. If you have two liters of tech lead and a market lead which we often had on our teams at 3M. The thing that they need to do is have a complete agreement on their shared goal and fair arguments Fair fights. Therefore, neither the tech lead nor the pratically should have
their opinion. Be the one that is, of course, everybody follows. They should have arguments. They should have They should have their flights. And if one of those two leads is Junior to the other one, there's no fair fight. Doesn't happen. I have see some of the really good teams. They tend to have two or three. If it's a lot of user interface on design lead, is another way to have an important lead. The oldest people need to be able to have Fair fights
arguments disagreements. They're disciplined background will absolutely cause that. So they have to take their discipline background based on feedback so far and ultimate goal. And decide amongst themselves, which of us in this case is going to have are disagreeing opinion Prevail generally speaking. When they're headed for the same goal. They can have a lot of fights about which is the best way to
achieve that goal. But if they're really joined at the hip and working together, they'll figure out either. This is the right way or we can't decide. So we need to do two experiments. Those are both really liable options. Okay, if they can't agree, they could try to approach us. That's not the way we've structured our development and that's unfortunate. It doesn't appear efficient right test. It's a lot like a successful marriage or a successful family. Same principles.
So thanks for sharing all this. I think we today listen and learn so many things about how we should optimize flow. How they are some anti patterns that we should avoid like proxies managing the utilization or tasks and priorities of the team and all that really appreciate all that. So unfortunately due to To time, we have to capture this exciting
discussion. But before I let both of you go, I don't really have one question that I always ask my guests, which is to share this thing called three technical leadership. Wisdom is for us to learn anything with them. Just from you, what we can do better in our role or in our day-to-day job. Okay, so I'm going to just give one and is the principle of responsibility. So the head of SpaceX launch
director. The Tory says that space except It's on the principle of responsibility, which means that everybody accepts responsibility for a component of the space shuttle launch, and they understand the role that component has to play in the overall goal. They are responsible for both proper, excellent operation of their components and it's contributing correctly and successfully to the overall goal.
So they have to understand both. There is a principal engineer that is responsible that if you work on the principle. Simple of responsibility, which is fractal. It can be passed down to some teams and make the team to responsible for results. Then this concept of making the responsible is first of all, very fun way to work for the team's. But it's also a very as notorious as there is no Engineering Process anywhere.
Ever has been discovered to be more effective and create better results than the principle of responsibility. I'd add a couple of man, which we've talked about one is the Hold on. Push you can't pull from the bottom. The other is respect people and that is what waste their time. Help them grow. Help them, do meaningful things. Whenever systems you have that you use to get your goals accomplished.
The most critical aspect is that the respect, the people who are implementing it. Thanks for all this wisdom. So I really like the respect people sometimes, for whatever reasons that line pressure and all that we can to, you know, focus on the Just finishing tasks and all that rather than respecting the people and make them do their job properly, rather than following the orders. If people want to find out more about you or maybe learn further. Where can they find you online
both of you? Well, I have a website but probably the most recent stuff is in my blood which is lean essays.com, anything different for you. Tom. Our most recent stuff is always podcasts. Like the one you're listening to right now. Cool. Really. Thanks so much for your time. Today. I have learned. From this conversation. I really appreciate that. Thanks, Mary, and Tom. Thank you.
Thanks again, I guess. 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 are 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 tackling Journal .f website, including the full transcript. I think words and links to the resources mention from the conversation. And lastly, make sure to subscribe to the show's mailing list on pack leader dot f to get notified for any future episodes. Stay tuned for the next technology. No episode. And until then. Goodbye.