#91 - Lean Software Development Principles and Mindset - Mary & Tom Poppendieck

 

 

“Pull, don’t push. Don’t tell people what to do. Tell them what results you want and let them figure out how best to achieve the outcome that’s needed."

Mary & Tom Poppendieck are the co-authors of several books related to Agile and Lean, including their award-winning book “Lean Software Development: An Agile Toolkit” published in 2003. In this episode, Mary & Tom shared about lean software development, its principles and mindset, and the concept of a pull system. Mary & 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 & Tom talked about the concept of flow, why it is important to optimize flow, and how to optimize flow by analyzing the value stream map and minimizing approval process.  

Listen out for:

  • Career Journey - [00:05:26]
  • Lean Software Development - [00:18:50]
  • Pull, Don’t Push - [00:23:34]
  • Proxies - [00:31:00]
  • Managing by Outcome - [00:37:10]
  • Optimizing Flow - [00:41:18]
  • Value Stream Map & Approvals - [00:47:00]
  • 3 Tech Lead Wisdom - [00:55:05]

_____

Mary Poppendieck’s Bio
Mary Poppendieck’s first job was programming the #2 Electronic Switching System at Bell Labs in 1967. She programmed minicomputers to control high energy physics experiments at the University of Wisconsin during the 1970’s. Moving to 3M, Mary developed digital systems to control roll-goods processes, spearheaded one of the first Just-in-Time production systems in the company, and led new product development teams which commercialized products ranging from digital controllers to lighting systems.

Upon retiring from 3M in 1998, Mary was surprised to discover that the typical software development process was quite different than the engineering-inspired approach she had found effective with control systems. So she wrote the now-classic book “Lean Software Development: an Agile Toolkit”, proposing an approach which focuses on customers, respects software engineers, concentrates on learning, and leverages flow. Mary is a popular writer and speaker. Sequels of her first book include “Implementing Lean Software Development: from Concept to Cash”, “Leading Lean Software Development: Results are Not the Point” and “The Lean Mindset: Ask the Right Questions”.

Tom Poppendieck’s Bio
Tom Poppendieck has over three decades of experience in computing including several years of work with object technology. His modeling and mentoring skills are rooted in his experience as a physics professor. His early work was in IT infrastructure, product development, and manufacturing support, and evolved to consulting project assignments in healthcare, logistics, mortgage banking, and travel services. Tom holds a PhD in Physics and has taught physics for ten years. He is the coauthor of four books: “Lean Software Development” (2003), “Implementing Lean Software Development” (2006), “Leading Lean Software Development” (2009) and “Lean Mindset” (2013).

Follow Mary and Tom:

Mentions & Links:

 

Our Sponsor - Skills Matter
Today’s episode is proudly sponsored by Skills Matter, the global community and events platform for software professionals.
Skills Matter is an easier way for technologists to grow their careers by connecting you and your peers with the best-in-class tech industry experts and communities. 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.
Head on over to skillsmatter.com to become part of the tech community that matters most to you - it’s free to join and easy to keep up with the latest tech trends.
Our Sponsor - Tech Lead Journal Shop
Are you looking for a new cool swag?
Tech Lead Journal now offers you some swags that you can purchase online. These swags 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 swags available by visiting techleadjournal.dev/shop. And don't forget to brag yourself once you receive any of those swags.

 

Like this episode?
Subscribe and leave us a rating & review on your favorite podcast app or feedback page.
Follow @techleadjournal on LinkedIn, Twitter, and Instagram.
Pledge your support by becoming a patron.

 

Quotes

Career Journey

  • 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 ago. You do what’s the current technical capability allows you to do.

  • 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 late 1990 problems, and we haven’t walked away from it and said, “What are today’s problems?” That’s what I’ve been trying to do for the past 20 years. When I wrote my first books, I was talking about 1990s problems. As I 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.

  • When you have a long feedback loop, you have to be really careful. If you put in relatively quick feedbacks on 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 that’s really important. And that’s actually one of those fundamental principles that hasn’t changed. The faster I, as a programmer, can get feedback, the better a job I can do and the more comfortable I am.

  • I think [understanding deep internals] is part of engineering. It’s doing something important and know you’re doing it right. Being able to do something, think it’s going to work, run a very sophisticated test 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. Because it feels so good to have done something right, that’s important to the system. It’s not just feedback that you’ve done something right. It’s like, it’s the fun of doing software development in general.

