Mary and Tom Poppendieck: How a Focused Leader Ensures Their Team’s Success

Richard:

And I want to know more, we’re going to keep talking. And in addition to all this about that best team and all these great ideas for entrepreneurial projects within big companies, and doing that really well. Is there anything else you want to add? Anything at all, about anything at all?

Mary:

Well, I think yes, today, the big thing that we’re on in software development is allowing software engineers to be engineers, okay. To be professional people who solve problems. So if you go to, here’s an example I like to do. say you’re an engineer, a structural engineer in Santiago, Chile. Say there’s an earthquake. They have earthquakes. And you work for a firm that sends you and three other folks to various buildings to inspect them after the earthquake, you know, to see if they’re safe, make recommendation for remediation, if not. Okay, and when you get to that building, nobody in the building tells you what your your answers are, tells you how you’re going to go about inspecting it. Tells you what kinds of solutions they want. Tells you how much time to spend. They don’t, because they want your expertise applied to their building, and they know better than to try and tell you how to do that. We should be treating software engineers with the same kind of respect. We give them a problem to solve, and we don’t tell them how to solve it. We maybe have a team with junior and senior people. So we can have various types of people who’ve done different things with leadership and apprentice type roles. But we do not tell people how much it’s got to cost. How the heck do the people who own the building know how much it’s going to cost to repair their building? Zero, if they’re lucky, but, you know, we don’t get to tell them how to inspect. We don’t get to tell them how to do their job. We don’t get to tell them what’s important. That’s their job to figure out. There’s so many people that are treated like professionals, like, you know, lawyers and most engineers. But software, quote, unquote, “developers” are supposed to do what they’re told. Nope, I don’t think so. That’s not, to me, that’s not having a, you know, most of the time I had a job with a title of engineer. That’s not a valid engineering role. And I think that software people who write code should be treated with the respect and treated like engineers and allowed to act like engineers, which means give them a problem and let them figure out how to solve it. Certainly not necessarily one person. You have to structure your team to match the problem, but you hand your structural evaluation team a building and say, “Tell me if it’s safe, “tell me what I need to do to make it safe. “And I’ll get out of your way.” And that’s the kind of instruction we could give to any software team. We could say, here’s, you know, bullet one, bullet two, bullet three, the plant system has to make good products. It has to be maintainable. It has to be friendly to the operator, go for it. Oh, and by the way, it would be pretty important to be done by such and such a date. And that’s it. Well, you don’t need any more detail about what you want software engineers to do. You can tell them the high level thing of what you want them to accomplish, and then let them figure it out. Instead of having all of these detailed requirements or somebody telling them in detail what tasks to do next and all of that sort of thing. And we just have not done that. And I think the reason why we haven’t done that is because historically, software development has been a support function in the business area, in a cost center, as opposed to a engineering function. I actually happened to work almost always in engineering software. So I didn’t get stuck in a cost center ever. And so I think of it that way. I think of it as an engineering function, where you make good decisions about solutions to problems, and as software becomes ubiquitous in everybody’s life, it’s way more important to make good decisions about solving people’s problems than it is to, I don’t know, be efficient, for example. It’s way more important to be resilient. It’s way more important to know the parameters of what’s important and to hand the problem to those smart people that should be able to figure it out and structure the team and lead the team so that it solves the problem, not takes a solution and executes it.

Richard:

Well, thank you. Deep in my heart, I’m still a software developer slash engineer. So it feels really good.

Mary:

And you don’t like to be told what to do any more than anybody else does.

Richard:

Hell no.

Mary:

No, sir.

Richard:

And I’ve done my best work when I could just go talk to customers and give them what they want, yeah.

Mary:

So why is it that none of our processes make that particularly important? Like, heavens.

Richard:

But I still want to know more, maybe we’ll add this in, we’ll weave it back in. My only experience with the cost accounting is where a software group has a cost center, and I’ve guided accountants. One place where I,

Mary:

How painful.

Richard:

Yeah, yeah, but at one little place where I worked, I guided the head accountant to do it differently, but it was still like, it was a cost. It was just that it was, it was done better, but it was so.

Mary:

Well, the problem with cost center is that all the way up through your whole level of management, everything is about reducing cost. It’s not about delivering good stuff.

Richard:

Yeah.

Mary:

Far as I’m concerned, ITS cost center is obsolete and they should all go. Every one of them.

Richard:

What do people do instead? What do you do at 3M, or what do companies do instead of that?

Mary:

Well, the IT cost center at 3M was just as bad as any other company. I just didn’t work in it. But we also had lots of division level IT groups that tended not to work on anything to do with the underlying business processes, but tended to work on lots of other stuff. And those groups were very interesting because they were always there in support of some business goal or other. Then we started to get automated. As we got automation and engineering systems, there is no way that the engineering department would go to the IT center to get software. It was like, it was not a concept. If you needed software in your product, you would never go to an IT group to even consider getting software from them. Because what did they know about putting product and software in product? So as software becomes a ubiquitous thing that’s driving our whole economy, we’ve got a lot of stuff to think about of how to make it good and how to make it work and how to make it secure and all that sort of stuff. It’s not about cost, because if it were about cost, you know, then as all of our extremely efficient supply chains collapse on us, we would come to realize that actually, it’s not about efficiency. It’s about resilience.

Richard:

Yeah, if it weren’t about cost, we wouldn’t do it. ‘Cause it costs.

Mary:

Yeah, right, and cost accountants wouldn’t get that.

Richard:

Yeah.

Mary:

Like, they just would not understand.

Tom:

Back in the sixties and seventies, lean manufacturing became ubiquitous around the world. But one of the greatest barriers to the adoption of lean thinking in the manufacturing world was, guess what? Cost accounting. Because from the perspective of lean thinking, inventory is waste, because it reduces flexibility and all sorts of other things. from the perspective of a cost accountant, inventory is an asset.

