1
00:00:00,000 --> 00:00:02,200
Hey, a quick message. 
For those of you who are 

2
00:00:02,200 --> 00:00:04,300
listening to this episode on 
Spotify. 

3
00:00:04,600 --> 00:00:07,500
I have a small favor to ask 
Spotify. 

4
00:00:07,500 --> 00:00:10,100
Now allows mobile users to rate 
podcasts. 

5
00:00:10,400 --> 00:00:13,300
I would really appreciate it. 
If you can take a quick, pause 

6
00:00:13,300 --> 00:00:16,100
to go to the technique Journal 
podcast page, and leave your 

7
00:00:16,100 --> 00:00:18,800
favorite show. 
Your best rating on Spotify. 

8
00:00:19,200 --> 00:00:21,800
It will help me a lot to get 
this podcast to reach more 

9
00:00:21,800 --> 00:00:24,300
people on the platform. 
Thanks a lot. 

10
00:00:24,800 --> 00:00:26,300
Who'll don't push? 
Yes. 

11
00:00:26,500 --> 00:00:29,800
Don't tell people what to do. 
Tell them what results you want.

12
00:00:30,000 --> 00:00:32,800
Point and let them figure it 
out, that gives them the 

13
00:00:32,800 --> 00:00:36,500
satisfaction in the 
responsibility, to figure out 

14
00:00:36,500 --> 00:00:39,200
how best to achieve the outcome 
that's needed. 

15
00:00:44,000 --> 00:00:46,700
Hey everyone. 
My name is Henry Surya with 

16
00:00:46,700 --> 00:00:50,100
Robin. 
And you're listening to the 

17
00:00:50,100 --> 00:00:53,300
technology, you know, podcast 
the show where I'll be bringing 

18
00:00:53,300 --> 00:00:56,500
you the greatest technical 
leaders practitioners and 

19
00:00:56,500 --> 00:01:00,200
thought leaders in the industry 
to discuss about their Journey 

20
00:01:00,400 --> 00:01:04,900
ideas and practices that we all 
can learn and apply to build a 

21
00:01:04,900 --> 00:01:08,500
highly performing technical team
and to make an impact in your 

22
00:01:08,500 --> 00:01:11,700
personal work. 
So let's dive into our Journal. 

23
00:01:16,800 --> 00:01:20,000
Hello, my friends and listeners.
Welcome to the tekhelet journal 

24
00:01:20,000 --> 00:01:23,300
podcast the show where you can 
learn about technical leadership

25
00:01:23,300 --> 00:01:26,300
and Excellence from my 
conversations, with great 

26
00:01:26,300 --> 00:01:30,000
thought, leaders out there, and 
this is episode number 91. 

27
00:01:30,300 --> 00:01:32,800
Thanks for tuning in and 
listening to this episode. 

28
00:01:33,100 --> 00:01:35,100
For those of you who are 
listening to technology. 

29
00:01:35,100 --> 00:01:38,300
You know, for the first time, 
don't forget to subscribe and 

30
00:01:38,300 --> 00:01:41,800
follow the show on your podcast 
app and social media on 

31
00:01:41,800 --> 00:01:43,800
LinkedIn. 
Twitter and Instagram. 

32
00:01:44,200 --> 00:01:46,900
And if anyone wants to 
contribute to the creation of 

33
00:01:46,900 --> 00:01:50,800
this podcast, Let Me by 
subscribing as a patron at 

34
00:01:50,800 --> 00:01:54,500
technology. 
No, Dev slash Patron today, I am

35
00:01:54,500 --> 00:01:57,500
excited to share my conversation
with another great thought 

36
00:01:57,500 --> 00:02:00,200
leaders and Pioneers in the 
software industry. 

37
00:02:00,600 --> 00:02:04,600
My guest for today's episode are
Mary and Tom poppendieck, they 

38
00:02:04,600 --> 00:02:08,199
are the causes of several books 
related to a gel and lean 

39
00:02:08,500 --> 00:02:11,900
including the award-winning book
lean software development and 

40
00:02:11,900 --> 00:02:17,100
agile toolkit published in 2003 
in this episode Mary and Tom 

41
00:02:17,100 --> 00:02:18,400
shared about lean software 
development. 

42
00:02:18,500 --> 00:02:22,000
Element, its principles and 
mindset and the concept of a 

43
00:02:22,000 --> 00:02:26,000
pull System including the story.
How Mary first learned and 

44
00:02:26,000 --> 00:02:30,000
implemented a pull system in her
work at 3M Mary. 

45
00:02:30,000 --> 00:02:33,400
And Tom, then pointed out the 
problems of having proxies in 

46
00:02:33,400 --> 00:02:37,000
software development and how it 
is much better to manage by the 

47
00:02:37,000 --> 00:02:40,600
outcomes by having the people 
directly figuring out the best 

48
00:02:40,608 --> 00:02:45,400
way to achieve those outcomes 
later on Mary and Tom talked 

49
00:02:45,400 --> 00:02:48,500
about the concept of flow y. 
It is important. 

50
00:02:48,500 --> 00:02:52,400
To optimize flow and how to 
optimize Flow by analyzing the 

51
00:02:52,400 --> 00:02:56,000
value stream map and minimizing 
approval process. 

52
00:02:56,600 --> 00:03:00,400
I really enjoyed my conversation
with Mary and Tom learning the 

53
00:03:00,400 --> 00:03:03,200
essence of lean software 
development from listening to 

54
00:03:03,200 --> 00:03:05,500
their insightful, stories and 
Concepts. 

55
00:03:05,900 --> 00:03:08,800
I specially like our discussion 
about the to so-called 

56
00:03:08,800 --> 00:03:12,400
anti-patterns to lean which are 
having proxies and requiring 

57
00:03:12,400 --> 00:03:14,900
approvals. 
If you also enjoyed this 

58
00:03:14,900 --> 00:03:17,500
episode, please share it with 
your friends and colleagues. 

59
00:03:17,800 --> 00:03:21,400
Who can also Benefit from 
listening to this episode, leave

60
00:03:21,400 --> 00:03:24,400
a rating and review on your 
podcast app and share your 

61
00:03:24,400 --> 00:03:27,600
comments or feedback about this 
episode on social media. 

62
00:03:27,900 --> 00:03:31,300
It is my ultimate mission to 
make this podcast available to 

63
00:03:31,300 --> 00:03:33,800
more people. 
And I need your help to support 

64
00:03:33,800 --> 00:03:35,700
me towards fulfilling my 
mission. 

65
00:03:36,200 --> 00:03:38,200
Before we continue to the 
conversation. 

66
00:03:38,500 --> 00:03:40,600
Let's hear some words from our 
sponsor. 

67
00:03:41,200 --> 00:03:44,500
Today's episode is proudly 
sponsored by skills matter. 

68
00:03:44,800 --> 00:03:48,400
The global community and events 
platform with more than 100,000.

69
00:03:48,500 --> 00:03:52,300
And software professionals here 
members can organize their 

70
00:03:52,300 --> 00:03:55,100
learning experiences around the 
technology topics. 

71
00:03:55,100 --> 00:03:58,900
They care about most you get 
on-demand access to their latest

72
00:03:58,900 --> 00:04:02,200
content thought, leadership 
insights, as well as the 

73
00:04:02,200 --> 00:04:06,300
exciting schedule of tech events
running across all time zones. 

74
00:04:06,700 --> 00:04:10,100
So we're the devops. 
Our data science is your bus or 

75
00:04:10,100 --> 00:04:13,600
you are fan of functional 
programming or all things Cloud,

76
00:04:13,600 --> 00:04:16,500
you can make real connections 
with people who share your 

77
00:04:16,500 --> 00:04:20,000
interests head on over. 
The scales method are calm to 

78
00:04:20,000 --> 00:04:22,800
become part of the tech 
community that matters most to 

79
00:04:22,800 --> 00:04:25,000
you. 
It's free to join and you will 

80
00:04:25,000 --> 00:04:28,000
find it easy to keep up with the
latest tech Trends. 

81
00:04:28,300 --> 00:04:31,000
Are you looking for a new cool 
swag package? 

82
00:04:31,000 --> 00:04:34,000
You know now offers you some 
swags that you can purchase 

83
00:04:34,000 --> 00:04:37,000
online. 
These wax are printed on demand 

84
00:04:37,000 --> 00:04:40,400
based on your preference and 
will be delivered safely to you 

85
00:04:40,400 --> 00:04:42,900
all over the world where 
shipping is available. 

86
00:04:43,400 --> 00:04:46,000
Check out all the cool tracks 
available by visiting 

87
00:04:46,000 --> 00:04:49,400
technology, you know, dot, f / 
shop, and don't forget to break 

88
00:04:49,400 --> 00:04:51,600
yourself. 
Once you receive any of those 

89
00:04:51,600 --> 00:04:57,200
threats, everyone welcome back 
to another new episode of the 

90
00:04:57,200 --> 00:04:59,000
tekhelet journal podcast. 
Today. 

91
00:04:59,000 --> 00:05:02,500
I have with me to guess in one 
episode and both are big names. 

92
00:05:02,500 --> 00:05:05,300
In software industry. 
They wrote books on lean 

93
00:05:05,300 --> 00:05:08,200
software development long time 
ago and they've been preaching 

94
00:05:08,200 --> 00:05:11,100
that for quite some time now, 
and I'm really proud to have 

95
00:05:11,100 --> 00:05:14,400
both Mary and Tom poppendieck in
one episode today. 

96
00:05:14,600 --> 00:05:17,100
So I really appreciate both of 
you spending your time here. 

97
00:05:17,100 --> 00:05:18,400
I'm really looking forward to 
this. 

98
00:05:18,500 --> 00:05:21,100
Thing about the in software 
development or anything that you

99
00:05:21,100 --> 00:05:24,600
are working on lately. 
So, welcome, Mary and Tom, it's 

100
00:05:24,600 --> 00:05:28,300
good to be here, indeed. 
So I always like to start my 

101
00:05:28,300 --> 00:05:31,400
conversation by asking about 
your journey or background. 

102
00:05:31,500 --> 00:05:34,400
If you have any turning points 
or highlights in your career, 

103
00:05:34,400 --> 00:05:36,800
that maybe you haven't shared 
with other people before. 

104
00:05:36,900 --> 00:05:39,600
Would you be able to share some 
of those to us here? 

105
00:05:40,500 --> 00:05:43,000
Sure. 
I started at my actual first 

106
00:05:43,000 --> 00:05:46,300
program was in 1967. 
I was a junior in high school 

107
00:05:46,700 --> 00:05:50,200
and I went to a science. 
It's summer camp or one of the 

108
00:05:50,200 --> 00:05:54,900
things we did was we programmed 
a computer and it was 

109
00:05:54,900 --> 00:05:59,400
programming in zeros and ones. 
We had an assembly language. 

110
00:05:59,400 --> 00:06:03,900
We manually translated that in 
paper into zeros and ones and 

111
00:06:03,900 --> 00:06:05,800
then we type those into Punch 
Cards. 

112
00:06:06,400 --> 00:06:10,500
My program was one of the later 
ones run, and I watched program 

113
00:06:10,500 --> 00:06:12,900
after program. 
We travel by bus to the computer

114
00:06:13,300 --> 00:06:14,800
one. 
After another, the programs were

115
00:06:14,800 --> 00:06:17,600
put in. 
And they failed, mine went in 

116
00:06:17,900 --> 00:06:21,800
and it Printed something I was 
doing either the in Victoria or 

117
00:06:21,800 --> 00:06:24,300
something because they said you 
can do a hard one, hears, this 

118
00:06:24,300 --> 00:06:27,400
one, and then it printed another
line, and then it gets lower and

119
00:06:27,400 --> 00:06:29,300
then it gets slower. 
And they said, it's, I guess it 

120
00:06:29,300 --> 00:06:31,400
must have hung up. 
They were about to stop the 

121
00:06:31,407 --> 00:06:33,500
computer, can be printed another
light. 

122
00:06:33,700 --> 00:06:36,200
So it's just taking longer and 
longer to compute. 

123
00:06:36,500 --> 00:06:40,500
I was so excited and pleased 
that probably made me a software

124
00:06:40,600 --> 00:06:44,400
programmer for life, because I 
was so proud of myself, but 

125
00:06:44,400 --> 00:06:47,300
note, the, what I had to do in 
order to make sure that it ran 

126
00:06:47,300 --> 00:06:51,400
was, I had to be, Sure, that 
every single punch matched. 

127
00:06:51,400 --> 00:06:54,800
Every single 0, and 1, and every
single 0, and 1 match, the 

128
00:06:54,800 --> 00:06:57,700
intention in Assembly Language 
and that the Assembly Language 

129
00:06:57,700 --> 00:07:00,300
matched the front language the 
concept that I have. 

130
00:07:00,500 --> 00:07:04,600
So a whole lot of inspection. 
Then I went to programming in 

131
00:07:04,700 --> 00:07:08,100
Bell, Telephone Laboratories, 
and we were programming 

132
00:07:08,200 --> 00:07:12,800
switching computers when I was 
doing the switching computers. 

133
00:07:13,200 --> 00:07:15,800
What I was working in is an 
assembly language, which 

134
00:07:15,800 --> 00:07:19,200
essentially mimicked 
electromechanical Actions that 

135
00:07:19,200 --> 00:07:22,100
the previous generation of 
telephone computers went 