Lean Software Development

  • The reason it worked was because we designed that pull system. The people that were doing the work design the details of every piece of the system, because we’re not here to tell them what to do. And there weren’t any lean consultants, thank God, that would tell you what to do.

  • They knew what to do because they had designed the system in the first place. It was their work, and they understood the reasoning behind everything.

  • 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.

Pull, Don’t Push

  • Pull, don’t push. 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 how best to achieve the outcome that’s needed.

  • It’s not going to 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 figure out how to accomplish. If you don’t have that environment, that doesn’t get pushed up from the bottom.

  • You have to remember the senior 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 crisis for people to realize that what we’ve done up till now isn’t going to cut it in the future.

  • The thing I found the best thing to do is look for some problem that a person has. Some crisis is clearly going to attack them, and see if they believe that that is a crisis, and then offer a way out of the impending doom. If you can’t do that, I haven’t seen it a whole lot of seriously good changes. So I don’t see how engineers can talk their bosses into thinking differently.

  • 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 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.

Proxies

  • I first got the word and the idea from a letter to shareholders by Jeff Bezos. He talked about what is day one. He’s always saying we’re still in day one. Day one means you’re in startup mode. You’re still acting like a startup. And then he listed the things, the four things that you had to do to stay in day one, because day two, you start dying.

  • One of the things you had to do was to avoid proxies. So what you need to do is to get the people doing the work in direct connection with the people for whom they are doing the work.

  • Teams have leaders, but they don’t have somebody telling the team what to do. They expect to have people that are going to be responsible for the results dealing directly with solving the problems.

  • In fact, most engineering, it does not operate with proxies. When you have a proxy in there, you take the responsibility off the team for thinking of good ideas and you don’t allow them to use their smart, intelligent capabilities to design solutions based on the technology that they understand.

  • First of all, that 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 an engineer in the same field. How can they know enough to come up with the best solution when they never programmed any code, for example, or they’ve never done any kind of engineering?

  • We have developed in software the concept that there needs to be an expert between the engineers and 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 got to stop this having somebody tell a team what to do. Setting priorities for a team, that’s absurd.

  • If you want to know the biggest mistake, the biggest bad thing that Scrum has brought to the world, it’s the concept of a product owner.

  • One of the most serious manifestations 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.

Managing by Outcome

  • If an effort has been approved, there exists a rationale for why it should be done. There exists somebody that has outcome expectations. Somehow, those get translated into proxies. But you start almost every effort with some expectation of outcome. And that’s what to be transmitted all the way down to those smart engineers and say, “Here’s an outcome. This is where we’re trying to get to. Here’s how we’re going to know it’s good.”

  • 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 there. They’re hidden in all those layers of proxies. Because in the end, it got chartered for a reason. And the person chartering it knows that reason. And we’ve separated both that person and that reason from the team that’s trained to achieve it.

  • If there’s a theory, if I do these five tasks, then that outcome is going to be achieved. But who proves that? Before they start, nobody’s really expected to.

  • How are you going to know with your proxies that end result which starts off being there? It’s actually going to be achieved by the intermediate results. You don’t.

  • And even if they choose the right tasks, if they don’t successfully convey the “why” to the people who are doing it, the decisions that the people doing it made day to day will not be optimum towards that result. They have to understand why.

  • 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 why?

Optimizing Flow

  • This concept of pull: Have the results, pull the thing. Optimizing flow says what you don’t want to do is start more stuff than 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 a flow as you can.

  • 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 pull system pulls towards a goal, whereas a scheduling system looks at a great big amount 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 goes not only faster, but the quality is usually significantly better.

  • 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 backlog.

  • In lean, you want to know what should I be doing right now? I’m pulling that from the result that I’m expecting. And I’m going to have a scheme where that pull can cascade on down to where the beginning of the process starts. And at all points in time, you have more capacity downstream. So you can always respond to a pull request.

  • So what happens is if we accept more work than we can do, we just get an amount of junk that we can’t act up. By the time we get ever get around to it, it’s not fresh anymore. People don’t have the same problem anymore. They’ve gone off to do other things because you made them be distracted cause they can’t accomplish what they want.

  • Nobody wants their project on your backlog. 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 than that stage is capable of putting out. I’m going to allow myself a little buffer. So I always have some work to do. But not a big buffer, only a small buffer, as long as I can make it, because that determines the speed with which I can respond to a request.

  • 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.

  • If we’re producing it in any kind of cadence, we also know our capacity. And if you know your capacity, you have absolutely no business accepting work beyond that capacity.

  • We need to gate our demand. And if we gate our demand, then we can respond immediately to it. We can get feedback much more rapidly.

  • We should be able to promise date our work. If we have flow, we understand the rate at which we can get typical size things done, and we should be able then to plan around that rate and promise date. 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.

