1
00:00:00,100 --> 00:00:03,300
Spend some time looking at the 
system in which he work, 

2
00:00:03,300 --> 00:00:05,100
understand how the width is 
working. 

3
00:00:05,100 --> 00:00:09,100
Understand how flow is for your 
organization and then you can 

4
00:00:09,100 --> 00:00:11,100
work to optimize that you can 
find. 

5
00:00:11,100 --> 00:00:13,200
You can look at where those 
hierarchies are the 

6
00:00:13,200 --> 00:00:15,700
informational hierarchies, it 
might not be on the orchestra, 

7
00:00:15,700 --> 00:00:18,700
it might be in the value stream 
maps and work to change that. 

8
00:00:23,500 --> 00:00:26,200
Hey everyone. 
My name is Henry Surya, we 

9
00:00:26,200 --> 00:00:29,500
Robin. 
And you're listening to the 

10
00:00:29,500 --> 00:00:33,100
Tecla Journal, podcast the show,
where I'll be bringing you the 

11
00:00:33,100 --> 00:00:36,200
greatest technical leaders 
practitioners and thought 

12
00:00:36,200 --> 00:00:39,700
leaders in the industry to 
discuss about their Journey 

13
00:00:39,900 --> 00:00:44,400
ideas and practices that we all 
can learn and apply to build a 

14
00:00:44,400 --> 00:00:47,900
highly performing technical team
and to make an impact in your 

15
00:00:47,900 --> 00:00:51,200
personal work. 
So let's dive into our Journal. 

16
00:00:56,100 --> 00:00:57,900
Hello again, to all of you my 
listeners. 

17
00:00:58,000 --> 00:01:00,500
Yes, you are listening to The 
Tackle, a journal podcast, the 

18
00:01:00,500 --> 00:01:02,700
podcast where you can learn 
about technical leadership and 

19
00:01:02,700 --> 00:01:05,700
Excellence from my conversations
with great thought leaders in 

20
00:01:05,700 --> 00:01:08,200
the tech industry. 
If you haven't, please follow 

21
00:01:08,200 --> 00:01:11,300
the show on your podcast app and
social media on LinkedIn. 

22
00:01:11,300 --> 00:01:14,300
Twitter and Instagram. 
And to appreciate and support my

23
00:01:14,300 --> 00:01:16,300
work. 
Subscribe as a patron at 

24
00:01:16,300 --> 00:01:19,000
technology. 
No, dot f / Patron or buy me a 

25
00:01:19,000 --> 00:01:21,800
coffee at technology. 
Not deaf / tip. 

26
00:01:22,500 --> 00:01:25,000
My guest for today's episode is 
James Lewis. 

27
00:01:25,400 --> 00:01:28,300
James is a director at 
thoughtworks and a Of 

28
00:01:28,300 --> 00:01:31,900
microservice architecture. 
In this episode, we went back 

29
00:01:31,900 --> 00:01:34,700
Memory Lane to the time when 
James first coined and 

30
00:01:34,700 --> 00:01:37,100
popularized, the micro service 
architecture. 

31
00:01:37,600 --> 00:01:40,500
James described, his definition 
of a micro service and it's 

32
00:01:40,500 --> 00:01:43,400
important characteristics. 
He also shared the reason 

33
00:01:43,400 --> 00:01:45,900
microservice Evolution, 
including the swing between 

34
00:01:45,900 --> 00:01:49,000
micro service and monolith in 
the second half of our 

35
00:01:49,000 --> 00:01:51,600
conversation. 
James shared, his insights from 

36
00:01:51,600 --> 00:01:54,800
complexity science related to 
different scaling patterns, 

37
00:01:55,100 --> 00:01:59,300
particularly he explained how 
different Archetypes can affect 

38
00:01:59,300 --> 00:02:03,000
an organization's growth rate 
and towards the end James gave 

39
00:02:03,000 --> 00:02:06,700
some tips on how organization 
can detect signs of suboptimal 

40
00:02:06,700 --> 00:02:08,800
growth. 
And what we can do to maintain 

41
00:02:08,800 --> 00:02:12,200
organizational agility. 
This is such an insightful 

42
00:02:12,200 --> 00:02:15,400
discussion with James and I find
it a really interesting story, 

43
00:02:15,400 --> 00:02:18,500
how he first got the idea of the
micro service architecture. 

44
00:02:19,000 --> 00:02:21,700
I hope you enjoyed listening to 
this episode and learning a lot 

45
00:02:21,700 --> 00:02:24,200
from it. 
And if you do, please share this

46
00:02:24,200 --> 00:02:26,400
with your colleagues, your 
friends, and your communities, 

47
00:02:26,700 --> 00:02:29,900
and also leave a five-star. 
And review on a podcast and 

48
00:02:29,900 --> 00:02:32,500
Spotify. 
Let's go to my conversation with

49
00:02:32,500 --> 00:02:35,600
James after hearing a few words 
from our sponsors. 

50
00:02:36,100 --> 00:02:38,000
Are you looking for a new cool 
swag? 

51
00:02:38,300 --> 00:02:40,900
Tackle, it Journal. 
Now offers you some swags that 

52
00:02:40,900 --> 00:02:44,700
you can purchase online. 
These wax are printed on demand 

53
00:02:44,700 --> 00:02:48,100
based on your preference and 
will be delivered safely to you 

54
00:02:48,200 --> 00:02:50,700
all over the world. 
We're shipping is available. 

55
00:02:51,100 --> 00:02:53,700
Check out all the cool tracks 
available by visiting 

56
00:02:53,700 --> 00:02:57,100
technology, you know, dot, f / 
shop and don't forget to break 

57
00:02:57,100 --> 00:02:59,400
yourself. 
Once you receive any of those 

58
00:02:59,400 --> 00:03:03,100
tracks. 
Hi everyone. 

59
00:03:03,100 --> 00:03:05,400
Welcome back to another new 
episode of the technology on our

60
00:03:05,400 --> 00:03:08,300
podcast today, we have another 
thought workers in the show. 

61
00:03:08,600 --> 00:03:11,200
So his name is James, DeWees a 
software, architect and 

62
00:03:11,200 --> 00:03:13,600
director. 
Thoughtworks is based in UK. 

63
00:03:13,800 --> 00:03:17,100
If some of you don't know about 
James Lewis, he is actually the 

64
00:03:17,100 --> 00:03:20,100
person who coined the term 
microservices with Martin Fowler

65
00:03:20,200 --> 00:03:23,800
back then in 2014 and I think 
some of you would have known by 

66
00:03:23,800 --> 00:03:28,200
now that since then it has been 
a craze and hype and so many You

67
00:03:28,200 --> 00:03:31,800
transfer following microservices
and today we will touch on a 

68
00:03:31,808 --> 00:03:35,100
little bit about the history of 
microservices and some Evolution

69
00:03:35,100 --> 00:03:37,600
since then and we'll talk about 
some other things as well. 

70
00:03:37,600 --> 00:03:40,300
So James thank you for the 
opportunity to have you on the 

71
00:03:40,300 --> 00:03:41,700
show. 
Looking forward for this 

72
00:03:41,700 --> 00:03:45,400
conversation, hiring your thanks
very much for asking me to be on

73
00:03:45,400 --> 00:03:46,800
the show. 
It's a real privilege and 

74
00:03:46,800 --> 00:03:49,700
pleasure So yeah, thank you. 
So James in the beginning, I 

75
00:03:49,700 --> 00:03:52,700
always love to ask my guess to 
actually share any courage, you 

76
00:03:52,700 --> 00:03:55,200
need highlights or turning 
points that you have in your 

77
00:03:55,200 --> 00:03:58,700
career to be share here for the 
listeners to learn from Yeah, 

78
00:03:58,700 --> 00:04:00,800
that's great question. 
Actually, what wants to create 

79
00:04:00,800 --> 00:04:02,200
hearts? 
Are there's been so many. 

80
00:04:02,200 --> 00:04:06,600
I've been, I think genuinely so 
lucky over the 26, or so years. 

81
00:04:06,600 --> 00:04:10,400
I've been doing this or adjacent
roles in technology. 

82
00:04:10,700 --> 00:04:14,300
I think I use the words luck 
deliberately, right, because my 

83
00:04:14,300 --> 00:04:17,500
career has spanned really work. 
If you think about the last 26 

84
00:04:17,500 --> 00:04:20,200
years of what's been happening 
in technology, expand the birth 

85
00:04:20,200 --> 00:04:22,200
of the internet and the World 
Wide Web. 

86
00:04:22,300 --> 00:04:24,900
I was one of the first 
generation, the UK to grow up 

87
00:04:24,900 --> 00:04:27,600
privileged enough to have access
to computer in school. 

88
00:04:27,600 --> 00:04:30,100
We do. 
This BBC micro thing that every 

89
00:04:30,100 --> 00:04:33,100
school was sent to computer by 
the government or by the BBC SE.

90
00:04:33,500 --> 00:04:37,000
So my career really spans from 
that when I was sort of 89 years

91
00:04:37,000 --> 00:04:40,600
old through Java through the 
birth of the World Wide Web 

92
00:04:40,600 --> 00:04:43,500
through Apache, through sun, 
Microsystems, all these 

93
00:04:43,500 --> 00:04:46,700
different milestones. 
And I've been very privileged 

94
00:04:46,700 --> 00:04:49,700
along the way to work with some 
bread people, we go way back, I 

95
00:04:49,700 --> 00:04:53,800
started off doing physics to be 
honest, I wasn't diligent enough

96
00:04:54,100 --> 00:04:55,800
to be a good theoretical 
physicist. 

97
00:04:55,800 --> 00:04:58,900
I didn't do enough practice and 
I'm definitely Not accurate or 

98
00:04:58,900 --> 00:05:01,000
precise enough to be 
experimental physicist. 

99
00:05:01,000 --> 00:05:04,500
So I said fell into systems 
Administration and programming 

100
00:05:04,500 --> 00:05:07,300
after that, which I've really 
loved ever since. 

101
00:05:07,300 --> 00:05:10,400
And I start off as a sysadmin 
that I was a Oracle database 

102
00:05:10,400 --> 00:05:13,600
administrator for a while. 
Well, that pl/sql goodness back 

103
00:05:13,600 --> 00:05:17,200
in the day and then I studied 
with programming on. 

104
00:05:17,200 --> 00:05:21,600
Would you believe TCL to control
language from things like chill?

105
00:05:21,600 --> 00:05:24,900
Control language for vignette 
story server, which was a sort 

106
00:05:24,900 --> 00:05:27,500
of very early content management
system for the web. 

107
00:05:28,000 --> 00:05:32,700
Java are going to Java, I guess 
back into of 2001 ish. 

108
00:05:33,000 --> 00:05:36,800
I joined for weeks about 2005 as
a Dev to don't know what that 

109
00:05:36,800 --> 00:05:38,300
meant at the time and I still do
it. 

110
00:05:38,300 --> 00:05:41,200
But that was my title death to. 
And I've been a thought, which 

111
00:05:41,200 --> 00:05:44,600
ever since, which is it's meant.
I've been incredibly privileged 

112
00:05:44,600 --> 00:05:47,000
to spend time with some amazing 
people, you know, forwards, 

113
00:05:47,000 --> 00:05:51,100
London 2005. 
Until today has been tremendous 

114
00:05:51,200 --> 00:05:54,200
amount of talents for which in 
general forward, slow ball has 

115
00:05:54,200 --> 00:05:57,100
this huge amount of talent, but 
for which London, but I joined 

116
00:05:57,100 --> 00:06:00,600
there were these People who went
on to really change our industry

117
00:06:00,600 --> 00:06:03,600
day Farley and Jazz humble where
they're being they went on to 

118
00:06:03,600 --> 00:06:06,800
write continuous delivery. 
You had in that price and Steve 

119
00:06:06,800 --> 00:06:10,500
Freeman who with a crisis of J, 
more from went on to write 

120
00:06:10,500 --> 00:06:11,700
growing object-oriented 
software. 

121
00:06:11,700 --> 00:06:15,900
Guided by tests down North, was 
there who went on to create 

122
00:06:15,900 --> 00:06:18,400
Behavior, driven development at 
area fifty Daniel tools and 

123
00:06:18,400 --> 00:06:21,700
obviously very evil, very 
influential and wise figuring 

124
00:06:21,700 --> 00:06:25,200
our community and, you know, 
Cindy Mitchell, who is the MD at

125
00:06:25,200 --> 00:06:29,400
the time but was former son? 
I think provides the swing 

126
00:06:29,400 --> 00:06:32,600
libraries for Java. 
So these amazing insects amazing

127
00:06:32,600 --> 00:06:34,200
people. 
I should mention Eric doing a 

128
00:06:34,200 --> 00:06:36,700
boot as well because he was an 
old friend before I joined the 

129
00:06:36,707 --> 00:06:39,200
likes of reunited with him and 
thought ways but this is a huge 

130
00:06:39,200 --> 00:06:43,000
talent that really helped me to 
embrace the fun, right? 

131
00:06:43,000 --> 00:06:45,400
The fun of working with 
technology, you know there's the

132
00:06:45,400 --> 00:06:47,800
old adage, if you enjoy, what 
you do, don't work a day in your

133
00:06:47,800 --> 00:06:50,800
life and I think I've been very 
privileged and lucky to have 

134
00:06:50,800 --> 00:06:53,500
that come true for me and I 
enjoy, what I do enjoy working 

135
00:06:53,500 --> 00:06:56,300
with the teams of people at 
thoughtworks, I enjoy meeting 

136
00:06:56,300 --> 00:06:59,000
new clients and learning new. 
Domains and still do. 

137
00:06:59,000 --> 00:07:02,100
I still find it fascinating? 
So, yeah, I guess that's a brief

138
00:07:02,100 --> 00:07:05,900
precis of my early career. 
So you've been at dogs for I 

139
00:07:05,907 --> 00:07:08,400
think about 17, 18 years by now.
So adapting. 

140
00:07:08,400 --> 00:07:11,300
That's pretty long, super long. 
And I think you naming some of 

141
00:07:11,300 --> 00:07:12,800
the people just now. 
Right. 

142
00:07:12,800 --> 00:07:15,700
I think some of these are 
thought leaders in the industry.

143
00:07:15,700 --> 00:07:19,100
They also change some of the 
trends in the industry as well. 

144
00:07:19,500 --> 00:07:21,400
So I'm sure. 
Today, we'll be talking a lot 

145
00:07:21,400 --> 00:07:24,900
about some of the trends that 
you also yourself a drive in the

146
00:07:24,900 --> 00:07:27,400
industry. 
So let's go back to the time 

147
00:07:27,400 --> 00:07:29,100
then. 
C14 right? 

148
00:07:29,100 --> 00:07:31,900
You are the first to coin the 
term microservice with Martin 

149
00:07:31,900 --> 00:07:33,300
Fowler. 
I don't know who came with the 

150
00:07:33,300 --> 00:07:36,700
term but I think if we can go 
back and reflect the story, how 

151
00:07:36,700 --> 00:07:38,500
did you actually come up with 
this idea? 

152
00:07:39,200 --> 00:07:41,600
It's a really good question. 
And actually you need to go 

153
00:07:41,600 --> 00:07:45,100
fears before in fact. 
So one thing about thought works