136
00:07:22,100 --> 00:07:24,700
through. 
It was all 70 language without 

137
00:07:24,700 --> 00:07:28,000
having to do the zeros and ones.
So a lot less inspection. 

138
00:07:28,200 --> 00:07:30,700
I did a lot of coming in on the 
weekends. 

139
00:07:30,900 --> 00:07:34,100
I was doing diagnostic. 
It was a completely reliable 

140
00:07:34,100 --> 00:07:36,300
computer. 
It would throw one out or the 

141
00:07:36,300 --> 00:07:38,500
other depending upon it was 
running twins. 

142
00:07:38,500 --> 00:07:41,600
If something went wrong because 
we had the goal of a maximum 

143
00:07:41,600 --> 00:07:46,700
down time of 2 hours and 40 
years, and we actually met that 

144
00:07:46,700 --> 00:07:50,100
goal with this twin computer. 
Because it was all individual 

145
00:07:50,100 --> 00:07:52,600
components with known mean times
between failure. 

146
00:07:53,000 --> 00:07:57,000
They had four hours to repair 
any downtime like programs had 

147
00:07:57,000 --> 00:07:59,700
to go and find the bad card and 
tell them to change it. 

148
00:08:00,100 --> 00:08:03,400
I did a lot of testing by just 
pulling a component out of a 

149
00:08:03,400 --> 00:08:06,300
card and then seeing if my 
diagnosis could determine which 

150
00:08:06,300 --> 00:08:11,300
car so I didn't necessarily 
worry too much about all of the 

151
00:08:11,300 --> 00:08:14,700
details being perfect because if
it didn't compiled and ready to 

152
00:08:14,700 --> 00:08:18,000
run, I could go in and fix it. 
The next program I had was 

153
00:08:18,000 --> 00:08:20,200
working. 
At the University of Wisconsin, 

154
00:08:20,200 --> 00:08:23,900
programming physics experiments 
that were being controlled by a 

155
00:08:23,900 --> 00:08:26,100
mini-computer. 
One of the very first 

156
00:08:26,100 --> 00:08:30,100
mini-computers predated. 
Even the Dell mini computers. 

157
00:08:30,400 --> 00:08:33,000
The company went bankrupt. 
My boss. 

158
00:08:33,000 --> 00:08:35,400
Always the kind of scrounge up 
for money, in a physics 

159
00:08:35,400 --> 00:08:39,299
department, bought up their 
whole stack of two or three and 

160
00:08:39,299 --> 00:08:42,400
then we programmed it. 
We had to complete the Fortran 

161
00:08:42,400 --> 00:08:46,100
compiler, which wasn't done yet.
So I was working at a council 

162
00:08:46,100 --> 00:08:49,500
with individual lights that I 
could Read the code while 

163
00:08:49,500 --> 00:08:53,100
watching the late scope. 
I I learned very quickly. 

164
00:08:53,100 --> 00:08:55,700
First of all, I started 
programming Assembly Language, 

165
00:08:55,800 --> 00:08:58,100
but once we got the compiler 
more or less working I 

166
00:08:58,100 --> 00:09:03,300
discovered that if I program in 
Fortran because the speed was so

167
00:09:03,300 --> 00:09:06,300
important. 
I'm a manually translated that 

168
00:09:06,300 --> 00:09:10,200
to Assembly Language. 
I could test the algorithm in 

169
00:09:10,200 --> 00:09:14,200
Fortran and then I could 
manually put it to Assembly 

170
00:09:14,200 --> 00:09:16,300
Language. 
Therefore knowing that things 

171
00:09:16,300 --> 00:09:20,800
were right became one step. 
Easier because I could get all 

172
00:09:20,800 --> 00:09:23,400
of the logic proven out its 
portrait. 

173
00:09:23,700 --> 00:09:26,600
The next thing I did was I 
programmed computers. 

174
00:09:26,600 --> 00:09:30,600
It was typically in basic that 
did process control systems and 

175
00:09:30,600 --> 00:09:34,000
we always test that our stuff by
having inner engineering lab 

176
00:09:34,300 --> 00:09:37,600
mock-ups of the equipment and 
then I would go in and I'm just 

177
00:09:37,600 --> 00:09:41,400
having an operator control a 
control Loop by putting in a set

178
00:09:41,400 --> 00:09:43,600
point. 
So, I would test and make sure 

179
00:09:43,600 --> 00:09:46,000
everything worked. 
So that, by the time we brought 

180
00:09:46,000 --> 00:09:49,800
it to the site to install. 
All of the logic had been 

181
00:09:49,800 --> 00:09:52,400
debugged and all we were doing 
was debugging like race 

182
00:09:52,400 --> 00:09:55,900
conditions and stuff like that. 
Most of the stuff that I 

183
00:09:55,900 --> 00:09:59,000
programmed had to be maintained 
by the plant engineer. 

184
00:09:59,700 --> 00:10:03,000
Therefore, I concluded. 
There was no way I could do any 

185
00:10:03,000 --> 00:10:06,300
Assembly Language because plant 
engineer could not be expected 

186
00:10:06,300 --> 00:10:08,100
to have to learn Assembly 
Language. 

187
00:10:08,200 --> 00:10:12,900
So I did virtually everything in
basic and just a few things in 

188
00:10:12,900 --> 00:10:15,800
Assembly Language, that probably
would not have to be changed. 

189
00:10:16,000 --> 00:10:19,500
Then I went to do stuff for 3m 
on presses. 

190
00:10:19,500 --> 00:10:21,900
Controls. 
Our tool was a mini computer, 

191
00:10:21,900 --> 00:10:24,500
which is now been a chips. 
But at that time it was like 

192
00:10:24,500 --> 00:10:26,900
that big. 
So then the next thing I did was

193
00:10:26,900 --> 00:10:29,200
I worked in a manufacturing 
plant that's r.e.m. 

194
00:10:29,400 --> 00:10:33,300
I was the it manager programmed 
in RPG. 

195
00:10:33,300 --> 00:10:36,800
So they only had to debug at a 
pretty high level because that 

196
00:10:36,800 --> 00:10:38,100
was a pretty high-level 
language. 

197
00:10:38,100 --> 00:10:41,800
And then I started going to a 
higher and higher level 

198
00:10:41,800 --> 00:10:44,400
languages. 
I always knew how the underlying

199
00:10:44,400 --> 00:10:47,000
system work because I grew up. 
You up with the underlying 

200
00:10:47,000 --> 00:10:50,700
system, but I moved to higher 
and higher mechanisms to 

201
00:10:50,700 --> 00:10:52,500
determine whether or not things 
were right. 

202
00:10:52,900 --> 00:10:55,100
I met a guy in Norway, Tom 
Guild. 

203
00:10:55,100 --> 00:10:58,000
And he told me once that he 
raised his family by teaching 

204
00:10:58,000 --> 00:11:00,900
people to inspect every single 
line of their code in detail 

205
00:11:00,900 --> 00:11:03,200
before they put it into a 
computer. 

206
00:11:03,500 --> 00:11:07,300
Well, I thought that was silly 
because first of all, you can't 

207
00:11:07,300 --> 00:11:11,500
find everything and second of 
all, as the tools for testing 

208
00:11:11,500 --> 00:11:15,600
increased, I had to do less and 
less infection because the 

209
00:11:16,100 --> 00:11:19,100
Courtney have fun this 
throughout the all the time that

210
00:11:19,100 --> 00:11:22,900
I was programming as you get 
better and better tools your 

211
00:11:22,900 --> 00:11:26,000
strategies for software 
development change. 

212
00:11:26,400 --> 00:11:28,900
You don't do the same thing. 
You did 10 years ago. 

213
00:11:29,100 --> 00:11:30,700
You surely don't do the same 
thing. 

214
00:11:30,700 --> 00:11:34,900
You did 20 years you do. 
What's the current technical 

215
00:11:34,900 --> 00:11:40,100
capability allows you to do now?
Just as a conclusion after I 

216
00:11:40,100 --> 00:11:45,500
retired from 3M in if 98 early 
1980 and started my own company.

217
00:11:45,700 --> 00:11:49,500
I Haven't actually developed 
code except maybe some controls 

218
00:11:49,500 --> 00:11:52,500
in their house, but I've 
observed that the kinds of 

219
00:11:52,500 --> 00:11:56,500
things that were our concern at 
the end of the last century, 

220
00:11:56,900 --> 00:11:59,700
which is when agile were 
invented, are long gone. 

221
00:12:00,100 --> 00:12:01,200
People. 
Don't do those. 

222
00:12:01,200 --> 00:12:05,200
Great big, massive deploys of 
two years apart and stuff like 

223
00:12:05,200 --> 00:12:09,000
that anymore. 
So we have developed a strategy 

224
00:12:09,000 --> 00:12:12,900
for dealing with 1890 problems, 
and we haven't walked away from 

225
00:12:12,900 --> 00:12:14,600
it. 
And said, what are today's 

226
00:12:14,600 --> 00:12:17,700
problems? 
What I've been trying to do for 

227
00:12:17,700 --> 00:12:20,700
the past 20 years. 
When I wrote my first books, I 

228
00:12:20,700 --> 00:12:25,200
was talking about 1990s, perhaps
as it went on, I started talking

229
00:12:25,200 --> 00:12:29,200
about mindset, how you think 
about things because the things 

230
00:12:29,200 --> 00:12:33,500
you do in detail, change all the
time, but the way you think 

231
00:12:33,500 --> 00:12:36,100
about how you do things doesn't 
change. 

232
00:12:36,600 --> 00:12:39,000
And so that's kind of what I 
learned in my career. 

233
00:12:39,600 --> 00:12:42,800
So one thing that I would 
probably add first, I appreciate

234
00:12:42,800 --> 00:12:46,000
the history, what you said. 
I couldn't imagine because I 

235
00:12:46,000 --> 00:12:48,800
wasn't born back then. 
I could really tell that it's 

236
00:12:48,800 --> 00:12:52,100
really hard to write a program. 
In fact, the feedback loop is 

237
00:12:52,100 --> 00:12:54,600
probably too long, right? 
Where you have to punch the card

238
00:12:54,600 --> 00:12:56,400
and then bring it to the 
computer and run it. 

239
00:12:56,400 --> 00:12:59,300
So when you have a willing see 
that review has to be really 

240
00:12:59,300 --> 00:13:02,900
careful. 
If you put in relatively quick 

241
00:13:02,900 --> 00:13:06,800
feedbacks and everything, the 
more feedback you put in the 

242
00:13:06,800 --> 00:13:09,700
more the feedback will tell you.
If you've done something wrong 

243
00:13:10,000 --> 00:13:14,100
rather than your taking the time
to inspect and it'll slap your 

244
00:13:14,100 --> 00:13:17,800
hand so fast that you'll learn. 
Do it really quickly and that's 

245
00:13:17,800 --> 00:13:20,300
really important. 
And that's actually one of 

246
00:13:20,300 --> 00:13:22,000
those. 
Fundamental principles have some

247
00:13:22,000 --> 00:13:23,900
Jake. 
The faster. 

248
00:13:23,900 --> 00:13:27,800
I as a programmer can get 
feedback, the better a job. 

249
00:13:27,800 --> 00:13:29,400
I can do in the more 
comfortable. 

250
00:13:29,400 --> 00:13:31,900
I am. 
So maybe tell me I've also other

251
00:13:31,900 --> 00:13:34,700
fascinating story that you want 
to share with us from your 

252
00:13:34,700 --> 00:13:38,300
background or your journey. 
My first contact with Computing 

253
00:13:38,300 --> 00:13:42,500
was in the 50s when I was in 
grade school, I became aware of 

254
00:13:42,500 --> 00:13:45,800
what computers were and that 
they needed to add. 

255
00:13:45,900 --> 00:13:50,000
Have flip-flops Gates. 
So I tried to build one out of 

256
00:13:50,000 --> 00:13:56,000
wood and nails and metal clipped
from a can, and a battery. 

257
00:13:56,000 --> 00:14:02,100
And I never did succeed. 
I went on to be a physics, major

258
00:14:02,100 --> 00:14:05,200
taught High School physics. 
Again, that was about the time 

259
00:14:05,208 --> 00:14:09,600
that the Commodore 64 and 
weighing calculators came into 

260
00:14:09,600 --> 00:14:13,100
being made a lot of use of that 
in teaching High School physics 

261
00:14:13,100 --> 00:14:16,400
for a number of years, but I 
wanted to No more. 

262
00:14:16,400 --> 00:14:20,800
So I went to graduate school and
when I got to my faceless, I had

263
00:14:20,900 --> 00:14:23,300
a bunch of calculation that 
needed to be done. 

264
00:14:23,700 --> 00:14:27,000
There are used for Tran 
fortunately, the engineering 

265
00:14:27,000 --> 00:14:31,400
department had a student 
computer lab that I could write 

266
00:14:31,400 --> 00:14:35,200
my program including a program 
to drive a plotter because I 

267
00:14:35,208 --> 00:14:37,300
didn't like their driver for 
their bladder. 

268
00:14:37,300 --> 00:14:41,000
So I wrote my own important 
thing was that I was able to 

269
00:14:41,000 --> 00:14:45,100
punch the cards, put them in the
card reader, see the print out 

270
00:14:45,100 --> 00:14:49,000
and in a very a short time, see 
how I'd screwed up. 