Value Stream Map & Approach

  • Value stream map is simply a box scenario diagram that shows what tasks are required to do whatever the group does and has in it the queues. All the 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 delays in which are huge. Often, half the time it takes from when you start to when you get into production is approval time. So it’s both the queues and the decisions, the approvals that are typically between 50 and 90% of the elapsed time between when you start on something and when you actually have it in production.

  • And why do you need approvals? If you already have an outcome that you were trying to achieve, your real goal 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.

  • 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 team to spend that much money or that much time to achieve that goal. And then we’ll make it clear what the goal is and what steps towards it are. Outside of that, approvals aren’t necessary.

  • Instead, you charter to achieve a business goal. You don’t approve a particular task toward that business goal, because then you’re making a decision, which of these tasks are going to get us to the best business goal? Instead, you approve business goals and let the team figure that out.

  • Approvals of task-based work are not a good idea. You are interfering with the ability of the engineering team to make decisions.

  • 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. It means that you have the operations representative. It 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 product people, there needs to be a product person.

  • The 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 and experiment and see what the feedback tells us. Not let’s go talk to some gray beard and get their permission to proceed.

  • 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.

  • My observation is in a team there are 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 this goal, which one of our perspectives on this problem is the most important? They should have good faith discussions on how they’re going to proceed to reach the best overall result. Typically, none of them are really going to be the right person.

  • 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. 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 product lead should have their own opinion, to be the one that is, of course, everybody follows. They should have arguments. They should have discussions. They should have their fights. And if one of those two leads is junior to the other one, there’s no fair fight.

  • Those people need to be able to have fair fights, arguments, disagreements. Their discipline 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 our disagreeing opinion prevail.

  • Generally speaking, when they’re headed for the same goal, they can have a lot of fights about what 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 viable options.

3 Tech Lead Wisdom

  1. The principle of responsibility.

    • SpaceX operates on the principle of responsibility, which means that everybody accepts responsibility for a component of the space 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 component, and it’s contributing correctly and successfully to the overall goal. So they have to understand both.

    • If you work on the principle of responsibility, which is fractal, it can be passed down to some teams and make the teams responsible for results. Then this concept of making them responsible is, first of all, very fun way to work for the teams.

    • But it’s also a very, as Muratore says, there is no engineering process anywhere ever has been discovered to be more effective and create better results than the principle of responsibility.

  2. Pull, don’t push. You can’t pull from the bottom.

  3. Respect people.

    • Don’t waste their time. Help them grow. Help them do meaningful things. Whatever systems you have that you use to get your goals accomplished, the most critical aspect is that you respect the people who are implementing it.
Transcript

[00:01:11] Episode Introduction

Henry Suryawirawan: Hello, my friends and listeners. Welcome to the Tech Lead 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 Tech Lead Journal 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, support me by subscribing as a patron at techleadjournal.dev/patron.

Today, I am excited to share my conversation with another great thought leaders and pioneers in the software industry. My guests for today’s episode are Mary and Tom Poppendieck. They are the co-authors of several books related to Agile and Lean, including their award-winning book “Lean Software Development: An Agile Toolkit” published in 2003. In this episode, Mary and Tom shared about lean software development, 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, why 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 two so-called anti-patterns to lean, which are having proxies and requiring approvals. If you also enjoy 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.

[00:04:54] Introduction

Henry Suryawirawan: Hey, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today I have with me two guests in one episode, and both are big names in software industry. They wrote books on “Lean Software Development” a long time ago, and they’ve been preaching that for quite some time now. 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 discussing about lean software development or anything that you are working on lately. So welcome Mary and Tom.

Mary Poppendieck: It’s good to be here.

Tom Poppendieck: Indeed.

[00:05:26] Career Journey