154
00:07:45,100 --> 00:07:48,200
is there are so many amazing 
people working that the weights 

155
00:07:48,200 --> 00:07:50,700
doing amazing things, right? 
So I mentioned a couple of them 

156
00:07:50,700 --> 00:07:53,300
days Farley mentions Jazz 
humble. 

157
00:07:53,500 --> 00:07:54,900
So continuous delivery 
eventually. 

158
00:07:54,900 --> 00:07:58,100
Daniel to host North his 
thinking wearing the A really 

159
00:07:58,100 --> 00:08:00,300
informs me. 
I worked on a team, building our

160
00:08:00,300 --> 00:08:03,400
services, our retail bank, with 
him restful services. 

161
00:08:03,400 --> 00:08:05,800
That really influenced my 
thinking Jim Weber idea, 

162
00:08:05,800 --> 00:08:08,200
Robinson, who were Christian 
practice, along with other 

163
00:08:08,200 --> 00:08:10,500
co-authors service that really 
tied together. 

164
00:08:10,500 --> 00:08:14,000
For me also Ian's observation 
that the be of the web, not 

165
00:08:14,000 --> 00:08:17,500
behind the web, this idea that. 
Why is it in big organizations? 

166
00:08:17,500 --> 00:08:20,300
We spent so much time, creating 
our own infrastructure is our 

167
00:08:20,300 --> 00:08:22,300
own protocols. 
We try and reinvent the wheel 

168
00:08:22,300 --> 00:08:24,500
the whole time and actually 
there's this massively 

169
00:08:24,500 --> 00:08:26,900
successful distributed system 
called the World Wide Web. 

170
00:08:27,000 --> 00:08:30,100
Why shouldn't we just Use the 
Technologies from the world wide

171
00:08:30,100 --> 00:08:33,000
web and your breasts Walker can 
choose level 3 Richardson 

172
00:08:33,000 --> 00:08:34,700
maturity model level 3 
architecture. 

173
00:08:34,700 --> 00:08:37,100
So I was lucky enough to be in 
that on the place and the other 

174
00:08:37,100 --> 00:08:39,799
thing I was lucky enough to 
experience a really formative 

175
00:08:39,900 --> 00:08:41,799
experience for me as he was in 
2007. 

176
00:08:41,799 --> 00:08:45,200
I think I went to my first cross
disciplinary or cross technology

177
00:08:45,200 --> 00:08:48,900
conference it was called Yahoo 
in all who's Daniel tears nor 

178
00:08:48,900 --> 00:08:50,500
they'd really pressed me to go 
to this thing. 

179
00:08:50,800 --> 00:08:53,200
Blew me away, right blew my 
mind, people talking about Cheri

180
00:08:53,200 --> 00:08:55,900
different things, different 
types of integration different 

181
00:08:55,900 --> 00:08:59,500
programming languages coming, Of
where Java came from virtual 

182
00:08:59,500 --> 00:09:03,300
machines in frustrations just 
this massive, interesting 

183
00:09:03,300 --> 00:09:06,400
information so that when it's my
home, and I think that started 

184
00:09:06,400 --> 00:09:10,200
me on this sort of Journey to 
try and synthesize a bunch of 

185
00:09:10,200 --> 00:09:13,300
the things that I was seeing 
that were successful and to come

186
00:09:13,300 --> 00:09:15,700
up with some way of doing the 
all at once. 

187
00:09:15,700 --> 00:09:19,500
I guess in the same way that XP 
extreme programming came about, 

188
00:09:19,500 --> 00:09:21,900
right? 
It's a bunch of practices or 

189
00:09:21,900 --> 00:09:23,600
bunch of things that people were
doing that, we're really 

190
00:09:23,600 --> 00:09:25,700
successful independently. 
So let's put them all together 

191
00:09:25,700 --> 00:09:27,500
to do the ball. 
That's going well, I think my 

192
00:09:27,500 --> 00:09:29,700
brain. 
Works that I see curtains and 

193
00:09:29,700 --> 00:09:31,800
I'm able to phone connections 
between things. 

194
00:09:31,800 --> 00:09:34,600
I think there's maybe a legacy 
of the physics earlier my life. 

195
00:09:34,700 --> 00:09:38,600
And so gradually, these sort of 
things I was seeing in the 

196
00:09:38,600 --> 00:09:41,300
waiting outside of thought, work
started to fit into place, then 

197
00:09:41,300 --> 00:09:44,100
there was one event. 
Actually in 2011 was lucky 

198
00:09:44,100 --> 00:09:46,000
enough to be invited to 
something called the software 

199
00:09:46,000 --> 00:09:48,900
architecture Workshop, this was 
in just north of Venice. 

200
00:09:48,900 --> 00:09:51,400
Actually, I can't remember the 
exact name and there were about 

201
00:09:51,400 --> 00:09:53,400
30 or so people. 
There had been invited to all 

202
00:09:53,400 --> 00:09:56,500
across Europe and the US Africa.
Actually, it's an unconference. 

203
00:09:56,500 --> 00:09:59,500
So we were talking over 3, Days 
form your own agenda and one of 

204
00:09:59,500 --> 00:10:01,800
the themes that came out over 
that three days. 

205
00:10:01,800 --> 00:10:04,500
Was, why are things so hard to 
change? 

206
00:10:04,700 --> 00:10:07,100
Why is it that these big 
products? 

207
00:10:07,300 --> 00:10:09,400
There's some product people that
we've got this big product. 

208
00:10:09,600 --> 00:10:11,900
How do we break it up? 
How do we change it more 

209
00:10:11,900 --> 00:10:14,000
effectively? 
How do we improve maintenance of

210
00:10:14,000 --> 00:10:15,800
it? 
Do you build a new one or do we 

211
00:10:15,800 --> 00:10:18,500
strangle it all these different 
questions I can? 

212
00:10:18,500 --> 00:10:21,400
Honestly say, I had a sort of 
never, it'll never happen to me.

213
00:10:21,400 --> 00:10:25,400
Again, you'll happened once at 
least I literally had like a 

214
00:10:25,600 --> 00:10:28,000
ding in my mind. 
You like, literally, almost Like

215
00:10:28,000 --> 00:10:29,100
a chime, right? 
I know. 

216
00:10:29,100 --> 00:10:31,300
It's like a cliche to say, but 
genuinely what? 

217
00:10:31,300 --> 00:10:33,500
My thought. 
Maybe, we're solving the wrong 

218
00:10:33,500 --> 00:10:35,700
problem. 
Maybe if we didn't have, the 

219
00:10:35,700 --> 00:10:37,700
problem of things that were too 
big, maybe, if we had lots of 

220
00:10:37,700 --> 00:10:41,600
smaller things that might make 
things easier to deal with. 

221
00:10:41,900 --> 00:10:45,000
So I came downstairs, very 
excited in the morning to Jimmy 

222
00:10:45,000 --> 00:10:47,000
Nielsen, who was organizing the 
event. 

223
00:10:47,100 --> 00:10:50,400
The Great's domain-driven design
expert in voice person. 

224
00:10:50,600 --> 00:10:53,500
I said, Jimmy Jimmy, I've got 
this idea, his wife and kids 

225
00:10:53,500 --> 00:10:56,200
with our he often travels with 
his wife and children and he was

226
00:10:56,200 --> 00:10:58,500
looking at me quizzically and I 
said Jimmy I've got this idea. 

227
00:10:58,500 --> 00:11:00,700
Like, what happens if we just 
have everything as an act of the

228
00:11:00,700 --> 00:11:03,300
route and they talk to each 
other across the network and he 

229
00:11:03,300 --> 00:11:05,200
looked at me as like, yeah? 
Okay. 

230
00:11:05,200 --> 00:11:07,200
That's interesting. 
James, but you're crazy, you 

231
00:11:07,200 --> 00:11:10,500
know, he probably remembers it 
differently and yeah, and then 

232
00:11:10,500 --> 00:11:12,600
we sort of went our separate 
ways and I went back to a client

233
00:11:12,600 --> 00:11:15,000
projects in the UK and we 
started putting some of this 

234
00:11:15,000 --> 00:11:17,300
stuff in the practice. 
So rather than doing threading 

235
00:11:17,300 --> 00:11:20,900
within the monolith or having a 
structured model, if we decided 

236
00:11:20,900 --> 00:11:24,000
to scale via processes. 
So every time we wanted to have 

237
00:11:24,000 --> 00:11:27,000
a new capability or subdomain if
you like we've created new 

238
00:11:27,000 --> 00:11:29,700
service, And along with that, 
there came a bunch of other 

239
00:11:29,700 --> 00:11:31,500
practices. 
We have one repository per 

240
00:11:31,500 --> 00:11:34,900
service and the reason we have 
one repository service is 

241
00:11:34,900 --> 00:11:37,700
because I'm stupid, right? 
And generally, that was the 

242
00:11:37,700 --> 00:11:39,500
reason. 
It's like if you put more into 

243
00:11:39,500 --> 00:11:43,500
the same repository, then I 
won't be able to avoid finding 

244
00:11:43,500 --> 00:11:46,400
the abstractions and extracting 
stuff into shared libraries. 

245
00:11:46,400 --> 00:11:47,500
And we don't want to do that, 
right? 

246
00:11:47,500 --> 00:11:50,500
We want to have across the wire 
a pi to 3 Pi communication. 

247
00:11:51,100 --> 00:11:52,900
We started putting all these 
things into practice. 

248
00:11:52,900 --> 00:11:55,200
We had something that looked 
very much like ansible free 

249
00:11:55,200 --> 00:11:57,300
ansible in order to manage all 
this stuff on. 

250
00:11:57,300 --> 00:11:58,100
Aw. 
Yes. 

251
00:11:58,200 --> 00:11:59,700
And it seemed to work pretty 
well. 

252
00:11:59,700 --> 00:12:02,400
And I did a talk at the time 
called Java, the Unix way. 

253
00:12:02,600 --> 00:12:05,700
And I first did that I think in 
Congress that weekend ever walks

254
00:12:05,800 --> 00:12:10,400
in Poland, I also then did it at
short notice in Q Khan, I think 

255
00:12:10,400 --> 00:12:13,300
it was coupon 2012 in San 
Francisco, Jose humble. 

256
00:12:13,300 --> 00:12:15,000
That asked me to go and do a 
training course. 

257
00:12:15,000 --> 00:12:17,800
I did a training course on micro
Services which was a little bit 

258
00:12:17,900 --> 00:12:21,100
scary because I had the guy who 
sat next to Roy Fielding Adobe 

259
00:12:21,200 --> 00:12:23,200
on my training course, I was 
trying to teach him about 

260
00:12:23,200 --> 00:12:25,900
resting, like for this is a bit 
awkward, and then I did this 

261
00:12:25,900 --> 00:12:27,600
talk and then it sort of went a 
bit quiet. 

262
00:12:27,800 --> 00:12:30,900
Martin Fowler, you know, Martin 
took a friend are, he'd been 

263
00:12:30,900 --> 00:12:32,200
trying to persuade me to write 
it up? 

264
00:12:32,200 --> 00:12:33,400
Should write it out. 
We should write to that. 

265
00:12:33,400 --> 00:12:36,400
We should write it up and we 
funded a internal Summits. 

266
00:12:36,400 --> 00:12:39,300
Always microservices some food 
people in from around the world 

267
00:12:39,300 --> 00:12:42,300
to talk about our experiences 
and eventually he decided that 

268
00:12:42,300 --> 00:12:45,800
the only way to get me to write 
it up, was to Fly Me To Boston, 

269
00:12:45,800 --> 00:12:47,600
and to go for a sleepover at his
house. 

270
00:12:47,700 --> 00:12:50,200
So that's what we did. 
I flew to Boston, I spent a week

271
00:12:50,200 --> 00:12:52,800
living with Martin and his 
amazing wife, Cindy drinking, 

272
00:12:52,800 --> 00:12:55,400
good craft beer. 
And writing about microservices,

273
00:12:55,700 --> 00:12:57,600
I should also point out that the
history here. 

274
00:12:57,700 --> 00:13:00,100
Yeah, and this is where the 
whole thought, waves, diaspora 

275
00:13:00,400 --> 00:13:03,300
and the sort of Corrections to 
the rest of the industry coming.

276
00:13:03,500 --> 00:13:06,000
There were other people at the 
same time, talking about exactly

277
00:13:06,000 --> 00:13:08,600
the same thing. 
So whilst I would argue that 

278
00:13:08,600 --> 00:13:12,400
Martin and myself, we wrote down
what became the description of 

279
00:13:12,400 --> 00:13:15,400
the characteristics Fred. 
George at the time, was also 

280
00:13:15,400 --> 00:13:19,400
talking about micro services in 
a different style, but he was 

281
00:13:19,400 --> 00:13:22,100
also talking about these really 
small things that he was told 

282
00:13:22,100 --> 00:13:25,200
about functional microservices. 
If you like and Adrian cockroft 

283
00:13:25,200 --> 00:13:29,300
at Netflix, he was also on a 
That clicks to what he was 

284
00:13:29,300 --> 00:13:31,900
going, fine, grain 
service-oriented architecture. 

285
00:13:32,200 --> 00:13:34,100
But then, you know, Adrienne for
a George's. 

286
00:13:34,100 --> 00:13:37,200
Explore wigs Adrienne has been a
longtime Ally and friend of 

287
00:13:37,200 --> 00:13:39,100
thought whips and marries all 
the people I know. 

288
00:13:39,200 --> 00:13:42,300
So it's no surprise really that 
these ideas all came together, 

289
00:13:42,600 --> 00:13:45,100
so you could probably say that 
the three of us Fred Adrian. 

290
00:13:45,100 --> 00:13:47,800
The myself with the people who 
sort of put it all together in 

291
00:13:47,808 --> 00:13:49,400
one place and then I were to 
that. 

292
00:13:49,400 --> 00:13:53,700
So yeah, that's, I guess, a very
long or very short version of 

293
00:13:53,700 --> 00:13:57,000
the story depending on cover. 
All right, I think it sounds 

294
00:13:57,000 --> 00:13:58,700
really interesting. 
II didn't know some of these 

295
00:13:58,700 --> 00:14:01,300
historical moments, right? 
Like when you shared the 

296
00:14:01,300 --> 00:14:04,400
lightbulb moment that you got 
and then you shared this idea 

297
00:14:04,600 --> 00:14:08,100
and then it became like a thing 
that we found out from Martins 

298
00:14:08,100 --> 00:14:09,800
block, right? 
So, I think it's still there. 

299
00:14:09,800 --> 00:14:13,100
Beyond 2014, both of you publish
this on his blog. 

300
00:14:13,500 --> 00:14:16,800
And I think if we have to go 
back to the definition, right? 

301
00:14:16,900 --> 00:14:18,900
If you would Define 
microservices. 

302
00:14:18,900 --> 00:14:21,700
Now, I know that people take 
microservices into different 

303
00:14:21,700 --> 00:14:25,000
types of understanding different
types of characteristics, but 

304
00:14:25,000 --> 00:14:27,600
maybe from you, originally, how 
would you define microservices? 

305
00:14:27,800 --> 00:14:31,200
This now I probably and we've 
talked about going back and 

306
00:14:31,200 --> 00:14:34,200
writing division to a writing 
updated as addition if you. 