271
00:14:49,500 --> 00:14:52,100
The rapid feedback is absolutely
critical. 

272
00:14:52,400 --> 00:14:56,500
Those were back in the days when
the computer I have in my pocket

273
00:14:56,600 --> 00:15:01,200
that my smartphone was about the
size of a University Computer. 

274
00:15:01,300 --> 00:15:04,500
The same one that Mary's 
software eventually fit into 

275
00:15:04,800 --> 00:15:07,300
Tom's High School. 
One of the things, when they 

276
00:15:07,300 --> 00:15:10,600
hired him they said, well, we 
have a new device to put in your

277
00:15:10,600 --> 00:15:12,300
classroom. 
Would you use it to teach? 

278
00:15:12,600 --> 00:15:15,500
And it was a calculator? 
I mean, Play-Doh. 

279
00:15:16,000 --> 00:15:19,500
Later, and it was this big and 
that wide. 

280
00:15:19,700 --> 00:15:23,500
And he had a calculator, the 
size of a desk and he loved it 

281
00:15:24,000 --> 00:15:27,100
from there. 
After I got my degree to teach 

282
00:15:27,100 --> 00:15:29,500
at a university here, in 
Annapolis st. 

283
00:15:29,500 --> 00:15:31,200
Paul area. 
One of the courses. 

284
00:15:31,200 --> 00:15:34,700
I taught was Electronics. 
I also thought Pascal 

285
00:15:34,800 --> 00:15:39,300
predecessor to Java and got more
into the abstract. 

286
00:15:39,300 --> 00:15:43,800
So programming about the time. 
And I started here at 3M, that 

287
00:15:43,800 --> 00:15:47,500
led to Bringing deck computers. 
Into the university crawling 

288
00:15:47,500 --> 00:15:50,000
through Steam, tunnels to string
wires. 

289
00:15:50,000 --> 00:15:53,200
So that teletype machines, could
be installed in several 

290
00:15:53,200 --> 00:15:55,900
buildings rather than only the 
science building. 

291
00:15:56,100 --> 00:15:59,500
I used it to teach course in 
astronomy for a self-paced, 

292
00:15:59,500 --> 00:16:03,600
astronomy course, so that will 
is a important step. 

293
00:16:04,000 --> 00:16:07,300
And at that point, every small 
University not just, the big 

294
00:16:07,300 --> 00:16:10,600
state universities had the 
smartphone level of computing 

295
00:16:10,600 --> 00:16:12,800
capability that they would Tha 
out. 

296
00:16:13,200 --> 00:16:17,000
I went from there to work for 
Honeywell, do I Helping with the

297
00:16:17,000 --> 00:16:20,700
group that supported design of 
the navigation systems for 

298
00:16:20,700 --> 00:16:23,700
commercial airplanes. 
If you fly a Boeing or an air 

299
00:16:23,700 --> 00:16:27,500
boss or several other major 
airplanes, you were probably 

300
00:16:27,500 --> 00:16:31,100
navigated by the inertial 
navigation system over the load 

301
00:16:31,100 --> 00:16:35,100
balancing system that our plant 
here in Minnesota produced 

302
00:16:35,400 --> 00:16:36,900
learned. 
A lot is there. 

303
00:16:37,600 --> 00:16:40,400
It's absolutely critical that 
you do things, right? 

304
00:16:40,700 --> 00:16:45,600
The automated fault detection. 
Not only for the software but 

305
00:16:45,600 --> 00:16:49,100
also Also, for Hardware failures
that s to be detected and 

306
00:16:49,100 --> 00:16:52,900
responded to properly. 
So the same theme there, find 

307
00:16:52,900 --> 00:16:55,700
out immediately. 
When there's a problem and 

308
00:16:55,700 --> 00:16:58,300
respond in the appropriate way 
from there. 

309
00:16:58,300 --> 00:17:02,800
I became a consultant or a 
company that when I joined was 

310
00:17:02,800 --> 00:17:06,700
helping companies adopt 
object-oriented development, 

311
00:17:07,099 --> 00:17:10,700
initially that was powerbuilder,
but it rapidly evolved, my talk,

312
00:17:10,700 --> 00:17:14,099
my company. 
How to use Java, most of them 

313
00:17:14,099 --> 00:17:17,500
were better programmers. 
And I were And rapidly outpaced 

314
00:17:17,500 --> 00:17:20,700
me, but I got him started. 
He consulted with a lot of major

315
00:17:20,700 --> 00:17:24,300
companies around the world, but 
Matt position and then retired 

316
00:17:24,300 --> 00:17:27,300
to join Mary in the business 
that we have run. 

317
00:17:27,300 --> 00:17:30,500
Now for 20, some years really, 
nice story. 

318
00:17:30,500 --> 00:17:35,600
But one thing that I am curious,
when did you both meet Ali met? 

319
00:17:35,600 --> 00:17:39,300
It Marquette University and 65, 
followed 65. 

320
00:17:39,300 --> 00:17:42,500
We became physics Lab Partners. 
Wow. 

321
00:17:42,900 --> 00:17:45,700
Okay. 67 was not my first 
computing. 

322
00:17:45,800 --> 00:17:48,100
That was my first job Computing 
at Bell labs. 

323
00:17:48,300 --> 00:17:51,500
And we met two years before the 
thanks for sharing the story. 

324
00:17:51,500 --> 00:17:53,700
The background. 
So one thing, if there's any 

325
00:17:53,700 --> 00:17:57,000
threat that I could see from 
both of your stories, both of 

326
00:17:57,000 --> 00:18:00,600
you like to know the inner 
details of how things work and 

327
00:18:00,600 --> 00:18:03,800
both of you also like to 
understand what is going on. 

328
00:18:03,800 --> 00:18:06,400
Not just from the higher 
abstraction level, but also deep

329
00:18:06,400 --> 00:18:08,500
internals, right? 
I think that's part of 

330
00:18:08,500 --> 00:18:11,900
engineering is doing something 
important and know you're doing 

331
00:18:11,900 --> 00:18:15,000
it, right. 
It's not fun to find out a long 

332
00:18:15,000 --> 00:18:16,700
time. 
Later that The drop everything 

333
00:18:16,700 --> 00:18:18,800
and fix it in from six months 
ago, or whatever. 

334
00:18:19,000 --> 00:18:22,600
That's not quite, but being able
to do something, think it's 

335
00:18:22,600 --> 00:18:25,600
going to work. 
Run a very sophisticated tests 

336
00:18:25,600 --> 00:18:28,100
to make sure you've got it even 
if it's only partial of the 

337
00:18:28,100 --> 00:18:30,100
system. 
I mean, it just makes you feel 

338
00:18:30,100 --> 00:18:32,500
so good. 
I used to sit in my desk area at

339
00:18:32,500 --> 00:18:35,100
three and when I was very first 
programming something would work

340
00:18:35,100 --> 00:18:37,900
on a test has a yes, and 
everybody looked like what's 

341
00:18:37,900 --> 00:18:40,800
coming up. 
Does it feel so good to have 

342
00:18:40,800 --> 00:18:43,300
done something right? 
That's important to the system. 

343
00:18:43,600 --> 00:18:45,700
It's not just feedback that 
you've done something, right? 

344
00:18:45,800 --> 00:18:48,200
Right. 
It's like it's the fun of doing 

345
00:18:48,200 --> 00:18:51,600
software development in general.
So from that background, you 

346
00:18:51,600 --> 00:18:55,000
wrote the book long time ago. 
Now, lean software development. 

347
00:18:55,000 --> 00:18:58,300
How did you start with all these
principles but lean software 

348
00:18:58,300 --> 00:19:00,000
development? 
Which kind of like borrowed from

349
00:19:00,000 --> 00:19:02,900
the manufacturing site, right? 
So maybe if you can tell us 

350
00:19:02,900 --> 00:19:05,200
briefly the story or are you 
came up with that? 

351
00:19:05,500 --> 00:19:09,100
Well, I was in rem and I got 
fired into a plant for which I 

352
00:19:09,108 --> 00:19:12,300
had done a process control 
system and it was really 

353
00:19:12,300 --> 00:19:14,900
successful. 
It was an Outsourcing project 

354
00:19:14,900 --> 00:19:18,100
that I manage. 
The Outsourcing part and made 

355
00:19:18,100 --> 00:19:21,400
sure that they were on time and 
on budget other 12 months 

356
00:19:21,400 --> 00:19:24,300
million dollar project which was
unheard of. 

357
00:19:24,300 --> 00:19:28,000
But they were they hated me in 
the plan to be the it manager 

358
00:19:28,000 --> 00:19:30,500
because the it manager had just 
been promoted to materials 

359
00:19:30,500 --> 00:19:33,200
control manager. 
We actually moved to this house 

360
00:19:33,200 --> 00:19:34,900
that we're in now and I commuted
out there. 

361
00:19:35,400 --> 00:19:40,500
While I was there, we discovered
lean because this was a made 

362
00:19:40,500 --> 00:19:44,100
magnetic tape and we were 
suddenly being killed by a 

363
00:19:44,100 --> 00:19:47,800
Japanese competition. 
Just Wiped out, they could sell 

364
00:19:47,800 --> 00:19:49,900
stuff for cheaper than we. 
Could make it four. 

365
00:19:50,200 --> 00:19:53,200
So we had to do something, 
dramatic and fast. 

366
00:19:53,200 --> 00:19:56,100
So what we started doing was 
reading the early books on WE 

367
00:19:56,200 --> 00:19:59,400
that were coming out of Japan. 
I have one of the early ones. 

368
00:19:59,700 --> 00:20:02,400
That's the worst translation of 
Chicago. 

369
00:20:02,400 --> 00:20:05,400
Ching goes first book. 
So we started studying those 

370
00:20:05,400 --> 00:20:08,200
books including this badly, 
translated, Green books. 

371
00:20:08,500 --> 00:20:11,500
And we started saying well, how 
would this work in our plant? 

372
00:20:11,500 --> 00:20:15,300
No, we didn't have a discrete 
Parts when we had a rogue. 

373
00:20:15,300 --> 00:20:17,700
Explain. 
So we said to apply the 

374
00:20:17,700 --> 00:20:21,800
principles, not the stuff. 
They actually did at one point, 

375
00:20:21,800 --> 00:20:24,800
we decided to go to a pull 
system scheduling rather than a 

376
00:20:24,800 --> 00:20:28,100
system scheduling. 
We created a kanban system 

377
00:20:28,100 --> 00:20:32,200
simply by trial and error and 
running simulations. 

378
00:20:32,600 --> 00:20:36,900
When we cut over, we had an 
amazingly successful cuttable 

379
00:20:37,100 --> 00:20:39,000
already. 
My process control systems were 

380
00:20:39,000 --> 00:20:42,000
getting rid of a lot of waste at
million dollar system paid for 

381
00:20:42,000 --> 00:20:45,600
itself in the first month 
because they use the data. 

382
00:20:45,800 --> 00:20:49,700
To do statistical analysis on 
problems and then they could 

383
00:20:49,700 --> 00:20:52,800
find sources of problems. 
So when we went to a pool system

384
00:20:52,800 --> 00:20:57,300
at that point in time, we had 
about sixty six percent accuracy

385
00:20:57,300 --> 00:20:59,300
and pack out against plan per 
week. 

386
00:20:59,800 --> 00:21:03,600
That 66 percent success against 
detailed plan is also pretty 

387
00:21:03,600 --> 00:21:06,600
typical in project management. 
If you have a great being 

388
00:21:06,600 --> 00:21:09,500
detailed plan in an environment 
where stuff happens, there's 

389
00:21:09,500 --> 00:21:12,000
variability, you can't stick to 
it. 

390
00:21:12,200 --> 00:21:15,200
Everybody said we'll try harder 
to stick to the plant, but 

391
00:21:15,200 --> 00:21:17,700
instead. 
That we decided to not have a 

392
00:21:17,700 --> 00:21:21,200
plan. 
So we made weekly plans and then

393
00:21:21,200 --> 00:21:24,200
we just pulled through the 
plant, from the weekly plans, 

394
00:21:24,200 --> 00:21:26,500
using a pull system. 
Just like we read about in the 

395
00:21:26,500 --> 00:21:28,900
book and we switch. 
We couldn't figure out how to 

396
00:21:28,900 --> 00:21:30,600
switch the part of the plant 
over. 

397
00:21:31,100 --> 00:21:34,300
So we switch the entire Clan 
from my computer doing 

398
00:21:34,300 --> 00:21:38,900
scheduling to a pull system 
overnight one weekend. 

399
00:21:39,100 --> 00:21:42,600
We didn't have an overnight. 
It was 24 hours, but it was down

400
00:21:42,600 --> 00:21:45,500
on Sundays. 
So one Sunday, we switch the 

401
00:21:45,500 --> 00:21:47,900
phone. 
Whole system to a paper-based 

402
00:21:47,900 --> 00:21:52,400
kanban card, pull system for all
scheduling that week. 

403
00:21:52,400 --> 00:21:57,900
We packed out, like 95% against 
point and it just got better. 

404
00:21:58,200 --> 00:22:00,400
Now. 
The reason it worked was because

405
00:22:00,400 --> 00:22:04,700
we designed that pull system, 
and we gave our simulation, 

406
00:22:04,700 --> 00:22:07,300
which was lipsticks, and coffee 
cups to the supervisors. 