Henry Suryawirawan: So I always like to start my conversation by asking about your journey, your 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?

Mary Poppendieck: Sure. I started at my actual first program was in 1967. I was a junior in high school and I went to a science summer camp, where 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 typed those into punch cards. My program was one of the later ones run and I watched program after program. We traveled 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 n-factorial or something like that, because they said you can do a hard one here, so here’s one. And then it printed another line and then it got slower and then it got slower. And I said, “Oh, I guess it must have hung up.” And they were about to stop the computer and it printed another line. So it was 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 that 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 zero and one, and every single zero and one matched the intention in the assembly language, and that the assembly language matched the front language, the concept that I had. 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 assembly 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. Cause we had the goal of a maximum downtime of two hours in 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. My 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 carton and seeing if my diagnostic could determine which card. So I didn’t necessarily worry too much about all of the details being perfect, because if it didn’t compile, if 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 guy who scrounged up for money in the 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 console with individual lights that I could read the code while watching the lights go by. I learned very quickly, first of all, I started programming in assembly language, but once we got the compiler more or less working, I discovered that if I programmed in Fortran, because the speed was so important, I 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 the things were right became one step easier because I could get all of the logic proven out in Fortran.

The next thing I did was I programmed computers that was typically in BASIC that did process control systems. And we always tested our stuff by having, in our engineering lab, mockups of the equipment. And then I would go in and I was 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 process controls. Our tool was mini computer which is now embedded chips. But at that time it was like that big. So then the next thing I did was I worked in a manufacturing plant at 3M. 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 higher and higher level languages. I always knew how the underlying system work because I grew 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 Gilb, 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 inspection because the computer caught me. I’m following this throughout 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 ago. You do what’s the current technical capability allows you to do.

Now, just as a conclusion, after I retired from 3M in end of 98, early 99, and started my own company, I haven’t actually developed code except maybe some controls in our 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 late 1990 problems, and we haven’t walked away from it and said, “what are today’s problems?” That’s what I’ve been trying to do for the past 20 years. When I wrote my first books, I was talking about 1990s problems. As I 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.

Henry Suryawirawan: 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.

Mary Poppendieck: So when you have a long feedback loop, you have to be really careful. If you put in relatively quick feedbacks on 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 snap your hand so fast that you’ll learn how to do it really quickly. And that’s really important. And that’s actually one of those fundamental principles that hasn’t changed. The faster I, as a programmer, can get feedback, the better a job I can do and the more comfortable I am.

Henry Suryawirawan: So maybe Tom, you have also other fascinating story that you want to share with us from your background or your journey.

Tom Poppendieck: My first contact with computing was in the fifties when I was in grade school. I became aware of what computers were and that they needed to 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 Wang 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 know more. So I went to graduate school and when I got to my thesis, I had a bunch of calculations that needed to be done. There, I used Fortran. 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 plotter so I wrote my own. The important thing was that I was able to punch the cards, put them in the card reader, see the printout and, in a very short time, see how I screwed up. The rapid feedback is absolutely critical. Those were back in the days when the computer I have in my pocket and my smartphone was about the size of a university computer, the same one that Mary’s software eventually fit into.

Mary Poppendieck: 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, plain old calculator. And it was this big and that wide. And he had a calculator the size of a desk and he loved it!

Tom Poppendieck: From there, after I got my degree to teach at a university here in Minneapolis St. Paul area. One of the courses I taught was electronics. I also thought Pascal, predecessor to Java, and got more into the abstract of programming about the time when I started here at 3M. That led to bringing DEC 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 courses in astronomy for a self-paced astronomy course. So that was an 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 tout.

I went from there to work for Honeywell design, helping with the group that supported design of the navigation systems for commercial airplanes. If you fly a Boeing or an Airbus or several other major airplanes, you were probably navigated by the inertial navigation system or the load balancing system that our plant here in Minnesota produced. Learned a lot because there, it’s absolutely critical that you do things right. The automated fault detection not only for the software but also for hardware failures that has 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 for a company that, when I joined, was helping companies adopt object-oriented development. Initially, that was Power Builder, but it rapidly evolved, and I taught my company how to use Java. Most of them were better programmers than I was, and rapidly outpaced me, but I got them started. Consulted at a lot of major companies around the world from that position. And then retired to join Mary in the business that we have run now for 20 some years.

