The role of leadership in software development

>> WILDAVSKY: My name is Adam Wildavsky. I'm a software engineer here and I'd like to thank
Joe Little in the back for bringing Mary and Tom Poppendieck to town. And I'm not going
to tell you much about them you're all here because you know who they are and you wanted
to hear them, so without further ado. >> POPPENDIECK: Good evening everybody. So
I'll thank Adam for choosing the topic for tonight. So I didn't actually choose I gave
them a list of several things and--I--if you don't like it I can change it. I got my computer
here and--you want me talk to about something else or ask questions about something, that's
quite all right because this one happens to be about leadership. Actually I said the history
of leadership. But--well after a late dinner last night I went back to the hotel room and
started to gather together the talks that I've done before and I really realize this
was the—first time I--or second time I did this talk it was already videotaped in on
web. So maybe I better say something more or different than that. So, I renamed it A
History of Leadership and changed a bunch of stuff and we'll see how it goes. But I
would like really to encourage you to ask questions and, you know, if you don't like
it challenge me or whatever you want. And then we'll just [INDISTINCT] from there. A
little bit about my background; I started out life as a programmer back when programmers
were called programmers and so developers. And programmers did like all sort of things
like understand customers and test their software and, you know, work with engineer--electrical
engineers. And I do process control systems. First I did the controls of a physics experiments
at the University of Wisconsin and then I did process control systems for 3M. And then
I became a manager at a manufacturing plant where we found ourselves in serious competition
with Japan and decide that we had to do something entirely different we've been doing before.
And we did something that in the early 1980's what's called Just In Time which came to be
called Lean and we did the--change our plans around quite a bit. A little bit more about
that later on in the talk. And later on I went back to corporate head quarters and I
did a bunch of product development. So, I was an IT manager. I was a developer. And
then I got in to product development. I did lighting systems with ultra-pure plastic;
honest. And eventually in late 90's 3M had this really cool [INDISTINCT] offer that I
couldn't refuse. So I went off and found myself managing a software project again as a program
manager. It was a government project and it's the very first time I ever heard this thing
called Waterfall. We didn't do that; honest. You know, I learned how to do software projects
as an engineer in a--in a department where they didn't do computers. Computers were new
but they could put control systems on process systems in their sleep. So, I learned about
projects from engineers who knew how to put plans together and always hit deadlines and
that was kind of interesting. So, then I--we--I spent at 3M perhaps a dozen years or more
being a manager. And I kind of liked the role manager and I got involved in talking about
how you can apply Lean ideas to software and I found some people that weren't software
thinking, like, really bad things about managers; maybe with good reason. But you didn't like
the fact that there was a stereotype that all managers are bad and should disappear
and so, I occasionally talk about leadership and what leadership is all about and what
can do when it's done right. So that's what I'd like to talk about today although it's
not going to always be about what leadership is done right. Because we're going to start
back in 1850 because it's a history; I like history. And on October 5th, 1841 was the
first serious train wreck in the U.S.; honest. At least that's what I understand form reading
the history. And the interesting thing was, up until this time there weren't any really
big organizations outside of, you know, church and military and some government stuff. But
big companies were just starting to exist because transportation was just becoming available
and you could just start amalgamating a bunch of things and creating big companies. And
trains use to, like, go from here to here on a track and then another train a few days
later from here to here on a track. And all of a sudden they started putting a lot of
trains on the same track and one fine day a couple of them ran into each other. And
then I said, "Oh, who caused that?" So, there was a big question about how do you run a
large dispersed train or railroad organization in such a way that trains don't crash because
you can't have lots of people sending people down the same track. The answer after a, you
know, government investigation and all that sort of stuff was; guess what? You've seen
this hierarchy before. It was an organizational structure that kind of looks just like the,
you know, pyramid that we out come to wonder about. And the investigation came up with
six principles of administration. This is sort of the first--this is what management
is all about or this is what managers are supposed to do. First one was; there was supposed
to be proper division of responsibilities so that people had, you know, control over
who decided who, what trains went where. There needed to be sufficient power conferred to
enable the--the people with the responsibilities to carry them out. There had to be a means
of knowing whether such responsibilities where faithfully carried out. There had to be great
promptness in reporting all derelictions of duty; got it. And information obtained through
a system of daily reports and checks. And adoption of a system to enable the General
Superintendent to detect errors and immediately point out the delinquent person, so it was
all about assigning blame if something went wrong because that's what they we're trying
to do is. If the trains crash somebody has to be responsible and take the blame. This
is from a very interesting book called The Leader's Handbook by Peter Scholtes and if
you want to read more interesting stuff about leadership this is--I think this is the book.
And he's actually quoting The Visible Hand: The Management Revolution in American Business
by Chandler in 1977. And in that book Chandler says, "Basically everything there was to know
about management was invented by about 1912 or 1915." I think stuff has been learned since
then but that's what he said in 1977. And so, the beginning of management in big organization
is all about hierarchy and assigning blame. Now there were other big organizations as
they said they were basically military organizations. And there, you know, doing the right things
is a matter of life and death in other things. So, let's talk about what happened in 1880's.
About this time guns became more prevalent in war and it turns out that a general could
no longer stand on the top of a hill and orchestrate a battle. Because distances were further and
guns were, you know, enabled--you know, things got just way more confusing than they used
to be. And so, Suzanne, you're going to have to help me. Helmuth von Moltke? Yes? Did I
get that right? She's from Munich, so, you know, she can get me right here; is the chief
of general staff in the Prussian army from 1857 to 1888 for 30 years. And he--in the
institute of this concept of command intent he said, you know, in a war where a general
can't stand in front and tell everybody what to do; we have to do something different.
"No plan of operations extends with any degree of certainty beyond the first encounter with
the main enemy force." Where have you heard that before? Lots of people are quoted but
that's where it started; von Moltke. And so, he had this thing called--now what's that?
>> Auftragstaktik. >> POPPENDIECK: Got it? Auftragstktik. Okay,
or close anyway which is mission tactics. And it's all about delegation of decision
making authority to subordinate commanders within the context of the higher command's
intent. So instead of telling people what to do; you tell the next level of command
what you want done. And let them figure out how to make it happen. And so that's command
intent. And he said the heart of mission command is this; the advantage which a commander thinks
he can attain through continued personal intervention is largely illusionary by engaging in it,
he assumes a test that really belongs to others whose effectiveness he thus destroys, he ought
to multiply his own task to a point where he can no longer fulfill the whole of them.
So the idea of delegation down started with people who had to win wars where the rules
of engagement had changed. And one of the interesting things you'll see is that a lot
of the good about leadership actually have come from this origin of various military
engagements where things got to be a matter of life and death. Where--you know, this is
the way we always did it. It doesn't hold anymore. Now let's go to 1910. And it's a--it's,
you know, the modality has just been invented and is about in 1913 was the first assembly
line; automated assembly line. And in 1911 Frederick Winslow Taylor wrote the book The
Principles of Scientific Management. This is not the same as the scientific method,
okay. It's totally different, in fact 180 degrees the opposite. But he had this idea
and you got a picture, it's the U.S., it's the automotive industry or the steel industry.
Most of the people that are working there have come from some other country, can't speak
English. So, certain people think they must be mot very smart because they can't speak
English. And they have to be told what to do; so there's a lot of--in Frederick Winslow
Taylor's writing; sort of condescension to people who actually do work. They're not smart,
they have to be told what to do, they're lazy, they will not do the job unless you make sure
and keep track of every last thing that they do. So the underlying theme here and the underlying
assumption is that workers will do as little as possible, that workers do not care about
quality so if they aren't forced to have quality it won't happen, and that workers are not
smart enough to know the best way to do their job. So, you need the smart people; the engineers
to tell the workers exactly how to do their job. And there's a lot of that and the things
that he did and has hit a lot of the assembly type manufacturing environments, like automotive
and also that was likely done in the steel industry. His view of efficiency was that
efficiency comes from knowing exactly what you want men to do and then seeing to it that
they do it in a best and cheapest way. So, they don't know how to do it best and cheapest
but, you know, the smart people; the managers, the engineers they do. Experts define the
best way. And the way they do it is by breaking down the job into individual parts and finding
the best way to do each part and then paying the workers extra if they do it the best way
that has been determined. At the--the highly insulting flavor to this is really there.
I mean, that's--it's comes through. And many of his writings actually I just reread this
book about a year ago and I was kind of appalled. And it's true that it was written in another
age. But it has the flavor of there are only certain smart people and everybody else is
lazy and needs to be told what to do. And if you watch management in many of the western
societies that theme has made it into a bunch of places but not all places. For example;
I worked at 3M and I never actually noticed this kind of philosophy. And I'm pretty sure
the reason is because 3M processees were big roll goods, you know; make big rolls of sandpaper
or tape or something like that. And the people who operated the production equipment had
to be extremely skilled workers. In fact the first RND head in 3M; the first person that
headed up RND got fired because he couldn't get along with the production workers. And
the production workers knew everything there was to know about how to make tape and if
the RND guide won't listen to them; they needed somebody else in charge of RND. Interesting
enough you'll find in Toyota a very similar; it's the way the things are manufactured.
And the skill in manufacturing this is the primary focus and things spin out from there.
So that's the one bets way. Somebody figures it out; somebody knows what's the one best
way and tells everybody what to do. And you see a lot of that in some industries. But
now let's go to 1920's and this isn't very long after that. And we'll talk about Charles
Allen. He was the guy in New Bedford, Massachusetts who started up the whole concept of industrial
training. If you look into the vo-tech schools in United States you'll find that most of
them had their origins in Massachusetts with three fellows. One of whom was Charles Allen.
And his idea of on-the job training was that there are people who really know how to do
a job and the way they get people to learn how to do the job is have a master train the
new people coming on to the job. He said, "Second class trainers produce second class
learners." So, you really need experts who know how to do the job to do training. But
one thing that experts may not know how to do is how to train people. So, he focused
it at how do we train experts to train people? Because they know how to do the job but they
don't know how to train. So he had a four step method. Now this is the days of divide
every job in to a lot of little bits. And there's nothing totally wrong with that but
it wasn't have experts figured it out. It says, have that master craftsman divide the
job into four steps; preparation, presentation, application, and testing and then train people
how to do it. Now what we have at war--there's a lot of war that triggers stuff in my story
and this particular war was a war of [INDISTINCT] at sea. Where it had the most ships at the
end was the winner basically. And so there needed to be a lot of ships built in Massachusetts.
And so Charles Allen was asked to put together a training program for shipbuilders. And he
put together training program for shipbuilders by training supervisors how to train people
how to built ships. And in two years 88,000 shipbuilders were trained with a hundred supervisors
learned how to do training. And at the end of the war in fact, there were more ships
on--in the U.S. than--besides--so I guess it worked. In any case--in any case he wrote
this book it's called The Instructor, the Man and the Job; A Handbook for Instructions
of Individual--of Industrial and Vo-Tech subjects. And he wrote a whole concept of training people
with on-the-job training. It was very different then the scientific management of the, you
know, the automotive industries. And think about it, a ship is a little bit different
than a car. Ships are all sort of--one of much more so than a car is. And so you needed
skilled workers that could bring their skills to other areas. And now it's the 1930's and
we're now going back to Germany. And we have a concept of--got that? Truppenführung--
Truppenführung; okay, which is unit command and this is the German field manual from 1933,
1934. And there's some interesting things in here. You can see the history from von
Moltke. It says in section four; lessons in the art of war cannot be exhaustively compiled
in a from of regulations. The principles must be applied in accordance with the situation.
Good idea. Simple actions logically carried out will lead to the--most truly to the objective.
The command of an army and its subordinate units requires leaders capable of judgment
with clear vision and foresight and the ability to make independent and decisive decisions
at all levels of the organization. An officer is in every sense a teacher and a leader.
The decisive factor despite technology and weaponry is a value of the individual soldier.
The battlefield requires soldiers who can think and act independently; who can make
calculated, decisive and daring use of every situation and who understand that victory
depends upon each individual. Okay. So you think perhaps of military as being tell everybody
what to do, but the concept of make sure that everybody is able to think for themselves
is what really works. So now we go to another war, lots of wars and this is 1940's. And
that is actually IBM Poughkeepsie Plant and the workers there are mostly women because
of course most of the men are over in Europe or some place like that. And there's a need
for wartime material to be produced. And in that time women had very little experience
in industrial--I mean actually nobody was in factory until like, 30 or 30 years before
that. And women didn't work in factories until there was need for production and no men to
do it so, you had a very inexperienced work force that need to be trained--train very
rapidly. Now what did they do? They went and they dust it off that Instructor, The Man
and The Job that we--had been written 20 years by Charles Allen they said, "Oh, this looks
like a good idea." And after a full start they decided the first thing to do is to train
first line supervisors who should be masters at their job. So you have a few people that
know how to do the job; what you got to do is train the supervisors how to train--how
to train the workers to do the job. And it was divided in to three parts: job Instruction
which is how to train workers, basically break down the job in to parts and teach each person
how to do each part, how to improve the way work is done and how to treat workers with
respect; okay, job methods; how to improve. So it wasn't teach people how to do things
it was teach them how to do things and then constantly improve the process and also teach
workers with respect. Now remember they're making munitions that haven't actually ever
been made before; airplanes those area kind of new and things like that. And so they had
to figure out how to manufacture them so they had to constantly improve the process in how
to treat workers with respect. Now this is--was a very successful training program. In fact
in this quote here it says without question, the most successful corporate training program
in the history of United States about 1.7 million people were certified and trained.
At the same time we had Deming; this is W. Edwards Deming at that time. And what he did
was he taught statistical process control; basically defense contractor, engineers and
technicians training over 30,000 people. These two programs were extraordinarily successful
in increasing productivity in United States and in Canada, basically in North America.
And however they were war programs and when the war was over they were dropped pretty
much. Except, you know, they were moved to countries that seemed to need them because
they didn't have any infrastructure and these programs are brought to Germany and especially
to Japan. And in Japan they were very interested in these programs and--so both TWI and SPC
went and were taught in Japan in the early 1950's. So for example here's the materials
from training with an industry. It was introduced in Japan in--as I said late 40's and 50's
and all three sections were very well received but most importantly the job instruction one.
How to train workers through their supervisor, how to break down the job into details and
train is to this day one of the pillars of a supervisor training program in Japan. It's
a 10-week program where you have a half of day and you do the stuff. And at the bottom
of the training materials that we some on a--another slide, I don't--I don't have it
here. It says if the learner hasn't learned; the teacher hasn't taught. So the burden is
in the supervisor to make sure that the people know how to do the job. Job methods; how to
constantly improve stuff was pretty good. But Taiichi Ohno the guy that invented the
Toyota Productions System had a better way to do that. So eventually he had it improved.
And to this day the improvement on that is taught in Toyota, too. And then here is Deming.
He went in 1950's to Japan and he was kind of annoyed because he got ignored in the U.S.
after the war was over. And he said as much more that statistical process control it's
the whole system. So, he gave lectures to the tune of, you have to appreciate not just
the piece you're doing but the entire system. You have to understand variations. And Deming
when he talked about variations he said, The thing you have to realize about variation
is that there's two kinds, there's a stuff you can't do anything about, and the stuff
you can do something about. So there's common cause; it's just there and there's special
cause. And it's a good idea to find out if there's a cause. What the cause is and fix
it. But it's not a good idea to try to get rid of variation that's just plain inherent
in the system. If you try to do that you actually are going to make the system worse. And he
had a treating course. I have a brother-in-law who went to it in the '80--yeah, late 80's.
And he would--he would have somebody, like you come up here and he would say, "Here,
here's a bag. It's got some marbles in it. I only want you to get white ones out of it."
And you put your hand in blind and if you got white ones he would say, "You are good."
And then he'd have you come up, and you would put your hand in and you get black one and
he would bellow out and tell you, "You should--I told you not to pull out any black. What do
you, you know, what don't you understand about that?" And then, "I'll tell you what, try
again, here's some money. Now put your hand in and--and don't pull out any black and if
you get only white, you get this money." Didn't work; okay, and the point is that if variation
is inheriting the system, no money yelling, no amount of money is going to change that.
You have to change the system instead. You also talked about the theory of knowledge
that is to use a scientific method, not scientific banish but scientific method in order to solve
problems. Think about it, create hypothesis, do experiments. Or sometimes called plan,
do, check, act; you've heard of that? And then psychology, when it comes to people it's
not numbers; it's pride, it's commitment, it's pride in your work, it's applause, it's
trust that matters. It's not making sure that numbers are met. And he was already bygone
that policy too. Somehow we seemed to have forgotten some of that stuff. Anyway, in the
1950's another thing was going on in the U.S. And that was the Cold War. Another war and
it--and you're going to see here that war tends to bring out good behavior. This was
the Polaris Project; it was one of the most successful weapons projects in the U.S. And
what it was--was weapons program that was triggered by a scare. The scare was, "Oh my
gosh, Sputnik went up and we're going to get, you know, missiles coming at us. We had better
put some missiles underwater at sea and patrol. This project was supposed to take like 10
years, 9 years. But everybody was worried so they'd changed the schedule and started
launching submarines that could control with the underwater missile launching capability
in three years. So it took a nine year impossible schedule and made it into three year schedule.
It was an amazing feat. And guess where PERT came from; you've heard of PERT and all of
its derivatives. This had actually came form the Polaris Program. Now there's a guy that
evaluated this program because after the Polaris success; its success was attributed to this
wonderful management technique called PERT. And so, Harry—Harvey Sapolsky was asked
to do a sort of a check it all out, interview all of the people and he was allowed to do
an independent summary of what actually went on in the Polaris Project. PERT was a management
system that Rear Admiral Rayburn thought was just told the whole world and congress especially
was the one thing that was going to make this program so much in assured success that they
didn't have to worry about it. And really what Sapolsky says is it was a façade to
keep congress happy. If congress thought it wasn't people, it was the system that was
going to make it work, they would keep funding it. Actually in practice it wasn't really
used to manage the program day to day, not for the first four or five years when they
launched submarine. And in fact the technical officers thought it was unreliable and the
contractors thought it was relatively worthless. However, it became the goal standard against
which we decided that we should manage projects after that; honest. And Sapolsky said, "Why
was the Polaris really successful? Was it really this management tracking system or
was it something else?" And he put in there; quality of leadership was first. The technical
director who was Levering Smith maintained control not only over all of the engineering
drawings but also over the description of success. What an interesting thing. So, over
the time, every iteration which was about 18 months to 2 years he got to define what
was success at the end. So he decided when he knew what he could do. Well, we're going
to define that as success and then that would be the next goal. And they would need it because,
you know, he knew they could. So he got control over that and he also had control over all
the interfaces and he focused everybody on nothing but; get this thing in the water.
In fact the very first week; two weeks when he got assigned he said, "Let's see how can
we do this fast?" You know, somebody's building a submarine down there and I forget where
and it's about half done he's, "Tell you what? Why don't you take that submarine, cut it
in half, stretch it out, I think it was 16 feet and then put them back together and then
we'll figure out how to put missiles in that 16 feet." And he did that like within two
or three weeks after he got started and up to this day that is the standard length of
what a missile submarine carries 16 feet. Why? Because it seem like a good number at
that time and he had to have one fast. That was a [INDISTINCT] The number of missiles
was because he talked to a lot of the submarine captains and then talked about what they would
be comfortable with. And those decisions were made within the first month. He had the decentralized
competitive organization. They had 10 fundamental technologies they had to invent in a very
short time. So what he did was; for every technology, every subsystem technology he
had three or four competing vendors, competing to be able to have the honor of putting that
in there. Now imagine the government program doing that today; kind of interesting. And
we call that set base design in design--in hardware design that is have multiple options
and when you get to the decision point, you choose the best one which is what he did.
Emphasis on reliability; if there was one thing that Smith was criticized for; it was
being too much of a fanatic about testing. Those of you who know Agile, so that was his
big criticism and then everybody was really engaged in making this happen. Contractors
went out to--and had meals with, you know, government people that wouldn't be allowed
today either. But it was then and that's--those are the reasons why it was successful. So,
really good kinds of things that we talked about in Lean product development were involved
in making this successful. Now we go to the 60's, so we're the next decade and we have
the Toyota Production System suddenly coming on the world. It actually had been going since
the late--early 50's. And here is Taiichi Ohno who was involved in making this thing
work inside of Toyota. It's very counter intuitive. It seems okay today; it kind of make sense.
But you know, when I was in the manufacturing plant in early 80's it did not seem very sensible
to us. We thought they were nuts. And so did most of the people in Toyota. It needed the
people he managed. So, you know, for the longest time, they didn't call the Toyota Production
System, they called it the Ohno System, you know, because they figured if it failed, it
was his system. And but then he kept getting more and more, you know, responsibility and
there's more people reported him like kind of had to adopt it in after while, they discovered
it actually worked. As coherent and intuitive as it is. And so he has a system that's fundamentally
about Just-In-Time Flow which in our plant, we thought was nuts but actually, it worked
for us too and Stop-the-Line Culture. Don't build in anything that has--if you find an
error, you stop and fix it. But not only that, if you are building something that might have
defects, you need to put in place in mechanism to find the defects the moment they get injected
and stop everything and fix them. Don't find them later, find them right on the front.
So mistake proofing your manufacturing line and you can think of that as mistake proofing
your code with a test structure. Right away as soon as you do something wrong on the keyboard,
I did too when I was programming, you have a mechanism to run it against something to
merge it with other code, find out if something's wrong, if it is, you fix it. No problem. You
just did it in the last 10 minutes. You come back 10 weeks later and find out something's
wrong is a much bigger problem. So that Stop-the-Line Culture Mistake-proof of a system so errors
cannot get injected. And lastly, relentless improvement. I'll tell you a little more about
that in a minute. So his book was--this book here which was written in '78 but didn't become
available in English until '88. I wish I could've read it in our plant in the early 1980s because
it really would have helped us. We had a book. It was not very good but it helped--I mean,
it was good but it was good but it was not great--well-translated into English and all
those detailed industrial engineering stuff [INDISTINCT] but it was our bible in figuring
out how to do just in time in our plant. This book is really good and even today, it's good.
It's a wonderful book to read. And then he wrote another book which was published in
1982. It was translated then and then recently retranslated into English in 2007. I'm just
going to read you one thing because I have here relentless improvement, learn through
experimentation which is one of the pillars of the Toyota way today and he didn't write
much about it in his book but he did write about it in the workplace management. So,
for example, this is just one quick example out of that book. He said standard work. Now
you all heard of Standard Work. Do things one way, okay. He said, when creating Standard
Work it's going to be difficult to establish a standard if you are trying to achieve the
best way. Now we're going back to the scientific measures as one best ways. So now, there's
not a best way. This is a big mistake. What you really want to do is you document exactly
what you're doing now. If you make it better, that's kaizen. That means change for the better.
And if not, and you establish the best possible way, there's no motivation for kaizen. So
the idea is you don't want to be perfect otherwise, nobody gets to improve it. That's why one
way of motivating people to do kaizen is to create a poor standard. Interesting concept.
So, remember the goal here, it's not to have the best way of doing things. It's to motivate
people to constantly improve the way things are done. Don't make it too bad, okay. Without
some standard, you can't say we made it better because there's nothing to compare it to,
so you have to have a correct standard for comparison and then you take that standard
and if the work is not easy to perform, you give many suggestions and do as kaizen and
the whole idea is to have all of the people that are doing the work constantly improve
it. That's kaizen. So that is--his constant improvement is much more important than telling
people the right way. And there was this feeling and I recognize it because we also had it
in our plan that only people who really knew how to do the job were people who were doing
the job, so those were the people who just figure out how to do the job. It's true that
the supervisor needs to train new people but it's also true that the people doing the work
are the ones with the problems, the issues and stuff like that and they are the ones
who should be constantly improving it. So in the 1970s, we had Theory X and Theory Z,
you've heard of those? Okay. Theory X, most people dislike work and don't give their best
efforts at their job. Therefore people must be encouraged with financial incentives or
threats to work towards organizational objectives. Generally people would rather avoid responsibility
and preferred people to tell them what to do. Now, there are plenty of people that actually
believe this. I don't happen to be one of them. I haven't observed it to be true but
there are people who kind of--you can tell from their behavior that they fix this. And
then there are--of course, they don't tend to be the people that are being directed,
they tend to be the people that are doing the direct. And then there's Theory Z. And
Theory Z became popular when people discovered that what was going on in Japan was actually
more successful than what was going on in the US. Let's see what this all about. So
there was a book even written by Theory Z. Theory X came from McGregor and Theory Z came
from Ouchi, there was this Theory Y too but I'll skip that. And Theory Z says, on the
contrary, people are motivated by the satisfaction of doing a good job, the enjoyment of cooperating
with others and being recognized by them and the satisfaction of using one's talents to
the fullest. Fundamental difference in perception of what motivates people and this--became
the basis of what was going on and in fact, you can see this in a book, for example, by
Ishikawa. How many have heard of Ishikawa diagrams or cause and effect diagrams? Okay,
well, those of you you haven't, they're pretty good. Anyway, this is that saying of Ishikawa
and he wrote the book, What is Total Quality Control and this is in the--it was in the--I
think it was in the early '70s because otherwise, I wouldn't have it on the slide, right? And
so he was from the '50s, a very strong leader of the quality movement in Japan which really
was what was patterned--what the quality movement moving to the US in the early '80s was patterned
on. And Ishikawa proves in many of his writings that this Theory Z is the fundamental perception
of what that whole total quality movement was built on. He said in the book, The fundamental
principle of successful management is to allow subordinates to make full use of their ability.
It sounds a little bit more like the, you know, the war manual than the scientific management.
Everyone who is connected with the company must be able to feel comfortable and happy
with the company and make use of his capabilities to realize his potential. A lot in his writings
about people must be able to realize their full potential and this management's job to
set up the situation so that they can. Top managers and middle managers must be bold
enough to delegate as much authority as possible and that is the way to establish respect for
humanity as your management philosophy. Now, this is not a delegate's delegation so you
can assign blame, you know, back to train wreck management. This is a delegation so
people can work to their full potential and that's Theory Z. So, you know, I have a book
in my shelf that I bought in about 19--you know, late 1970's and it was--maybe, I think
it was the early part of '80s called Theory Z Management and it was all about how, you
know, some people might take this but this is what actually really works. I was lucky
enough to be in the company where Theory Z was kind of the philosophy anyway so that
was very handy. And just about that time, I had been working in, you know, process control
and I did a process monitoring system for video tape manufacturing. And my assistant
went into a plant about 60 or 70 miles from where we lived and they invited me to come
out and be the IT manager in the plant. So I've never been a manager before and it was
a little scary because, you know, I read books that say management's different than being
a technical person and I was a really good technical person and I had no clue if I would
be any good at a manager but I thought I'd give it a try and it was kind of fun actually.
We went to the plant--I went to the plant and my boss Dave Dilger who's a plant manager
says, so, you know, you own responsibility for systems. Now, systems are not just computers.
They're anything that makes things work around this place. And I actually spent four years
taking computers out of the plant. Because we had this thing at that time, you know,
computers had just learned how to do scheduling and they were used first and foremost as schedule
manufacturing plants; this thing called MRP, Material Requirements Planning. So back in
those days, there was MRP--there were MRP systems and they said, if you would just do
what the MRP system tells you to do exactly, then your plant will be perfect and if you're
not perfect then you're just not trying hard enough. Now, our plant, at that point, packed
out about--for every week, we'd schedule what we wanted to do and we'd look ahead and all
about 60% of our weekly plan. We just weren't trying hard enough, right? 60% of plant. And
the other problem we had was that our competition started selling video cassettes which is what
we made for a whole lot less money than we could make them for. So this was really serious.
We weren't--actually, we're doing all the right things according to the book and they
were doing stuff in Japan that was so much better that they could--we thought they were
dumping. Nope. They were making stuff better. They were making stuff higher quality than
us, and then we're getting it over to US and selling it at--less than we can make it for
and they were making money. I'm thinking, whoa, either we got to close this plant or
we got to do something like dramatically different. We decided that we didn't believe in this--at
first, we didn't believe in this thing called Just-in-Time. But, you know, the more we study
that the more we thought, whoa, It seems to be what's working for them as much as it doesn't
makes sense. So we--there was a small Just-in-Time movement in the US. There weren't any real
consultants; maybe one or two. There was a little tiny group this is sort of like, agile
software development in 1999, right? And so we went and we learned about it and we gave
it a try because it was either close the plant. And what we did was we took the conference
table about like this big. We laid out paper. We draw all of our processes on it and then
Gary, as being the materials control manager produced our weekly pack out and then we had
coffee cups and in the coffee cups, we had, as you can see, little sticks and this got--each
coffee cup was a cart of video cassettes. Say, a thousand video cassettes decked in
the cart. And that said--the stick here said, this is, you know, T120 black or T120 red,
says what kind of video cassette, what color, how many minutes, that sort of thing. And
so we pretended that those were carts and then we had some carts ready to pack out and
what we did was we simulated all--no computer systems. All we did was, we had a pack up,
we started with some inventory. We started packing out and when we used up one of those
cups, we would take a stick and we bring it down to the next process on the table and
we say, okay, process make that. And then we would simulate having that process, make
some more of that and see what we would need to do to be able to pack out. So we simulated
a pull system and after a few hours, it kind of worked. So, we said, okay, this is cool.
But there were three of us and this is a plant with a thousand people and a lot of complicated
processes all scheduled by my computers. And so we decided we better get the general managers
to come in and take a look and so the next Saturday, the general managers came in to
take a look at this and the five of us simulated this and they said, It might work. It seems
like a perish concept but, you know, we're just managers, we can't make this happen.
And remember, there is no IEs around there; there's no consultants to help so we have
to figure this out for ourselves. And so the general managers said we better call in the
general supervisors because they could help us. So then two weeks later, the general supervisors
came in on Saturday and we spent all day doing this coffee cup simulation ki9n dof thing
with these dozen or so people, we were able to do a much more detailed simulation and
it kept locking up after like 24 to 48 hours. And so we changed the rules, we changed all
sorts of stuff, went to lunch, had a big break, came back, changed some more rules and suddenly,
we got it right. We got the idea of level loading and we were able to simulate one full
week of pack out with no lock-up. Yes. So we thought wow, this is pretty cool. So the
general supervisor said, Yeah, but, you know, like, we can't make this happen. There's a
lot of detail work here. We better get the supervisors involved. So then the general
managers, general supervisors, the shift supervisors, all walk through the simulation on the three
shifts because we were three shifts a day, six days a week and they all walk through
it and they said, Well, this is, you know, kind of interesting. It might work actually.
But we're just, you know, we're just the bosses around here and there's a lot of work so we
better show this to all the shift workers. So everybody that was involved which is like
90% of the plant went through this simulation and then the shift supervisors with their
teams on their shifts figured out where the up--the, you know, opposing shifts how to
make it work in their area. How to put the little cards and what things are going to
happen because remember, all my computers are going to get turned off one day, one day
because we couldn't figure out of how to face it in, had to be called Turkey and one weekend,
we did, we turned off the computers and we printed out the week's pack-out and we sent
it to packing and hell the rest, okay. And by the end of that week, guess what our pack-out
percentage was, 95%. Now, remember, we'd never done much better than 60% or 65% trying this
MRP thing forever. It just couldn't be done and suddenly, we started a poll system and
wow, we could pack out basically everything we wanted every single week. Poll systems
do that for you, you know, and if you try it in any other kind of schedule and you'll
see the same thing but that's not the idea. The lesson is that we couldn't have done this
without engaging all of the people in the plant to figure out how to make it happen.
Why do we get 95%? Because--guess who figured out how to make it work. It wasn't some, you
know, people coming in from outside saying you put this here and put this here. It was
the shift supervisors puzzling through with their shifts and the people next to them how
they were going to make it work. If something goes wrong, guess what, people who have to
deal with the problems have already simulated that, kind of know what to do, make some adaptations,
figure it out and that's why it worked because the people doing the processes designed their
own processes. So it wasn't like we went to the people in the plant and said, Oh, dear.
We are in bad trouble. What do you think we should do? That doesn't what we did. We said,
We're in bad trouble. We have a plan. We're pretty sure that this is going to make things
better. We're not sure how much but we think it's worth the shot. Here's the general idea
and we'll show you with the simulation in detail, give you all the help you need to
work it up and in the end, you got to figure it out and make it work yourself. So there
was a lot of leadership from the management team but in the end, the details were worked
out by the people on the floor and that's kind of my vision of leadership. In addition
to the fact that I also got an interesting taste in my mouth as far as outsiders coming
in and telling people how to do stuff. I'm pretty convinced that if we had a bunch of
outsiders coming in and telling us how to do stuff, we wouldn't have been successful
and it was near successful as us puzzling this out, figuring it out, banging our heads
against the wall, getting everybody involved and admittedly, you know, it was, I'll close
the plant or figure-it-out situation, so it's not like we had a choice but it was everybody
getting engaged and figuring out how to make it work. So that was the result. And the employees
said it was the best thing that ever happened in the plant. So this--if Japan can, why can't
we? That's up there because there was a video in the early 1980s about Japan being so good
all of a sudden when I used to, you know, before this, Japan was known for making cheap
junk. Anybody remember those days when Japan was cheap junk? Okay. Well, it didn't happen
at about 19--late 1970's that kind of changed around, and by 1980, it was, Why can't we
do that? And this video was made with Deming in it and Deming got rediscovered and from
1980 until 1993 when he died. And by the way, he was born in 1900. So he got rediscovered
when he was 80, worked until he was 93 and basically kind of turned forth around and
lots of other people and many of the things that you read up from him came from that time.
Now let's talk about the 1990s. Actually, in the 1990s, I was not in computers. I was
working in product development in 3M which is a fun thing to do because 3M kind of does
new product development for a living. I still think that Google has copied a lot of 3M ideas
like our 15% time and things like that but, you know, so I kind of get some of those ideas
and I think highly of Google because I kind of thought highly of 3M and there's a lot
of similar culture there. But in the 1990s, I was doing product development with plastics,
not--not--well, I had some with embedded software and some with plastics. And I was--well, I'll
show you later product champion most of the time and so what was going on in sulfur at
that time was kind of hidden from me. But we had this thing called Waterfall as Jack
Colt told you. I didn't hear about until the end of the decade, if you've seen that, yeah.
Okay. And then there was this process maturity model. Yes, we saw that too. I learned about
this one in 1999 actually, honest. And then we had, you know, project management in all
sorts of flavors, good old Purt coming back to haunt everybody and the thing about this
in particular is that having moved from a scheduling system that was pushed to a poll
system and seeing the difference. I never believed that if you guys would only try harder
to meet your project deadlines, you know, all would be perfect. Probably, you'll get
60% performance against plan on a week to week basis. Anything that's scheduled at a
detailed level, that's pretty much what you get. And if you switch to a poll system instead,
you'll probably do a whole lot better. So there is this poll push system and then there
is six sigma and I never was too much involved of this, 3M got involved in there after I
left. And so there was lots of process, okay. In fact, there were some companies--they still--some
of them exist, which think that process is going to settle of our problems. If you just
have a standard process, anybody can do it. Everybody in the company should have the same
process whether they're doing the same thing, should be the standard across the company.
Interesting ideas, it's not like process is wrong because, you know, we had a lot of process
improvement we had to constantly do in our plant but making it be all and in all and--so
we can have fungible people and so that everybody does exactly the same thing means forget process
improvement, forget constantly having new ideas from people, forget people working through
their maximum of their potential. So, I want to tell you about plank roads. Just because
I want to tell you about plank roads. This is the plank road and that's in the mid-1980,
1840's to 1850's. You ever hear about plank roads? In the US, in Milwaukee where I live,
we have this road called Watertown Plank Road, t goes to Watertown. So what happened was,
railroads came into the country, about this time, you saw that at the beginning and there
was a massive boom in plank road construction because they wanted to get stuff from the
farm to the sea where the railroad station was and so there wasn't a whole lot of money
around so they thought, we start up these little businesses where people would pay to
have this plank road put in and get a lot of investors and it would be paid for with
tolls, the tolls were generally regulated by the state. So instead of building roads,
the state just had this laws for, you know, one cent of mile or something like that and
they were amazingly successful and you know, you just find this hard to believe because
you haven't ever seen one but actually, there were immediate positive results far superior
to muddy, rutted roads, dramatic decrease in travel time, expand--much expanded real
markets, so they were very, very successful and therefore, well, they got built all over
the country. You can look in the southeast, you can look in the Midwest, you can look
all across New York and you're going to find a huge numbers of plank roads were built but
there was a problem. The investment period was 10 years for pay off. That's what it was
sold as. It turns out, after something like four years, they started to die the, you know,
wood rats and about four years later, every single plank road within four years after
it was built had to have serious maintenance. In fact, which was less than half the projected
life screen and annual cluster maintenance were, for instance, 20% to 30% of the initial
cost. And guess what, that money didn't exist. It hadn't even paid back, it's initial investment.
So stuff would rot out and they would take out the wood and put in gravel. And in the
end, all the plank roads ended up becoming gravel roads but when they were gravel, there
were no longer toll roads and they basically got maintained by the state. So that's the
story of plank roads. They were amazingly successful at first but they--as Jim Surowiecki
says in The Wisdom of Clouds; the first plank roads were a huge success. People looking
for a solution to the road problem found a ready-made, one at hand. As more people built
plank roads, they're legitimacy became more entrenched and the desire to consider alternate
solution shrink. It was years before the fundamental weakness of the plank roads that they didn't
last long enough became obvious. Okay, it's sort of like, for every problem, there is
a solution that is fast, cheap and wrong and this is one of those. And so to go back to
our process chart, I think for every problem, there is a solution that is quick, cheap and
wrong and heavy processes happen to be in that category in my view. Just a quick--this
isn't actually fair but I thought I wouldn't pick on the software processes but there is
this interesting thing that was reported in Fortune--in Fortune Magazine in July. A 58
large companies out of a non-six sigma program has 91% have trailed the S&P ever since. Well,
anyway, what really makes organizations work is not one standard process and fungible people
that do exactly what's written down. That's going back to Taylor. That doesn't work. At
least, not in my experience. So let's look at organizations that are--what I'm going
to call high reliability organizations. That is organizations where mistake is a matter
of life and death. For example, firefighters, nuclear power plants, power grid dispatching
centers, hospital emergency rooms, air traffic control, aircraft carriers, those kinds of
places. Think about an aircraft carrier. I mean, the planes don't have a lot of place
to land and a lot of place to take off and there's huge amounts of potential for accident
and they're going to be fatal if they happen most of the time. High reliability organizations
have more than their fair share of unexpected events and they persistently have less than
their fair share of accidents and they really relate to this because our plant worked in
almost exclusively highly explosive chemicals. That's basically what, you know, happens in
our plants. When I did computer control systems, I had to put my computers in class one group
D enclosure so those of you have been in explosion environments know that that means that no,
you know, it's got pressure out so that no spark can get--so that no spark from the computer--pressure
in so no spark can get out kind of thing. And so, in our plant--actually, in all 3M
labs, all labs have an explosion wall, in case, you know, whatever blows up in there,
it just--it will collapse out. It's happened once or twice. We had a plant to--we had a
fire once and the plant manager was really pleased it wasn't our coating area. It lasted
about 15 minutes. He says the first time in the plant that a woman cause the fire, a woman
found it, a woman who put it out. And because he was proud of that--but anyway, we had--we
had an occasional disaster too and I was involved in the startup at the Oklahoma City plant
where I was doing a startup. I was sitting in the control room and the project manager
was there and the alarms went off and he's--I looked at him, he says, They're just testing
the alarms today. And then all of a sudden, they got up and shout out of the room and
I says, Just testing, sure. And they weren't. So I went out and here's this cloud of smoke,
what is it? It's CO2. Now CO2 sits in all 3M plants by the coater head because if there's
a fire, that's what you got to do, is suppress it immediately with CO2. But if you're a person
and you get suppressed with CO2, you're going to also get suppressed. So this is not a good
thing and this is a startup. Startups are the most dangerous time in any kind of an
environment and here was this huge cloud of CO2. The question is, was the area clear?
Now, fortunately, for everybody the plant engineer happened to be at the coater room
door when this happened and he was smart enough and he always knew exactly what to do because
he lived in that plant. He cleared the area and by the time the project manager got down
there, the plant engineer had everything under control, knew that the area is clear but it
was scary because it's, you know, when you get involved in life critical situations,
you have a huge emphasis on safety. In our plant, we had--somebody did nothing but make
sure everybody understood safety. The common characteristic of these kinds of organizations
is mindfulness. This is a very interesting book about these kinds of organizations by,
let's see, Weick... >> Weick and Sutcliffe.
>> POPPENDIECK: Weick and Sutcliffe and it's called Managing the Unexpected: Assuring High
Performance in an Age of Complexity. And what they say is that in these kinds of things,
nuclear power plants, aircraft carriers, that sort of thing, mindfulness is the thing that
makes things work. It's the thing that you have to have throughout the culture of the
organization in order to have high reliability. What is that? It's preoccupation with failure
which sounds strange. Why are we preoccupied with failure? Think about it. You have to
always expect that's something's going to go wrong and always be prepared for it. There's
none of this life is good. This is, ignore all those little problems. You can't ignore
issues. You never ignore issues. You make sure that you're always aware that something
unexpected could happen and you're prepared for it because it can--anything that can go
wrong will eventually go wrong. You know, if you're building something that's going
to be on a transaction processing environment some day in your code and you say, well, that'll
happen once in a million or once in two million times, you know, it's going to happen. Someday,
it's going to bring some system down and it's going to cost one whole lot of money if that
transaction system gets tied up for an hour or two. A lot more than it would cost you
to pay attention to it on the front. Reluctance to simplify. The fact is, we live in a complex
unpredictable world and standard procedures cannot replace thinking people. So you will
not--you will find--like I went to an airport and it was very interesting. I was watching
the driver and he had a, you know, luggage cart behind him and he got out of the luggage
cart and he seemed to be totally absentminded as he walked to the front of the luggage cart,
took these two triangles that were sitting there, put one by each wheel and then went
off and get whatever. It was so routine, I'm sure he didn't think--he didn't look like
he was thinking about what he was doing but to him, stopping a car meant checking the
wheels. There was no question. It's just, like, it was so automatic. It happened. You
could see how automatic his reactions were. That's what happens here. You have standard
procedures. You must check the wheels but you also have everybody paying attention to
make sure that that doesn't--that that happens. Sensitivity operations. What you really have
to do is be attentive to the frontline where the work gets done and it's called in the
Toyota Production System, Go to the Gemba. Go where things work. In an aircraft carrier,
the head of the--I don't forget which they call the admin will spend time on the deck
because that's the only place you can really feel what's happening. Commitment to resilience.
You have to take every single smallest incident that happens and deal with it. Stop, investigate,
find the first root cause and fix it. And also you have to have difference to expertise.
It doesn't matter if you're the most senior guy in the ship. The experts are the ones
who really understand the technology on how to do the detailed stuff. So you use mission
command not detailed command. I'm going to talk about mission command versus detailed
command later so you just have to remember that for a minute. Oh, now. It's next. Mission
command versus detailed command. Okay. So this is straight out of the Armed Forces commanding
control book. It's called Mission Command, command forces and it's about what constitutes
commanding control in the US Armed Forces. And by the way, it's an interesting book,
it doesn't have--it doesn't have a copyright, it says, "Please use this however you want."
So that's why I get to copy it. And it defines very clearly there's mission command and detailed
command. And mission command, if you look at it, it assumes that war or whatever is
your doing, economic war you name it is, if you're in detailed command deterministic and
predictable. But if you want mission command what if war is probilistic and unpredictable?
Then maybe you have a different approach. It accepts mission command that there is disorder,
there is uncertainty and therefore it tends to lead to decentralization, spontaneity,
informality, loose reins, self-discipline, initiative, cooperation, acceptable decisions
faster rather than optimal decision as is listed over here. And so the kind of leadership
that you need is there. Now, that's command and control. So I don't like the term command
and control is bad because people tend to think that command and control means detailed
command. But in army manuals does not actually what it means at all, it means both of these.
And when you have this kind of an environment over here which is all of these probabilistic
and other things then you want mission command versus detailed command. So, where does software
fit in? I think it fits over here, just like--just like those high reliabity organizations fit
over there. So, now where does software fit in? When I was at 3M I was what--with the
last decade on 90's I was what was called a product champion and I'm going to call it
for purposes of now, a product leader or at Toyota this person would be called a chief
engineer. So, when you're developing a product it is really important for the organization
to make sure that they get the right thing, they get what people really want and--and
I was a very big advocate, and I still am, of making sure that when people are working
in a project they talk the potential costumers, they walk on their shoes, they understand
them. But when push comes to shove it--you don't leave important decision up to a vote,
somebody takes responsibility for making the ultimate decisions or maybe you can have a
committee vote. But if the committee votes, you know, then who's responsible? Or maybe
you can have a marketing person say "Oh, all of our competitors are doing this maybe we
ought to do the same thing." But, you know, that's not going to give you the next generation
product either. So, instead when you need to--in the end have somebody that really is
deciding what a product wants to be this is a leader not somebody that tells everybody
what to do, but somebody has a vision. And at Toyota and actually 3M the chief and the--the
champion, was exactly very similar; responsible for business success and it was okay to have
failures too because of you didn't have a few failures you weren't trying. Which probably
sounds familiar at Google, right? If you don't have a few failures you're not trying. But
you got to have also responsible for business success, develops deep costumer understanding.
So this-this product leader is responsible to really understand costumers and bring the
team out to understand costumers. Develops a product concepts but note, creates a high
level systems design. The chief engineer at Toyota is one of the most skilled, technical
people in the company, highly skilled engineer. At 3M, the product champion was 95% or 98%
of the time a highly skilled technical person not from marketing. It didn't get marketing
input but the vision had to marry the available technology with the market need and that was
generally done through the eyes of somebody who really got the technology and then understood
the market. And that is also the same concept that Toyota has with their chief engineer.
Sets the schedule, that's interesting, I can talk more about that later if we have time
if you ask questions, but the chief engineer sets the schedule, decides product concept
to release it's going to be 15 months sets the major milestones and that's what happens.
Understands what costumers will value and conveys this to the engineers making the day-to-day
tradeoffs by walking around and talking to them, by making sure they understand the metaphor
or what you're trying to accomplish. And this is important the chief engineer has deep knowledge
of the technical details not every technical detail but certainly is a highly competent
technical person. Arbitrates tradeoffs when necessary and defends the vision. And whether
is the chief engineer or the product leader defending the vision against or from. Well,
then we have other people here, in a classic matrix organization anyway, you have another
kind of leader this is what we could call a department leader, functional leader at
3M. So you have a product development process of some sort and the end is to create not
just a product but a value stream that brings in some money somehow. And you have somebody
who has a vision and understands technical opportunities and really understands the market
and knows how to create some outcomes valued by costumers so that you can get some money
in. And then you have the development them that works. And the important thing here is
these technical people that are developing the product there also a learning stuff. And
one of the things in any product development process is that you're not just developing
a product, you are developing knowledge that will be use in future products. And that has
to be captured or you just re-learned it you dump it on the ground so you have useful knowledge,
where does it go. And like in my product for example as working in light fiber and we have
a lot of optics and I'm a mathematician, I got the optics but we have a lot of chemistry
and I'm actually not a chemist. So, we also created a lot of chemical inventions and we
had to have places for that to be--have a home. So, here is where somebody who protects
the knowledge of a particular technical area will come in and create functional expertise
whether it's how do we do use our interaction design, how do we do security, how do we do
chemistry, whatever or in--in our cases was how do we do micro structured surfaces, how
do we do ultra-pure plastics, you know, detailed how do we do the specific area of chemistry.
So, I had accesses to like some of the best people in the world in the chemistry environment
and in the areas that I was working in and it's because they had a functional home where
they had their equipment and material, their processes and they could do experiments and
bring it in to the product. So, the product leader and then the functional leaders, and
then what happens here is as these functional people with deep knowledge get assigned into
teams, they bring good decisions, integration thinking, innovation comes from this deep
technical knowledge brought to bear on a new product to people are trying to develop. So
that matrix of somebody leading the product and somebody understanding the underlying
technology is where I'm thinking about in product development in general and certainly
even in software development a--an idea of leadership, this kind of leadership of the
product and leadership of the technical expertise. So I'll look at it this way, when you have
a really important brilliant product you need to understand--you need to have somebody that
really understands the market that has business responsibility, costumer understanding, overall
planning anyway, tradeoffs. And you need to have technical leadership. You need an architecture.
You need some technical guidance on tradeoffs and integration and stuff like that. And that's
what they call the product leader. Product leader can be one or two people. If it's two
people however in Toyota for example always does it with two people. They have a brand
manager up top and a very good at that because of their history, you know, they are founded
Steve Cook who's a brand, you know, Procter and Gamble brand manger graduate. And then
they have a technical leader and these two joined at the hip working closely together
direct the product. So you can handle these two or one but my observation is brilliant
products have both. In some way to understand the market and understand timing and in some
way to understand the underlying technical capabilities marry in the head of a very,
you know, one or two people which then bring in the technical team. But you need one other
kind of thing. You need--let's go back to the training with an industry; supervisor's
job is to act as a teacher, make sure people who are new know how to do things, solve problems,
set standards constantly improve. And make sure that everybody that's there is assigned
into jobs and career paths where they can reach their full potential, somebody that's
taking care of people. And so somehow that role and these roles become my vision of the
important leadership roles and in any development organization whether it's software or whatever.
Now, we have some other people we see around, we see process leaders, okay? And if you have
a new process it doesn't hard to have process coaches but overtime that needs to become
embedded in the organization and become the job of the supervisor, line manager, as supposed
to the other way around. And we have these people that we call project leaders, worry
about funding, and scheduling and tracking. We actually didn't have project management
as a--a valid title in 3M until the mid to late 90's, because we had products but we
didn't really have projects. Okay? So, the idea here is that if you have overall release
planning with people able to meet the schedule based on, you know, milestones that they meet
then that is something that can be assumed into that job. So, any questions so far? None,
okay, sort of--yeah, go ahead. >> No--I'm thinking probably to myself [INDISTINCT]
where do consultants fit into this [INDISTINCT] >> POPPENDIECK: Well, you know, I actually
told you that already. He wants to know where consultants fit into this picture.
>> The ones that disappears, how you [INDISTINCT] >> POPPENDIECK: You know, at 3M you then have
consultants unless you needed help. >> Right.
>> POPPENDIECK: And you're goal in life was not to need help, okay? So--and remember in
our plans I think I had mention the strong bias against depending upon consultants and
so I see consultants as teachers feeding ideas, and getting people on--align on the same thinking
process so that the management team can get their act together and head together and figure
out in detail what it takes to move forward, okay? So, lots of--lots of things about ideas
but not going in and solving the company's problems, the company has to solve its own
problems. So, new ideas, new ways of thinking about things, new ways thinking about how
to aligns processes. We had an--we did have a consultant come in to our plant actually,
he was there for a day, looked around the plant, and at the end of the day he said "You
ought to go see the Nabisco factory in Chicago," I mean we're in, you know, Hutchinson, Minnesota
it's a long way, but I use to work in Chicago and I remember the Nabisco factory, "Because
they make cookies, you know, what you make isn't much different than cookies. But cookies
have to be made and got into shelves and sold and in people's house and eaten all in a week,
it's really fast. Those foods companies they have this problem solved. You ought to figure
out how they do it," that was like golden information it never occurred me until that
time, that they were companies that had been doing this for like decades, its just a time
thing and it was entirely possible if you had perishable items. And in fact if you look
at ZARA which doest very rapid replenishment of clothing in fashion stores, they treat
clothing like perishable food. And it's--they do. So the idea is don't figure out what's
going to be bought constantly replenish and rapidly make and move stuff into the market,
get it bought, and get it use in a very, very short cycle time. That's really about all
I remember he told us, but it was very interesting, very good idea, very good mental model for
us. It's--made the whole thing seem possible. Oh, maybe those guys in Japan weren't so nuts.
Actually if they could do it on the Nabisco surely we were smart enough to do it too,
that's what we figured. We were young and we were kind of foolish but we were actually,
also quite successful. So, consultants can see ideas but in the end the company has to
figure out how to solve its problems. And pretty much I looked at a management team
that has, you know, close responsibility for the lives or maybe, you know, a few hundred
people getting in line and thinking alike and figuring how to change that world. And
that kind of group of five hundred thousand people with, you know, group of management
that, you know, eight or ten that can talk to each other, not to fifty, that kind of
group can make dramatic changes fast. If you're talking about three or four thousand people
that need to be change I'm thinking "Yeah, I don't think so." So I don't try to go there.
So, that's--and I have this [INDISTINCT] 1:16 because I really did not spend my life being
a consultant, I spent my life in a--as a manager in a large corporation in which if you had
to have a consultant you weren't really doing your job and I have that bias until this day
although they do have some good roles. >> I come from financial services firm.
>> POPPENDIECK: Uh-hmm. >> And I--I'm just wondering if you [INDISTINCT]
>> POPPENDIECK: Uh-hmm. >> Now, we used to rely on consultants because
we used to have things that were sort of, you know, can processes that [INDISTINCT]
operations environment or even in business environment. And we used to really rely on
them to [INDISTINCT] objection of external perspective.
>> POPPENDIECK: Uh-hmm. >> For the last two years.
>> POPPENDIECK: Yup. >> From another firm.
>> POPPENDIECK: Make sense, it--really a good idea.
>> This--this role that that really fit. >> POPPENDIECK: Especially any process which
anybody in your industry can do already, okay? So, if want them to look at your, you know,
precious proprietary things probably not but if you--there's a really good process that
everybody in the industry has to do and you're not doing it as well as the others, you better
just figure out how everybody else just doing it and either buy it out or bring it in, it
makes a lot of sense. So, you definitely want to make sure that on the stuff that doesn't
really matter you are at least equal to everybody else in your industry, don't even try to be
better through. What you really want is one of those few things where if you're better
it's going to matter to your market and those are not where you want the consultants. Because
once you teach the consultant how to do your core important things right, you know, they
can sell it to somebody else. But, yeah, that's another good spot for consultants', standard
processes that must happen correctly within any kind of industry. You have no business
doing it worst than anybody else, okay? Once its known in the industry how to do stuff
I--I remember I was a--as a process control engineer one of the things I did was evaluate
was this computer screens that were used to control processes. And actually, at least
in my opinion and I'm bias and have a memory that undermine, that would be quite right,
but as I recall the TVC's 2000 or 3000 the Honeywell screen set the standard for user
interaction in process control design. And then I went out to all the other companies
that have process control systems and anybody that that didn't look at what Honeywell was
doing and invented their own user interaction screen they just, you know, they--they couldn't--they
couldn't come close. And I couldn't really have a lot for respect for the ones that didn't
recognize. The standards have been set just go follow it, instead of trying new invent
your own thing because you probably not going to come out with anything better. So, there's
areas where you definitely should be seeing what everybody else does and either buying
another [INDISTINCT] to help make it happen. And I'm not even saying anything wrong about
six sigma because in our plant if we didn't have really high discipline and good processes
we certainly weren't going to be able to solve our problem and, you know, capture the market
and we do, we change--the whole plans are wrong, we drop the prices dramatically, we
had very standard processes but they were all devise--devise by the people and the quality
program and the six sigma programs have many, many things in common. So, you know, nothing
against that, that's actually why I pick that one, is because I think it has a huge amount
of good stuff. As long as you don't think it's going to save your company because it
isn't, the people are. >> You're--you're statically [INDISTINCT]
>> POPPENDIECK: It wasn't mine. I was just doing the funny quote there.
>> The reason for that one [INDISTINCT] >> POPPENDIECK: Uh-hmm.
>> So who's going to [INDISTINCT] >> POPPENDIECK: Well, I'm not going to chase
down that path, how about that? Anymore questions, yes?
>> It seems that the product leader really needs to have a good marketing, very deep
marketing and very deep technical knowledge, do you find those people?
>> POPPENDIECK: So, the marketing leader has to have access to deep, technical and ar--no,
it's a deep marketing knowledge not have it. So, let's take the case of--first of all I
wont to answer your second question for a minute, but example is the Lexus, when the
Toyota decided to do--they decide that they were in a cheap car market and their--their
buyers were going up and getting more money and they--they have a luxury car. So that
was a decision by EG Toyota who pretty much said we need to go this way. And they tap
a very senior marketing executive from the US to figure out how to sell the car because
it was a US car. And he wrote a book about it and he said in that book that the hardest
thing you do was go back until EG Toyota that the car could not have the Toyota name, it
had to have a different brand and--because it would have the wrong image. Now, the chief
engineer was not figuring out what kind of image the Lexus had to have in the US, was
not figuring it out that that it had to have a new distribution market. But the chief engineer
was responsible to make sure that that was thought of. And that it happened in the same
amount of timeframe as everything else. So, while the--he was doing all of this marketing
investigation he was also going to Japan talking to the chief engineer and the team like that.
So he had access to stuff and understood that entirely new distribution market--distribution
system had to be set up in time for the introduction of the car. And while we're at it, they also
had to build complete new manufacturing facility because the tolerances on the car were much
tighter than any existing process equipment. So, the chief engineer had to know that he
had to build a value stream, new manufacturing capability complete new distribution system,
and a car and synchronize it. Now, one person didn't do that all by themselves but they
knew that it had to happen and had, you know, plenty of help to make the things that they
didn't have expertise [INDISTINCT] happen. So, that's the--one person can't do it all
but in the end somebody ends up being responsible and in Toyota and in 3M, it usually starts
out anyway with new products being a technical person that has the vision of the technology
in the market as opposed to the other way around. So, where do these people come from?
Depends on the company. It depends on if your company values them, they tend to actually
grow. So in 3M we actually didn't have a lot of trouble finding product champions because
people love to be on this teams, that was the best job in the company. Everybody aspired
to be a product champion; you could watch them--I work for--I work for Roger Appledorn,
he invented the overhead projector and he brought into the company billions of dollars
of micro structured surface business, he was an amazing guy and, you know, just to work
for him was amazing and he thought me a lot and I tried to pass it on to other people.
You don't have a few to seed and you don't respect the job, you won't have the people
but it's actually a really fun job and when it's there people will find their way into
it that are good. We had a talk two weeks ago at the Lean product and process development
conference in the--Denver and this was a talk by somebody from GE Medical Imaging System
and he was talking about how they decided they were going to have product managers wing
to wing responsibility for a product and they had no people like that. So, they did their
best shot of assigning them and then they created training, lots of help, a product
leader console so they could get together and help each other out, plenty of guidance
but they first decided they really had to have this wing to wing ownership responsibility.
So, it's not people that happen by magic but you can if you decide this is important, find
and grow the people to make it happen but you have to respect an honor them, it has
to be really the best--well, I think the best job in the company. More questions? Yes.
>> Okay, you may have answered this already, I assume [INDISTINCT] collaborated on me but
in my organization, and some of the organizations I have seen, the IT well improve, you know,
as a service, right, in the business. So they don't necessarily have like business knowledge
which gives me a full [INDISTINCT] representative from a particular business function that is
[INDISTINCT] the company needs [INDISTINCT] is public leader as you mentioned, right?
Where I see the technical lead... >> POPPENDIECK: Help?
>> Well, I--I'm just--my experience... >> POPPENDIECK: But go ahead, yeah, go ahead,
go ahead. >> From my experience I've seen that the business,
I mean, when the functional people come in and they play more as a [INDISTINCT] leader
and in--from your development team--0your technical group maybe an architect or project
manager or business analyst is more of that technical leader role.
>> POPPENDIECK: Uh-hmm. >> So, when you start saying that you have
a product leader here and--and this best job is out there, you see mostly as that--those
individuals from the It services that are playing more the part--the leader role or
do you seem to be more as those business representatives that gets to see that it's coming in [INDISTINCT]
leader role. >> POPPENDIECK: So, IT is an interesting situation
because it's a service organization into an organization that then provides product sense
of market. So, you're like a layer removed from where the money is and I've seen some
interesting stuff from McKenzie about how the best way to run in the situation like
that is to create a product manager role inside of IT and not believe everything that the
business does but actually figure out what they--help them to figure out what they really
need in order to be profitable because--or, you know, in order to get productivity out
of your services because if you just do everything they say and it's one person, what if they
get it wrong and how are you walking in their shoes and really understanding how it works?
And so if one model is to be actually product company and sell your products into the rest
of the company. There are other models too but it's a struggle in that particular situation
to figure out where the real ownership is because you are one level removed from where
the real value is and you need to get close to the value in order to have the vision of
what your trying to do. >> I'm actually at McKenzie and...
>> POPPENDIECK: You remember that report? >> Yes.
>> POPPENDIECK: It's about--it's about--thanks for--because I'm pulling Spain and in Europe
and it's about three or four years old and if you check it out or give me an email I
can probably send you the reference. So if you're at McKenzie, you better give me [INDISTINCT]
send me an email. Any more? So, I'll just rap up with my last story and that is a story
about a philosopher in Italy that was strolling through a quarry some decades ago and he went
up to some stone cutters and he says, So, what are your buildings? I mean, you know,
philosophers do crazy things. So, the first he said was to the first fellow he ran into.
So, What are you doing? And he said, You know, what do you think I'm doing? What did it look
like? I'm cutting stones. I don't like this job I hate it I have to do it because I can't
get any other job and it's really hot then go away, I don't want to talk to you. Okay,
so being a, you know, intrepid philosopher he goes on to the next fellow and he says,
What are you doing? And he says, I'm earning a living. I am putting food on the table,
house over my family, you know, I'm earning a living. And well, actually that wasn't such
a bad response he felt a little bit better but, you know, we've got to always check out
three different sources, that's my theory too. You can't ask just--you can't read one
book on anything, you can't talk to one people or person or anything. You got to check out
three. So, there goes the third person and she says, So, what are you doing? And he said,
I'm building a Cathedral. This is a book by Ricardo Semler which is called Maverick and
he also wrote the Seven-Day weekend and it's about the company in Brazil that his--he--he
took it over as a very young age and his--he first ran it sort of like a judicial company,
almost killed himself and then he said, Something's wrong here. And he got a brilliant personnel
manager and he said, What I really want is Cathedral builders, so he took this parable
and he said, I want Cathedral builders. What does it take to have Cathedral builders and
he kind of changed the whole philosophy of the company around, I got to figure out what
it takes to of every single person in my company be a Cathedral builder. So, there's a lot
in this books, they're pretty radical actually about how he has a very large engineering
organization with pretty much no rules and it works but he's trying to create an environment
where--what [INDISTINCT] everybody reaches their full potential, they build Cathedrals.
So, what your trying to do, this is what I remember from my experience in the planks
and from other times that I was working. I had this beaten into my head, the idea is
to move responsibility and decision making to the lowest possible level, that's what
you do when you're a leader. You don't make the decisions, you do the same thing that
they figured out in the art of war and, you know, the 1870's and 1930's move this--it's
the individual who counts and it's the leader who makes that individual feel valuable and
take initiative, that's the good leader. So, if you have people, how do you know whether
you have stone cutters or Cathedral builders? Do I have a test and you can all take this
test. So, says somebody shows up with your company in the morning and they get annoyed
by their job, something in their job makes them annoyed. I mean, it could happen to you,
right? Ever been annoyed by something? Okay. So, let's just pretend that happens. Now,
the question is, what would you expect them to do? Would they complain, would they ignore
it or would they fix it? If you pretty much expect everybody to complain and you have
Cathedral stonecutters and after they ignore it, you have people who are earning a living
and if you basically have the stuff in place that the people are expected to fix this stuff
that annoys them then you have Cathedral builders. So, this concept that relentless improvement
means, the structures are in place, the management encouragement is in place, the leadership
is in place so that when people are annoyed by something in their job, their boss's job
is to help them fix it not live with it, not well, sorry that's regulations, but okay,
how about we figure out what the real problem is, you know, maybe that's not the problem
let's get it at the root cause. How about you come up with an idea about what make it--what
might make it better? Maybe we could do some experiments to figure out whether not that
really makes it better, that's the job of a manager in an organization that has Cathedral
builders and really can do constant improvement all the time for decades on it. So, if you
have cathedral builders, you have a leadership culture which helps people who were annoyed
by their job use their creativity not to drop a suggestion in the suggestion box but to
go out and figure out how to solve the problem, get data, try experiments to prove that there's
a better way and make that better way the way things are done. So with that, it's time
to go I guess and thanks everybody.