307
00:14:34,200 --> 00:14:36,800
Like think it holds up pretty 
well. 

308
00:14:37,300 --> 00:14:39,900
I mean, there's always going to 
be I think Martin calls its 

309
00:14:39,900 --> 00:14:43,600
semantic diffusion right where 
the original meaning of a term 

310
00:14:43,600 --> 00:14:46,100
is lost over time. 
As many people start to add 

311
00:14:46,100 --> 00:14:48,600
their own meanings to it but I 
think it actually if you look at

312
00:14:48,608 --> 00:14:51,800
those characteristics they stand
up pretty well and might make 

313
00:14:51,800 --> 00:14:54,100
more of a focus. 
She on the business side of 

314
00:14:54,100 --> 00:14:56,100
things, rather than the 
technical side of things, I 

315
00:14:56,100 --> 00:14:58,800
think the technical side of 
things is accelerated off in all

316
00:14:58,800 --> 00:15:01,700
sorts of directions. 
Remembered all came after this, 

317
00:15:01,700 --> 00:15:03,700
right? 
And kubernetes, these are 

318
00:15:03,700 --> 00:15:06,800
technologies that have been 
invented or popularized because 

319
00:15:06,800 --> 00:15:09,900
we doctors being the other line 
Tech has been around for ages to

320
00:15:09,900 --> 00:15:12,400
help obviously a lot with 
building distributed systems. 

321
00:15:12,400 --> 00:15:15,100
It makes it a lot easier. 
I think we're, I'm Consulting, 

322
00:15:15,100 --> 00:15:19,200
the things I see, least the 
pride are the things around 

323
00:15:19,200 --> 00:15:22,900
products versus projects and the
organization around business 

324
00:15:22,900 --> 00:15:25,900
capabilities and really 
embedding domain-driven design 

325
00:15:26,000 --> 00:15:28,700
Into the Heart of what you do 
and I think that's because 

326
00:15:28,700 --> 00:15:31,300
that's actually harder in some 
ways to solve than the 

327
00:15:31,300 --> 00:15:33,300
technology problems of breaking 
things up and promote 

328
00:15:33,300 --> 00:15:35,000
communication. 
And why do I say that will? 

329
00:15:35,000 --> 00:15:36,500
Because it involves humans. 
Right. 

330
00:15:36,500 --> 00:15:39,100
So, whenever we're in a position
where we can pull humans, and 

331
00:15:39,100 --> 00:15:43,300
teams and people and structures,
and this may be related to some 

332
00:15:43,300 --> 00:15:45,500
of the stuff I'll talk about 
later, but the time scales to 

333
00:15:45,500 --> 00:15:48,800
change and for experimentation, 
on much longer, it's much harder

334
00:15:49,100 --> 00:15:52,800
to change your developer ization
of your organizational structure

335
00:15:52,900 --> 00:15:55,400
frequently. 
Like we can do when we refactor 

336
00:15:55,400 --> 00:15:57,600
code bases or where we actually 
redesign. 

337
00:15:57,700 --> 00:16:00,500
A Nori architecture, because it 
takes a long time to see if 

338
00:16:00,500 --> 00:16:02,800
something's working. 
I think the other thing is with 

339
00:16:02,800 --> 00:16:05,100
the characteristics, I'm pretty 
early with emphasize Conway's 

340
00:16:05,100 --> 00:16:08,600
little more in a sense because I
think that again, is something 

341
00:16:08,600 --> 00:16:13,500
that's a real driver for a long.
The microservices, I'll all the 

342
00:16:13,500 --> 00:16:16,500
problems I see with 
implementations, we often get 

343
00:16:16,500 --> 00:16:18,100
asked a question. 
Like, you know, we've got these 

344
00:16:18,400 --> 00:16:21,600
two thousand Services, I how am 
I supposed to understand all of 

345
00:16:21,600 --> 00:16:24,200
those to which my answer is? 
We you know, right? 

346
00:16:24,200 --> 00:16:27,400
Yes, that's the whole point of 
breaking things up into smaller 

347
00:16:27,400 --> 00:16:28,700
units. 
Old Rising around the 

348
00:16:28,700 --> 00:16:31,400
capabilities, rather domains and
then split the team's up like 

349
00:16:31,400 --> 00:16:33,700
that. 
Conway's Law happened in there. 

350
00:16:33,700 --> 00:16:36,400
So that all you need to know is 
about the things that you know 

351
00:16:36,400 --> 00:16:38,500
about and the things may be 
adjacent to. 

352
00:16:38,500 --> 00:16:41,900
You don't need to know about all
2000 or 4000 of these things 

353
00:16:41,900 --> 00:16:44,300
that I think that's definitely 
something that I would spend it.

354
00:16:44,300 --> 00:16:47,300
Go back and focus a little bit 
on some Newman is going to 

355
00:16:47,300 --> 00:16:48,800
lovely phrase. 
He talks about, you know, when 

356
00:16:48,800 --> 00:16:51,300
you've got a big problem, how do
you solve a really big complex 

357
00:16:51,300 --> 00:16:53,100
problem? 
Break it up into a lot of 

358
00:16:53,100 --> 00:16:56,100
smaller, but still complex 
problems and solve the small 

359
00:16:56,100 --> 00:16:57,900
problem. 
That's really what We were 

360
00:16:57,900 --> 00:17:00,400
trying that's one of the hearts 
of microservices. 

361
00:17:00,600 --> 00:17:03,600
The other thing I probably would
have emphasized the bit more and

362
00:17:03,600 --> 00:17:07,700
this is may be due to my journey
as a software professional since

363
00:17:07,800 --> 00:17:12,099
is the concept of flow. 
So I probably would have put 

364
00:17:12,099 --> 00:17:16,500
more effort into describing. 
If are these optimize your 

365
00:17:16,500 --> 00:17:19,800
ability to get things done and 
to scale teams around these 

366
00:17:19,800 --> 00:17:22,700
things because that 
fundamentally is such a huge 

367
00:17:22,700 --> 00:17:25,700
issue in our industry. 
Now how do we go faster? 

368
00:17:25,700 --> 00:17:27,599
How do we get more stuff done 
here? 

369
00:17:27,700 --> 00:17:30,800
Pretty developer experience. 
How do we get value out the door

370
00:17:30,900 --> 00:17:34,600
improve cost of delay, all these
things and I think microservices

371
00:17:34,600 --> 00:17:38,400
at the heart or a way of doing 
that, but only if they're done 

372
00:17:38,900 --> 00:17:43,300
properly, are quoting properly 
by paying attention to how you 

373
00:17:43,300 --> 00:17:46,500
split up your teams and that you
don't get this, massive 

374
00:17:46,500 --> 00:17:49,000
distributed model, if that 
everyone has to understand 

375
00:17:49,000 --> 00:17:52,100
everything and everything has to
be deployed along once, but that

376
00:17:52,100 --> 00:17:54,600
just might be more able 
obsession with flow and flow 

377
00:17:54,600 --> 00:17:57,000
efficiency that I've developed 
over the last few years. 

378
00:17:57,000 --> 00:17:58,400
I'm not sure. 
Yeah. 

379
00:17:58,400 --> 00:18:01,100
So I think what you said is 
really insightful, because many 

380
00:18:01,100 --> 00:18:04,200
people actually took to the 
extreme on the technology side, 

381
00:18:04,208 --> 00:18:05,600
right? 
So things like for example, 

382
00:18:05,600 --> 00:18:08,700
lines of code like how big is a 
micro service right? 

383
00:18:08,700 --> 00:18:11,200
Or what technologies that we 
should use maybe like kubernetes

384
00:18:11,200 --> 00:18:13,700
contain, and things like that? 
But I think you remind us the 

385
00:18:13,700 --> 00:18:17,200
important things which is 
already defined by both of you 

386
00:18:17,200 --> 00:18:19,500
in the article itself 9 
characteristics, right? 

387
00:18:19,500 --> 00:18:22,800
And things that stand true to 
the test of time. 

388
00:18:22,800 --> 00:18:25,500
I believe things like for 
example, componentization fire 

389
00:18:25,500 --> 00:18:27,100
Services, organizing around 
business. 

390
00:18:27,700 --> 00:18:29,700
These products are projects and 
things like that. 

391
00:18:29,700 --> 00:18:31,700
So I think that's a really 
insightful. 

392
00:18:31,700 --> 00:18:34,900
And I like the way you also 
mention about Conway's law, I 

393
00:18:34,908 --> 00:18:38,000
think 11 also mention that it's 
like a law of gravity. 

394
00:18:38,000 --> 00:18:41,400
You can't escape from that and 
you just need to adapt to 

395
00:18:41,400 --> 00:18:43,500
Conway's law, right? 
The other thing about 

396
00:18:43,500 --> 00:18:46,400
microservices lately is that 
people have been swinging, 

397
00:18:46,400 --> 00:18:48,200
right? 
So some started with like 

398
00:18:48,200 --> 00:18:50,600
service-oriented architecture, 
then they went into 

399
00:18:50,600 --> 00:18:53,900
microservices, monolith became 
quite a trend as well because 

400
00:18:53,900 --> 00:18:56,500
people implemented microservices
in the wrong way. 

401
00:18:56,600 --> 00:18:59,100
And our people started to think 
about right size service 

402
00:18:59,100 --> 00:19:01,100
microservice. 
So, what do you think about all 

403
00:19:01,100 --> 00:19:02,800
these different swings right 
now? 

404
00:19:02,900 --> 00:19:05,800
What could go wrong here or what
is the underlying Trend behind 

405
00:19:05,800 --> 00:19:08,000
all these? 
That's a good question. 

406
00:19:08,000 --> 00:19:10,600
I mean, going back and I'm 
fortunate enough to have been 

407
00:19:10,700 --> 00:19:12,500
involved with industry from 
family or time. 

408
00:19:12,500 --> 00:19:14,100
You mentioned service-oriented 
architecture. 

409
00:19:14,400 --> 00:19:17,000
But what was the driver for SOA 
to start with, right? 

410
00:19:17,100 --> 00:19:20,100
So this is pre ATI economy. 
This is in many ways. 

411
00:19:20,100 --> 00:19:22,900
This is pre Thomas. 
Write the ideas behind 

412
00:19:22,900 --> 00:19:26,600
service-oriented architectures. 
It was about how to maximize the

413
00:19:26,600 --> 00:19:29,100
investment in our To like to use
date, right? 

414
00:19:29,300 --> 00:19:32,700
If you think about how 
organizations grew in the 80s 

415
00:19:32,700 --> 00:19:34,800
and 90s, what you had 
internally, you'd end up with 

416
00:19:34,800 --> 00:19:37,600
lots of these different 
platforms that were sometimes 

417
00:19:37,600 --> 00:19:40,200
doing the same thing. 
Sometimes naughty is our big Erp

418
00:19:40,200 --> 00:19:43,100
systems that were like sucks. 
All your data is really hard to 

419
00:19:43,100 --> 00:19:45,300
get stuff out of, maybe one 
department. 

420
00:19:45,300 --> 00:19:46,600
But one thing, another 
department. 

421
00:19:46,600 --> 00:19:49,100
But another thing that they both
did the same thing to end up 

422
00:19:49,100 --> 00:19:52,100
with duplication of Investments 
and things and service oriented 

423
00:19:52,100 --> 00:19:54,200
architecture. 
Really, was this idea of how can

424
00:19:54,200 --> 00:19:57,500
we create a set of common 
building blocks that we can? 

425
00:19:57,600 --> 00:20:00,300
Using our organization, right? 
So this is going back to 

426
00:20:00,308 --> 00:20:02,300
capabilities as well as business
capabilities. 

427
00:20:02,300 --> 00:20:04,000
Were first talked about in the 
late 50s. 

428
00:20:04,000 --> 00:20:06,700
So, this is nothing new, right? 
But when we talked about 

429
00:20:06,700 --> 00:20:09,600
capabilities, they were talked 
about, not in the sense of 

430
00:20:09,600 --> 00:20:11,800
Purity, is in the software. 
I adjust the services. 

431
00:20:11,800 --> 00:20:15,800
They were talked about in the 
sense of people processes and 

432
00:20:15,800 --> 00:20:20,000
tools that make up an important 
part of what your business does 

433
00:20:20,000 --> 00:20:22,200
and serious oriented 
architecture was about then 

434
00:20:22,200 --> 00:20:25,200
almost like, creating these 
units that will allow these 

435
00:20:25,200 --> 00:20:27,500
things to talk to one another 
without a duplication. 

436
00:20:27,700 --> 00:20:31,600
So on so reducing cost by doing 
X, Y Zed, and I think as things 

437
00:20:31,600 --> 00:20:34,900
change those, then you move into
the internet age, into the world

438
00:20:34,900 --> 00:20:36,600
of of where everything is 
digital. 

439
00:20:36,800 --> 00:20:38,800
Doesn't matter, if your bricks 
and mortar retail, you're also a

440
00:20:38,800 --> 00:20:41,600
digital retailer. 
In a sense, at least you have to

441
00:20:41,600 --> 00:20:43,500
offer your catalogs digitally 
Etc. 

442
00:20:43,800 --> 00:20:46,000
Then the meaning of a 
service-oriented architecture 

443
00:20:46,000 --> 00:20:48,800
started to change and we started
thinking less about internal 

444
00:20:48,800 --> 00:20:52,100
integration between systems and 
how to make that more stable, 

445
00:20:52,300 --> 00:20:55,100
which is really where my head 
was back in the day into this 

446
00:20:55,100 --> 00:20:57,100
idea of K. 
How do we offer apis? 

447
00:20:57,600 --> 00:20:59,300
Externally, how do we build 
software? 

448
00:20:59,300 --> 00:21:02,800
That's providing these apis that
either our channels can use or 

449
00:21:02,800 --> 00:21:05,700
that we can offer as a service, 
Google Maps as an example. 

450
00:21:06,000 --> 00:21:09,400
So maybe there's been this long 
term Trend towards more 

451
00:21:09,400 --> 00:21:11,400
service-oriented architecture 
everywhere. 

452
00:21:11,400 --> 00:21:15,100
If you like backing 2014 15, in 
my training courses, I'd be 

453
00:21:15,100 --> 00:21:18,600
asked how big should one be, you
know, do you think we'll end up 

454
00:21:18,600 --> 00:21:21,300
with thousands of these small 
things that are 50 lines of 

455
00:21:21,300 --> 00:21:25,000
code, each which some proponents
of them at the time were saying,

456
00:21:25,000 --> 00:21:28,800
you know, there was one 
classically This is my chance to

457
00:21:28,808 --> 00:21:31,000
chat. 
It comes with a minute, but his 

458
00:21:31,000 --> 00:21:34,100
rule was you can write your 
service in any language. 

459
00:21:34,200 --> 00:21:37,300
You like, as long as you can 
rewrite it in half a day in 

460
00:21:37,300 --> 00:21:39,300
another language, which means 
things are really small, you 

461
00:21:39,300 --> 00:21:41,100
know. 
So there was that movement. 

462
00:21:41,100 --> 00:21:43,800
Then there's also the idea of 
modular monoliths do we have to 

463
00:21:43,800 --> 00:21:46,700
start with microservices? 
This seems like a really complex