Henry Suryawirawan: Really nice story. But one thing that I am curious, when did you both meet?

Mary Poppendieck: Ah, we met at Marquette University in 65, Fall of 65.

Tom Poppendieck: We became physics lab partners.

Henry Suryawirawan: Wow. Okay.

Mary Poppendieck: 67 was not my first computing. That was my first job computing at Bell Labs. And we met two years before that.

Henry Suryawirawan: Thanks for sharing the story, the background. So one thing, if there’s any thread 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?

Mary Poppendieck: I think that’s part of engineering. It’s doing something important and know you’re doing it right. It’s not fun to find out a long time later that you have to drop everything and fix something from six months ago or whatever. That’s not fun. But being able to do something, think it’s going to work, run a very sophisticated test 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 3M when I was very first programming. Something would work on a test. And I said, “Yes!” And everybody looked like, “what’s going on?” Because it feels so good to have done something right, that’s important to the system. It’s not just feedback that you’ve done something right. It’s like, it’s the fun of doing software development in general.

[00:18:50] Lean Software Development

Henry Suryawirawan: So from that background, you wrote the book, a long time ago now, “Lean Software Development”. How did you start with all these principles about lean software development, which kind of like borrowed from the manufacturing side, right? So maybe if you can tell us briefly the story of how you came up with that.

Mary Poppendieck: Well, I was in 3M and I got hired into a plant for which I had done a process control system, and it was really successful. It was an outsourcing project that I managed the outsourcing part and made sure that they were on time and on budget out of the 12 month million dollar project, which was unheard of, but they worked. They hired me in the plant 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 then 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 Japanese competition, just wiped out. They could sell stuff for cheaper than we could make it for.

So we had to do something dramatic and fast. So what we started doing was reading the early books on lean that were coming out of Japan. I had one of the early ones. That’s the worst translation of Shigeo Shingo’s first book. So we started studying those books, including this badly translated green book. And we started saying, well, how would this work in our plant? Now, we didn’t have a discrete parts plant. We had a raw goods plant. So we sat to apply the principles, not the stuff they actually did. At one point, we decided to go do a pull system scheduling rather than a push system scheduling. We created a Kanban system simply by trial and error and running simulations. When we cut over, we had an amazingly successful cut over. Already, my process control systems were getting rid of a lot of waste. That million dollar system paid for itself in the first month. Because they used the data to do a statistical analysis on problems, and then they could find sources of problems.

So when we went to a pull system at that point in time, we had about 66% accuracy and packed out against the plan per week. That 66% success against detailed plan is also pretty typical in project management. If you have a great big 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 plan, but instead of 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 post system, just like we read about in the book. And we switched. We couldn’t figure out how to switch the part of the plant over. So we switched the entire plant 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 Sunday. So on Sunday, we switched the whole system to a paper-based Kanban card whole system for our scheduling. That week we packed out like 95% against plan. And it just got better.

Now, the reason it worked was because we designed that pull system and we gave our simulation, which was little sticks 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 Kanban system. The people that were doing the work design the details of every piece of the system, because we’re not here to tell them what to do. And there weren’t any lean consultants, thank God, that would tell you what to do. So the 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 the reasoning behind everything because they designed it themselves with simulations, and so it just worked.

It got better because the glitches, they quickly smoothed out. But the whole system was designed by the people on the floor using it. I became convinced that was the way we built. That post systems 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 am absolutely sure of today, I don’t see it widely used that way, but it’s the only way. I ran into so many people that say, “Well, we tried to do this pull system. It didn’t work.” I said, “Yeah, you had consultants come in, right?” “Yeah.” “Well, that’s why it didn’t work.” Real simple. You always thought the consultants were bad. Because if you needed a consultant, that meant you couldn’t do your own job.

[00:23:34] Pull, Don’t Push

Tom Poppendieck: Pull, don’t push.

Mary Poppendieck: Yes.

Tom Poppendieck: 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 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.

Henry Suryawirawan: 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 side. So how can we translate this? Okay, please don’t push more and more demands. Involve us at the low level, the engineers to actually be involved, design the system, do more pull based rather than push based. So maybe from your experience doing consulting and helping people, any tips that you want to give for stakeholders?