407
00:22:07,300 --> 00:22:10,600
And then they gave them to the 
shift supervisors, and the shift

408
00:22:10,600 --> 00:22:14,600
supervisors did simulations with
their people and the people 

409
00:22:14,600 --> 00:22:18,400
designed the Assist the people 
that were doing the work, 

410
00:22:18,400 --> 00:22:22,000
designed the details of every 
piece of the system because we 

411
00:22:22,000 --> 00:22:24,200
don't know how to tell them what
to do there, weren't any bling 

412
00:22:24,200 --> 00:22:25,700
Consultants? 
Thank God that would tell you 

413
00:22:25,700 --> 00:22:28,800
what to do. 
So that plant people designed 

414
00:22:28,800 --> 00:22:30,900
their system. 
So let's say something went 

415
00:22:30,900 --> 00:22:33,000
wrong that first week and I'm 
sure it did. 

416
00:22:33,200 --> 00:22:36,100
Well, they knew what to do 
because they had designed the 

417
00:22:36,100 --> 00:22:39,900
system in the first place. 
It was their work and they 

418
00:22:39,900 --> 00:22:43,500
understood that reasoning behind
everything because they designed

419
00:22:43,500 --> 00:22:47,600
it themselves with simulations. 
And Oh, it just worked, it got 

420
00:22:47,600 --> 00:22:51,000
better because the glitches it 
quickly smoothed out, but the 

421
00:22:51,000 --> 00:22:53,900
whole system was designed by the
people who are on the floor, 

422
00:22:53,900 --> 00:22:56,200
using it. 
I became convinced that was the 

423
00:22:56,200 --> 00:22:59,000
way to go. 
That post assumes were amazing 

424
00:22:59,500 --> 00:23:03,000
and that the only way you could 
actually make a big change in an

425
00:23:03,000 --> 00:23:05,500
environment is to have the 
people who are going to do the 

426
00:23:05,508 --> 00:23:08,300
change design, the change. 
Those two things. 

427
00:23:08,300 --> 00:23:12,600
I absolutely sure of today. 
I don't see it widely used that 

428
00:23:12,600 --> 00:23:15,700
way, but it's the only way I run
into so many. 

429
00:23:15,800 --> 00:23:18,900
People that say well we tried to
do this, pull system wouldn't 

430
00:23:18,900 --> 00:23:19,800
work. 
I said yeah. 

431
00:23:19,800 --> 00:23:21,800
Consultants come in, right? 
Yeah. 

432
00:23:21,800 --> 00:23:26,700
Well, that's why I did work real
simple. 

433
00:23:27,900 --> 00:23:29,400
Yep. 
It's not the Consultants were 

434
00:23:29,400 --> 00:23:32,600
bad because if you needed a 
consultant that meant you 

435
00:23:32,600 --> 00:23:35,400
couldn't, do your own jet cool. 
Don't push. 

436
00:23:35,500 --> 00:23:37,600
Yes. 
Don't tell people what to do. 

437
00:23:37,900 --> 00:23:41,400
Tell them what results you want,
and let them figure it out. 

438
00:23:41,500 --> 00:23:45,500
That gives them the satisfaction
and the responsibility to figure

439
00:23:45,500 --> 00:23:48,900
out out how best to achieve the 
outcome that's needed. 

440
00:23:49,100 --> 00:23:52,600
That is something that is only 
now starting to Echo 

441
00:23:52,700 --> 00:23:55,100
economy-wide. 
If you look at the great 

442
00:23:55,100 --> 00:23:58,900
resignation, that everybody is 
so upset about, there's an awful

443
00:23:58,900 --> 00:24:02,300
lot of pull. 
Don't push being sought by the 

444
00:24:02,300 --> 00:24:05,000
people who are quitting the jobs
that are telling them what to 

445
00:24:05,000 --> 00:24:06,500
do. 
Wow. 

446
00:24:06,700 --> 00:24:09,200
So there's a correlation with 
the great resignation. 

447
00:24:09,500 --> 00:24:11,900
The thing that I also think 
about lean, sometimes it's 

448
00:24:11,900 --> 00:24:14,900
counterintuitive for those in 
the stakeholders site. 

449
00:24:15,100 --> 00:24:18,500
So, how can We translate this. 
Okay, please don't push more and

450
00:24:18,500 --> 00:24:22,400
more demands involve us at the 
low level Engineers to actually 

451
00:24:22,400 --> 00:24:25,900
be involved design the system do
more pull based rather than push

452
00:24:25,900 --> 00:24:28,100
base. 
So maybe from your experience 

453
00:24:28,100 --> 00:24:31,000
doing consulting and helping 
people any tips that you want to

454
00:24:31,000 --> 00:24:32,900
give for stakeholder. 
Okay. 

455
00:24:32,900 --> 00:24:36,400
I mean, you can, it's not gonna 
work unless the upper people. 

456
00:24:36,700 --> 00:24:39,800
The more senior people 
understand what needs to be 

457
00:24:39,800 --> 00:24:45,300
accomplished and why they need 
to accomplish it and then let 

458
00:24:45,300 --> 00:24:47,400
the people We'll figure out how 
to accomplish. 

459
00:24:47,400 --> 00:24:48,900
If you don't have that 
environment. 

460
00:24:48,900 --> 00:24:53,000
That doesn't get pushed up from 
the bottom in our environment. 

461
00:24:53,000 --> 00:24:57,100
When we started doing Lee, the 
plant manager was all behind it 

462
00:24:57,100 --> 00:24:59,600
completely. 
He's the one that sent me to the

463
00:24:59,600 --> 00:25:03,000
very first just-in-time seminar 
in the u.s. 

464
00:25:03,400 --> 00:25:06,000
To see what was going on. 
I said, well, you should come 

465
00:25:06,000 --> 00:25:08,700
too and he said, no Paul should 
come because I believe this 

466
00:25:08,700 --> 00:25:11,700
stuff but Paul who reported to 
him and who was a general 

467
00:25:11,700 --> 00:25:14,300
manager of assembly, doesn't get
it yet. 

468
00:25:14,800 --> 00:25:18,300
So you dragged him. 
They're so he understands. 

469
00:25:18,500 --> 00:25:23,000
So he went there and he spent 
the entire two days side by side

470
00:25:23,000 --> 00:25:27,600
with the UPS manager of that 
plant, talking about how things 

471
00:25:27,600 --> 00:25:31,900
worked and he came back 
convinced, not because somebody 

472
00:25:31,900 --> 00:25:36,200
brainwashed him, but because he 
saw the results of doing things 

473
00:25:36,200 --> 00:25:39,300
different and he was impressive.
He said we could do this. 

474
00:25:39,600 --> 00:25:42,800
And if you don't have that at 
the senior level and the only 

475
00:25:42,800 --> 00:25:45,600
reason he went, he surely would 
not have gone if I invited him. 

476
00:25:45,900 --> 00:25:47,600
He went because his boss told 
him to go. 

477
00:25:48,100 --> 00:25:51,700
So if you don't have the belief 
at the top, I've never figured 

478
00:25:51,700 --> 00:25:53,900
out how to get it. 
But I have figured out how it 

479
00:25:53,900 --> 00:25:56,700
gets to the top. 
Okay, the companies I've seen 

480
00:25:56,900 --> 00:25:59,200
that had wanted to change what 
they do. 

481
00:25:59,800 --> 00:26:02,200
First of all, you have to 
remember the obscene. 

482
00:26:02,200 --> 00:26:04,800
Your people are there because 
they've been successful doing 

483
00:26:04,800 --> 00:26:06,900
things differently than you want
them to do. 

484
00:26:07,300 --> 00:26:12,100
It almost always takes a crisis 
or an impending crises for 

485
00:26:12,100 --> 00:26:15,400
people to realize that what 
we've done up till now isn't 

486
00:26:15,400 --> 00:26:17,400
going. 
Cut it in the future that mean 

487
00:26:17,400 --> 00:26:18,700
that's what happened. 
In a point. 

488
00:26:18,800 --> 00:26:23,000
We invented, videotape, all of 
the broadcast video tape in the 

489
00:26:23,000 --> 00:26:24,900
country. 
And in fact, we're mostly around

490
00:26:24,900 --> 00:26:28,200
the world was 3M tape. 
And yet, we were about to get 

491
00:26:28,200 --> 00:26:32,000
kicked out of the industry. 
We realize that and started 

492
00:26:32,000 --> 00:26:35,100
saying we've got to do something
drastic because the incremental 

493
00:26:35,100 --> 00:26:37,000
approach is that we've had, 
don't work. 

494
00:26:37,400 --> 00:26:40,000
If you don't have that. 
I don't know. 

495
00:26:40,000 --> 00:26:42,700
You can just sit down and talk 
some sense into somebody who's 

496
00:26:42,700 --> 00:26:45,200
had a whole history of success 
up till now. 

497
00:26:45,700 --> 00:26:48,500
And doesn't really want to 
abandon that, unless something, 

498
00:26:48,500 --> 00:26:51,100
not you, but something else is 
forcing them. 

499
00:26:51,600 --> 00:26:54,100
So they'll think I found. 
The best thing to do is look for

500
00:26:54,100 --> 00:26:58,300
some problem that person has 
some crisis is clearly going to 

501
00:26:58,300 --> 00:27:00,800
attack them and see if they 
believe that. 

502
00:27:00,800 --> 00:27:04,200
Then is Graces. 
And then offer a way out of the 

503
00:27:04,200 --> 00:27:05,100
impending. 
Doom. 

504
00:27:05,600 --> 00:27:09,200
If you can't do that. 
I haven't seen it a lot of 

505
00:27:09,200 --> 00:27:14,500
seriously, good changes, so I 
don't see how Engineers can talk

506
00:27:14,500 --> 00:27:17,500
their bosses into thinking. 
Currently, there are two 

507
00:27:17,500 --> 00:27:20,200
options. 
One is change your organization.

508
00:27:20,600 --> 00:27:24,000
If you have the capability of 
doing it, the other more, common

509
00:27:24,000 --> 00:27:29,000
one is change your organization.
The people that cannot change 

510
00:27:29,000 --> 00:27:31,800
the organizations that cannot 
change cannot succeed. 

511
00:27:32,400 --> 00:27:35,300
The failure rate of even large 
companies. 

512
00:27:35,400 --> 00:27:39,400
It is impressively high. 
There's no point if you can't 

513
00:27:39,400 --> 00:27:42,500
change how things are in, your 
current organization sticking 

514
00:27:42,500 --> 00:27:46,200
with it because the organization
is going to fail, Probably 

515
00:27:46,200 --> 00:27:52,200
before you hope to retire. 
And the thing that we have seen 

516
00:27:52,200 --> 00:27:58,200
over the past, I don't know, 15,
20 years is that Industries move

517
00:27:58,200 --> 00:28:03,100
from their past to their future 
almost as a group when suddenly 

518
00:28:03,100 --> 00:28:07,100
the industry is attacked or so 
this until come, we saw this in 

519
00:28:07,100 --> 00:28:10,000
medical devices. 
We saw this in banking, all of a

520
00:28:10,008 --> 00:28:14,200
sudden, there's this concept of 
online banking on a telephone 

521
00:28:15,000 --> 00:28:19,400
that just She looked up so many 
banks and the fintech companies 

522
00:28:19,400 --> 00:28:23,500
started attacking the big Banks 
fee system, and fees is how 

523
00:28:23,500 --> 00:28:26,000
Banks make money. 
Now. 

524
00:28:26,000 --> 00:28:30,900
The next step was the insurance 
industry because insurance has 

525
00:28:30,900 --> 00:28:34,300
all these devices out there that
you can hook to iot. 

526
00:28:34,500 --> 00:28:38,300
You can notice, how does your 
industry make money Banks make 

527
00:28:38,300 --> 00:28:40,200
money on fees. 
Insurance companies. 

528
00:28:40,200 --> 00:28:44,600
Make money by minimizing risk. 
So what they are is a risk. 

529
00:28:44,600 --> 00:28:47,400
Mitigator. 
Now, if you have iot, and you 

530
00:28:47,400 --> 00:28:50,900
can connect it to physical 
objects that are being insured, 

531
00:28:51,000 --> 00:28:54,600
you can change your results in 
Insurance because you can 

532
00:28:54,600 --> 00:28:56,300
monitor, if it's been used 
properly. 

533
00:28:56,300 --> 00:28:59,700
You can monitor, if there's a 
fire when you start using the 

534
00:28:59,700 --> 00:29:02,300
internet of things in 
conjunction with different 

535
00:29:02,300 --> 00:29:06,000
concepts that we charge, you can
dramatically change the risk 

536
00:29:06,000 --> 00:29:09,600
game, and your computers, and 
your smirk scientist that used 

537
00:29:09,600 --> 00:29:12,000
to do, all the risk 
calculations, become less, and 

538
00:29:12,000 --> 00:29:14,300
less relevant. 
And if that's what your whole 

539
00:29:14,300 --> 00:29:18,500
company is built on. 
Then either you go down, or you 

540
00:29:18,500 --> 00:29:22,800
see this and say what we've got 
to change and we have seen 

541
00:29:22,800 --> 00:29:26,700
companies that have said, what 
we've got to change and they 

542
00:29:26,700 --> 00:29:30,900
ones in Asia tended, to be the 
ones that saw it first because 