464
00:21:46,700 --> 00:21:50,200
way to build simple systems and 
it is really complex ways to 

465
00:21:50,200 --> 00:21:52,700
build simple systems. 
I don't think anyone's ever said

466
00:21:52,700 --> 00:21:54,200
that you shouldn't build 
structured. 

467
00:21:54,200 --> 00:21:57,400
Bolus, I think the problem came 
that over time. 

468
00:21:57,600 --> 00:22:02,000
I'm we saw this really hard once
you go past a certain scale to 

469
00:22:02,000 --> 00:22:04,600
keep the model with modular. 
If you've got something that's 

470
00:22:04,600 --> 00:22:07,200
relatively simple and small, 
then that's fine. 

471
00:22:07,300 --> 00:22:10,400
But at a certain point with a 
certain amount of tune on the 

472
00:22:10,400 --> 00:22:12,700
team with a certain number of 
people working on the platform 

473
00:22:12,700 --> 00:22:16,700
excetera, you tend to reach a 
point where things start to 

474
00:22:16,700 --> 00:22:19,100
become Tangled. 
Yeah, you end up having to put a

475
00:22:19,100 --> 00:22:23,000
lot of energy into managing Tech
debt or a lot of energy into 

476
00:22:23,300 --> 00:22:25,600
avoiding entropy if you like in 
the morning. 

477
00:22:26,100 --> 00:22:29,300
So I think naturally So the 
strong one way, I think. 

478
00:22:29,300 --> 00:22:31,700
Then they're actually we're 
swinging somewhat in the other 

479
00:22:31,700 --> 00:22:34,400
direction but I also think 
there's something in the middle,

480
00:22:34,400 --> 00:22:36,400
right? 
I suspect we still haven't 

481
00:22:36,400 --> 00:22:38,900
settled on that yet. 
Which probably looks a bit more 

482
00:22:38,900 --> 00:22:41,700
like fine grains, 
service-oriented architectures, 

483
00:22:41,700 --> 00:22:44,900
which you guys agency because at
certain points are certain 

484
00:22:44,900 --> 00:22:48,500
scales, you can't solve the 
problems without using this sort

485
00:22:48,500 --> 00:22:50,500
of distributed system. 
There are certain things you 

486
00:22:50,500 --> 00:22:53,100
have to use these sort of 
patterns for. 

487
00:22:53,500 --> 00:22:56,100
And obviously, as an industry we
are amazing. 

488
00:22:56,100 --> 00:22:57,400
Well bit like, uber Asia know 
this. 

489
00:22:57,600 --> 00:23:00,100
Snake that eats its own tail. 
We keep on going back, round and

490
00:23:00,100 --> 00:23:01,700
round and round and do the same 
things. 

491
00:23:01,700 --> 00:23:03,600
I had that there's a funny 
conversation with someone 

492
00:23:03,800 --> 00:23:06,600
recently about what should we 
use, Simple stack to build like 

493
00:23:06,600 --> 00:23:08,400
an internal simple internal 
ever. 

494
00:23:08,400 --> 00:23:11,300
That's never going to be exposed
to the outside world is going to

495
00:23:11,300 --> 00:23:13,500
be a really simple line of 
business, kind of thing, not 

496
00:23:13,500 --> 00:23:16,600
many users, and of course, the 
immediate reaction from many 

497
00:23:16,600 --> 00:23:18,800
people were as well. 
You first of all, you start with

498
00:23:18,800 --> 00:23:20,900
react. 
So then you need maybe graph to 

499
00:23:20,900 --> 00:23:24,100
hourly this massive, massive 
stack of stuff, right? 

500
00:23:24,100 --> 00:23:27,400
Just to build something that you
could do really simply via so. 

501
00:23:27,600 --> 00:23:30,000
Side rendering and I think 
that's the safely microservices 

502
00:23:30,200 --> 00:23:32,200
will hit everything with the 
microservices tournament. 

503
00:23:32,400 --> 00:23:35,100
The getting that you don't 
always have to solve every 

504
00:23:35,100 --> 00:23:37,500
problem that way, I still think 
they're very useful tools 

505
00:23:37,500 --> 00:23:39,300
though. 
Although I do often when I 

506
00:23:39,300 --> 00:23:42,500
introduce myself as the sort of 
grumpy old full of 

507
00:23:42,500 --> 00:23:45,800
microservices, I do say and I'm 
sorry about that, you know? 

508
00:23:48,100 --> 00:23:49,600
Right. 
So I think the one of the 

509
00:23:49,600 --> 00:23:52,300
classic things also for people 
who are building internal tools,

510
00:23:52,300 --> 00:23:53,500
like what you said just now, 
right? 

511
00:23:53,500 --> 00:23:56,400
So there are only a few 
developers but they create more 

512
00:23:56,400 --> 00:23:59,400
than the number of basis that 
they could handle as a 1%. 

513
00:23:59,400 --> 00:24:01,500
So for example, one person could
handle three to five 

514
00:24:01,500 --> 00:24:04,500
microservices on his own. 
I think that's also probably not

515
00:24:04,500 --> 00:24:06,800
the right thing to do. 
So I think, let's see how it 

516
00:24:06,800 --> 00:24:09,400
goes in the industry. 
These days I want to continue 

517
00:24:09,400 --> 00:24:11,700
our conversation to the other 
thing that you mentioned, just 

518
00:24:11,700 --> 00:24:14,600
now conversation, right? 
We are always trying to optimize

519
00:24:14,600 --> 00:24:17,600
ourselves, how can we deliver 
things faster and Lady? 

520
00:24:17,600 --> 00:24:20,400
You'll have also been giving 
talks in various conferences 

521
00:24:20,400 --> 00:24:23,800
about this topic which I had the
opportunity to attend in y'all 

522
00:24:23,800 --> 00:24:27,300
Sydney back then in December, 
which I found really insightful.

523
00:24:27,600 --> 00:24:30,200
I want to go and maybe cover 
some of the things that you 

524
00:24:30,200 --> 00:24:33,000
mentioned as well. 
So one of the most important 

525
00:24:33,000 --> 00:24:36,300
thing that you mentioned in the 
talk is about most companies 

526
00:24:36,300 --> 00:24:38,800
right as they get bigger, 
actually, it becomes very 

527
00:24:38,800 --> 00:24:42,200
difficult for them to scale even
bigger while in the top. 

528
00:24:42,200 --> 00:24:46,000
You also mentioned that AWS, 
interestingly didn't have that 

529
00:24:46,000 --> 00:24:48,700
characteristics as they get 
bigger actually, they become 

530
00:24:48,700 --> 00:24:51,300
much, much bigger looking back 
from my experience as well. 

531
00:24:51,300 --> 00:24:53,200
Right. 
I can see many companies as they

532
00:24:53,300 --> 00:24:55,800
tend to become bigger as more 
number of people join the 

533
00:24:55,800 --> 00:24:57,400
company's things start to get 
slow. 

534
00:24:57,500 --> 00:24:59,500
Our. 
So maybe in the first place. 

535
00:24:59,600 --> 00:25:03,100
Let's go there. 
Then try to analyze why things 

536
00:25:03,100 --> 00:25:05,800
become slow as most 
organizations Ruby? 

537
00:25:05,800 --> 00:25:07,800
Good. 
Sure you're absolutely. 

538
00:25:07,800 --> 00:25:09,700
Let's do that. 
My observation of Max is and I 

539
00:25:09,700 --> 00:25:12,900
should point out that again, 
this is matter research, this is

540
00:25:12,900 --> 00:25:15,200
me summarizing. 
The whole water of work. 

541
00:25:15,200 --> 00:25:17,500
Really insightful stuff that's 
been going on in the world of 

542
00:25:17,500 --> 00:25:20,200
biology and economics in the 
world, things like City 

543
00:25:20,200 --> 00:25:23,900
Planning, or all these different
areas that generally come under 

544
00:25:23,900 --> 00:25:26,600
the term complexity science. 
So it's been a huge amount of 

545
00:25:26,608 --> 00:25:28,800
work going on. 
Is Singapore's a big sound 

546
00:25:28,800 --> 00:25:31,200
reflects the sciences that is an
Institute in Singapore. 

547
00:25:31,200 --> 00:25:34,400
For be the home of complexity 
science has been the Santa Fe 

548
00:25:34,400 --> 00:25:37,600
Institute in New Mexico and 
there's just been some super 

549
00:25:37,600 --> 00:25:38,800
interesting things coming out of
there. 

550
00:25:38,800 --> 00:25:41,500
Well, what I find fascinating is
they put together a 

551
00:25:41,500 --> 00:25:45,700
cross-disciplinary group of 
scientists of academics, right? 

552
00:25:45,700 --> 00:25:48,700
People who wouldn't normally 
talk to one another talk to each

553
00:25:48,700 --> 00:25:50,900
other, and they get them 
together and they bought a 

554
00:25:50,900 --> 00:25:53,200
conversation if you like. 
So you end up with a columnist 

555
00:25:53,200 --> 00:25:56,600
and biologists and physicists 
and chemists and geographers, 

556
00:25:56,600 --> 00:25:58,600
and all these dead. 
Different groups of people 

557
00:25:58,800 --> 00:26:02,200
coming together to talk about 
problems in a holistic way or 

558
00:26:02,200 --> 00:26:04,300
think interesting things that 
they're seeing in a holistic 

559
00:26:04,300 --> 00:26:06,200
way. 
One example would be economics. 

560
00:26:06,500 --> 00:26:08,900
So Santa Fe Institute is a 
driver of this idea of 

561
00:26:08,900 --> 00:26:13,000
complexity economics or non 
equilibrium economics where I 

562
00:26:13,008 --> 00:26:16,400
want to murder this definition 
but the idea is that traditional

563
00:26:16,400 --> 00:26:19,500
economics is based on four 
Librium States frankly because 

564
00:26:19,500 --> 00:26:21,200
the math is easy. 
The math easy. 

565
00:26:21,200 --> 00:26:24,100
If you're talking about systems 
at equilibrium, the observation 

566
00:26:24,100 --> 00:26:27,300
from a bunch of people coming 
together in Santa Fe was hang 

567
00:26:27,300 --> 00:26:29,100
on. 
It most things answer, accurate 

568
00:26:29,100 --> 00:26:31,700
rewrite, most things are not 
every dream states like the 

569
00:26:31,700 --> 00:26:34,000
world is in a non equilibrium 
state. 

570
00:26:34,100 --> 00:26:37,200
So why is it we're trying to 
approximate what's really going 

571
00:26:37,200 --> 00:26:40,100
on and economics with these 
massive oversimplification. 

572
00:26:40,400 --> 00:26:43,700
And the answer is because the 
economists are economists, then 

573
00:26:43,700 --> 00:26:45,200
our mathematical physicist, 
right? 

574
00:26:45,200 --> 00:26:48,500
So, the mass, that is easier for
the mathematical physicist, is 

575
00:26:48,500 --> 00:26:49,900
not so easy if you don't have 
that. 

576
00:26:50,300 --> 00:26:52,700
So, that's one example of the 
sort of cross-disciplinary stuff

577
00:26:52,700 --> 00:26:55,100
has been happening and they've 
been doing some amazing things. 

578
00:26:55,100 --> 00:26:57,400
Usually, agent-based models they
can now do things like say, 

579
00:26:57,500 --> 00:27:01,000
Simulated economy is not growing
economies in the large and they 

580
00:27:01,000 --> 00:27:05,800
can produce by putting in the 
rules that the difference 

581
00:27:06,100 --> 00:27:09,300
countries in the world, apply to
the capitalist systems of their 

582
00:27:09,300 --> 00:27:11,500
end. 
So the different Market controls

583
00:27:12,000 --> 00:27:14,500
just by using these simple 
agent-based models exchanging 

584
00:27:14,500 --> 00:27:16,600
value. 
And these Market controls, they 

585
00:27:16,600 --> 00:27:19,700
can produce the gini 
coefficients for Nations around 

586
00:27:19,700 --> 00:27:22,200
the world so you can say left 
before in the Netherlands we've 

587
00:27:22,200 --> 00:27:24,900
got this type of Market control.
All right, let's run the model 

588
00:27:24,900 --> 00:27:27,300
with these Market controls own 
turns out. 

589
00:27:27,400 --> 00:27:31,400
We can get the gini coefficient 
so that's the ratio between the 

590
00:27:31,400 --> 00:27:33,800
richest in society in the 
poorest in society where the 

591
00:27:33,800 --> 00:27:36,300
wealth is it pops out for the 
Netherlands? 

592
00:27:36,300 --> 00:27:38,800
If you put them off in controls,
the UK has its unique 

593
00:27:38,800 --> 00:27:41,200
coefficient pops. 
Acts, they do some fascinating 

594
00:27:41,200 --> 00:27:42,600
interesting stuff across the 
board. 

595
00:27:42,600 --> 00:27:46,300
I think what really interested 
me was how it then related to 

596
00:27:46,300 --> 00:27:50,300
have some of that research into 
scaling laws into how things get

597
00:27:50,300 --> 00:27:53,900
bigger relates to what we do as 
technologists, or what we do in 

598
00:27:53,900 --> 00:27:56,300
the area, or the organizations, 
in which we find ourselves. 

599
00:27:56,300 --> 00:27:59,500
And there's Seems to be, I 
think, in, at all, that talk, 

600
00:27:59,500 --> 00:28:02,000
about Geoffrey West hooks to 
paraphrase. 

601
00:28:02,200 --> 00:28:05,000
Every time you see straight 
lines on a graph, in lots of 

602
00:28:05,000 --> 00:28:07,300
different places, you all these 
straight lines, basically, 

603
00:28:07,300 --> 00:28:09,800
replicating across different 
domains different parts of the 

604
00:28:09,800 --> 00:28:11,700
world, different types of 
complex system. 

605
00:28:12,000 --> 00:28:13,900
Then you should find something 
interesting in it. 

606
00:28:13,900 --> 00:28:15,700
I you should be looking like 
maybe there's something 

607
00:28:15,700 --> 00:28:19,100
underlying maybe there's 
something that's like a truth. 

608
00:28:19,100 --> 00:28:22,800
We can go after and that we can 
use scientific methods to try 

609
00:28:22,800 --> 00:28:25,200
and determine and that's what 
they've kind of been doing in. 

610
00:28:25,200 --> 00:28:27,300
Santa Fe around scaling Jeffrey 
Webb. 

611
00:28:27,500 --> 00:28:29,900
The professor West, I should 
say, I don't know them, they're 

612
00:28:29,900 --> 00:28:32,000
the gentleman. 
He's been instrumental as well 

613
00:28:32,000 --> 00:28:34,000
as some others. 
And what they've sort of found 

614
00:28:34,000 --> 00:28:37,100
essentially is with different 
types of network. 

615
00:28:37,200 --> 00:28:39,400
And I'm using the words, the 
network in the kind of 

616
00:28:39,400 --> 00:28:42,800
mathematical sense, if you like 
so, whether you've got and like,

617
00:28:42,800 --> 00:28:46,800
hierarchical like graph, like 
directed graph, like networks 

618
00:28:47,100 --> 00:28:51,200
versus things like social 
networks, different types of 

619
00:28:51,200 --> 00:28:54,400
networks, coming explain the 
different straight lines on 

