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