543
00:29:30,900 --> 00:29:34,600
they saw more competition from 
insurance companies that could 

544
00:29:34,600 --> 00:29:38,100
deal with risk much more 
electronically than with 

545
00:29:38,100 --> 00:29:41,600
algorithms. 
So, if you look at your industry

546
00:29:41,600 --> 00:29:45,800
and see where is its weak spots,
where is it going to get? 

547
00:29:46,300 --> 00:29:49,900
Where is it current strength 
going to become much less 

548
00:29:49,900 --> 00:29:53,100
relevant and you hit that way. 
You will find that. 

549
00:29:53,100 --> 00:29:56,300
There are people in Senior 
Management that get that but 

550
00:29:56,300 --> 00:29:57,700
they don't know what to do about
it. 

551
00:29:58,300 --> 00:30:01,900
So if you have sympathy for, 
we're going to be attacked here,

552
00:30:02,400 --> 00:30:05,300
what should we do about it? 
And you can offer a solution, 

553
00:30:05,800 --> 00:30:10,200
then you can help them do their 
job better and that can become a

554
00:30:10,200 --> 00:30:13,400
real book. 
There are however, people whose 

555
00:30:13,400 --> 00:30:16,700
jobs change or disappear. 
Appear. 

556
00:30:16,900 --> 00:30:20,900
When you add any kind of 
different strategies mean, I 

557
00:30:20,900 --> 00:30:23,400
could remember talking to a 
Healthcare company. 

558
00:30:23,600 --> 00:30:27,200
We had like 15 or 20 people of 
the management team there, and 

559
00:30:27,200 --> 00:30:32,300
about a quarter of them, entire 
job was prioritizing the work of

560
00:30:32,300 --> 00:30:35,200
the. 
IT department hundred percent of

561
00:30:35,200 --> 00:30:38,500
their job was in the priority 
setting process. 

562
00:30:39,000 --> 00:30:42,600
We went there and said priority,
setting is a waste, you 

563
00:30:42,600 --> 00:30:45,600
shouldn't do it. 
You know what they couldn't hear

564
00:30:45,600 --> 00:30:47,900
that. 
They couldn't hear it. 

565
00:30:47,900 --> 00:30:52,500
Because what we said was the 25%
of that audience, your job is 

566
00:30:52,500 --> 00:30:54,800
irrelevant. 
You're not going to be able to 

567
00:30:54,800 --> 00:30:56,500
keep it. 
You should do something that 

568
00:30:56,500 --> 00:30:59,200
gets rid of your job. 
It's impossible for people to 

569
00:30:59,200 --> 00:31:02,800
hear that which brings to one of
the topics that you mentioned is

570
00:31:02,800 --> 00:31:04,800
about proxies. 
So these days, you have been 

571
00:31:04,800 --> 00:31:08,000
writing and talking a lot about 
proxies in the business world. 

572
00:31:08,300 --> 00:31:11,600
No matter what company is this 
kind of proxies exist, either. 

573
00:31:11,600 --> 00:31:15,300
It's business analyst, quality 
engineer test, engineer product 

574
00:31:15,300 --> 00:31:16,700
owners. 
Us and all that. 

575
00:31:16,700 --> 00:31:20,000
So you have a strong point of 
view about the existence of this

576
00:31:20,000 --> 00:31:21,700
proxies. 
Maybe you can share with us. 

577
00:31:22,000 --> 00:31:24,300
What's the problem with having 
these proxies? 

578
00:31:24,900 --> 00:31:28,800
I first got the word in the idea
from a letter to shareholders by

579
00:31:28,800 --> 00:31:31,500
Jeff Bezos. 
He talked about what is day one.

580
00:31:31,600 --> 00:31:33,000
He's almost saying we're still 
in day. 

581
00:31:33,000 --> 00:31:36,100
One day, one means you're in 
start-up mode. 

582
00:31:36,500 --> 00:31:39,600
You're still acting like a 
start-up and then he listed the 

583
00:31:39,600 --> 00:31:41,500
things. 
The four things that you had to 

584
00:31:41,500 --> 00:31:45,300
do to stay in day one because 
Day to you start dying. 

585
00:31:45,900 --> 00:31:50,000
One of the things you had to do,
was to avoid proxies and I'm 

586
00:31:50,000 --> 00:31:53,300
thinking, that's interesting. 
So, what you need to do is to 

587
00:31:53,300 --> 00:31:55,800
get the people doing the work 
and direct connection with the 

588
00:31:55,800 --> 00:31:58,300
people for whom they are doing 
the work. 

589
00:31:58,600 --> 00:32:01,400
And if you look at the way, 
Amazon teams are structured, 

590
00:32:01,600 --> 00:32:05,600
they don't have proxies teams 
have leaders, but they don't 

591
00:32:05,600 --> 00:32:08,400
have somebody telling the team 
what to do. 

592
00:32:08,900 --> 00:32:13,500
If you look at the way SpaceX 
and Tesla does engineering, they

593
00:32:13,500 --> 00:32:17,000
don't have proxies, they expect 
to have Have people that are 

594
00:32:17,000 --> 00:32:20,400
going to be responsible for the 
results dealing directly with 

595
00:32:20,400 --> 00:32:23,600
solving the problems. 
In fact, most engineering. 

596
00:32:23,600 --> 00:32:26,400
He does not operate with Praxis 
when I was in an engineering 

597
00:32:26,400 --> 00:32:29,600
department. 
We didn't have the concept of a 

598
00:32:29,600 --> 00:32:33,700
product owner or the concept of 
a process master or anything 

599
00:32:33,700 --> 00:32:36,800
like that. 
We were responsible for the end 

600
00:32:36,800 --> 00:32:40,300
results and we were expected to 
go to the plant and talk to the 

601
00:32:40,300 --> 00:32:42,500
operators and make sure we 
understood how they thought 

602
00:32:42,500 --> 00:32:44,000
before. 
We designed an interface for 

603
00:32:44,000 --> 00:32:45,800
them. 
We didn't have people. 

604
00:32:45,900 --> 00:32:50,200
In between us and the problem. 
And when you have a proxy in 

605
00:32:50,200 --> 00:32:52,900
there, you take the 
responsibility off the team 

606
00:32:52,900 --> 00:32:56,000
through thinking of good ideas 
and you don't love them to use 

607
00:32:56,000 --> 00:32:59,500
their smart intelligent 
capabilities, to design 

608
00:32:59,500 --> 00:33:03,000
Solutions, based on the 
technology that they understand.

609
00:33:03,600 --> 00:33:05,900
First of all, you'll have 
multiple people thinking about 

610
00:33:05,900 --> 00:33:08,800
the problem and secondly, 
there's no way the intermediary 

611
00:33:08,800 --> 00:33:11,300
can know all of the different 
aspects of the problem. 

612
00:33:11,600 --> 00:33:15,900
But secondly, that intermediary 
way too often is not a An 

613
00:33:15,900 --> 00:33:20,200
engineer in the same field, how 
can they know enough to come up 

614
00:33:20,200 --> 00:33:23,200
with the best solution? 
When they've never programmed 

615
00:33:23,200 --> 00:33:27,000
any couple would, for example, 
or they've never done any kind 

616
00:33:27,000 --> 00:33:31,200
of engineering engineering 
departments don't have proxies 

617
00:33:31,200 --> 00:33:33,600
between the engineers and the 
problem. 

618
00:33:33,600 --> 00:33:36,400
So, for example, let's pretend 
you're a structural engineer, 

619
00:33:36,900 --> 00:33:41,300
you work for a company and 
you're in, say, Santiago and 

620
00:33:41,300 --> 00:33:45,200
there's an earthquake and your 
structural engineering firm is 

621
00:33:45,200 --> 00:33:48,200
hired. 
To evaluate businesses before 

622
00:33:48,200 --> 00:33:50,600
they get reoccupied because 
you've got to know if they're 

623
00:33:50,600 --> 00:33:53,400
safe. 
Now, the business hires the 

624
00:33:53,400 --> 00:33:56,600
structural engineering firm. 
Do you think they treat them 

625
00:33:56,600 --> 00:33:59,600
like they would treat the same 
number of software developers. 

626
00:34:00,100 --> 00:34:03,000
Do they say you have to be done 
in this amount of time and 

627
00:34:03,000 --> 00:34:05,100
here's the results that you have
to come up with. 

628
00:34:05,400 --> 00:34:08,000
Let us tell you exactly how 
you're going to do that job. 

629
00:34:08,300 --> 00:34:11,400
They would be crazy because the 
structural engineers are the 

630
00:34:11,400 --> 00:34:14,699
experts and similarly, when we 
design Control Systems. 

631
00:34:14,699 --> 00:34:18,400
There was nobody in between Join
us and the problem because we 

632
00:34:18,400 --> 00:34:21,400
were the experts in control 
engineering, not some 

633
00:34:21,400 --> 00:34:24,600
intermediary, but we have 
developed in software. 

634
00:34:24,699 --> 00:34:28,300
The concept that there needs to 
be an expert between engineers 

635
00:34:28,300 --> 00:34:30,900
in the problem. 
And that's not an engineering 

636
00:34:30,900 --> 00:34:33,100
concept. 
That's treating software 

637
00:34:33,100 --> 00:34:36,000
developers as if they were 
technicians that couldn't think 

638
00:34:36,000 --> 00:34:38,400
for themselves, treating them 
like children. 

639
00:34:38,800 --> 00:34:41,900
We have a history of doing that 
because our history was that the

640
00:34:41,900 --> 00:34:44,400
first computers were mainframes 
and big companies. 

641
00:34:44,699 --> 00:34:47,800
It was a costume. 
A put in a cost Center and they 

642
00:34:47,800 --> 00:34:51,000
were told by the people in the 
business what kinds of problems 

643
00:34:51,000 --> 00:34:54,800
that they needed to solve, and 
they had lots of constraints and

644
00:34:54,800 --> 00:34:58,100
that was fine until suddenly 
many computers can walk, which 

645
00:34:58,100 --> 00:35:00,800
is where I started programming 
in the engineering department. 

646
00:35:00,800 --> 00:35:02,900
We wouldn't hear of that kind of
nonsense. 

647
00:35:03,000 --> 00:35:04,900
Okay. 
We were the experts, we knew how

648
00:35:04,900 --> 00:35:07,000
to use this new tool to solve 
the problem. 

649
00:35:07,000 --> 00:35:09,700
We went to the problem. 
There were senior engineers at 

650
00:35:09,700 --> 00:35:13,300
coach Junior Engineers. 
Yep, okay, but they could do the

651
00:35:13,308 --> 00:35:15,600
problem in their sleep and they 
were teaching. 

652
00:35:15,800 --> 00:35:18,200
The younger Engineers. 
How to think about the problem, 

653
00:35:18,400 --> 00:35:21,500
that's how engineering is 
typically done, whether it's 

654
00:35:21,500 --> 00:35:23,700
Structural Engineering control. 
Engineering. 

655
00:35:24,100 --> 00:35:28,100
We do not allow our software 
Engineers to be Engineers to be,

656
00:35:28,100 --> 00:35:32,700
that's like losing so much of 
their capability and also making

657
00:35:32,700 --> 00:35:34,800
their life so much less fun than
it. 

658
00:35:34,800 --> 00:35:37,200
Could was a challenging 
interesting. 

659
00:35:37,300 --> 00:35:41,700
So we got to stop this having 
somebody tell a team went to do 

660
00:35:42,100 --> 00:35:45,700
setting priorities for a team. 
That's observed if you want. 

661
00:35:45,800 --> 00:35:49,400
No, the biggest mistake, the 
biggest bad thing that's grown 

662
00:35:49,400 --> 00:35:51,600
has brought to the world. 
It's the concept of a product 

663
00:35:51,600 --> 00:35:54,000
owner. 
I think it's widely adopted 

664
00:35:54,000 --> 00:35:55,700
these days product owner. 
Yeah. 

665
00:35:55,700 --> 00:35:58,700
It's terribly unfortunate 
because it didn't used to be 

666
00:35:58,700 --> 00:36:02,400
like that before scrum. 
One of the most serious, Hannah 

667
00:36:02,400 --> 00:36:06,200
for stations here is pursuit of 
efficiency efficiency. 

668
00:36:06,200 --> 00:36:10,800
Usually means maximize 
utilization of your resources. 

669
00:36:10,800 --> 00:36:15,600
That means that people who are 
good Engineers should not do. 

670
00:36:15,800 --> 00:36:19,200
Anything, but the engineering 
part, but you can't separate the

671
00:36:19,200 --> 00:36:24,500
engineering part. 
The idea is that if you maximize

672
00:36:24,500 --> 00:36:28,400
utilization, you're going to get
the most value, the reality is 

673
00:36:28,400 --> 00:36:31,400
that you will not be able to get
value. 

674
00:36:32,000 --> 00:36:35,700
This idea of utilization, 
maximization is an accounting 

675
00:36:35,700 --> 00:36:40,400
type concept that has no 
relevance to achieving the goals

676
00:36:40,400 --> 00:36:44,900
of an engineering effort. 
The utilization metric itself is

677
00:36:44,900 --> 00:36:47,900
a proxy. 
And it's a highly deceptive 

678
00:36:47,900 --> 00:36:50,100
proxy. 
That leads you to make very 

679
00:36:50,100 --> 00:36:54,100
unintelligent decisions. 
You have to respect the people. 