620
00:28:54,400 --> 00:28:57,300
graphs, that they've been 
finding and all sorts of weird. 

621
00:28:57,400 --> 00:28:59,700
Weird and wonderful ways with 
wonderful places. 

622
00:28:59,700 --> 00:29:03,200
So, in example, the straight 
line on the graph that is the 

623
00:29:03,200 --> 00:29:06,800
scaling law for metabolic rate 
in mammals, you can draw a 

624
00:29:06,800 --> 00:29:08,400
straight line. 
There's now is getting bigger. 

625
00:29:08,700 --> 00:29:11,400
There is the straight line that 
can be drawn about how many 

626
00:29:11,400 --> 00:29:14,700
calories, essentially, they need
to intake to take in to survive 

627
00:29:15,000 --> 00:29:17,600
and there's another straight 
line for how the infrastructure 

628
00:29:17,600 --> 00:29:21,500
in the city's expands as a city 
gets bigger, can you water pipes

629
00:29:21,500 --> 00:29:23,600
and much more water pipes? 
Do you need? 

630
00:29:23,700 --> 00:29:26,000
And it's a very similar straight
line with a very, very similar 

631
00:29:26,000 --> 00:29:28,300
experience and it's the same A 
companies as well. 

632
00:29:28,300 --> 00:29:31,100
And Company, growth revenue is 
the same and all of these 

633
00:29:31,100 --> 00:29:34,400
different things appear to be 
related to a particular type of 

634
00:29:34,400 --> 00:29:37,600
network, a hierarchical network.
So water pipes and cities are 

635
00:29:37,600 --> 00:29:40,300
hierarchies in. 
Mammals it our circulatory 

636
00:29:40,300 --> 00:29:43,600
system is a hierarchy 
essentially for heart, down to 

637
00:29:43,600 --> 00:29:46,700
the quarries, in organizations, 
we have hierarchies of 

638
00:29:46,708 --> 00:29:50,000
information flow, right? 
So, where do ideas come from? 

639
00:29:50,000 --> 00:29:53,000
Well, is direction from from 
whether you orders in some 

640
00:29:53,000 --> 00:29:56,000
senses come from, and they tend 
to be hierarchies as well, 

641
00:29:56,000 --> 00:29:59,400
because as companies grow It 
tends to become easier to create

642
00:29:59,400 --> 00:30:03,300
a hierarchy which information 
trickles down through in the 

643
00:30:03,308 --> 00:30:06,200
same way that water flows 
through pipes in the city than 

644
00:30:06,200 --> 00:30:09,600
it is to do it any other way. 
But the interesting thing about 

645
00:30:09,600 --> 00:30:13,200
these hierarchical networks is 
that they all scale using what's

646
00:30:13,200 --> 00:30:16,300
called a sub linear scaling. 
Also this scale with its UB 

647
00:30:16,300 --> 00:30:19,200
exponentially. 
What that means is as you double

648
00:30:19,200 --> 00:30:23,000
the size of a city, you don't 
have to double the number of 

649
00:30:23,000 --> 00:30:25,400
water pipes. 
Instead, you get less, you have 

650
00:30:25,400 --> 00:30:27,300
to do less than that, and the 
same as you double. 

651
00:30:27,500 --> 00:30:29,500
Size of a metal. 
You don't have to double the 

652
00:30:29,500 --> 00:30:32,400
amount of calories intake in its
scales, less than that. 

653
00:30:32,500 --> 00:30:35,200
And it's the same for all those 
ations for physical 

654
00:30:35,200 --> 00:30:37,200
infrastructure. 
As you double the size of an 

655
00:30:37,200 --> 00:30:39,600
office, the network cables are 
double, right? 

656
00:30:39,600 --> 00:30:43,200
I mean, it's the infrastructure 
in the office, doesn't double. 

657
00:30:43,600 --> 00:30:46,200
This is what we call or 
columnist, call economies of 

658
00:30:46,200 --> 00:30:48,700
scale. 
So, as you get bigger, you pay 

659
00:30:48,700 --> 00:30:52,400
less for things essentially, and
all of these complex systems 

660
00:30:52,400 --> 00:30:55,700
exhibit these behaviors. 
But it does also implies the 

661
00:30:55,700 --> 00:30:58,800
other things employers. 
The fact that things slow down 

662
00:30:58,800 --> 00:31:01,500
right things, move more slowly 
when you have deeper 

663
00:31:01,500 --> 00:31:05,600
hierarchies. 
So humans experience, life more 

664
00:31:05,600 --> 00:31:08,900
slowly than a marriage does. 
And it's down to a mathematical 

665
00:31:08,900 --> 00:31:12,300
relationship related to the 
death of our civil HP system 

666
00:31:12,300 --> 00:31:15,700
compared to the depth of the 
circulatory system of most all 

667
00:31:15,700 --> 00:31:17,500
seems to be explainable that 
way. 

668
00:31:17,500 --> 00:31:20,300
Anyway, I should say science, we
might find something else out. 

669
00:31:20,400 --> 00:31:23,500
And similarly, with cities have 
cities, get bigger. 

670
00:31:23,600 --> 00:31:24,700
The higher Arc is give us 
anything. 

671
00:31:24,900 --> 00:31:27,000
And then the issue thing is with
companies, I what happens with 

672
00:31:27,000 --> 00:31:30,300
clump, I think we experienced 
this in our everyday lives here.

673
00:31:30,300 --> 00:31:33,600
If you work for a big copy as 
you get bigger, things do get 

674
00:31:33,600 --> 00:31:36,800
slower, we do experienced this 
personally day today, you do 

675
00:31:36,800 --> 00:31:41,600
individually day today but also 
you can see it in the things 

676
00:31:41,600 --> 00:31:44,200
like the results that public 
companies Post in terms of 

677
00:31:44,200 --> 00:31:47,100
Revenue and so on. 
So as a company doubles in Size,

678
00:31:47,100 --> 00:31:49,000
Doesn't double the amount of 
Revenue. 

679
00:31:49,300 --> 00:31:53,400
Interestingly, the other thing 
is like, mammals companies die 

680
00:31:53,600 --> 00:31:56,700
all the time and this is another
fascinating similarity between 

681
00:31:56,700 --> 00:31:59,600
the two which It is also 
expandable via these lobbyists, 

682
00:31:59,600 --> 00:32:02,600
your own complexity science, 
complex adaptive systems, so has

683
00:32:02,600 --> 00:32:05,300
mammals get older as we get 
older we're taking the same 

684
00:32:05,300 --> 00:32:08,900
number of calories but we're 
having to direct more and more 

685
00:32:08,900 --> 00:32:11,900
of those categories to 
self-repair to repairing 

686
00:32:11,900 --> 00:32:14,700
ourselves rather than you know 
vigorously youth without having 

687
00:32:14,700 --> 00:32:16,800
to do that. 
And so therefore we slow down 

688
00:32:17,000 --> 00:32:20,100
the age, things like brain down 
and eventually we passed away. 

689
00:32:20,700 --> 00:32:23,200
Seems like companies do the same
thing with something interesting

690
00:32:23,200 --> 00:32:26,300
facts in the book scale. 
Think it's the half-life of a 

691
00:32:26,308 --> 00:32:30,300
company on the stage. 
Is 10 years, so every 10 years, 

692
00:32:30,300 --> 00:32:33,200
50 percent of the companies and 
the exchanges will change. 

693
00:32:33,400 --> 00:32:35,900
So as I say, there's all these 
interesting things that seem to 

694
00:32:35,900 --> 00:32:39,400
be related to hierarchy things. 
Slowing down, things taking 

695
00:32:39,400 --> 00:32:43,000
longer as things get older. 
And so on, which I thought was 

696
00:32:43,000 --> 00:32:44,800
really interesting. 
Right, because in my experience,

697
00:32:44,800 --> 00:32:48,000
when you plot out, things like 
development, life cycle is like,

698
00:32:48,000 --> 00:32:50,200
you look at the big old 
organization. 

699
00:32:50,500 --> 00:32:52,700
You look at the software 
development lifecycle you drop 

700
00:32:52,700 --> 00:32:55,800
that as a value stream map, 
you'll end up with these huge 

701
00:32:55,800 --> 00:32:58,900
long processes, right? 
Massive, where you've got like 

702
00:32:58,900 --> 00:33:03,700
it takes a year from an idea to 
get even to the project 

703
00:33:03,700 --> 00:33:06,600
management function to be able 
to see scheduled to have some 

704
00:33:06,600 --> 00:33:08,700
work done, right? 
Because bouncing around between 

705
00:33:08,700 --> 00:33:11,500
different review, board bouncing
between different architecture 

706
00:33:11,500 --> 00:33:13,600
groups and the technical 
business analysis. 

707
00:33:13,600 --> 00:33:15,300
This is the business analysis at
La one. 

708
00:33:15,300 --> 00:33:17,500
Never know what? 
Any of these things me then you 

709
00:33:17,500 --> 00:33:20,200
hit development and then maybe 
some development gets double. 

710
00:33:20,200 --> 00:33:23,400
It takes however long, it takes 
and then it pops out into some 

711
00:33:23,400 --> 00:33:27,900
really long involved process of 
testing, you know, Testing and 

712
00:33:27,908 --> 00:33:29,700
user acceptance. 
Testing regression testing 

713
00:33:29,700 --> 00:33:33,300
performance testing there until 
you eventually production and 

714
00:33:33,300 --> 00:33:37,200
you see this in every old, big 
traditional company that I visit

715
00:33:37,200 --> 00:33:40,500
conversely, if you look at 
younger companies, often they 

716
00:33:40,500 --> 00:33:45,100
don't usually they have much 
shorter time to market, right? 

717
00:33:45,100 --> 00:33:48,400
They're much more able to be 
much more Innovative because the

718
00:33:48,400 --> 00:33:52,200
time it takes for idea to go 
from in someone's head that 

719
00:33:52,200 --> 00:33:56,200
information passing through a 
series of process steps to make 

720
00:33:56,200 --> 00:33:59,000
it may. 
Tends to be much shorter and 

721
00:33:59,000 --> 00:34:00,700
slowly over time. 
There's this thing that 

722
00:34:00,700 --> 00:34:03,700
companies are add all these 
processes, these constraints, 

723
00:34:03,800 --> 00:34:06,800
they add hierarchy to manage all
this constraints and all these 

724
00:34:06,800 --> 00:34:09,100
processes and things start 
slowing down. 

725
00:34:09,400 --> 00:34:12,699
There's also another interesting
idea that larger organizations 

726
00:34:12,699 --> 00:34:15,199
do the same thing. 
Bigger older organizations 

727
00:34:15,199 --> 00:34:17,699
rather do the same thing that 
happens with mammals where they 

728
00:34:17,699 --> 00:34:22,000
have to spend more of their 
revenue on keeping the company 

729
00:34:22,000 --> 00:34:24,199
running. 
In the same way that, as we get 

730
00:34:24,199 --> 00:34:27,600
older, we spend more of the 
color if it intake on Ariel 

731
00:34:27,600 --> 00:34:31,600
cells companies, they spend more
money on just being the company.

732
00:34:31,699 --> 00:34:34,199
Whereas at the start, they were 
spending money on Innovation and

733
00:34:34,199 --> 00:34:37,300
products, and people and all 
this cool stuff and that's why 

734
00:34:37,300 --> 00:34:40,100
they were successful. 
Eventually, they end up in this 

735
00:34:40,100 --> 00:34:42,500
position where they're spending.
So much just keeping themselves 

736
00:34:42,500 --> 00:34:44,400
going. 
They stop thinking about 

737
00:34:44,400 --> 00:34:47,400
Innovation or innovation becomes
hard R and D becomes hard. 

738
00:34:47,400 --> 00:34:49,300
I've got this great idea but I 
don't know where to put it 

739
00:34:49,300 --> 00:34:51,199
because there's no one 
interested in me. 

740
00:34:51,199 --> 00:34:53,900
Because planning, everything 
you've got on, will be rude to 

741
00:34:53,900 --> 00:34:56,300
say marketing, I don't know. 
But yeah, that's the own 

742
00:34:56,300 --> 00:34:58,700
observations but the The issue 
thing is you coming back to what

743
00:34:58,700 --> 00:35:00,900
I was saying earlier, the two 
types of network it appears, 

744
00:35:00,900 --> 00:35:03,400
there's another type of network 
which in the natural world is 

745
00:35:03,400 --> 00:35:06,600
associated with a different type
of scaling or something called 

746
00:35:06,600 --> 00:35:09,800
super linear scaling. 
So, super linear scaling is when

747
00:35:09,800 --> 00:35:11,500
you're in advance of exponential
growth. 

748
00:35:11,700 --> 00:35:14,500
So as you double the amount of 
one thing, as you double the 

749
00:35:14,500 --> 00:35:16,800
number of people, you get more 
than double the revenue. 

750
00:35:17,000 --> 00:35:20,300
For example, and in the cities, 
cities are another example of 

751
00:35:20,300 --> 00:35:23,200
social networks, massive, social
networks exist, should people 

752
00:35:23,200 --> 00:35:26,300
communicating as you double the 
size of a city, you would get 

753
00:35:26,300 --> 00:35:29,900
more than double The amount of 
socio-economic things out of it.

754
00:35:29,900 --> 00:35:32,600
So you get more than double The 
Innovation. 

755
00:35:32,700 --> 00:35:35,900
You get more than double wage 
growth, other effects negative 

756
00:35:35,900 --> 00:35:39,400
effects to get more than double 
Prime pollution disease, these 

757
00:35:39,400 --> 00:35:42,200
things, right? 
And all these super linear 

758
00:35:42,200 --> 00:35:46,900
scaling super linear factors are
related to these social 

759
00:35:46,900 --> 00:35:49,500
networks. 
So people talking with people, I

760
00:35:49,500 --> 00:35:52,300
like to sort of explain it in 
the sense that if you live in a 

761
00:35:52,308 --> 00:35:55,600
village of 150 people, right? 
And I'm a software developer. 

762
00:35:55,800 --> 00:35:58,700
I live in a village of 150. 
People, how many other software 

763
00:35:58,700 --> 00:36:01,200
developers live in that Village 
for me to commit to, on a 

764
00:36:01,200 --> 00:36:04,200
professional level? 
Maybe one, who knows maybe more 

765
00:36:04,200 --> 00:36:07,100
than one these days, but 
probably not that many. 

766
00:36:07,500 --> 00:36:10,600
Whereas, if you go to, Yo, 
Sydney, there's a thousand 

767
00:36:10,600 --> 00:36:14,100
people just at the, I've Sydney 
talking about Innovation, 

768
00:36:14,100 --> 00:36:16,700
talking about bootstrapping each
other's ideas. 

769
00:36:16,900 --> 00:36:19,700
Like the original conference. 
I went to, and we talked about 

770
00:36:19,700 --> 00:36:22,900
right at the start of this, that
boot strapped on my ride is so 

771
00:36:22,900 --> 00:36:25,300
you get a bigger city. 
As you get bigger places where 

772
00:36:25,300 --> 00:36:28,600
more people live people tend to 
Together we'd like addressed. 

773
00:36:28,600 --> 00:36:30,800
All right, so you get this 
bootstrapping effect where 