Mary Poppendieck: Okay. I mean, you can’t. It’s not going to 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 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 lean, 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 US 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 drag him there so he understands. So he went there, and he spent the entire two days side by side with the ops 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 impressed and he said, “We could do this.” And if you don’t have that at the senior level, and the only reason he went there, 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 have wanted to change what they do. First of all, you have to remember their senior 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 crisis for people to realize that what we’ve done up till now isn’t going to cut it in the future. I mean, that’s what happened in other plant. We invented videotape. All of the broadcast videotape in the country. And the fact we’re mostly around the world was 3M tape. And yet, we were about to get kicked out of the industry. We realized that and started saying we’ve got to do something drastic because the incremental approaches 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 until now, and doesn’t really want to abandon that unless something, not you, but something else is forcing them.

So the thing 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 that is a crisis, and then offer a way out of the impending doom. If you can’t do that, I haven’t seen it a whole lot of seriously good changes. So I don’t see how engineers can talk their bosses into thinking differently.

Tom Poppendieck: 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 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.

Mary Poppendieck: 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. All of us as a group. When suddenly the industry is attacked, we saw this in telecom. 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 shook up so many banks, and the fintech companies started attacking the big bank’s fee system, and fee 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 got to know this. 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 being used properly, you could monitor if there’s a fire. When you start using the internet of things in conjunction with different concepts of insurance, you can dramatically change the risk game. And your computers and your smart scientists 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, “Wow, we’ve got to change.” And we have seen companies that have said, “Wow, we’ve got to change.” And the 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 spot? Where is it going to get? Where is its current strength going to become much less relevant? And you head that way, you will find that there are people in senior management that give 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 boost. There are, however, people whose jobs change or disappear when you add any kind of different strategies. I mean, I can remember talking to a healthcare company. We had like 15 or 20 people of the management team there, and about a quarter of them in prior 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. That’s impossible for people to hear that.

[00:31:00] Proxies

Henry Suryawirawan: Which brings to one of the topics that you mentioned, it’s about proxies. So these days you have been writing and talking a lot about proxies in the business world. No matter what companies, this kind of proxies exists. Either it’s business analysts, quality engineer, test engineer, product owners and all that. So you have a strong point of view about the existence of these proxies. Maybe you can share with us. What’s the problem with having these proxies?

Mary Poppendieck: I first got the word and the idea from a letter to shareholders by Jeff Bezos. He talked about what is day one? He’s always saying we’re still in day one. Day one means you’re in startup mode. You’re still acting like a startup. And then he listed the things, the four things that you had to do to stay in day one, because day two, 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 in 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 do engineering, they don’t have proxies. They expect to have people that are going to be responsible for the results dealing directly with solving the problems.

In fact, most engineering, it does not operate with proxies. 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 for thinking of good ideas and you don’t allow them to use their smart, intelligent capabilities to design solutions based on the technology that they understand.

First of all, that 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 an engineer in the same field. How can they know enough to come up with the best solution when they never programmed any code, 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 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 designed control systems, there was nobody in between 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 the engineers and 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 cost, and they were 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 came along, which is where I started programming in the engineering department. We wouldn’t hear 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 that coached 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 me, that’s like losing so much of their capability and also making their life so much less fun than it could. Pleasant. Challenging. Interesting. So we got to stop this having somebody tell a team what to do. Setting priorities for a team, that’s absurd. If you want to know the biggest mistake, the biggest bad thing that Scrum has brought to the world, it’s the concept of a product owner.

Henry Suryawirawan: I think it’s widely adopted these days, product owner.

Mary Poppendieck: Yeah. It’s terribly unfortunate. Because it didn’t use to be like that before Scrum.

Tom Poppendieck: One of the most serious manifestations 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.

[00:37:10] Managing by Outcome

Henry Suryawirawan: 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 mentioned about maximizing utilization, it’s like you’re managing them, the priorities, the tasks. 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.

Mary Poppendieck: Let them be capable.

Henry Suryawirawan: Yeah. Maybe 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?