680
00:36:54,700 --> 00:36:58,300
You have to help them grow. 
You have to give them the 

681
00:36:58,300 --> 00:37:02,400
satisfaction of solving problems
that they care about, if they 

682
00:37:02,400 --> 00:37:04,800
don't care about it, no 
satisfaction. 

683
00:37:05,200 --> 00:37:08,900
If they simply Implement 
somebody else's solution, very 

684
00:37:08,900 --> 00:37:12,200
weak satisfaction. 
So you also brought up this 

685
00:37:12,200 --> 00:37:13,700
point. 
I mean, in parts of your 

686
00:37:13,700 --> 00:37:16,500
writings, right? 
It's about giving the outcome 

687
00:37:16,500 --> 00:37:18,900
rather than managing the output.
So when you mention about 

688
00:37:18,900 --> 00:37:21,800
maximizing utilization, it's 
like you're managing them the 

689
00:37:21,800 --> 00:37:24,900
priorities, the task, what they 
need to do, what they need to 

690
00:37:24,900 --> 00:37:28,100
finish, but instead of that, the
best way is actually to give 

691
00:37:28,100 --> 00:37:31,600
them what the outcomes that they
should achieve and let them 

692
00:37:31,600 --> 00:37:33,100
solve the problems by 
themselves. 

693
00:37:33,200 --> 00:37:34,700
Let them be capable. 
Yeah. 

694
00:37:34,800 --> 00:37:36,800
Maybe you can you explain a 
little bit about this. 

695
00:37:36,900 --> 00:37:39,200
How do you actually do it? 
How do you actually give the 

696
00:37:39,200 --> 00:37:42,800
people outcome based? 
Target or goals rather than 

697
00:37:42,800 --> 00:37:47,100
managing them by priority, if an
effort has been approved, there 

698
00:37:47,100 --> 00:37:51,300
exists, rationale for why it 
should be done there, exist. 

699
00:37:51,300 --> 00:37:55,400
Somebody that has outcome 
expectations somehow those get 

700
00:37:55,400 --> 00:37:59,900
translated into proxies, but you
stare almost every effort with 

701
00:37:59,900 --> 00:38:02,700
some expectation of outcome and 
that's what should be 

702
00:38:02,700 --> 00:38:05,600
transmitted all the way down 
till those smart engineers and 

703
00:38:05,600 --> 00:38:09,100
say Here's an open. 
This is where we're trying to 

704
00:38:09,100 --> 00:38:11,700
keep two. 
Here is How we're going to know 

705
00:38:11,700 --> 00:38:13,200
it's good. 
Like when we were given a 

706
00:38:13,207 --> 00:38:17,600
process control system to 
design, we had typically a year.

707
00:38:18,200 --> 00:38:20,900
Maybe there would be a team of 
several Engineers with different

708
00:38:20,900 --> 00:38:23,400
Specialties. 
Here's the deadline. 

709
00:38:23,400 --> 00:38:27,000
It has to be up by and it has to
work. 

710
00:38:27,000 --> 00:38:30,400
Well, it has to be maintained or
whether plant Engineers The 

711
00:38:30,400 --> 00:38:34,700
Operators have to accept and 
like it because if they don't, 

712
00:38:34,700 --> 00:38:36,700
they're going to make product 
anyway, and they'll defeat your 

713
00:38:36,700 --> 00:38:39,100
system. 
And if they defeat your system, 

714
00:38:39,100 --> 00:38:42,200
it's your problem. 
There's no intermediary, you get

715
00:38:42,200 --> 00:38:43,500
to blame. 
It's because you didn't 

716
00:38:43,500 --> 00:38:47,400
understand them, well enough, if
we would just give the software 

717
00:38:47,400 --> 00:38:51,800
engineering team, the reasons, 
for which the outcomes, which 

718
00:38:51,800 --> 00:38:56,400
the people are looking for. 
Then they could start moving the

719
00:38:56,408 --> 00:39:00,100
system towards those outcomes, 
they exist. 

720
00:39:00,100 --> 00:39:03,600
They're they're, they're hidden 
in all those layers of proxies 

721
00:39:04,000 --> 00:39:07,300
because at the end it got 
chartered for a reason and the 

722
00:39:07,308 --> 00:39:11,000
person chattering it knows that 
reason and we've separated Rated

723
00:39:11,000 --> 00:39:14,200
both that person and that reason
from the team that's trying to 

724
00:39:14,200 --> 00:39:17,200
achieve it. 
So if there's a theory, if I do 

725
00:39:17,200 --> 00:39:20,800
these five tasks, then that 
outcome is going to be a cheap 

726
00:39:21,000 --> 00:39:25,200
but who proves that before they 
start, nobody's in really 

727
00:39:25,200 --> 00:39:29,000
expected to let's take a product
manager who wants a certain 

728
00:39:29,200 --> 00:39:32,000
capability in a product. 
If you let them tell the 

729
00:39:32,000 --> 00:39:33,600
engineering team, here's a 
capability. 

730
00:39:33,600 --> 00:39:36,600
I'm looking for then they can 
figure that out. 

731
00:39:36,600 --> 00:39:39,600
If you have them till the 
engineers, here's five tasks 

732
00:39:39,600 --> 00:39:43,400
that you are supposed. 
Do and when those tasks get done

733
00:39:43,700 --> 00:39:46,800
a hope I get this result, but 
don't tell him the results. 

734
00:39:47,100 --> 00:39:51,300
Then how does that person know 
that those tests are going to 

735
00:39:51,300 --> 00:39:54,200
give that result when they are 
not even in the field, the 

736
00:39:54,200 --> 00:39:57,100
people figuring out the tests. 
How are they gonna know? 

737
00:39:57,500 --> 00:40:00,900
So, how are you going to know 
with your prax eat that end 

738
00:40:00,900 --> 00:40:03,900
result which starts out being 
there is actually going to be 

739
00:40:03,900 --> 00:40:08,000
achieved by the intermediate 
results, you know, and so that's

740
00:40:08,000 --> 00:40:10,500
another reason why these 
intermediate results are pretty 

741
00:40:10,700 --> 00:40:13,800
Adam, I guess this is what I 
suspect happens, right? 

742
00:40:13,800 --> 00:40:16,600
We have this concept of product 
owner the proxies and then the 

743
00:40:16,600 --> 00:40:19,800
company has a goal, a Target. 
And then the product owner will 

744
00:40:19,800 --> 00:40:21,100
try to translate that. 
Okay. 

745
00:40:21,100 --> 00:40:24,000
This is the goal where they 
going to get the background in 

746
00:40:24,000 --> 00:40:26,900
The Savvy and Technical 
knowledge to make the right 

747
00:40:26,900 --> 00:40:29,100
translation. 
There will be a few. 

748
00:40:29,300 --> 00:40:33,100
Yeah, but most of them that's 
not really what their child was 

749
00:40:33,700 --> 00:40:35,900
the worst describe but that's 
what they're supposed to do. 

750
00:40:36,100 --> 00:40:39,300
And even if they choose the 
right tests, if they don't 

751
00:40:39,300 --> 00:40:42,600
successfully conveyed. 
The why to the people who are 

752
00:40:42,600 --> 00:40:47,000
doing it, the decisions that the
people doing it, make day-to-day

753
00:40:47,000 --> 00:40:49,700
will not be Optimum towards that
result. 

754
00:40:50,100 --> 00:40:54,800
They have to understand why it's
not just why overall, although 

755
00:40:54,800 --> 00:40:59,100
why overall is critical, but 
what are you going to learn from

756
00:40:59,100 --> 00:41:02,900
each step along the way? 
Because you only learn when you 

757
00:41:02,900 --> 00:41:06,200
get feedback, when you see the 
consequences of this Choice 

758
00:41:06,200 --> 00:41:09,300
versus that choice, you have to 
break it down into little 

759
00:41:09,300 --> 00:41:12,500
pieces. 
And understand how each of these

760
00:41:12,500 --> 00:41:16,900
pieces is going to help you. 
Learn how to better achieve, the

761
00:41:16,900 --> 00:41:19,400
Big Y. 
And this comes back to one of 

762
00:41:19,400 --> 00:41:22,500
the big Concept in lean, which 
is about optimizing flow. 

763
00:41:22,700 --> 00:41:25,500
So when you have these short 
feedback loop where you can do 

764
00:41:25,500 --> 00:41:28,300
something learn, maybe you can 
tell us a little bit more. 

765
00:41:28,300 --> 00:41:30,400
Why is it important to optimize 
this flow? 

766
00:41:31,000 --> 00:41:35,800
Well, it's this concept of pull 
have the results, pull the 

767
00:41:35,800 --> 00:41:38,600
thing. 
But after amazing Flo says you 

768
00:41:38,600 --> 00:41:40,600
want, you don't want to do is 
start. 

769
00:41:40,700 --> 00:41:43,500
Stuff, then you can finish work 
on multiple things. 

770
00:41:43,500 --> 00:41:46,300
At the same time. 
What you want to do is go from 

771
00:41:46,300 --> 00:41:50,200
start to finish quickly with as 
rapid flow as you can. 

772
00:41:50,500 --> 00:41:53,100
So in manufacturing. 
The reason why we wanted flow 

773
00:41:53,400 --> 00:41:56,900
was because when we knew what we
wanted to pack out, we had a 

774
00:41:56,900 --> 00:41:59,000
system to make sure that that's 
what we worked on. 

775
00:41:59,200 --> 00:42:00,900
We did not build up any 
inventory. 

776
00:42:00,900 --> 00:42:04,100
Nothing got in the way, and we 
spent a whole lot of time making

777
00:42:04,100 --> 00:42:07,300
sure that nothing got in the way
and it was responsibility of the

778
00:42:07,300 --> 00:42:10,100
production workers to go from. 
At the end of the week. 

779
00:42:10,100 --> 00:42:12,000
We went up. 
Pack this O2, what am I going to

780
00:42:12,000 --> 00:42:15,800
do right now? 
So when you have flow, you have 

781
00:42:15,800 --> 00:42:20,000
an ability to focus to 
concentrate to do the right 

782
00:42:20,000 --> 00:42:21,500
thing. 
Because that's the only thing 

783
00:42:21,500 --> 00:42:25,000
that is being expected right now
because the pole system pulls 

784
00:42:25,000 --> 00:42:27,800
towards a goal. 
Whereas a scheduling system, 

785
00:42:27,800 --> 00:42:30,200
looks at the great big mound of 
things, and it makes lots of 

786
00:42:30,200 --> 00:42:32,800
inventory and piles of maybe 
documents or whatever in 

787
00:42:32,800 --> 00:42:37,300
between, but it doesn't get 
something done when people have 

788
00:42:37,300 --> 00:42:40,500
one thing to do and concentrate 
on it it. 

789
00:42:40,700 --> 00:42:45,400
Was not only faster, but the 
quality is usually significantly

790
00:42:45,400 --> 00:42:48,900
better. 
So the concept of flow means one

791
00:42:48,900 --> 00:42:53,000
of the things you do not want to
do is this concept of if I have 

792
00:42:53,000 --> 00:42:56,600
a demand from a customer, I 
should put it on a back lot like

793
00:42:56,600 --> 00:42:59,600
that's absurd. 
And then I start looking at the 

794
00:42:59,600 --> 00:43:03,200
length of backlogs and then one 
year or two years and you spend 

795
00:43:03,200 --> 00:43:05,300
time prioritizing and stuff like
that. 

796
00:43:05,700 --> 00:43:08,900
They lean you wanted what should
I been doing right now? 

797
00:43:09,400 --> 00:43:11,500
And I'm going to pull that. 
From the result that I'm 

798
00:43:11,500 --> 00:43:15,100
expecting and I'm going to have 
a skiing where that pull can 

799
00:43:15,100 --> 00:43:19,000
Cascade on down, to where the 
beginning of the process starts 

800
00:43:19,400 --> 00:43:23,000
and it all points in time. 
You have more capacity 

801
00:43:23,100 --> 00:43:26,600
Downstream. 
So you could always respond to a

802
00:43:26,600 --> 00:43:31,000
pull request. 
So what happens is if we accept 

803
00:43:31,000 --> 00:43:34,600
more work than we can do, we 
just get amount of junk that we 

804
00:43:34,600 --> 00:43:37,500
can't act on it. 
By the time we get ever get 

805
00:43:37,500 --> 00:43:39,300
around to it. 
It's not fresh anymore. 

806
00:43:39,700 --> 00:43:41,700
People don't have the A problem 
anymore. 

807
00:43:42,000 --> 00:43:44,700
They've gone off to do other 
things because you made them be 

808
00:43:44,700 --> 00:43:47,300
distracted because they can 
accomplish what they want. 

809
00:43:47,500 --> 00:43:50,200
It's very deceiving to tell 
somebody. 

810
00:43:50,200 --> 00:43:53,500
Oh, it's on my back walk. 
I mean nobody wants their 

811
00:43:53,500 --> 00:43:55,700
project on your back with 
nobody. 

812
00:43:56,300 --> 00:44:00,300
And so what you really want to 
do is you want to have a pull 

813
00:44:00,300 --> 00:44:04,600
system, which says I am not 
going to accept any more work at

814
00:44:04,600 --> 00:44:07,700
any stage. 
Then that stage is capable of 

815
00:44:07,700 --> 00:44:09,700
putting out. 
I'm going to allow myself a 