774
00:36:30,800 --> 00:36:32,300
people with like interests get 
together. 

775
00:36:32,500 --> 00:36:34,800
That's true for not just 
software and cool stuff with 

776
00:36:34,800 --> 00:36:37,200
Innovation software. 
You get more than doubled, the 

777
00:36:37,200 --> 00:36:39,200
number of lawyers in bigger 
cities, right? 

778
00:36:39,300 --> 00:36:42,400
You get more than double the 
number of accountants, etc, etc.

779
00:36:42,700 --> 00:36:45,400
And it related to these social 
violence, these social network 

780
00:36:45,400 --> 00:36:48,900
graphs for me, that's a really 
interesting observation that we 

781
00:36:48,900 --> 00:36:51,400
know mathematically there's this
relationship. 

782
00:36:51,600 --> 00:36:55,100
If you structure yourself, if 
information is allowed to flow 

783
00:36:55,100 --> 00:36:58,700
in a particular way, then you 
get Get like the whole is 

784
00:36:58,700 --> 00:37:00,100
greater than the sum of the 
parts. 

785
00:37:00,200 --> 00:37:03,300
If you like, you get more out of
than you think you should. 

786
00:37:03,600 --> 00:37:06,000
And if you structure yourself in
a different way, conversely, you

787
00:37:06,000 --> 00:37:08,900
get less act than you think you 
should information. 

788
00:37:08,900 --> 00:37:12,300
You know, if the information 
flows hierarchical E versus via 

789
00:37:12,300 --> 00:37:15,200
social network mathematically, 
there's a choice between the 

790
00:37:15,200 --> 00:37:16,700
two. 
So the question is, how to take 

791
00:37:16,700 --> 00:37:20,400
advantage of this, how to use 
this knowledge, to improve our 

792
00:37:20,400 --> 00:37:22,500
ability to get stuff done, 
because that's really what we 

793
00:37:22,500 --> 00:37:25,100
want to do. 
Not necessarily make more money,

794
00:37:25,300 --> 00:37:27,200
maybe it's save lives, maybe 
it's work. 

795
00:37:27,400 --> 00:37:31,500
Hospitals and organizing teams 
such that they're communicating 

796
00:37:31,500 --> 00:37:33,800
super effectively which they do 
incidentally. 

797
00:37:33,800 --> 00:37:36,300
Soon in the UK are constantly 
for the rest of the world. 

798
00:37:36,400 --> 00:37:39,100
Paul, maybe it's schools. 
How do we organize our schools 

799
00:37:39,100 --> 00:37:40,800
such that? 
We've got the right information 

800
00:37:40,800 --> 00:37:43,500
at the right time and stuff 
doesn't have to trickle down 

801
00:37:43,500 --> 00:37:47,100
slowly from above or if it's a 
big organization, how do we 

802
00:37:47,100 --> 00:37:49,400
organize ourselves? 
Such that people have got 

803
00:37:49,500 --> 00:37:53,100
everything they need within a 
short number of hops from them. 

804
00:37:53,500 --> 00:37:55,400
And this is why, you know, we 
took and go back to 

805
00:37:55,400 --> 00:37:57,100
microservices microservices at 
all. 

806
00:37:57,200 --> 00:38:00,000
About product teams, which have 
everything there. 

807
00:38:00,000 --> 00:38:02,600
You've got everything you need 
on your team to solve the 

808
00:38:02,607 --> 00:38:04,900
problem, right? 
So, we've all of your products 

809
00:38:04,900 --> 00:38:08,100
towards have been about a price,
which is it's the same idea and 

810
00:38:08,100 --> 00:38:09,500
it's related to Commerce law as 
well. 

811
00:38:09,500 --> 00:38:12,700
How do we avoid having to go 
outside our team? 

812
00:38:12,800 --> 00:38:16,700
Ask other people to do stuff for
us because that's from the 

813
00:38:16,700 --> 00:38:20,200
hierarchical way of doing things
and the observation are making 

814
00:38:20,200 --> 00:38:22,400
the talk. 
Of course, which was related to 

815
00:38:22,400 --> 00:38:26,200
me originally by someone at AWS 
wasn't that scary WS structures 

816
00:38:26,200 --> 00:38:28,700
themselves. 
These Any small independent 

817
00:38:28,700 --> 00:38:31,300
teams relying on Self Service 
infrastructure. 

818
00:38:31,700 --> 00:38:34,000
That's another key thing that I 
should talk about in terms of 

819
00:38:34,000 --> 00:38:36,600
microservices more there. 
So decoupled from one another 

820
00:38:36,700 --> 00:38:39,800
that they're able to add new 
things on the side super fast. 

821
00:38:40,000 --> 00:38:43,400
So their ability to spin up your
product teams is super quick. 

822
00:38:43,700 --> 00:38:45,700
Interestingly, we also sort of 
point out, don't know if you've 

823
00:38:45,700 --> 00:38:50,100
ever done much work with AWS 
but, you know, their apis you 

824
00:38:50,100 --> 00:38:52,900
could be using one set of apis. 
You look at different set of 

825
00:38:52,900 --> 00:38:54,800
products and they bear. 
No relation to one another 

826
00:38:54,800 --> 00:38:57,100
right, like the user experience 
that developer experience it 

827
00:38:57,200 --> 00:39:00,400
Across the different products is
very different, but that's 

828
00:39:00,400 --> 00:39:03,700
deliberate, it's not deliberate 
per se, as if we want things to 

829
00:39:03,707 --> 00:39:06,400
be different, but it's 
deliberate in the sense is we're

830
00:39:06,400 --> 00:39:09,400
not going to pay the 
coordination cost to make our 

831
00:39:09,400 --> 00:39:12,300
apis consistent because the 
coordination costs is going to 

832
00:39:12,300 --> 00:39:15,100
slow us down. 
So with allow the teams to be 

833
00:39:15,100 --> 00:39:18,200
independent and that means we 
have to put up with the fact 

834
00:39:18,400 --> 00:39:21,100
that the developer experience 
isn't going to be potentially 

835
00:39:21,300 --> 00:39:23,800
the best, which of course has 
interesting implications for 

836
00:39:23,808 --> 00:39:28,000
things like micro front ends or 
how do you build Those apps that

837
00:39:28,000 --> 00:39:31,000
are able to use multiple teams 
to deliver parts of an aircraft 

838
00:39:31,000 --> 00:39:34,500
parts of a website parts of the 
page or whatever it is retain 

839
00:39:34,500 --> 00:39:37,300
that experience because most 
organizations that they want 

840
00:39:37,300 --> 00:39:39,500
their brand to be relatable 
across the difference. 

841
00:39:39,500 --> 00:39:41,400
You don't want one the 
recommendations bit to look, 

842
00:39:41,400 --> 00:39:43,700
very different from the main 
product bit, but it means you 

843
00:39:43,700 --> 00:39:45,300
have to pay a coordination cost 
to do that. 

844
00:39:45,300 --> 00:39:48,700
I think that's the direct result
of some of this complexity song.

845
00:39:49,500 --> 00:39:52,700
Wow, so many interesting stuffs 
that you brought up here, right?

846
00:39:52,700 --> 00:39:55,200
So things from the type of 
networks that you have in the 

847
00:39:55,200 --> 00:39:58,100
organization, whether it's 
hierarchical social, Social so 

848
00:39:58,100 --> 00:40:01,400
amount of flow how much 
information trickle down easily.

849
00:40:01,500 --> 00:40:04,100
So one thing that I want to 
bring up first before we go into

850
00:40:04,100 --> 00:40:06,800
recommendations for all 
organizations or software teams 

851
00:40:06,800 --> 00:40:11,000
here many times actually, I also
read that software teams is also

852
00:40:11,000 --> 00:40:14,400
the analogies like it's also a 
complex adaptive system, right? 

853
00:40:14,500 --> 00:40:17,500
So for many people who may not 
be familiar with this term, they

854
00:40:17,500 --> 00:40:20,000
always think like okay it's just
another department within an 

855
00:40:20,000 --> 00:40:22,300
organization. 
You can just produce whatever 

856
00:40:22,300 --> 00:40:25,600
code that you can do and then 
just deployed but I think we all

857
00:40:25,600 --> 00:40:28,700
know as a software Engineers 
that Not that easy, right? 

858
00:40:28,800 --> 00:40:31,400
So there are a lot of things 
that actually going on and some 

859
00:40:31,400 --> 00:40:34,300
people actually call it complex 
adaptive system, maybe if you 

860
00:40:34,300 --> 00:40:37,500
can touch on a little bit and 
explain why we should also think

861
00:40:37,500 --> 00:40:40,200
that software engineering team 
or product engineering team is 

862
00:40:40,200 --> 00:40:44,200
also a complex adaptive system. 
Here are good question, what is 

863
00:40:44,200 --> 00:40:46,400
the definition of complex 
adaptive system, right? 

864
00:40:46,400 --> 00:40:48,700
I mean again from the center 
face-to-face, Ethel dollar 

865
00:40:48,700 --> 00:40:51,800
definition which is a complex 
adaptive systems, display four 

866
00:40:51,800 --> 00:40:55,200
characteristics. 
The first one is that inherently

867
00:40:55,200 --> 00:40:57,600
complex so that the whole is 
greater than In the sum of the 

868
00:40:57,607 --> 00:41:00,500
parts, that's the first thing. 
So for example, I normally 

869
00:41:00,500 --> 00:41:03,300
explain that by saying I am a 
complex adaptive system. 

870
00:41:03,400 --> 00:41:07,500
James, if you put James into a 
blender and came up with like, 

871
00:41:07,500 --> 00:41:09,500
James soup, that's not very nice
idea. 

872
00:41:09,700 --> 00:41:14,900
And then you pulled James soup 
into a James shaped jar, would 

873
00:41:14,900 --> 00:41:16,500
it be James? 
And the answer is no right now. 

874
00:41:16,508 --> 00:41:18,800
This is the interesting thing, 
this is why the history is 

875
00:41:18,800 --> 00:41:21,500
fascinating. 
It comes back to an old 

876
00:41:21,500 --> 00:41:23,300
physicist called Murray 
gell-mann. 

877
00:41:23,300 --> 00:41:25,900
He was fascinated by the idea of
pairing. 

878
00:41:26,000 --> 00:41:28,700
You get such From such 
Simplicity, he wrote a book 

879
00:41:28,700 --> 00:41:30,400
called The quark and the Jaguar,
right? 

880
00:41:30,400 --> 00:41:33,500
How do you get something as 
complex as a Jackie or from 

881
00:41:33,500 --> 00:41:35,600
something as simple as a 
subatomic particle pulled 

882
00:41:35,600 --> 00:41:38,300
acquire right? 
What makes a j hero and what 

883
00:41:38,300 --> 00:41:39,900
makes a human? 
What makes a team or 

884
00:41:39,900 --> 00:41:42,200
organization or city? 
So this is idea of complexity, 

885
00:41:42,200 --> 00:41:43,300
right? 
The whole is greater than the 

886
00:41:43,308 --> 00:41:45,000
sum of the parts. 
There's also this idea of 

887
00:41:45,000 --> 00:41:48,200
emergent Behavior, so when we 
say measuring Behavior, would 

888
00:41:48,200 --> 00:41:52,900
mean that you can't reliably 
predict the outputs of a complex

889
00:41:52,900 --> 00:41:56,000
adaptive system from its inputs.
Every time it's not a functional

890
00:41:56,100 --> 00:41:59,600
problem where you can Say, given
this stimuli this thing will 

891
00:41:59,600 --> 00:42:01,400
always happen. 
Everything coming back to the 

892
00:42:01,400 --> 00:42:04,600
thing about teams which teams 
exhibit that behavior all the 

893
00:42:04,600 --> 00:42:05,200
time. 
All right? 

894
00:42:05,200 --> 00:42:09,200
You could never run the same 
situation, the same maybe even 

895
00:42:09,200 --> 00:42:12,200
use a story or Sprint twice, you
couldn't do it, you'd get 

896
00:42:12,200 --> 00:42:15,200
different outcomes if you buy it
a second time, the third 

897
00:42:15,200 --> 00:42:17,600
characteristic, is this idea 
that they're made up of self 

898
00:42:17,600 --> 00:42:20,100
similar parts. 
So in humans, the self 

899
00:42:20,100 --> 00:42:23,100
similarity is the cells. 
We are self-similar our cells 

900
00:42:23,100 --> 00:42:25,800
have self similar to one. 
Another actually in mammals, and

901
00:42:25,800 --> 00:42:27,000
this is where the scaling laws 
were. 

902
00:42:27,300 --> 00:42:30,100
Come from all cells are 
self-similar to you and Marcy 

903
00:42:30,100 --> 00:42:34,100
sell or to an elephant cell, 
will to a blue whale cell and on

904
00:42:34,100 --> 00:42:36,600
teams to self similarity, is the
people on the teams are 

905
00:42:36,600 --> 00:42:39,700
self-similar, we were not within
limits and then this idea of 

906
00:42:39,700 --> 00:42:42,200
self-organization. 
So there's no Central thing 

907
00:42:42,300 --> 00:42:45,700
telling a complex adaptive 
system, how to organize itself. 

908
00:42:45,900 --> 00:42:47,900
Mammals, in our cases, DNA, 
right? 

909
00:42:47,900 --> 00:42:50,600
There's nothing, when we're in 
the room that says, okay. 

910
00:42:50,600 --> 00:42:53,400
Now, build a heart. 
It just evolved over time, and 

911
00:42:53,400 --> 00:42:56,600
that happens According to some 
weird magical, biological 

912
00:42:56,600 --> 00:42:58,200
process. 
Yes, and there's obviously 

913
00:42:58,200 --> 00:42:59,600
similar to the teams are as 
well. 

914
00:42:59,800 --> 00:43:03,500
And so that's why I talk about 
teams being complex, adaptive 

915
00:43:03,500 --> 00:43:05,900
systems example, I used again, 
the Sprint thing. 

916
00:43:06,100 --> 00:43:08,900
If you just change one member of
a team, you've got a different 

917
00:43:08,900 --> 00:43:10,700
outcome. 
If one person is sick at a 

918
00:43:10,707 --> 00:43:12,700
different time, you get a 
different outcome. 

919
00:43:12,900 --> 00:43:15,700
If people pay or don't pay you 
get a different outcome, it's 

920
00:43:15,700 --> 00:43:18,600
almost like every single line of
codes could for, your could not 

921
00:43:18,600 --> 00:43:20,900
be written depending on so many 
different factors. 

922
00:43:21,000 --> 00:43:23,600
And that's why we talk about 
teams has been complex, adaptive

923
00:43:23,600 --> 00:43:25,800
systems, and of course, 
organizations are made up of 

924
00:43:25,800 --> 00:43:28,700
these components. 
Made up of these things. 

925
00:43:28,700 --> 00:43:31,700
So that organization is also a 
complex adaptive system. 

926
00:43:31,700 --> 00:43:35,000
Hope that someone else's look 
wet definitely and it's not just

927
00:43:35,000 --> 00:43:36,600
within internal, the team's 
themselves. 

928
00:43:36,600 --> 00:43:38,600
I think the external factors are
so, they are so many 

929
00:43:38,600 --> 00:43:40,800
complexities. 
What people call the vuca world,