Mary Poppendieck: If an effort has been approved, there exists rationale for why it should be done. There exists somebody that has outcome expectations. Somehow, those get translated into proxies. But you start almost every effort with some expectation of outcome. And that’s what to be transmitted all the way down to those smart engineers and say, “Here’s an outcome. This is where we’re trying to get to. Here’s how we’re going to know it’s good.” Like when we were given the process control system to design, we had typically a year. Maybe there’d be a team of several engineers with different specialties. Here’s the deadline that has to be up by, and it has to work well. It has to be maintainable by the 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 there. They’re hidden in all those layers of proxies. Because at the end, it got chartered for a reason. And the person chartering it knows that reason. And we’ve separated both that person and that reason from the team that’s trained to achieve it. So if there’s a theory, if I do these five tasks, then that outcome is going to be achieved. But who proves that? Before they start, nobody’s 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 the capability I’m looking for, then they can figure that out. If you have them tell the engineers, here’s five tasks that you were supposed to do, and when those tasks get done, “Hey, hope I get this result.” But don’t tell them the results. Then how does that person know that those tasks are going to give that result when they’re not even in the field, the people who are figuring out the tasks? How are they going to know? So how are you going to know with your proxies that end result which starts off being there? It’s actually going to be achieved by the intermediate results. You don’t. And so that’s another reason why these intermediate results are pretty dumb.

Henry Suryawirawan: 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.

Mary Poppendieck: Where are they going to get the background and the savvy and the technical knowledge to make the right translation? There will be a few. Yeah. But most of them, that’s not really what their job was. Nowhere is described, but that’s what they’re supposed to do.

Tom Poppendieck: And even if they choose the right tasks, if they don’t successfully convey the “why” to the people who are doing it, the decisions that the people doing it made 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 why?

[00:41:18] Optimizing Flow

Henry Suryawirawan: And this comes back to one of the big concept in lean, which is about optimizing flow. So when you have this 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?

Mary Poppendieck: Well, it’s this concept of pull. Have the results, pull the thing. But optimizing flow says what you don’t want to do is start more stuff than 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 a 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 the responsibility of the production workers to go from, at the end of the week we want to pack this out to 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 pull system pulls towards a goal, whereas a scheduling system looks at a great big amount 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 goes 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 backlog. 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.

In lean, you want to know what should I be doing right now? And I’m going to pull that from the result that I’m expecting. And I’m going to have a scheme where that pull can cascade on down to where the beginning of the process starts. And at all points in time, you have more capacity downstream. So you can 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 up. By the time we get ever get around to it, it’s not fresh anymore. People don’t have the same problem anymore. They’ve gone off to do other things because you made them be distracted cause they can’t accomplish what they want.

It’s very deceiving to tell somebody, oh, it’s on my backlog. I mean, nobody wants their project on your backlog. 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 than that stage is capable of putting out. I’m going to allow myself a little buffer. So I always have some work to do. But not a big buffer, only a small buffer, as 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 request in two weeks. I have a buffer of one week of 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 request in a 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 can produce stuff. If it’s acceptable for them to create a backlog, it’s a slotted backlog. They are producing at a given rate, which they must maintain. And they would not over promise. They might under promise. They might be able to do it a week faster, but manufacturing smartphones, they don’t over promise. They never promised to be able to do something that they don’t have the capacity for.

Now, if we’re producing it in any kind of cadence, we also know our capacity. And if you know your capacity, you have absolutely no business accepting work beyond that capacity. So let’s pretend that 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 five, give or take a little bit, things come out. There’s no way that team should accept more than five things a week. Five requests a week are all that get accepted because that’s what’s coming up, and they only have a small buffer in there.

So we need to gate 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 can do that, and it will be done in two weeks.” Or we can say, “How I wish I could do that. But, you know, I don’t have the capacity.” And those are the only two reasonable requests. We should be able to promise date our work. If we have flow, we understand the rate at which we can get typical size things done, and we should be able then to plan around that rate and promise date. 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.

[00:47:00] Value Stream Map & Approvals

Tom Poppendieck: Almost every workshop we’ve done is focused around a value stream map. Value stream map is simply a box scenario diagram that shows what tasks are required to do whatever the group does and has in it the queues that Mary’s been talking about. All the 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 delays in which are huge. Often, half the time it takes from when you start to when you get into 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 queues and the decisions, the approvals that are typically between 50 and 90% of the elapsed time between when you start on something and when you actually have it in production.

Mary Poppendieck: And why do you need approvals? If you already have a outcome that you were trying to achieve, your real goal 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 team to spend that much money or that much time. Two months, five weeks, whatever to achieve that goal. And then we’ll 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 in that amount of time and they’re free, then that’s what they work on. Outside of that, approvals aren’t necessary.