816
00:44:09,707 --> 00:44:11,900
little buffer. 
So so I always have some work to

817
00:44:11,900 --> 00:44:15,600
do but not a big bus, only a 
small buffers long, as I can 

818
00:44:15,600 --> 00:44:18,600
make it because that determines 
the speed with which I can 

819
00:44:18,600 --> 00:44:22,600
respond to a request. 
So if I have a buffer between 

820
00:44:22,600 --> 00:44:26,500
start to finish of like, say two
weeks of work, I can respond to 

821
00:44:26,500 --> 00:44:29,000
requests in two weeks. 
I have a buffer. 

822
00:44:29,000 --> 00:44:31,600
When we can work. 
I could respond to a request in 

823
00:44:31,600 --> 00:44:34,300
a week. 
If I have one day of work in a 

824
00:44:34,300 --> 00:44:38,300
buffer anywhere, I can respond 
to a request for sure in a day. 

825
00:44:38,700 --> 00:44:41,100
Now, would you rather that 
somebody be able to Respond to 

826
00:44:41,100 --> 00:44:44,200
your question the day or that 
they would accept every single 

827
00:44:44,200 --> 00:44:47,500
request coming at them and then 
create a five-week long list of 

828
00:44:47,500 --> 00:44:50,800
things that they might do. 
Almost, everybody would rather 

829
00:44:50,800 --> 00:44:55,200
know the rate at which things 
can be produced, and have the 

830
00:44:55,200 --> 00:44:59,900
input demand gated to that rate 
because you can move so much 

831
00:44:59,900 --> 00:45:02,000
faster. 
You can focus so much better and

832
00:45:02,000 --> 00:45:05,500
you can be so much more honest 
with the people who are 

833
00:45:05,500 --> 00:45:08,400
ordering. 
So if you make an order from a 

834
00:45:08,408 --> 00:45:12,200
manufacturing plant, even if I'm
Ordering a Lenovo computer if 

835
00:45:12,200 --> 00:45:13,800
it's going to come from Hong 
Kong. 

836
00:45:14,100 --> 00:45:16,400
I still get the ship date the 
day. 

837
00:45:16,400 --> 00:45:19,800
I do the order. 
Okay, because they know the rate

838
00:45:19,800 --> 00:45:23,000
at which they could produce 
stuff, if it's acceptable for 

839
00:45:23,000 --> 00:45:25,500
them to create a backlog. 
It's a slotted back. 

840
00:45:25,500 --> 00:45:29,400
What they are producing at a 
given rate which they must 

841
00:45:29,400 --> 00:45:32,100
maintain and they would not over
premise. 

842
00:45:32,100 --> 00:45:34,800
They might under-promise. 
They might be able to do it a 

843
00:45:34,808 --> 00:45:37,800
week faster. 
But manufacturing Smart Ones. 

844
00:45:37,800 --> 00:45:40,400
They don't over promise. 
They never promised. 

845
00:45:40,600 --> 00:45:43,900
Able to do something that they 
don't have the capacity for now,

846
00:45:44,000 --> 00:45:46,400
if we're producing it and any 
kind of cadence. 

847
00:45:46,700 --> 00:45:50,700
We also know our capacity and if
you know your capacity, you have

848
00:45:50,700 --> 00:45:53,900
absolutely no business, 
accepting work beyond the 

849
00:45:53,900 --> 00:45:56,300
capacity. 
So let's pretend that you for a 

850
00:45:56,300 --> 00:45:59,300
fact that you are able to do 
every week. 

851
00:45:59,300 --> 00:46:03,800
You release about five things. 
Okay, these three teams, they 

852
00:46:03,800 --> 00:46:06,800
work together and every week by 
give or take a little bit 

853
00:46:07,000 --> 00:46:10,000
things, come out. 
There is no way that team should

854
00:46:10,000 --> 00:46:12,500
accept. 
It more than by things a week, 

855
00:46:12,700 --> 00:46:15,100
five requests and weaker, all 
that gets accepted because 

856
00:46:15,100 --> 00:46:17,400
that's what's coming up. 
And they only have a small 

857
00:46:17,400 --> 00:46:20,400
buffer in there. 
So we need to hate our demand 

858
00:46:20,900 --> 00:46:24,100
and if we gate our demand, then 
we can respond immediately to 

859
00:46:24,100 --> 00:46:25,900
it. 
We can get feedback, much, more 

860
00:46:25,900 --> 00:46:28,100
rapidly. 
We can say to customers. 

861
00:46:28,400 --> 00:46:32,000
Oh, all right, we could do that 
and it'll be done in two weeks 

862
00:46:32,300 --> 00:46:35,400
or we can say, oh, I wish I 
could do that. 

863
00:46:35,400 --> 00:46:38,800
But, you know, I don't have the 
capacity and those are the only 

864
00:46:38,800 --> 00:46:40,400
two reasonable request. 
We should be. 

865
00:46:40,600 --> 00:46:44,800
Will the promised date our work?
If we have flow, we understand 

866
00:46:44,800 --> 00:46:48,400
the rate at which we can get 
typical sized things done and we

867
00:46:48,400 --> 00:46:51,800
should be able to plan around 
that rate and from estate. 

868
00:46:52,100 --> 00:46:55,800
And if you can't do that, then 
your flow is probably accepting.

869
00:46:55,800 --> 00:46:59,400
More work at some stage than is 
capable of that stage to 

870
00:46:59,400 --> 00:47:02,300
produce. 
Almost every Workshop. 

871
00:47:02,300 --> 00:47:06,800
We've done is focused around a 
value stream map value stream 

872
00:47:06,800 --> 00:47:11,700
map is simply to the box and 
arrow diagram that Shows what 

873
00:47:11,700 --> 00:47:16,300
tasks are required to do 
whatever the group does and has 

874
00:47:16,300 --> 00:47:18,000
in it. 
The queues of Mary's been 

875
00:47:18,000 --> 00:47:22,600
talking about all stacks of 
stuff waiting for the next task 

876
00:47:22,600 --> 00:47:25,200
to get to it. 
But there's another critical 

877
00:47:25,200 --> 00:47:29,100
thing that wastes enormous 
amounts of time and that is 

878
00:47:29,100 --> 00:47:34,300
approvals the approval process. 
Typically adds no value but it 

879
00:47:34,300 --> 00:47:39,000
puts the Lays in which are huge 
often half the time it takes 

880
00:47:39,000 --> 00:47:42,600
from when you start to when you 
get Did the production is 

881
00:47:42,700 --> 00:47:45,500
approval time waiting for 
somebody to say? 

882
00:47:45,600 --> 00:47:49,900
Yes, this is good, far better to
get direct feedback from the 

883
00:47:49,900 --> 00:47:52,700
place that is supposed to have 
goodness from it. 

884
00:47:53,200 --> 00:47:57,500
And let that place tell you is 
this good and if it's not you 

885
00:47:57,500 --> 00:48:02,400
rapidly change it. 
So it's both the cues and the 

886
00:48:02,400 --> 00:48:08,000
decisions, the approvals that 
are typically between 50 and 90 

887
00:48:08,000 --> 00:48:10,200
percent of the elapsed time 
between, will you? 

888
00:48:10,500 --> 00:48:12,700
Start on something. 
And when you actually have it in

889
00:48:12,700 --> 00:48:15,400
production in, why do you need 
approvals? 

890
00:48:15,900 --> 00:48:20,600
If you already have a outcome 
that you are trying to achieve, 

891
00:48:21,000 --> 00:48:24,500
you're really little is to set 
up the delivery of the outcome 

892
00:48:24,500 --> 00:48:27,700
and feedback from the outcome to
the team so they can decide what

893
00:48:27,700 --> 00:48:30,400
to do next. 
So, all you're approving is, 

894
00:48:30,400 --> 00:48:34,600
this is a good outcome goal and 
it's worth this much money or 

895
00:48:34,600 --> 00:48:37,200
this much time. 
And I will Charter a tea to 

896
00:48:37,200 --> 00:48:40,400
spend that much money or that 
much time, two months Lively. 

897
00:48:40,600 --> 00:48:43,400
Whatever to achieve that goal 
and it will make it clear, what 

898
00:48:43,400 --> 00:48:45,600
the goal is. 
And what steps towards it are? 

899
00:48:46,000 --> 00:48:49,100
If they in their experience 
think that they can achieve that

900
00:48:49,100 --> 00:48:51,100
goal. 
And then I'm on a time and 

901
00:48:51,100 --> 00:48:53,400
they're free, then that's what 
they work on. 

902
00:48:53,600 --> 00:48:56,000
Outside of that approvals are 
necessary. 

903
00:48:56,400 --> 00:49:00,100
Instead you Charter to achieve a
business school. 

904
00:49:00,500 --> 00:49:04,000
You don't approve a particular 
task toward that business goal 

905
00:49:04,300 --> 00:49:06,100
because then you're making a 
decision. 

906
00:49:06,400 --> 00:49:09,100
Which of these texts are going 
to get us to the best business 

907
00:49:09,100 --> 00:49:12,200
goal instead. 
Ed, you approve business goals 

908
00:49:12,200 --> 00:49:14,000
and with the team figure that 
out. 

909
00:49:14,000 --> 00:49:17,800
So, approvals of task-based work
is like, again, it's not a good 

910
00:49:17,800 --> 00:49:20,000
idea. 
You are interfering with the 

911
00:49:20,000 --> 00:49:22,700
ability of the engineering team,
to make decisions. 

912
00:49:22,700 --> 00:49:25,100
So when I did a process control 
system, as I said, we having 

913
00:49:25,100 --> 00:49:29,100
here, we had a team, some 
control Engineers with our boss 

914
00:49:29,100 --> 00:49:31,700
who was basically an expert 
control engineer. 

915
00:49:32,000 --> 00:49:35,600
We had other people doing 
equipment, we work together, but

916
00:49:35,600 --> 00:49:39,000
inside of that year, there was 
no concept of approval of 

917
00:49:39,000 --> 00:49:43,200
anything we have The budget, we 
had senior Engineers, with 

918
00:49:43,200 --> 00:49:46,200
advice. 
We knew what we had to achieve. 

919
00:49:46,600 --> 00:49:49,800
We would have run up the 
authorization for expenditure. 

920
00:49:49,900 --> 00:49:52,800
If it was over a certain amount 
to the board of directors or 

921
00:49:52,800 --> 00:49:55,200
other ways to the end of 
engineering, we would get the 

922
00:49:55,200 --> 00:49:58,500
approval and that was it. 
This project is worth doing, 

923
00:49:58,500 --> 00:50:01,800
it's approved and then it would 
get scheduled or not and they 

924
00:50:01,800 --> 00:50:04,300
would try very hard, not to 
approve stuff that they didn't 

925
00:50:04,300 --> 00:50:08,500
have the resources beyond that 
approvals are just another waste

926
00:50:08,500 --> 00:50:10,300
of time. 
It lets people doing that. 

927
00:50:10,500 --> 00:50:14,700
Jungle the resources, of course 
mean that you need a 

928
00:50:14,700 --> 00:50:17,900
cross-functional team, 
cross-functional, doesn't mean 

929
00:50:17,900 --> 00:50:21,200
that you have both front-end and
back-end Engineers or that. 

930
00:50:21,200 --> 00:50:24,000
You also have testers on the 
team that needs that you have 

931
00:50:24,000 --> 00:50:27,700
operations, representative means
that you have customer support 

932
00:50:27,700 --> 00:50:30,400
represented. 
It means that you have all of 

933
00:50:30,400 --> 00:50:34,700
the things that are going to be 
impacted whose perspectives are 

934
00:50:34,700 --> 00:50:37,700
important to merge in coming up 
with a solution. 

935
00:50:37,800 --> 00:50:40,700
And surely if you have brought 
of people there's nice To be a 

936
00:50:40,700 --> 00:50:45,100
product person, a solution needs
to be negotiated within the team

937
00:50:45,400 --> 00:50:48,700
rapidly without waiting for 
somebody outside who has other 

938
00:50:48,700 --> 00:50:51,900
responsibilities. 
The team itself has a single 

939
00:50:51,900 --> 00:50:54,800
responsibility. 
So approvals. 

940
00:50:54,900 --> 00:50:58,800
Inside a team are typically, 
let's try an experiment and see 

941
00:50:58,800 --> 00:51:04,300
what the feedback tells us not. 
Let's go talk to some graveyard 

942
00:51:04,400 --> 00:51:07,000
and get their permission to 
proceed. 

943
00:51:07,700 --> 00:51:10,900
If so, don't get me wrong. 
There's a great need for good 

944
00:51:10,900 --> 00:51:14,000
product people. 
It's just that their job is not 

945
00:51:14,000 --> 00:51:17,100
to serve as a proxy. 
Their job is to bring their 

946
00:51:17,100 --> 00:51:19,600
product knowledge to a 
cross-functional team. 

947
00:51:19,900 --> 00:51:22,100
They are not generally the 
leader. 

948
00:51:22,500 --> 00:51:24,500
Now. 
Remember, we were working with a

949
00:51:24,500 --> 00:51:27,800
bank in Amsterdam and they had 
developed teams. 

950
00:51:28,100 --> 00:51:30,200
All of their team leaders were 
designers. 

951
00:51:30,700 --> 00:51:34,200
They were doing mostly design of
new cell phone type. 