930
00:43:40,800 --> 00:43:42,100
right? 
The disruptions the new 

931
00:43:42,100 --> 00:43:45,200
technologies that come as well. 
So I think all these play A Part

932
00:43:45,200 --> 00:43:47,500
as well, to make it much more 
complex. 

933
00:43:47,800 --> 00:43:51,800
So, coming back to the topic of 
how can organization avoid this 

934
00:43:51,800 --> 00:43:55,800
sub linear optimization growth. 
So, would you be able to suggest

935
00:43:55,800 --> 00:43:59,100
some things like How can we 
actually first identify? 

936
00:43:59,100 --> 00:44:01,300
If we are sharing a sign of 
Aging. 

937
00:44:01,300 --> 00:44:04,700
So things get slow down. 
Things are not flowing much much

938
00:44:04,700 --> 00:44:08,600
faster as when we are small and 
how she'll organization start to

939
00:44:08,600 --> 00:44:12,000
think about the more optimal way
to actually have this super 

940
00:44:12,000 --> 00:44:15,200
linear growth that you mentioned
for really great question. 

941
00:44:15,200 --> 00:44:18,200
And what we normally do is I 
told you that by saying hey I'm 

942
00:44:18,200 --> 00:44:20,200
just here to provide the 
information you can do with it 

943
00:44:20,200 --> 00:44:21,500
what you want. 
But actually that's not very 

944
00:44:21,500 --> 00:44:23,800
helpful at all, is it? 
I mean I do have in that talk 

945
00:44:23,800 --> 00:44:27,100
some concrete advice, right? 
Which is for example, you can 

946
00:44:27,100 --> 00:44:29,600
use Use the metrics from the 
door reports of the accelerate, 

947
00:44:29,600 --> 00:44:32,300
Burke the full key metrics. 
You should become very popular 

948
00:44:32,400 --> 00:44:35,100
rightly. 
So as indicators leading 

949
00:44:35,100 --> 00:44:37,000
indicators, actually of 
organizational health. 

950
00:44:37,300 --> 00:44:40,100
So you have the four key metrics
need time to Value. 

951
00:44:40,400 --> 00:44:42,700
They put a weird definition of 
lead time is from commits 

952
00:44:42,700 --> 00:44:45,100
through to production. 
Whereas real lead time is 

953
00:44:45,100 --> 00:44:48,400
actually from idea through Soup 
To Nuts, while don't be used to 

954
00:44:48,400 --> 00:44:51,000
lead, time to find mean, time to
recovery change the failure 

955
00:44:51,000 --> 00:44:53,300
rates and number of deploys per 
unit. 

956
00:44:53,300 --> 00:44:57,000
Time those things I think are 
really interesting to track now 

957
00:44:57,100 --> 00:44:59,600
Now, a lot of people then fall 
into the Trap of saying great, 

958
00:44:59,600 --> 00:45:02,200
you've got tools that will tell 
us this and then they spent 

959
00:45:02,200 --> 00:45:05,100
eight months trying to automate 
measurable, this stuff. 

960
00:45:05,300 --> 00:45:08,100
There's no need, right? 
We don't need Precision, we 

961
00:45:08,100 --> 00:45:11,400
don't need the Precision you get
from knowing on average we have 

962
00:45:11,400 --> 00:45:14,300
exactly 30 2.5 hours between 
each commit. 

963
00:45:14,500 --> 00:45:15,700
That's not what we're after 
here. 

964
00:45:15,700 --> 00:45:19,200
What we're after is saying, 
yeah, look, accuracy finger in 

965
00:45:19,207 --> 00:45:22,300
the air, your tea. 
Hello, why average does it take 

966
00:45:22,300 --> 00:45:24,300
to get stuff into production? 
That's good enough. 

967
00:45:24,600 --> 00:45:27,000
And as long as you track that 
somewhere and as long as, 

968
00:45:27,200 --> 00:45:30,000
Reflect on it. 
Maybe at the end of iteration or

969
00:45:30,000 --> 00:45:31,900
whatever it is. 
But you doing quarterly training

970
00:45:31,900 --> 00:45:34,100
or when you're okay, ours are 
being refused. 

971
00:45:34,300 --> 00:45:36,200
And you look at our we better or
worse. 

972
00:45:36,400 --> 00:45:37,800
That's what we're really looking
at. 

973
00:45:37,800 --> 00:45:39,800
You know, are we trending in the
right direction? 

974
00:45:40,100 --> 00:45:42,100
Save me, time to recovery same 
for the others. 

975
00:45:42,300 --> 00:45:45,300
We can use those Trends to work 
out which direction we're 

976
00:45:45,300 --> 00:45:46,000
heading. 
How are you? 

977
00:45:46,000 --> 00:45:49,800
Use the analogy from biology or 
Medicine of going to doctors? 

978
00:45:49,800 --> 00:45:52,400
Start general practitioners in 
the UK, they'll take your blood 

979
00:45:52,400 --> 00:45:56,000
pressure, your temperature, your
heart rate, that kind of stuff. 

980
00:45:56,200 --> 00:45:59,000
They'll know if There's 
something a bit dodgy going on. 

981
00:45:59,000 --> 00:46:00,500
Right? 
You got super high blood 

982
00:46:00,500 --> 00:46:03,200
pressure maybe there's an 
intervention that needs to be 

983
00:46:03,200 --> 00:46:06,600
Sage doesn't tell me exactly 
what the problem is but it might

984
00:46:06,600 --> 00:46:09,200
tell you there is an issue. 
Now there are a couple of 

985
00:46:09,200 --> 00:46:11,000
caveats to using the full key 
matter. 

986
00:46:11,000 --> 00:46:14,400
It dry before, key metrics are 
only going to be improvable to 

987
00:46:14,400 --> 00:46:16,400
the limit of the system, you 
find yourself it. 

988
00:46:16,400 --> 00:46:19,300
So, if you're in a deeply 
hierarchical organization with 

989
00:46:19,300 --> 00:46:22,300
these massive, long value 
streams to get stuff done. 

990
00:46:22,500 --> 00:46:24,800
You can optimize for key 
metrics, but you're only going 

991
00:46:24,800 --> 00:46:28,300
to be able to optimize to the 
limits imposed by System that's 

992
00:46:28,300 --> 00:46:29,700
long. 
Keeping I think that's kind of 

993
00:46:29,700 --> 00:46:31,600
interesting is that would be one
thing. 

994
00:46:31,900 --> 00:46:35,800
I think the other thing is this 
idea of signals when we have 

995
00:46:35,800 --> 00:46:38,300
some of this information, by how
we structure our self 

996
00:46:38,300 --> 00:46:42,600
fundamentally impacts performers
to such a degree, which we kind 

997
00:46:42,600 --> 00:46:45,100
of no, no based on a bunch of 
data that's out there in the 

998
00:46:45,100 --> 00:46:47,100
public to me. 
How do you take advantage and 

999
00:46:47,100 --> 00:46:49,400
how do we listen to signals from
our own organization. 

1000
00:46:49,400 --> 00:46:52,000
So that's one set of signals. 
I've just given you which is a 

1001
00:46:52,000 --> 00:46:56,900
full key metrics but the other 
thing is taking time setting, 

1002
00:46:57,100 --> 00:47:00,000
The organization up so that 
people in the organization can 

1003
00:47:00,000 --> 00:47:02,000
take the time to listen for the 
signals. 

1004
00:47:02,300 --> 00:47:05,200
Now I often these days, use the 
phrase that people are so busy. 

1005
00:47:05,200 --> 00:47:07,500
Doing the work. 
They don't have time to think 

1006
00:47:07,500 --> 00:47:09,900
about how the work Works. 
They don't have time to think 

1007
00:47:09,900 --> 00:47:12,200
about the system and optimize 
the system. 

1008
00:47:12,300 --> 00:47:14,600
These people are just head down,
just doing stuff, doing stuff, 

1009
00:47:14,600 --> 00:47:16,800
doing stuff all the time. 
And often that's actually why 

1010
00:47:16,800 --> 00:47:19,200
they hire people. 
I thought Works to come in right

1011
00:47:19,200 --> 00:47:22,200
because we come up with tool box
with a bunch of techniques. 

1012
00:47:22,200 --> 00:47:24,200
We can say hey we'll build you 
this value stream map. 

1013
00:47:24,200 --> 00:47:26,900
Now we can optimize it, I 
probably shouldn't say this. 

1014
00:47:27,100 --> 00:47:30,600
Secret, there's no reason that 
you for example Henry films do 

1015
00:47:30,600 --> 00:47:34,100
the same thing with the same 
tools, it's just that often we 

1016
00:47:34,100 --> 00:47:36,200
don't have time to do that 
ourselves, you know, because 

1017
00:47:36,200 --> 00:47:37,700
we're so busy doing other 
things. 

1018
00:47:37,700 --> 00:47:40,800
So that will be the other piece 
of advice I would give is spend 

1019
00:47:40,800 --> 00:47:44,700
some time looking at the system,
in which you were understand how

1020
00:47:44,700 --> 00:47:47,900
the work is working. 
Understand how flow is for your 

1021
00:47:47,900 --> 00:47:51,000
organization and then you can 
work to optimize that you can 

1022
00:47:51,000 --> 00:47:52,400
find. 
You can look at where those 

1023
00:47:52,400 --> 00:47:54,700
hierarchies are the 
informational hierarchies. 

1024
00:47:54,700 --> 00:47:56,700
It might not be on the 
orchestra, it might be in the 

1025
00:47:56,700 --> 00:47:58,800
valley. 
Streamers and work to change 

1026
00:47:58,800 --> 00:48:00,600
that. 
And one thing I think I 

1027
00:48:00,600 --> 00:48:03,600
mentioned it briefly, I think 
one thing that is often 

1028
00:48:03,600 --> 00:48:07,800
overlooked is self-service and 
why self-service is so powerful 

1029
00:48:08,500 --> 00:48:11,600
because as I mentioned the 
problem with hierarchies is you 

1030
00:48:11,600 --> 00:48:14,200
tricking information one way and
often by have to ask someone to 

1031
00:48:14,207 --> 00:48:17,500
get something done and waiting 
on someone else doing some work,

1032
00:48:17,500 --> 00:48:19,600
right? 
That's kind of like blocking my 

1033
00:48:19,600 --> 00:48:22,900
flow broking my circulatory 
system in this Century. 

1034
00:48:23,100 --> 00:48:25,600
So how do we make those systems 
such that their cell service? 

1035
00:48:25,600 --> 00:48:29,100
So I don't ask someone to do 
Something for me, instead, they 

1036
00:48:29,100 --> 00:48:32,400
provide that in a self-service 
way and that's what's so 

1037
00:48:32,400 --> 00:48:36,600
powerful that AWS is that they 
recognize that by providing the 

1038
00:48:36,600 --> 00:48:39,300
undifferentiated, heavy lifting 
was the original term. 

1039
00:48:39,300 --> 00:48:42,700
They use all the stuff that the 
original AWS platform did when 

1040
00:48:42,700 --> 00:48:45,300
they provide that self-service, 
they solve a couple of problems.

1041
00:48:45,400 --> 00:48:48,200
The first is you have to wait on
anyone to get stuff done. 

1042
00:48:48,400 --> 00:48:49,900
All right. 
So that's a flow Improvement 

1043
00:48:49,900 --> 00:48:52,500
problem and the other thing is 
you solve the problem of scarce 

1044
00:48:52,500 --> 00:48:55,000
resource because it's queuing 
Theory, right? 

1045
00:48:55,100 --> 00:48:58,900
If you've got a request coming 
in, To a service into a queue 

1046
00:48:58,900 --> 00:49:02,500
rather and you've got one thing 
able to take that request off 

1047
00:49:02,500 --> 00:49:05,500
that you and processes. 
The only way it by adding 

1048
00:49:05,500 --> 00:49:08,300
another message in at the same 
rate, if you've got multiple 

1049
00:49:08,500 --> 00:49:11,600
producers feeding messages into 
a queue, then you have to have 

1050
00:49:11,600 --> 00:49:14,600
multiple consumers to process, 
the messages at the same range. 

1051
00:49:14,600 --> 00:49:17,200
Keep the cue from backing up. 
And it's the same with what we 

1052
00:49:17,200 --> 00:49:20,800
do is exactly the same as what 
we do when we are asking people 

1053
00:49:20,800 --> 00:49:23,500
to spin up the ends for us when 
we are asking another team to 

1054
00:49:23,500 --> 00:49:26,200
make a change for us. 
The only way for them to scale 

1055
00:49:26,300 --> 00:49:28,200
is for that. 
Team were asking to add more 

1056
00:49:28,200 --> 00:49:30,400
people, as they get more 
requests, they have to add more 

1057
00:49:30,400 --> 00:49:33,800
people, it's unsustainable. 
As we asked, cops to do more for

1058
00:49:33,800 --> 00:49:36,500
us, they have to add more people
and that's unsustainable. 

1059
00:49:36,800 --> 00:49:39,600
So, you invert the relationship 
and say, make these things 

1060
00:49:39,600 --> 00:49:42,100
self-service make providing 
infrastructure. 

1061
00:49:42,100 --> 00:49:45,000
Self-service make, providing 
changes self-service, things 

1062
00:49:45,000 --> 00:49:47,600
like develop a platform 
engineering teams, providing 

1063
00:49:47,600 --> 00:49:51,100
self-service access to tooling 
to release pipelines to 

1064
00:49:51,100 --> 00:49:54,400
databases on, demand, all that 
stuff, that's all about 

1065
00:49:54,400 --> 00:49:56,800
improving flow, but you don't 
get to see that. 

1066
00:49:57,000 --> 00:50:00,800
Really unless you are able to 
visualize your system, unless 

1067
00:50:00,800 --> 00:50:04,600
you're able to step back, take 
the time and understand where 

1068
00:50:04,600 --> 00:50:07,700
the blockage is, are where the 
cholesterol is building up in 

1069
00:50:07,700 --> 00:50:10,700
your arteries if you like. 
So, I think that's a very good 

1070
00:50:10,700 --> 00:50:12,600
reminder yet. 
Like you mentioned, right, when 

1071
00:50:12,600 --> 00:50:14,800
we are working in the 
organization in the team, we 

1072
00:50:14,800 --> 00:50:16,300
tend to just get things done, 
right? 

1073
00:50:16,300 --> 00:50:18,900
Okay, we have new features, we 
have new ideas, we have new, 

1074
00:50:18,900 --> 00:50:22,200
roadmaps, whatever that is, and 
we just get things done, and we 

1075
00:50:22,200 --> 00:50:25,100
just live with the same habit. 
Maybe let's put it this way. 

1076
00:50:25,100 --> 00:50:26,700
The same habit that we used to 
do. 

1077
00:50:26,700 --> 00:50:28,300
Right. 
Maybe it proves successful in 

1078
00:50:28,300 --> 00:50:30,700
the beginning and we just 
continuously do that without 

1079
00:50:30,700 --> 00:50:33,300
actually monitoring and review 
the system, right? 

1080
00:50:33,300 --> 00:50:36,600
How the system looks like after 
some time that we go through it.

1081
00:50:36,800 --> 00:50:38,700
So I think that's a good 
reminder to always look at the 