Richard:

Oh yeah, right, it’s backward.

Mary:

So it goes on the positive side of the balance sheet.

Tom:

So as you make progress on eliminating waste from a lean mindset, you are making your balance sheet look worse than worse.

Mary:

You’re messing up the balance sheet, you really are.

Tom:

And the saying at the time was they had to wait for a whole generation of cost accountants to retire before they could be expected to make decisions that were based on values of lean. Well, those cost accountants never got out of IT.

Richard:

Yeah.

Tom:

As long as they’re still measuring inputs as the primary thing in cost center IT, you’re not going to be able to make good decisions, no matter what process you use.

Richard:

Right.

Tom:

When you start measuring based on the impact on the goal of the organization, which frequently is benefiting somebody who is purchasing or using your product, your output, then you can make good decisions. It’s always constrained, of course, by having enough profit built in to sustain the organization. But if it doesn’t satisfy the people who it’s supposed to satisfy, none of the rest of it matters. So all of the criteria of cost accounting lead you to make the worst possible decisions. And you’ve lived with that.

Richard:

I have, a long time.

Mary:

It also has to do with optimizing for short-term versus long-term. So I like to think about AWS because it’s really clear that the only reason why it exists and is successful is because a huge number of long-term decisions were made at the expense of short-term decisions. Somebody once said that during the time from 2001 to 2006, when they were going from a great big monolithic front end to services, that Bezos just simply protected them for six years while they made the transition, because he understood that the monoliths could never match his ambitions, that it was too big. He also had this theory, quite right, that the only way to go real seriously large scale was to have independent agents making independent decisions. Now, that’s not a software thing or a lean thing, that is just a belief that really serious scale involves decoupling and independent control and redundancy. And everybody knows that large systems need those things. So he figured there had to be that, and this was the way people were heading towards it. And so he just protected them and it took a long time. The other thing he did at the same time was he even wrote in one of his things. He said, if any accountant ever took a look at Amazon Prime for the first 10 years, they would have told us it made no economic sense at all. And yet it’s a pillar of the company because it wasn’t about economic sense. It was about saying, what do we need to do in order to make sure 10 years from now that people love Amazon? And he was always thinking about, what do we have to do that’s the right thing for 10 years out? And so if you look at AWS now, you actually have an interesting model of large scale systems being done by relatively independent teams. But they used to have what they call these two pizza teams, small teams. But they did some research. There’s this book called “Working Backwards” at Amazon. It’s written by some executives at the time. And they said, well, they said in the book that that worked sort of in software for services, but it didn’t work for larger things in other areas. So they discovered that there was something else with a lot of experiments and data. There was something else that was the primary success factor in successful products and stuff like that. And in successful teams. And their primary success model came from what they call a single threaded leader. So by single threaded, they meant a leader who had nothing else to do, but to solve one problem. No other jobs, they said, you know, the best way not to innovate is to make it your part time job. And the single threaded leader was responsible for assembling a single threaded team. So the leader had responsibility for results, you know, not like a project manager, but like an entrepreneur, and assembled a team that was dedicated to only that thing. So now you had a single-threaded leader with a focus team that had nothing else to do, but to solve whatever problem they had. Now, if the problem was bigger than a small team, then it would sort of like, it would cascade into sub teams. But the same thing, each sub team would have a single-threaded leader and a focus team to do their piece. Just like my process guy had a build this process. Then to make this product, and be part of the team, that’s figuring out how the product is going to work because the process might change. And that leader, and as appropriate, the team members on that group would come to the main meeting to see how the overall strategy fit them. And so it’s this focus, and nothing else to do. And that’s when stuff gets done, we have discovered that when people focus on one thing at a time and don’t stop until it’s solved, you get higher quality and faster results virtually all the time. And any structure that focuses teams on a single thing, and doesn’t let them stop working on a thing until it’s solved, you can’t put aside, you can’t have delays. You can’t say, “Well, you know, we’ve got blockages.” That doesn’t count. They have to make everything work. Don’t get started until you’re ready to finish, and then do the whole thing all at once. But we found that that has a really good effect on making things high quality and much faster. And similarly at AWS, they have this sort of hierarchy of single-threaded leaders. And each sub leader has a subset of the higher level service, because you can’t tell me that their big services have only five people on the team, they don’t. But I have a really good friend who works for Amazon. And he said, “You can be sure that any problem “that exists that AWS has trained to solve, “it has a small focused team that has nothing else to do “but solve that problem.” It’s a two pizza team, but it might cascade into more of them. And that has nothing else to do but solve that problem. And responsibility for solving the problem. We don’t give either solution responsibility to our software teams in most of our agile processes, which is wrong.

Tom:

And we only focus on software teams, not the real teams needed to do a result.

Mary:

The full team to really bring a product to market and keep it there.

Tom:

So your definition of team is a shared goal. It’s a pretty small product if it can only be done with two people.

Mary:

Yeah, talk to anybody who started up a new business, and that will be clear. Any new business that’s successful grows beyond two people, pretty fast.

Richard:

For sure, for sure, for sure. And mine, it’s a super simple and general definition of team, not even work, like, the project this morning was get Molly to the bus and take the dog for a walk at the same time.

Mary:

Really?

Richard:

And we succeeded. It was more than two people. It’s two people and a dog.

Mary:

Two people and a dog.

Richard:

Well, thanks again, I really appreciate it. Really appreciate the extra conversation afterwards. It’s been a lot of fun.

Mary:

Thank you.

Richard:

So there’s our extra add on super special episode with our guests, Mary and Tom Poppendieck. I hope you enjoyed it. And remember to support this podcast, visit my website, kasperowski.com.