Instead, you charter to achieve a business goal. You don’t approve a particular task toward that business goal, because then you’re making a decision, which of these tasks are going to get us to the best business goal? Instead, you approve business goals and let 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 had a year. We had a team. Some control engineers with a boss who was basically an expert control engineer. We had other people doing equipment. We worked together. But inside of that year, there was no concept of approval of anything. We had to 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. So they kind of engineer it. We would give 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 for. Beyond that, approvals are just another waste of time. And lots of people doing their job, though.

Tom Poppendieck: 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. It means that you have operations representative. It 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.

Mary Poppendieck: And surely if you have product people, there needs to be a product person.

Tom Poppendieck: The 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 and experiment and see what the feedback tells us. Not let’s go talk to some gray beard and get their permission to proceed.

Mary Poppendieck: Yeah. So don’t get me wrong. There’s 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. I 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, you know that they don’t have one answer to a problem. They try things. What a concept, right? That doesn’t mean that there weren’t people who understood. They had people who used an artificial intelligence to examine comments and the bank comments system and all that kind of stuff. So those channels of information came to the team, but it wasn’t this one person responsible for figuring out which was important. It was the team with feedback, figuring out how to accomplish the overall goal best. Feedback and discussion amongst the different disciplines inside of the team.

My 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 this goal, which one of our perspectives on this problem is the most important? They should have good faith discussions on 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 Scrum made it 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 leaders, a 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 product lead should have their own opinion be the one that is, of course, everybody follows. They should have arguments. They should have discussions. They should have their fights. And if one of those two leads is junior to the other one, there’s no fair fight. Doesn’t happen. I’ve seen some of the really good teams, they tend to have two or three. If it’s a lot of user interface, a design lead is another way to have an important lead.

Those people need to be able to have fair fights, arguments, disagreements. Their discipline 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 our disagreeing opinion prevail. Generally speaking, when they’re headed for the same goal, they can have a lot of fights about what just 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 viable options. Okay. If they can’t agree, they can try two approaches. But that’s not the way we’ve structured our development. And that’s unfortunate.

Tom Poppendieck: It doesn’t appear efficient. It’s a lot like a successful marriage or a successful family. Same principles.

Henry Suryawirawan: So, thanks for sharing all this. I think we today listen and learn so many things about how we should optimize flow. How there 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.

[00:55:05] 3 Tech Lead Wisdom

Henry Suryawirawan: So unfortunately, due to time, we have to cut short this exciting discussion. But before I let both of you go, I normally have one question that I always ask my guests, which is to share this thing called three technical leadership wisdom. It’s for us to learn anything, wisdom, gist from you, of what we can do better in our role or in our day-to-day job.

Mary Poppendieck: Okay. So I’m going to just give one, and that is the principle of responsibility. So, the head of SpaceX launch director, Muratore, says that SpaceX operates on the principle of responsibility, which means that everybody accepts responsibility for a component of the space 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 component, 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 for that.

If you work on the principle of responsibility, which is fractal, it can be passed down to some teams and make the teams responsible for results. Then this concept of making them responsible is, first of all, very fun way to work for the teams. But it’s also a very, as Muratore says, there is no engineering process anywhere ever has been discovered to be more effective and create better results than the principle of responsibility.

Tom Poppendieck: I’d add a couple of more which we’ve talked about. One is the pull, don’t push. You can’t pull from the bottom. The other is respect people. And that is don’t waste their time. Help them grow. Help them do meaningful things. Whatever systems you have that you use to get your goals accomplished. The most critical aspect is that you respect the people who are implementing it.

Henry Suryawirawan: Thanks for this wisdom. So I really liked the respect people. Sometimes for whatever reasons, deadline pressure and all that, we tend to 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.

Mary Poppendieck: Well, I have a website. But probably the most recent stuff is on my blog, which is LeanEssays.com.

Henry Suryawirawan: Anything different for you, Tom?

Tom Poppendieck: Our most recent stuff is always podcasts. Like the one you’re listening to right now.

Henry Suryawirawan: Cool. Really, thanks so much for your time today. I have learned a lot from this conversation. I really appreciate that. Thanks Mary and Tom.

Mary Poppendieck: Thank you. Thanks for the podcast.

– End –