952
00:51:34,400 --> 00:51:37,100
They wanted their interface, 
both on the web and on the 

953
00:51:37,100 --> 00:51:39,700
phone. 
To be very nice for customers to

954
00:51:39,700 --> 00:51:42,000
use. 
The teams were led by designers,

955
00:51:42,300 --> 00:51:44,600
the ones who knew the best. 
If you've ever worked with a 

956
00:51:44,607 --> 00:51:46,800
designer and you know, that they
don't have one answer to a 

957
00:51:46,800 --> 00:51:50,300
problem. 
They try to fix what a concept. 

958
00:51:50,300 --> 00:51:52,600
Correct. 
That doesn't mean that there 

959
00:51:52,600 --> 00:51:55,900
were people who understood, they
had people who used an 

960
00:51:55,900 --> 00:51:59,400
artificial intelligence to 
examine prominence, and the bank

961
00:51:59,400 --> 00:52:01,200
comment system and all that kind
of stuff. 

962
00:52:01,300 --> 00:52:05,200
So, those channel of information
came to the team, but it wasn't 

963
00:52:05,200 --> 00:52:08,600
this one person responsible for 
figuring Going out which was 

964
00:52:08,600 --> 00:52:11,300
important. 
It was the teen with feedback 

965
00:52:11,500 --> 00:52:16,000
figuring out how to accomplish 
the overall goal, best feedback 

966
00:52:16,000 --> 00:52:18,900
and discussion amongst the 
different disciplines inside of 

967
00:52:18,900 --> 00:52:21,800
the team. 
Why observation is in a team? 

968
00:52:21,900 --> 00:52:26,400
There's usually three roles that
should have conflict and that's 

969
00:52:26,400 --> 00:52:30,300
quality engineering and product.
They represent a different way 

970
00:52:30,300 --> 00:52:33,900
of looking at the world. 
They should not always agree. 

971
00:52:34,400 --> 00:52:38,700
They should have discussions 
about to reach the Stole which 

972
00:52:38,700 --> 00:52:42,500
one of our perspectives on this 
problem is the most important. 

973
00:52:42,900 --> 00:52:45,700
They should have good faith 
discussions and how they're 

974
00:52:45,700 --> 00:52:48,100
going to proceed to reach the 
best. 

975
00:52:48,200 --> 00:52:50,300
Overall result. 
Typically. 

976
00:52:50,300 --> 00:52:53,800
None of them are really going to
be the right person. 

977
00:52:54,200 --> 00:52:56,700
In fact, if you look at team 
leadership, which used to be a 

978
00:52:56,700 --> 00:52:59,000
good idea until spring me, that 
a bad idea. 

979
00:52:59,300 --> 00:53:03,100
If you look at team leadership, 
typically really good successful

980
00:53:03,100 --> 00:53:07,300
teams have a pair of people. 
Sometimes this role is in. 

981
00:53:07,400 --> 00:53:10,800
One person, but typically 
there's a product or Market role

982
00:53:11,000 --> 00:53:15,500
and there is a technical role. 
If you have two liters of tech 

983
00:53:15,500 --> 00:53:19,100
lead and a market lead which we 
often had on our teams at 3M. 

984
00:53:19,400 --> 00:53:22,500
The thing that they need to do 
is have a complete agreement on 

985
00:53:22,500 --> 00:53:26,700
their shared goal and fair 
arguments Fair fights. 

986
00:53:27,300 --> 00:53:30,800
Therefore, neither the tech lead
nor the pratically should have 

987
00:53:30,800 --> 00:53:33,600
their opinion. 
Be the one that is, of course, 

988
00:53:33,600 --> 00:53:36,200
everybody follows. 
They should have arguments. 

989
00:53:36,200 --> 00:53:39,300
They should have They should 
have their flights. 

990
00:53:39,500 --> 00:53:42,600
And if one of those two leads is
Junior to the other one, there's

991
00:53:42,600 --> 00:53:44,500
no fair fight. 
Doesn't happen. 

992
00:53:44,900 --> 00:53:46,900
I have see some of the really 
good teams. 

993
00:53:46,900 --> 00:53:50,100
They tend to have two or three. 
If it's a lot of user interface 

994
00:53:50,100 --> 00:53:52,900
on design lead, is another way 
to have an important lead. 

995
00:53:53,100 --> 00:53:55,800
The oldest people need to be 
able to have Fair fights 

996
00:53:56,100 --> 00:53:59,200
arguments disagreements. 
They're disciplined background 

997
00:53:59,200 --> 00:54:02,400
will absolutely cause that. 
So they have to take their 

998
00:54:02,400 --> 00:54:06,700
discipline background based on 
feedback so far and ultimate 

999
00:54:06,700 --> 00:54:09,300
goal. 
And decide amongst themselves, 

1000
00:54:09,700 --> 00:54:13,700
which of us in this case is 
going to have are disagreeing 

1001
00:54:13,700 --> 00:54:15,800
opinion Prevail generally 
speaking. 

1002
00:54:16,100 --> 00:54:18,100
When they're headed for the same
goal. 

1003
00:54:18,500 --> 00:54:21,100
They can have a lot of fights 
about which is the best way to 

1004
00:54:21,100 --> 00:54:24,600
achieve that goal. 
But if they're really joined at 

1005
00:54:24,600 --> 00:54:28,000
the hip and working together, 
they'll figure out either. 

1006
00:54:28,000 --> 00:54:30,100
This is the right way or we 
can't decide. 

1007
00:54:30,100 --> 00:54:31,600
So we need to do two 
experiments. 

1008
00:54:31,900 --> 00:54:34,300
Those are both really liable 
options. 

1009
00:54:34,300 --> 00:54:36,800
Okay, if they can't agree, they 
could try to approach us. 

1010
00:54:37,600 --> 00:54:40,900
That's not the way we've 
structured our development and 

1011
00:54:40,900 --> 00:54:43,600
that's unfortunate. 
It doesn't appear efficient 

1012
00:54:44,200 --> 00:54:47,000
right test. 
It's a lot like a successful 

1013
00:54:47,000 --> 00:54:50,100
marriage or a successful family.
Same principles. 

1014
00:54:50,700 --> 00:54:53,900
So thanks for sharing all this. 
I think we today listen and 

1015
00:54:53,900 --> 00:54:57,100
learn so many things about how 
we should optimize flow. 

1016
00:54:57,200 --> 00:54:59,800
How they are some anti patterns 
that we should avoid like 

1017
00:54:59,800 --> 00:55:03,700
proxies managing the utilization
or tasks and priorities of the 

1018
00:55:03,700 --> 00:55:06,100
team and all that really 
appreciate all that. 

1019
00:55:06,200 --> 00:55:10,000
So unfortunately due to To time,
we have to capture this exciting

1020
00:55:10,000 --> 00:55:12,700
discussion. 
But before I let both of you go,

1021
00:55:12,800 --> 00:55:15,800
I don't really have one question
that I always ask my guests, 

1022
00:55:15,800 --> 00:55:18,100
which is to share this thing 
called three technical 

1023
00:55:18,100 --> 00:55:20,700
leadership. 
Wisdom is for us to learn 

1024
00:55:20,700 --> 00:55:23,800
anything with them. 
Just from you, what we can do 

1025
00:55:23,800 --> 00:55:26,300
better in our role or in our 
day-to-day job. 

1026
00:55:26,800 --> 00:55:29,800
Okay, so I'm going to just give 
one and is the principle of 

1027
00:55:29,800 --> 00:55:33,700
responsibility. 
So the head of SpaceX launch 

1028
00:55:33,700 --> 00:55:37,300
director. 
The Tory says that space except 

1029
00:55:37,400 --> 00:55:40,800
It's on the principle of 
responsibility, which means that

1030
00:55:40,800 --> 00:55:46,000
everybody accepts responsibility
for a component of the space 

1031
00:55:46,000 --> 00:55:49,200
shuttle launch, and they 
understand the role that 

1032
00:55:49,200 --> 00:55:51,600
component has to play in the 
overall goal. 

1033
00:55:52,100 --> 00:55:55,900
They are responsible for both 
proper, excellent operation of 

1034
00:55:55,900 --> 00:55:59,100
their components and it's 
contributing correctly and 

1035
00:55:59,100 --> 00:56:00,600
successfully to the overall 
goal. 

1036
00:56:00,600 --> 00:56:04,000
So they have to understand both.
There is a principal engineer 

1037
00:56:04,000 --> 00:56:07,300
that is responsible that if you 
work on the principle. 

1038
00:56:07,400 --> 00:56:09,600
Simple of responsibility, which 
is fractal. 

1039
00:56:09,600 --> 00:56:12,600
It can be passed down to some 
teams and make the team to 

1040
00:56:12,600 --> 00:56:16,900
responsible for results. 
Then this concept of making the 

1041
00:56:16,900 --> 00:56:20,100
responsible is first of all, 
very fun way to work for the 

1042
00:56:20,100 --> 00:56:22,700
team's. 
But it's also a very as 

1043
00:56:22,700 --> 00:56:26,200
notorious as there is no 
Engineering Process anywhere. 

1044
00:56:26,400 --> 00:56:30,400
Ever has been discovered to be 
more effective and create better

1045
00:56:30,400 --> 00:56:33,000
results than the principle of 
responsibility. 

1046
00:56:33,600 --> 00:56:37,100
I'd add a couple of man, which 
we've talked about one is the 

1047
00:56:37,400 --> 00:56:39,900
Hold on. 
Push you can't pull from the 

1048
00:56:39,900 --> 00:56:43,200
bottom. 
The other is respect people and 

1049
00:56:43,200 --> 00:56:46,400
that is what waste their time. 
Help them grow. 

1050
00:56:46,400 --> 00:56:50,500
Help them, do meaningful things.
Whenever systems you have that 

1051
00:56:50,500 --> 00:56:52,800
you use to get your goals 
accomplished. 

1052
00:56:53,200 --> 00:56:56,400
The most critical aspect is that
the respect, the people who are 

1053
00:56:56,400 --> 00:56:59,300
implementing it. 
Thanks for all this wisdom. 

1054
00:56:59,600 --> 00:57:03,000
So I really like the respect 
people sometimes, for whatever 

1055
00:57:03,000 --> 00:57:06,500
reasons that line pressure and 
all that we can to, you know, 

1056
00:57:06,500 --> 00:57:09,300
focus on the Just finishing 
tasks and all that rather than 

1057
00:57:09,300 --> 00:57:12,000
respecting the people and make 
them do their job properly, 

1058
00:57:12,000 --> 00:57:13,400
rather than following the 
orders. 

1059
00:57:13,800 --> 00:57:17,200
If people want to find out more 
about you or maybe learn 

1060
00:57:17,200 --> 00:57:19,300
further. 
Where can they find you online 

1061
00:57:19,300 --> 00:57:22,000
both of you? 
Well, I have a website but 

1062
00:57:22,000 --> 00:57:25,700
probably the most recent stuff 
is in my blood which is lean 

1063
00:57:25,700 --> 00:57:28,500
essays.com, anything different 
for you. 

1064
00:57:28,500 --> 00:57:31,500
Tom. 
Our most recent stuff is always 

1065
00:57:31,500 --> 00:57:33,500
podcasts. 
Like the one you're listening to

1066
00:57:33,500 --> 00:57:34,900
right now. 
Cool. 

1067
00:57:35,000 --> 00:57:36,300
Really. 
Thanks so much for your time. 

1068
00:57:36,300 --> 00:57:37,200
Today. 
I have learned. 

1069
00:57:37,400 --> 00:57:39,700
From this conversation. 
I really appreciate that. 

1070
00:57:39,700 --> 00:57:41,200
Thanks, Mary, and Tom. 
Thank you. 

1071
00:57:41,500 --> 00:57:46,900
Thanks again, I guess. 
Thank you for listening to this 

1072
00:57:46,900 --> 00:57:50,300
episode and for staying, right 
until the end if you highly 

1073
00:57:50,300 --> 00:57:53,000
enjoyed it, I would appreciate 
if you share it with your 

1074
00:57:53,000 --> 00:57:56,000
friends and colleagues who you 
think would also benefit from 

1075
00:57:56,000 --> 00:57:58,600
listening to this episode. 
And if you are new to the 

1076
00:57:58,600 --> 00:58:01,600
podcast, make sure to subscribe 
and leave me your valuable 

1077
00:58:01,600 --> 00:58:04,600
review and feedback. 
It helps me a lot in order to 

1078
00:58:04,600 --> 00:58:07,800
grow this podcast better. 
You can also find the full show 

1079
00:58:07,800 --> 00:58:11,100
notes of this conversation on 
the episode page at tackling 

1080
00:58:11,100 --> 00:58:14,400
Journal .f website, including 
the full transcript. 

1081
00:58:14,800 --> 00:58:18,100
I think words and links to the 
resources mention from the 

1082
00:58:18,100 --> 00:58:20,900
conversation. 
And lastly, make sure to 

1083
00:58:20,900 --> 00:58:24,600
subscribe to the show's mailing 
list on pack leader dot f to get

1084
00:58:24,600 --> 00:58:26,800
notified for any future 
episodes. 

1085
00:58:27,200 --> 00:58:28,800
Stay tuned for the next 
technology. 

1086
00:58:28,800 --> 00:58:30,900
No episode. 
And until then. 

1087
00:58:31,000 --> 00:58:31,600
Goodbye.