1082
00:50:38,700 --> 00:50:40,800
systems. 
Think about how we do the work, 

1083
00:50:40,800 --> 00:50:42,400
right? 
And I think the concept of 

1084
00:50:42,400 --> 00:50:45,100
platform teams, the self-service
thing, it goes back also to the 

1085
00:50:45,100 --> 00:50:47,900
team topologies, right? 
I think this work by Emanuel 

1086
00:50:47,900 --> 00:50:50,700
Pious and metal skeleton is 
really called it in everywhere. 

1087
00:50:50,700 --> 00:50:52,500
I think I would say, you know, 
the concept of for the 

1088
00:50:52,500 --> 00:50:55,800
Streamline team and the platform
team enabling team and things 

1089
00:50:55,800 --> 00:50:57,300
like that. 
So I think that's really good 

1090
00:50:57,300 --> 00:50:59,800
concept as well for people to 
look at how you can actually 

1091
00:50:59,800 --> 00:51:03,100
optimize your organization and 
you kept mentioning about flow, 

1092
00:51:03,100 --> 00:51:04,500
right? 
Optimizing flow. 

1093
00:51:04,600 --> 00:51:07,200
I think this is also, another 
thing that is really critical 

1094
00:51:07,200 --> 00:51:10,200
for organization to figure out 
how the flow in your team 

1095
00:51:10,200 --> 00:51:11,700
actually moves. 
Is it fast? 

1096
00:51:11,700 --> 00:51:14,000
Or is it slow? 
And we can use the key metrics 

1097
00:51:14,000 --> 00:51:16,500
from Dora as one indicator. 
It's not the true answer of 

1098
00:51:16,500 --> 00:51:19,000
everything and we don't have to 
be accurate so thanks for 

1099
00:51:19,000 --> 00:51:21,000
sharing that. 
So James unfortunately, due to 

1100
00:51:21,000 --> 00:51:22,700
time we have to wrap up pretty 
soon. 

1101
00:51:22,800 --> 00:51:25,300
I have one last question though 
which I would like to ask you 

1102
00:51:25,400 --> 00:51:28,300
which I call this a question 3. 
I think the leadership is Adam 

1103
00:51:28,600 --> 00:51:31,300
so you can think of it like an 
advice that you want to import 

1104
00:51:31,300 --> 00:51:34,200
for us here to learn from your 
experience and your expertise. 

1105
00:51:34,300 --> 00:51:36,600
So can you share maybe two or 
three technical leadership 

1106
00:51:36,600 --> 00:51:39,400
wisdom? 
Yeah, this is a big word, right?

1107
00:51:39,400 --> 00:51:42,100
And you may expect me to come up
with some deeply technical from 

1108
00:51:42,100 --> 00:51:44,200
a set of answers here. 
I'm going to go completely the 

1109
00:51:44,207 --> 00:51:46,000
other way, okay? 
These are three things that I've

1110
00:51:46,000 --> 00:51:48,100
learned from people who work 
within four weeks. 

1111
00:51:48,100 --> 00:51:52,000
And in particular, I want to 
call out and with what Daniel to

1112
00:51:52,000 --> 00:51:54,400
his North year because he's one 
of the people that I've really 

1113
00:51:54,400 --> 00:51:57,400
learned a lot for is a very, 
very wise person and The first 

1114
00:51:57,400 --> 00:52:00,500
thing is that empathy is a 
superpower, especially as you 

1115
00:52:00,508 --> 00:52:03,200
get more. 
Experienced being empathetic is 

1116
00:52:03,300 --> 00:52:07,000
absolutely key to getting things
done, I think from a personal 

1117
00:52:07,000 --> 00:52:10,600
perspective so much so that you 
know, I'll go back to 2008 2009 

1118
00:52:10,600 --> 00:52:13,800
with another team with them. 
It was when he wrote the article

1119
00:52:13,800 --> 00:52:17,500
that became the bdd article. 
It so just invented whatever it 

1120
00:52:17,500 --> 00:52:20,900
was he originated bdd Behavior 
driven development and in that 

1121
00:52:20,900 --> 00:52:23,900
it's all about being empathetic 
is all about understanding. 

1122
00:52:23,900 --> 00:52:26,900
Not just what your team needs, 
what you need, it's about. 

1123
00:52:27,000 --> 00:52:29,200
Understanding what your other 
stakeholders need that aren't 

1124
00:52:29,200 --> 00:52:32,000
just the business stakeholders 
that are, your stakeholders, in,

1125
00:52:32,000 --> 00:52:35,500
security, and operations, you've
Downstream or Upstream, folks. 

1126
00:52:35,900 --> 00:52:38,600
Within the large Apollo, the 
suffered, a long process, but 

1127
00:52:38,600 --> 00:52:41,200
empathy of this is all your 
empathy with the people you're 

1128
00:52:41,200 --> 00:52:42,900
working with. 
You don't know what's going on 

1129
00:52:42,900 --> 00:52:46,000
in people's lives often, and be 
their pathetic as a long way to 

1130
00:52:46,000 --> 00:52:47,600
creating a really fun 
environment. 

1131
00:52:47,600 --> 00:52:51,000
And that comes to my second 
piece of advice or maybe rather 

1132
00:52:51,000 --> 00:52:54,100
it's a statement and I would say
that seriousness does not equal 

1133
00:52:54,100 --> 00:52:56,900
professionalism the best 
projects I've ever. 

1134
00:52:56,900 --> 00:52:59,900
I worked on the most successful 
products have ever built the 

1135
00:52:59,900 --> 00:53:03,300
best teams I've worked in. 
They understood that seriousness

1136
00:53:03,300 --> 00:53:06,700
was not professionalism. 
Having fun makes a better team 

1137
00:53:06,800 --> 00:53:09,700
having a good time. 
Being empathetic with your 

1138
00:53:09,700 --> 00:53:12,000
colleagues, sharing good 
experiences. 

1139
00:53:12,300 --> 00:53:14,900
That makes the team pure as much
as anything else. 

1140
00:53:15,000 --> 00:53:17,300
I think we sometimes make the 
mistake that if we seem to be 

1141
00:53:17,300 --> 00:53:18,700
having a good time doing 
something. 

1142
00:53:18,900 --> 00:53:20,700
Then surely we're not doing it 
right, you know. 

1143
00:53:21,000 --> 00:53:24,400
But actually often I think it's 
completely the inverse so that 

1144
00:53:24,400 --> 00:53:26,900
would be my second one serious 
does not equal. 

1145
00:53:27,800 --> 00:53:30,200
And then the final one, which is
interesting, only, then this 

1146
00:53:30,200 --> 00:53:32,600
like awesome down doors. 
It comes from a conversation 

1147
00:53:32,600 --> 00:53:35,400
with you like gold, brass the 
great Management Consultant, who

1148
00:53:35,400 --> 00:53:37,800
wrote the goal and Beyond the 
goal, and a number of other 

1149
00:53:37,800 --> 00:53:39,600
books. 
And he was asked about it. 

1150
00:53:39,600 --> 00:53:43,700
Why organizations often fail at 
adopting new things, new ideas, 

1151
00:53:43,700 --> 00:53:45,900
new Innovations. 
And he says that in his 

1152
00:53:45,900 --> 00:53:49,000
experience, it's because there 
are four questions they need to 

1153
00:53:49,000 --> 00:53:51,300
ask, right? 
And they forget to ask when. 

1154
00:53:51,600 --> 00:53:53,700
So the four questions are, if 
you've got a new thing, whatever

1155
00:53:53,700 --> 00:53:56,500
that Innovation is microservices
Docker, kubernetes continuous 

1156
00:53:56,500 --> 00:53:58,200
delivery. 
You should ask yourself, okay, 

1157
00:53:58,300 --> 00:54:00,100
one of the cool things that this
thing gives. 

1158
00:54:00,500 --> 00:54:02,600
What can this unlock for my 
organization? 

1159
00:54:02,600 --> 00:54:05,500
If we adopt this Innovation is 
technology and the second 

1160
00:54:05,500 --> 00:54:09,300
question you should ask is OK, 
what current its limitations in 

1161
00:54:09,300 --> 00:54:11,600
the company? 
Will this new innovation help us

1162
00:54:11,600 --> 00:54:13,800
overcome? 
And then he says, you should 

1163
00:54:13,800 --> 00:54:18,100
then look and say, okay. 
What rules do we have to manage 

1164
00:54:18,100 --> 00:54:20,800
our existing limitations? 
And he says, when people adopt 

1165
00:54:20,800 --> 00:54:23,000
new technologies often what they
do is they stop there. 

1166
00:54:23,600 --> 00:54:26,600
So as an example, continuous 
delivery would be a good example

1167
00:54:26,600 --> 00:54:28,000
of this. 
When you adopting continuous 

1168
00:54:28,000 --> 00:54:30,200
delivery, that's going to give 
you the ability to speed your 

1169
00:54:30,200 --> 00:54:33,500
time to Market to the Ultimate 
Security audit, all these really

1170
00:54:33,500 --> 00:54:36,600
cool things built by quality 
etcetera, etc, etc. 

1171
00:54:37,100 --> 00:54:39,900
And what limitations do we 
currently have are we've got 

1172
00:54:39,900 --> 00:54:43,200
this massive manual testing 
process that we could, probably 

1173
00:54:43,200 --> 00:54:46,000
use continuous delivery would 
help shorten the amount of time 

1174
00:54:46,000 --> 00:54:48,000
it takes to do that, okay? 
And then they are all. 

1175
00:54:48,100 --> 00:54:51,000
What rules do we currently have?
Well, you know the rules are 

1176
00:54:51,000 --> 00:54:53,400
that you wanted to get into you,
80 years have to pass this 

1177
00:54:53,400 --> 00:54:56,600
barrier in order to integration.
Pass this thing about it. 

1178
00:54:56,900 --> 00:54:59,000
And so you adopt continuous 
delivery and the development 

1179
00:54:59,000 --> 00:55:02,200
teams, go super super fast, but 
you forget to ask the fourth 

1180
00:55:02,200 --> 00:55:04,600
question. 
What new rules do? 

1181
00:55:04,600 --> 00:55:08,100
We need and the new rules are 
the important bits because if we

1182
00:55:08,100 --> 00:55:11,300
try and marriage new stuff with 
the old rules, you don't get 

1183
00:55:11,300 --> 00:55:13,300
anywhere. 
So, in the continuous delivery 

1184
00:55:13,300 --> 00:55:16,800
case you can say, well, we'll 
manage our new features delivery

1185
00:55:16,800 --> 00:55:21,200
process, but using the same set 
of manual gates to get through 

1186
00:55:21,200 --> 00:55:23,400
to different environments, it 
doesn't matter if you've got a 

1187
00:55:23,408 --> 00:55:26,000
computer doing it, if it still 
takes you six weeks to get 

1188
00:55:26,000 --> 00:55:29,700
through, if you do Anything. 
So what are the new rules look 

1189
00:55:29,700 --> 00:55:32,700
for the new rules that you need 
and implement the new rules? 

1190
00:55:33,000 --> 00:55:35,900
That would be my third one. 
I've ever listened to this. 

1191
00:55:35,900 --> 00:55:38,500
Four key questions that you 
mentioned right whenever we want

1192
00:55:38,500 --> 00:55:40,800
to adopt new things. 
So thanks for sharing that and I

1193
00:55:40,808 --> 00:55:43,300
left the second one. 
Seriousness does not equal 

1194
00:55:43,300 --> 00:55:45,800
professionalism. 
So I think yeah, in some 

1195
00:55:45,800 --> 00:55:48,800
organizations they tend to want 
to be very strict and follow the

1196
00:55:48,800 --> 00:55:51,000
process. 
You always hit the target, 

1197
00:55:51,000 --> 00:55:53,400
right? 
But that doesn't always equate 

1198
00:55:53,400 --> 00:55:55,200
to professionalism. 
But you mentioned right? 

1199
00:55:55,200 --> 00:55:57,100
Or like we need to create fun. 
Fun. 

1200
00:55:57,200 --> 00:56:00,300
And I think when we work in a 
fun manner, I think people tend 

1201
00:56:00,300 --> 00:56:03,200
to try for, I tend to produce 
the best results. 

1202
00:56:03,700 --> 00:56:06,000
So James, I think it's really a 
great composition. 

1203
00:56:06,000 --> 00:56:08,200
I learned a lot. 
So if people want to continue 

1204
00:56:08,200 --> 00:56:10,700
the conversation and maybe 
connect with you, is there a 

1205
00:56:10,707 --> 00:56:13,700
place they can find you online. 
They're arming, the best place 

1206
00:56:13,700 --> 00:56:16,000
is probably very email. 
If you want to chat with me very

1207
00:56:16,000 --> 00:56:18,100
long dreams, don't leave 
yourself a full which to come. 

1208
00:56:18,300 --> 00:56:23,000
I'm also on Twitter at Boise be.
Oh, I see why I don't like data 

1209
00:56:23,000 --> 00:56:24,200
that. 
Use it that much. 

1210
00:56:24,300 --> 00:56:26,800
So those are probably the three 
places of the best. 

1211
00:56:27,200 --> 00:56:29,900
Thank you for this opportunity. 
James, I hope people also 

1212
00:56:29,900 --> 00:56:31,300
learned a lot from this 
conversation. 

1213
00:56:31,300 --> 00:56:33,600
So thank you again. 
We thank you so much variation, 

1214
00:56:33,600 --> 00:56:35,800
actually, pleasure talking with 
you and hopefully I'll get to 

1215
00:56:35,800 --> 00:56:37,700
see you in Australia again 
before too long. 

1216
00:56:38,100 --> 00:56:39,300
Yeah. 
Looking forward for that. 

1217
00:56:41,800 --> 00:56:45,100
Thank you for listening to this 
episode and for staying, right 

1218
00:56:45,100 --> 00:56:47,600
until the end if you highly 
enjoyed it. 

1219
00:56:47,800 --> 00:56:50,100
I would appreciate if you share 
it with your friends and 

1220
00:56:50,100 --> 00:56:53,100
colleagues who you think would 
also benefit from listening to 

1221
00:56:53,100 --> 00:56:55,100
this episode. 
And if you are new to the 

1222
00:56:55,100 --> 00:56:58,100
podcast, make sure to subscribe 
and leave me your valuable 

1223
00:56:58,100 --> 00:57:00,700
review and feedback. 
It helps me a lot. 

1224
00:57:00,700 --> 00:57:02,700
In order to grow this podcast 
better. 

1225
00:57:03,100 --> 00:57:06,000
You can also find the full show 
notes of this conversation on 

1226
00:57:06,000 --> 00:57:09,700
the episode page at technology 
Arnold death website, including 

1227
00:57:09,700 --> 00:57:13,500
the full transcript, In quotes 
and links to the resources 

1228
00:57:13,500 --> 00:57:17,500
mention from the conversation. 
And lastly, make sure to 

1229
00:57:17,500 --> 00:57:20,200
subscribe to the show's mailing 
list on pack leader know that 

1230
00:57:20,200 --> 00:57:23,300
deaf to get notified for any 
future episodes. 

1231
00:57:23,800 --> 00:57:26,200
Stay tuned for the next 
technology, no episode. 

1232
00:57:26,500 --> 00:57:28,200
And until then goodbye.