1
00:00:00,000 --> 00:00:03,400
Those are our four key metrics 
deployment, frequency the time 

2
00:00:03,400 --> 00:00:07,500
for changes change, failure rate
and your time to restore 

3
00:00:07,500 --> 00:00:10,500
service. 
Now, what we found as we looked 

4
00:00:10,500 --> 00:00:14,100
at those four metrics and what 
we found consistently over 

5
00:00:14,100 --> 00:00:16,800
throughout the course of the 
research study is that they are 

6
00:00:16,800 --> 00:00:19,400
trade-offs many organizations 
think. 

7
00:00:19,500 --> 00:00:23,800
In order to be safe, I have to 
be slow but the data shows us 

8
00:00:23,800 --> 00:00:27,400
that the best performers are 
getting both and in fact as 

9
00:00:27,400 --> 00:00:30,300
speed increases so too does. 
T. 

10
00:00:34,900 --> 00:00:38,200
Hey everyone. 
My name is Henry Surya Barragan.

11
00:00:40,000 --> 00:00:43,600
And you're listening to the 
tekhelet Juno, the show will be 

12
00:00:43,600 --> 00:00:46,900
bringing you the greatest 
technical leaders practitioners 

13
00:00:47,100 --> 00:00:50,500
and thought leaders in the 
industry to discuss about their 

14
00:00:50,500 --> 00:00:55,300
Journey ideas and practices that
we all can learn and apply to 

15
00:00:55,300 --> 00:00:58,200
build a highly performing 
technical team and to make an 

16
00:00:58,200 --> 00:01:02,800
impact in your personal work. 
So let's dive into our Journal. 

17
00:01:08,200 --> 00:01:10,100
Hello. 
Hello to all of you, my friends.

18
00:01:10,100 --> 00:01:12,200
I hope that you're feeling great
and healthy today. 

19
00:01:12,700 --> 00:01:15,100
Welcome to another new episode 
of the technology on our 

20
00:01:15,100 --> 00:01:17,400
podcast. 
Thank you for tuning in and 

21
00:01:17,400 --> 00:01:20,200
listening to this episode. 
If you are new to technology, 

22
00:01:20,200 --> 00:01:23,200
you know, I invite you to 
subscribe and follow the show on

23
00:01:23,200 --> 00:01:26,800
your podcast app or I will 
growing social media communities

24
00:01:26,900 --> 00:01:29,100
on LinkedIn, Twitter, and 
Instagram. 

25
00:01:29,500 --> 00:01:31,900
And if you have been regularly 
listening, and enjoying this 

26
00:01:31,900 --> 00:01:35,800
podcast, and love the type of 
content that I'm producing, Will

27
00:01:35,800 --> 00:01:38,600
you support the show by 
subscribing as a patron at 

28
00:01:38,600 --> 00:01:41,800
technology? 
Not Dev slash Patron and support

29
00:01:41,800 --> 00:01:43,900
my journey to produce great 
episode. 

30
00:01:43,900 --> 00:01:46,900
Every week state of devops 
report. 

31
00:01:47,100 --> 00:01:49,900
Many of you may have heard about
this report which has been 

32
00:01:49,900 --> 00:01:52,100
running for over the past seven 
years. 

33
00:01:52,500 --> 00:01:55,100
It is the largest and 
longest-running research that 

34
00:01:55,100 --> 00:01:59,000
aims to provide data driven 
industry, insights, that examine

35
00:01:59,000 --> 00:02:03,300
the capabilities and practices 
that drive software delivery as 

36
00:02:03,300 --> 00:02:05,200
well as operational and 
organizational. 

37
00:02:05,300 --> 00:02:08,500
Final performance. 
My guest for today's episode is 

38
00:02:08,500 --> 00:02:11,800
Nathan Harvey. 
Nathan is a developer Advocate 

39
00:02:11,800 --> 00:02:16,100
at Google, a part of the Google 
Cloud Dora research team and the

40
00:02:16,100 --> 00:02:20,100
co-author of the 2021 accelerate
state of devops report. 

41
00:02:20,500 --> 00:02:23,300
He was also the editor for the 
97 things. 

42
00:02:23,400 --> 00:02:26,900
Every cloud engineer should 
know, published by O'Reilly in 

43
00:02:26,900 --> 00:02:31,100
2020. 
In this episode, we discussed in

44
00:02:31,100 --> 00:02:35,000
depth, the latest release of the
state of devops report, Nathan 

45
00:02:35,000 --> 00:02:37,800
started by describing what the 
report is all about, 

46
00:02:37,900 --> 00:02:41,600
historically, how it got started
and what problems it was trying 

47
00:02:41,600 --> 00:02:45,600
to solve and then he explained 
the famous five key metrics 

48
00:02:45,700 --> 00:02:48,700
suggested by the report to 
measure the software delivery 

49
00:02:48,800 --> 00:02:52,800
and operational performance, 
Nathan then explained how the 

50
00:02:52,800 --> 00:02:55,900
report categorises different 
Performance Based on their 

51
00:02:55,900 --> 00:02:57,800
performance against the key 
metrics? 

52
00:02:58,000 --> 00:03:01,700
And how the Elite Performance, 
outperform the others in terms 

53
00:03:01,700 --> 00:03:04,400
of speed, stability and 
reliability. 

54
00:03:05,200 --> 00:03:07,900
Next, we dived into several new 
key findings. 

55
00:03:07,900 --> 00:03:12,000
That came out of the 2021 report
that relate to the importance of

56
00:03:12,000 --> 00:03:15,300
good documentation. 
Secure software, supply chain 

57
00:03:15,600 --> 00:03:18,800
and positive team culture. 
That mitigates Bernard during 

58
00:03:18,800 --> 00:03:23,100
challenging circumstances, like 
the pandemic towards the end, 

59
00:03:23,300 --> 00:03:26,900
Nathan gave great tips on how we
can use the findings from the 

60
00:03:26,900 --> 00:03:30,600
reports, not just the latest, 
Report on how we can all get 

61
00:03:30,600 --> 00:03:33,700
started and improve our software
delivery, and operational 

62
00:03:33,700 --> 00:03:36,200
performance. 
That ultimately will also 

63
00:03:36,200 --> 00:03:39,100
improve our organizational 
performance as a whole. 

64
00:03:40,000 --> 00:03:43,100
I really enjoyed my conversation
with Nathan learning about the 

65
00:03:43,100 --> 00:03:46,400
accelerate state of devops 
report, the five key metrics, 

66
00:03:46,400 --> 00:03:49,500
and the new key findings that we
can find in the latest 2021 

67
00:03:49,500 --> 00:03:51,600
report. 
And if you also enjoyed this 

68
00:03:51,600 --> 00:03:55,100
episode, I encourage you to 
share it to someone, you know, 

69
00:03:55,200 --> 00:03:58,500
who would also benefit from it. 
You can also leave a rating and 

70
00:03:58,700 --> 00:04:01,700
View on your podcast app or 
share some comments on the 

71
00:04:01,700 --> 00:04:04,700
social media on what you enjoy 
from this episode. 

72
00:04:04,900 --> 00:04:07,600
I always love reading your 
reviews and comments and they 

73
00:04:07,600 --> 00:04:10,500
are one of the best ways to help
me spread this podcast to more 

74
00:04:10,500 --> 00:04:12,800
people. 
And it is my hope that it can 

75
00:04:12,800 --> 00:04:16,800
also benefit from this podcast. 
Let's get our episode started 

76
00:04:16,899 --> 00:04:20,399
right after our sponsor message.
Are you looking for a new cool 

77
00:04:20,399 --> 00:04:22,000
swag? 
Taglit Journal. 

78
00:04:22,000 --> 00:04:25,200
Now offers you some swags that 
you can purchase online? 

79
00:04:25,600 --> 00:04:29,600
These wax are printed on demand 
based on your Reference and will

80
00:04:29,600 --> 00:04:33,000
be delivered safely to you all 
over the world where shipping is

81
00:04:33,000 --> 00:04:35,300
available. 
Check out all the cool tracks 

82
00:04:35,300 --> 00:04:38,200
available by visiting 
technology, you know, dot, f / 

83
00:04:38,200 --> 00:04:40,600
shop, and don't forget to break 
yourself. 

84
00:04:40,700 --> 00:04:46,200
Once you receive any of those 
tracks, hello everyone. 

85
00:04:46,200 --> 00:04:48,600
Welcome back to another episode 
of the technology, you know, 

86
00:04:48,600 --> 00:04:50,600
podcast. 
Today I have with me, a 

87
00:04:50,600 --> 00:04:54,700
developer relations at Google. 
His name is Nathan Harvey. 

88
00:04:54,900 --> 00:04:58,500
He's actually one of the 
co-author of the latest state of

89
00:04:58,700 --> 00:05:01,400
But 2021. 
So if you are not aware about 

90
00:05:01,400 --> 00:05:04,100
state of their jobs report today
we'll be covering a lot about 

91
00:05:04,100 --> 00:05:05,800
it. 
Talk about what are the latest 

92
00:05:05,800 --> 00:05:08,700
findings as well. 
Nathan is also, someone who is 

93
00:05:08,700 --> 00:05:10,900
experienced in develops, a 
sorry. 

94
00:05:11,200 --> 00:05:13,800
So, he'll be talking a lot. 
Probably from his experience as 

95
00:05:13,800 --> 00:05:16,400
well. 
And he's also an editor for the 

96
00:05:16,400 --> 00:05:18,800
97 things. 
Every car engineer should know 

97
00:05:19,000 --> 00:05:21,800
which is published in 2020. 
So, welcome to the show. 

98
00:05:21,800 --> 00:05:24,400
Nathan looking forward to have 
this discussion with you about 

99
00:05:24,400 --> 00:05:27,300
state of devops report. 
Oh, thank you so much, Henry, 

100
00:05:27,300 --> 00:05:30,300
and I'm really happy to be here.
So Nathan in the beginning. 

101
00:05:30,300 --> 00:05:33,100
Maybe if you can introduce 
yourself sharing more about your

102
00:05:33,100 --> 00:05:34,900
highlights or turning points in 
your career. 

103
00:05:35,600 --> 00:05:36,900
Yeah, for sure. 
Thanks. 

104
00:05:36,900 --> 00:05:38,800
As Henry mentioned. 
My name is Nick and Harvey our 

105
00:05:38,800 --> 00:05:41,500
developer relations engineer 
here with Google Cloud. 

106
00:05:41,600 --> 00:05:44,900
Some highlights of my career. 
Well, it's been a long career, 

107
00:05:44,900 --> 00:05:47,300
for sure. 
I would say, the couple of quick

108
00:05:47,300 --> 00:05:50,200
highlights. 
I really look at my career, as a

109
00:05:50,200 --> 00:05:53,600
career, where I've tried to help
teams improve the work that 

110
00:05:53,600 --> 00:05:56,600
they're doing, sometimes that 
means helping teams improve the 

111
00:05:56,600 --> 00:06:00,200
work that we are doing for, 
Example, I've worked with many 

112
00:06:00,200 --> 00:06:03,600
different web applications. 
Well actually, one of the first 

113
00:06:03,600 --> 00:06:07,100
applications I was responsible 
for Henry, we called it the 

114
00:06:07,100 --> 00:06:11,000
customer and partner Extranet. 
Do you know what an Extranet is?

115
00:06:11,200 --> 00:06:14,800
It's basically a website, but 
you have to login to get to it 

116
00:06:14,900 --> 00:06:17,900
in the late 90s, early 2000, it 
was mine. 

117
00:06:17,900 --> 00:06:21,300
Breaking that we would have 
these things on the web for 

118
00:06:21,300 --> 00:06:23,600
customer. 
So, I've been a lead engineer on

119
00:06:23,600 --> 00:06:26,700
a project like that I've helped 
an organization. 

120
00:06:26,700 --> 00:06:30,600
A team that I was on really at 
adopt automation practices 

121
00:06:30,800 --> 00:06:34,100
moving things from data centers 
into the cloud. 

122
00:06:34,500 --> 00:06:36,200
One. 
Turning point that I have is I'm

123
00:06:36,200 --> 00:06:39,100
working at this huge software 
company at the time. 

124
00:06:39,100 --> 00:06:43,100
I was responsible for managing 
our sales force automation tool 

125
00:06:43,200 --> 00:06:46,300
which happen to be a product 
called siebel back in the day 

126
00:06:46,500 --> 00:06:51,100
and it ran in our data centers 
and I recognized the problem we 

127
00:06:51,100 --> 00:06:54,400
needed more capacity for our 
servers but they run in our data

128
00:06:54,400 --> 00:06:56,400
center. 
So I went to my boss and I said,

129
00:06:56,400 --> 00:06:58,500
Boston need more capacity and he
said yeah. 

130
00:06:59,200 --> 00:07:01,800
Fill out this form and then I'll
get it to accounting and we'll 

131
00:07:01,800 --> 00:07:04,300
get it all approved. 
So filled out the forums, got it

132
00:07:04,300 --> 00:07:08,700
all approved Henry, it was only 
18 months later that I was able 

133
00:07:08,700 --> 00:07:11,900
to log on to that server was a 
very, very fast 18 months. 

134
00:07:11,900 --> 00:07:14,900
That's all it took. 
Obviously that's unacceptable in

135
00:07:14,900 --> 00:07:18,500
today's technology landscape the
very next job. 

136
00:07:18,500 --> 00:07:22,100
I went to though was a start-up 
and we were doing everything on 

137
00:07:22,100 --> 00:07:24,800
the cloud. 
So instead of waiting 18 months,

138
00:07:24,800 --> 00:07:28,400
I could put my credit card in to
a web form and in five minutes 

139
00:07:28,600 --> 00:07:31,000
it's have access to a full 
server. 

140
00:07:31,200 --> 00:07:34,300
A server that I would never be 
able to touch but I have full 

141
00:07:34,300 --> 00:07:38,200
control over that server. 
That really changed everything 

142
00:07:38,300 --> 00:07:41,600
about how I approach Taco. 
I think about tech it was pretty

143
00:07:41,600 --> 00:07:45,400
incredible and then at that same
organization I was responsible 

144
00:07:45,400 --> 00:07:47,700
for operations. 
Like I said, it was a start-up, 

145
00:07:47,700 --> 00:07:50,200
it was very small. 
I was responsible for everything

146
00:07:50,400 --> 00:07:53,700
and have a good Mentor who was 
helping me one day that Mentor 

147
00:07:53,700 --> 00:07:56,000
came to me and he said, Nathan, 
you know, there's these tools 

148
00:07:56,000 --> 00:07:59,400
out there that can automate a 
lot of the work that Doing maybe

149
00:07:59,400 --> 00:08:02,300
you should look into them. 
They have names like, puppet and

150
00:08:02,300 --> 00:08:04,200
Chef. 
And I looked at him and I said, 

151
00:08:04,200 --> 00:08:08,000
you know what, Tom, I am too 
busy to automate too busy to 

152
00:08:08,000 --> 00:08:11,100
automate, what a great phrase, 
and that phrase is really stuck 

153
00:08:11,100 --> 00:08:14,400
with him, too busy to improve. 
Obviously, if you automate, 

154
00:08:14,400 --> 00:08:16,400
you'll have more time and more 
capacity. 

155
00:08:16,700 --> 00:08:20,700
So, I took those words to heart 
and eventually I learned both 

156
00:08:20,700 --> 00:08:24,300
puppet and Chef and ended up 
using Chef quite a lot in 

157
00:08:24,300 --> 00:08:28,100
another organization. 
And then eventually I fell in 

158
00:08:28,100 --> 00:08:29,700
love. 
With the chef Community. 

159
00:08:30,000 --> 00:08:33,299
I have to tell you it was open 
source and it was a community of

160
00:08:33,299 --> 00:08:36,299
practitioners that were really 
automating infrastructure. 

161
00:08:36,500 --> 00:08:38,299
I felt so much in love with that
Community. 

162
00:08:38,299 --> 00:08:40,100
I said, I have to help that 
community. 

163
00:08:40,400 --> 00:08:43,000
And so, I joined Chef the 
company and I was part of 

164
00:08:43,000 --> 00:08:46,800
leading and fostering that 
Community for about six years. 

165
00:08:47,200 --> 00:08:50,400
After my time at Chef, I joined 
Google Cloud to continue my 

166
00:08:50,400 --> 00:08:54,600
journey through devops into a 
sorry and really helping teams 

167
00:08:54,600 --> 00:08:56,600
find ways that they can perform 
the best. 

168
00:08:57,300 --> 00:08:58,800
Thanks so much for sharing your 
story. 

169
00:08:59,000 --> 00:09:02,000
I could still remember as well 
traditionally last time we used 

170
00:09:02,000 --> 00:09:05,800
to ask for servers and all that 
even hardening process itself 

171
00:09:05,800 --> 00:09:08,800
and take months. 
So I think I really relate to 

172
00:09:08,800 --> 00:09:11,700
your story, and thanks for 
sharing the story where you 

173
00:09:11,700 --> 00:09:14,100
said, that you are too busy to 
automate. 

174
00:09:14,300 --> 00:09:17,300
I think we have been there, 
especially all these as arjan, 

175
00:09:17,300 --> 00:09:19,800
Dev Ops people. 
Sometimes we are just too busy 

176
00:09:19,800 --> 00:09:23,200
in our daily work. 
They'll eat oils and also forget

177
00:09:23,200 --> 00:09:24,900
how to actually improve from 
there. 

178
00:09:25,500 --> 00:09:27,400
It's Sookie. 
It's Sookie. 

179
00:09:27,400 --> 00:09:30,700
Even to make a small investment 
in improving, just a little bit 

180
00:09:30,700 --> 00:09:31,600
better. 
Every day. 

181
00:09:32,100 --> 00:09:36,200
Speaking about Improvement and 
devops related automation this 

182
00:09:36,200 --> 00:09:38,300
year. 
I saw that Google cloud and Dora

183
00:09:38,300 --> 00:09:41,000
just released a state of devops 
report 2021. 

184
00:09:41,300 --> 00:09:44,500
So can you tell us more what is 
actually state of devops report?

185
00:09:45,000 --> 00:09:48,100
Yes, absolutely. 
So the state of devops report is

186
00:09:48,100 --> 00:09:49,800
essentially what it says on the 
title. 

187
00:09:49,800 --> 00:09:53,200
It's a state of devops report 
about this but let's get into a 

188
00:09:53,208 --> 00:09:54,700
little bit deeper background 
there. 

189
00:09:54,700 --> 00:09:59,700
So there's a research program. 
Dora research program, it is the

190
00:09:59,800 --> 00:10:03,400
longest and largest running 
research program of its kind. 

191
00:10:03,700 --> 00:10:08,400
Dora itself, brings an academic 
rigor to the investigation of 

192
00:10:08,400 --> 00:10:12,400
this question of how two teams 
improve their software, delivery

193
00:10:12,400 --> 00:10:16,000
and operations performance. 
And so each year Dora has 

194
00:10:16,000 --> 00:10:19,500
published a state of devops 
report that summarizes the 

195
00:10:19,500 --> 00:10:21,600
findings from that years 
research. 

196
00:10:21,600 --> 00:10:24,700
From that years investigation, 
the investigations, the 

197
00:10:24,700 --> 00:10:29,000
research, always go across 
Across every industry vertical. 

198
00:10:29,200 --> 00:10:32,800
So we talk to organizations in 
finance in government and 

199
00:10:32,800 --> 00:10:37,200
technology in retail across the 
board really seeking to 

200
00:10:37,200 --> 00:10:40,100
understand what helps teams 
improve. 

201
00:10:40,900 --> 00:10:43,900
So, if I'm not mistaken, this 
has been running for the last 

202
00:10:43,900 --> 00:10:45,700
seven eight years is that 
correct? 

203
00:10:45,700 --> 00:10:46,900
Yeah. 
Yes, that's right. 

204
00:10:46,900 --> 00:10:49,400
It's been seven years now that 
this has been running. 

205
00:10:49,400 --> 00:10:52,100
Yes. 
So if you can, probably explain 

206
00:10:52,100 --> 00:10:54,800
how did they started? 
What kind of problem that they 

207
00:10:54,800 --> 00:10:56,900
are trying to solve back then? 
And why? 

208
00:10:57,000 --> 00:11:00,300
Coming up at this report itself 
can help ya. 

209
00:11:00,300 --> 00:11:03,400
Interestingly the report itself 
in their research actually was 

210
00:11:03,400 --> 00:11:06,900
started by Puppet Labs or a 
puppet and what they saw. 

211
00:11:06,900 --> 00:11:09,100
Almost a decade or over a decade
ago. 

212
00:11:09,100 --> 00:11:12,500
Now, they saw this burgeoning 
community that identified as the

213
00:11:12,500 --> 00:11:15,800
devops community, puppet had 
this question, what is the 

214
00:11:15,800 --> 00:11:17,900
devops community? 
What are they doing? 

215
00:11:17,900 --> 00:11:22,100
How can we bring the lessons 
that Community is learned to a 

216
00:11:22,100 --> 00:11:25,000
wider audience? 
So they started the state of 

217
00:11:25,000 --> 00:11:28,200
devops report and an annual 
survey to go with that. 

218
00:11:28,400 --> 00:11:32,200
Now, as that program evolved dr.
Nicole for his grin, got 

219
00:11:32,200 --> 00:11:36,200
involved in that to again, bring
a little bit more academic rigor

220
00:11:36,200 --> 00:11:38,700
to the research and to the 
investigations. 

221
00:11:39,200 --> 00:11:41,900
So those reports continue to 
then eventually dr. 

222
00:11:41,900 --> 00:11:45,700
Nicole for is Rin together with 
jazz humble and Gene Kim formed,

223
00:11:45,700 --> 00:11:50,600
an organization called Dora, 
Dora stands for devops research 

224
00:11:50,600 --> 00:11:53,900
and assessment what that 
organization did was continue. 

225
00:11:53,900 --> 00:11:57,500
The research program in 
conjunction with Papa And on 

226
00:11:57,500 --> 00:12:00,600
their own. 
But they also built a tool, an 

227
00:12:00,600 --> 00:12:05,000
assessment tool to go in and 
help organizations measure, how 

228
00:12:05,000 --> 00:12:06,800
are they doing against their 
software, delivery and 

229
00:12:06,800 --> 00:12:09,700
operations performance? 
And importantly, how to 

230
00:12:09,700 --> 00:12:13,100
identify, where they should 
focus their improvement. 

231
00:12:13,100 --> 00:12:17,700
Work Dora eventually, in 2018 
was acquired by Google cloud. 

232
00:12:18,000 --> 00:12:22,400
And we've continued to expand on
that research and continue to 

233
00:12:22,400 --> 00:12:25,400
work together to bring the 
findings of that research and 

234
00:12:25,400 --> 00:12:27,900
practical implementations. 
Is to our customers. 

235
00:12:28,700 --> 00:12:31,400
If I can also relate with my 
personal experience, looking at 

236
00:12:31,400 --> 00:12:33,700
these reporter. 
I think since the state of Davos

237
00:12:33,700 --> 00:12:36,800
reports suddenly we come to see 
a lot of state of other things 

238
00:12:36,800 --> 00:12:40,200
reports in the market, including
actually lately that we have 

239
00:12:40,200 --> 00:12:42,500
seen puppet. 
Also releasing another state of 

240
00:12:42,500 --> 00:12:44,700
devops report. 
Why are there so many reports 

241
00:12:44,800 --> 00:12:46,500
maybe can you clarify little bit
here? 

242
00:12:47,100 --> 00:12:48,800
Yeah. 
So why are there so many 

243
00:12:48,800 --> 00:12:51,100
reports? 
Well I think we have a lot to 

244
00:12:51,100 --> 00:12:54,300
learn from one another and there
are always questions that we 

245
00:12:54,300 --> 00:12:56,500
have. 
So I think this is really 

246
00:12:56,500 --> 00:12:58,400
important. 
I think when Dora the 

247
00:12:58,400 --> 00:13:01,800
organization was formed and 
started publishing their own 

248
00:13:01,800 --> 00:13:04,600
reports Papa continued with 
their own research. 

249
00:13:04,800 --> 00:13:08,800
I was just looking at the 2021 
puppet state of devops report 

250
00:13:08,800 --> 00:13:11,200
and I found fascinating insights
in there. 

251
00:13:11,500 --> 00:13:14,700
The methodology is similar 
across the two, although not 

252
00:13:14,700 --> 00:13:17,100
identical. 
And certainly the things that 

253
00:13:17,100 --> 00:13:21,500
are investigated in each Year's 
report are completely different 

254
00:13:21,500 --> 00:13:24,000
to one another. 
So I think it's really 

255
00:13:24,000 --> 00:13:27,000
interesting, but I also think, 
you know, we see the state of of

256
00:13:27,000 --> 00:13:30,100
the secure supply chain or the 
software supply chain, we see 

257
00:13:30,100 --> 00:13:33,300
that a state of that report, the
state of Dempsey cops. 

258
00:13:33,400 --> 00:13:35,400
Yes, there were reports 
everywhere. 

259
00:13:35,700 --> 00:13:39,000
And I think the important thing 
to remember, is how do you as a 

260
00:13:39,000 --> 00:13:43,100
team utilize, the findings of a 
report to help your team 

261
00:13:43,100 --> 00:13:45,200
improve? 
That's the biggest question, 

262
00:13:45,200 --> 00:13:49,000
always thanks for putting that 
as a note because we all see 

263
00:13:49,000 --> 00:13:51,500
these report we all see the 
findings but at the end, I don't

264
00:13:51,500 --> 00:13:54,400
know whether we improve or not. 
So that's the only measurable 

265
00:13:54,400 --> 00:13:56,800
things that we need to do 
speaking about the fine. 

266
00:13:57,200 --> 00:14:00,100
We know that state of Davos 
report has this popular 

267
00:14:00,100 --> 00:14:04,300
findings, which was used to be 
called for Golden Matrix of four

268
00:14:04,300 --> 00:14:07,000
key metrics. 
But now there are five key 

269
00:14:07,000 --> 00:14:09,300
metrics and you probably explain
to us. 

270
00:14:09,300 --> 00:14:11,200
What are these? 
Five key metrics? 

271
00:14:11,900 --> 00:14:13,100
Yes. 
Absolutely. 

272
00:14:13,100 --> 00:14:16,000
So the five key metrics and 
you're right they started off as

273
00:14:16,000 --> 00:14:19,400
for key metrics really at the 
beginning of the research 

274
00:14:19,400 --> 00:14:21,300
program. 
The question was, how do we 

275
00:14:21,300 --> 00:14:25,700
improve and sure software 
delivery performance, frankly 

276
00:14:25,700 --> 00:14:28,500
when it comes to the word? 
Devops Henry, you have a 

277
00:14:28,500 --> 00:14:31,500
different definition than I 
have, then any one of our 

278
00:14:31,500 --> 00:14:35,700
listeners has this is one of the
challenges of devops as a 

279
00:14:35,700 --> 00:14:39,000
community. 
Devops has always shunned a 

280
00:14:39,000 --> 00:14:43,200
common definition. 
So as a researcher, how do you 

281
00:14:43,200 --> 00:14:46,200
measure a thing and research a 
thing that's not? 

282
00:14:46,200 --> 00:14:48,800
Well defined. 
Well this was one of the 

283
00:14:48,800 --> 00:14:52,200
problems that the door research 
team set out to solve for. 

284
00:14:52,500 --> 00:14:56,300
So what they came up with was a 
very practical and pragmatic way

285
00:14:56,300 --> 00:14:58,200
to measure. 
Our software delivery 

286
00:14:58,200 --> 00:15:01,100
performance, and that's where we
got the Four Keys. 

287
00:15:01,100 --> 00:15:04,100
So, software delivery, how do 
you measure software delivery? 

288
00:15:04,300 --> 00:15:07,900
Well with Endora, what we 
measure, our two, metrics for 

289
00:15:07,900 --> 00:15:10,700
stability, and two metrics for 
throughput. 

290
00:15:10,800 --> 00:15:12,900
I'll start with the throughput, 
the velocity. 

291
00:15:12,900 --> 00:15:16,100
How fast do you delivering 
software for that? 

292
00:15:16,100 --> 00:15:18,900
We look at deployment frequency.
So how frequently are you 

293
00:15:18,900 --> 00:15:22,500
pushing changes out to your 
customers or the users of your 

294
00:15:22,500 --> 00:15:24,900
application? 
And then importantly, we look at

295
00:15:24,900 --> 00:15:29,100
lead time for changes So as a 
developer, I'm making a change 

296
00:15:29,100 --> 00:15:32,300
to the code base, I commit that 
change to the Version Control 

297
00:15:32,300 --> 00:15:34,900
System, you're using a Version 
Control System, right? 

298
00:15:34,900 --> 00:15:38,100
Henry, I hope all of you are, if
you're not using a Version 

299
00:15:38,100 --> 00:15:41,000
Control System, stop listening 
to this podcast go read up on 

300
00:15:41,000 --> 00:15:43,900
get or any other version control
system and then come back and 

301
00:15:43,900 --> 00:15:46,000
listen to the rest of this 
podcast, okay? 

302
00:15:46,100 --> 00:15:49,000
Sorry I had to get on there for 
a second so to play with 

303
00:15:49,000 --> 00:15:51,200
frequency how frequently re 
pushing out changes. 

304
00:15:51,500 --> 00:15:55,100
Next is lead time for changes as
a developer, I make a change, 

305
00:15:55,200 --> 00:15:56,800
commit it to the Version 
Control. 

306
00:15:57,300 --> 00:16:01,200
Timer starts that timer stops 
when that change lands in 

307
00:16:01,200 --> 00:16:04,100
production and so we want to 
increase the frequency with 

308
00:16:04,100 --> 00:16:07,400
which were pushing out changes 
and decrease. 

309
00:16:07,400 --> 00:16:09,800
The amount of time it takes for 
those changes to go from the 

310
00:16:09,800 --> 00:16:13,000
developer into production. 
Those are our velocity metrics 

311
00:16:13,300 --> 00:16:17,000
and then we have our stability 
metrics, moving fast as great. 

312
00:16:17,200 --> 00:16:20,100
But if you're moving fast and 
always breaking everything, 

313
00:16:20,300 --> 00:16:22,500
that's not so good. 
So stability. 

314
00:16:22,500 --> 00:16:25,900
We look at two things there. 
The first is your change fail 

315
00:16:25,900 --> 00:16:28,600
rate. 
So when you make a push into 

316
00:16:28,600 --> 00:16:32,300
production, how frequently are 
you shouting out an expletive? 

317
00:16:32,500 --> 00:16:35,200
Oh my gosh. 
Ah this is broken. 

318
00:16:35,200 --> 00:16:36,900
We have to roll it back 
immediately. 

319
00:16:37,200 --> 00:16:39,800
So when you have that, that's a 
change failure. 

320
00:16:40,000 --> 00:16:43,000
Someone had to get involved in 
that deployment process. 

321
00:16:43,500 --> 00:16:45,800
We want to decrease those as 
much as possible. 

322
00:16:46,200 --> 00:16:49,400
Our final stability metric has 
to do with this idea. 

323
00:16:49,600 --> 00:16:52,000
This truth that it doesn't 
matter. 

324
00:16:52,000 --> 00:16:56,700
What we do to reduce risk risk 
is always present failures. 

325
00:16:56,900 --> 00:17:00,000
Inevitable. 
Something is going to break so 

326
00:17:00,000 --> 00:17:01,800
we have to look beyond the 
tools. 

327
00:17:01,800 --> 00:17:05,400
We have to look at our team and 
say how quickly does it take us 

328
00:17:05,400 --> 00:17:08,500
or how quickly can we restore 
service to our customers? 

329
00:17:08,599 --> 00:17:10,400
When there is something that 
impacts them. 

330
00:17:10,700 --> 00:17:12,500
And so this is our time to 
restore service. 

331
00:17:12,500 --> 00:17:15,300
So those are our four key 
metrics deployment frequency 

332
00:17:15,599 --> 00:17:19,599
lead time for changes change, 
failure rate and your time to 

333
00:17:19,599 --> 00:17:23,000
restore service. 
Now, what we found as we looked 

334
00:17:23,000 --> 00:17:26,700
at those four metrics and what 
we found consistently over 

335
00:17:26,800 --> 00:17:29,400
throughout the course of the 
research study is that they are 

336
00:17:29,400 --> 00:17:31,900
trade-offs many organizations 
think. 

337
00:17:31,900 --> 00:17:36,200
In order to be safe, I have to 
be slow, but the data shows us 

338
00:17:36,200 --> 00:17:40,000
that the best performers are 
getting both and in fact, as 

339
00:17:40,000 --> 00:17:42,600
speed increases, so too does 
stability. 

340
00:17:42,600 --> 00:17:45,500
So they have some really 
interesting findings there. 

341
00:17:45,500 --> 00:17:47,500
Okay. 
But you asked about the five 

342
00:17:47,500 --> 00:17:50,000
metrics and I said there was a 
fifth one that we've added this 

343
00:17:50,000 --> 00:17:53,500
year that fifth one that we've 
added, we've really refined it 

344
00:17:53,500 --> 00:17:55,500
this year. 
I would say for the past couple 

345
00:17:55,500 --> 00:17:58,400
of years since I want to say, 
18:11 might have to check my 

346
00:17:58,400 --> 00:18:01,200
notes on that 2018 2019, 
whatever it takes. 

347
00:18:01,400 --> 00:18:04,300
We introduced this idea, not 
just of software delivery 

348
00:18:04,300 --> 00:18:06,900
performance but software 
delivery in operations 

349
00:18:06,900 --> 00:18:09,500
performance. 
Now operations performance. 

350
00:18:09,500 --> 00:18:12,700
Because when you've deployed 
something that's the beginning 

351
00:18:12,800 --> 00:18:16,400
of it, providing value to you as
an organization and to your 

352
00:18:16,400 --> 00:18:19,100
customers. 
So we really need to answer this

353
00:18:19,100 --> 00:18:21,500
question of what's our 
operational performance look 

354
00:18:21,500 --> 00:18:25,600
like in the past in previous 
years, we asked questions about 

355
00:18:25,600 --> 00:18:29,000
your operational performance. 
It's in terms of availability 

356
00:18:29,400 --> 00:18:32,900
but this year, we've refined our
approach and gone deeper with 

357
00:18:32,900 --> 00:18:38,100
the research to move from, 
availability to reliability now.

358
00:18:38,100 --> 00:18:41,500
A subtle change in language but 
as we know language is 

359
00:18:41,500 --> 00:18:44,500
important. 
But that subtle change is really

360
00:18:44,500 --> 00:18:48,000
more to help everyone. 
Consider not just is the 

361
00:18:48,000 --> 00:18:51,300
application available but 
availability is really a 

362
00:18:51,300 --> 00:18:55,200
component of reliability. 
In both cases, though. 

363
00:18:55,300 --> 00:18:56,700
What we're really trying to 
answer. 

364
00:18:56,900 --> 00:18:58,200
Question. 
We're getting at. 

365
00:18:58,600 --> 00:19:02,500
Can you keep your promises to 
your customers? 

366
00:19:03,100 --> 00:19:06,000
Can they rely on the application
or the service that your team is

367
00:19:06,000 --> 00:19:09,300
building and shipping? 
So what we found this year, as 

368
00:19:09,300 --> 00:19:11,900
we dug, really deep into 
reliability. 

369
00:19:12,100 --> 00:19:16,700
Is that reliability practices, 
push organizational performance.

370
00:19:16,700 --> 00:19:20,000
They drive that organizational 
performance as an organization. 

371
00:19:20,000 --> 00:19:23,500
If you want to get better 
investing in reliability can 

372
00:19:23,500 --> 00:19:26,100
really help. 
I really love the way you 

373
00:19:26,100 --> 00:19:29,400
explain all these key metrics, 
hey, with a little bit of humor,

374
00:19:29,400 --> 00:19:31,800
he had asthma. 
So this is my first time here is

375
00:19:31,800 --> 00:19:33,900
such a hundred of them, golden 
key metrics. 

376
00:19:34,200 --> 00:19:37,400
So just to recap, that's the 
philosophy of through booked a 

377
00:19:37,408 --> 00:19:40,700
metrics, which are the 
deployment frequency, and also 

378
00:19:40,700 --> 00:19:44,400
lead time for changes daddy 
stability, part, which is the 

379
00:19:44,400 --> 00:19:47,600
change, failure rate and tied to
restore the service. 

380
00:19:48,000 --> 00:19:50,900
And the fifth one, which is 
related to operational site, 

381
00:19:50,900 --> 00:19:53,500
which is now called reliability 
aspect. 

382
00:19:53,500 --> 00:19:57,100
So it used to be Ability. 
But now we change the turn to 

383
00:19:57,100 --> 00:19:59,400
reliability. 
I think you mentioned as well in

384
00:19:59,400 --> 00:20:02,900
your explanation that used to be
traditionally well-known, right?

385
00:20:03,000 --> 00:20:06,500
So if you want to be safe for 
reservist, you have to go slow. 

386
00:20:06,600 --> 00:20:09,200
So that's why there are maybe 
quarter release monthly release 

387
00:20:09,200 --> 00:20:11,900
or even year we released because
the software just couldn't get 

388
00:20:11,900 --> 00:20:14,500
deployed. 
And now, it seems that most of 

389
00:20:14,500 --> 00:20:17,900
the organization's understand 
that in order to be more safe, 

390
00:20:18,000 --> 00:20:20,200
you have to go faster. 
And that's why you have this 

391
00:20:20,200 --> 00:20:23,000
velocity and throughput 
measurements to actually 

392
00:20:23,000 --> 00:20:24,600
indicates whether the 
organization. 

393
00:20:24,700 --> 00:20:28,100
Changes rapidly or not and now 
you have the reliability aspect 

394
00:20:28,100 --> 00:20:30,500
as well. 
What does it tell the balance 

395
00:20:30,500 --> 00:20:33,400
trade-off between risk. 
And what's the operational side 

396
00:20:33,400 --> 00:20:35,600
actually tells us? 
Yeah. 

397
00:20:35,600 --> 00:20:38,800
Interestingly, what we found is 
that all of the performers 

398
00:20:38,800 --> 00:20:41,700
across, whether you're low 
performer, were the best of the 

399
00:20:41,708 --> 00:20:44,400
best, the elite performers when 
it comes to software delivery, 

400
00:20:44,400 --> 00:20:47,900
each one of those performance 
categories, could improve their 

401
00:20:47,900 --> 00:20:51,200
overall organizational 
performance with the adoption of

402
00:20:51,200 --> 00:20:55,000
reliability practices. 
So we find that these are Very 

403
00:20:55,000 --> 00:20:58,000
complimentary practices to one 
another. 

404
00:20:58,300 --> 00:21:00,500
And in fact what we talked about
or what? 

405
00:21:00,500 --> 00:21:03,100
We investigated a lot of within 
reliability. 

406
00:21:03,100 --> 00:21:07,400
A classic example here, are you 
using the data from your 

407
00:21:07,400 --> 00:21:09,400
reliability measures to help 
you? 

408
00:21:09,400 --> 00:21:13,900
Prioritize work in the world of 
site, reliability, engineering, 

409
00:21:14,000 --> 00:21:18,000
or the practice of a sorry, we 
often talk about an error budget

410
00:21:18,000 --> 00:21:21,800
and we use an error budget to 
say if we're not meeting our 

411
00:21:21,800 --> 00:21:25,700
reliability goals and we should 
focus our Effort on the things 

412
00:21:25,700 --> 00:21:29,300
that will make the system more 
reliable and flip side of that. 

413
00:21:29,300 --> 00:21:32,500
If we are meeting or even 
exceeding, our reliability 

414
00:21:32,500 --> 00:21:36,000
goals, then we should focus on 
things that make us faster. 

415
00:21:36,400 --> 00:21:38,900
The other thing I think that's 
really interesting about all of 

416
00:21:38,900 --> 00:21:41,500
these metrics together. 
There's kind of two things I 

417
00:21:41,500 --> 00:21:44,400
want to point out one. 
We have to make sure that as a 

418
00:21:44,400 --> 00:21:48,300
team responsible for an 
application or service, we have 

419
00:21:48,300 --> 00:21:53,100
joint accountability to all of 
these metrics part of the reason

420
00:21:53,100 --> 00:21:56,500
in the past, we used to think, 
That slow met safe. 

421
00:21:56,700 --> 00:22:00,300
It also comes down to who's 
incentivised for which we've 

422
00:22:00,300 --> 00:22:03,900
spent a lot of times telling our
developers go faster, go faster,

423
00:22:04,400 --> 00:22:06,500
and then turning to our 
operators and say, keep it 

424
00:22:06,500 --> 00:22:08,800
stable and I've been that 
operator. 

425
00:22:08,800 --> 00:22:11,900
I know the best way to keep the 
system stable is to not change 

426
00:22:11,900 --> 00:22:14,900
it but that's no good for our 
customers, right? 

427
00:22:15,100 --> 00:22:19,000
So we have to take these five 
metrics are for software 

428
00:22:19,000 --> 00:22:21,900
delivery metrics and our 
operational metric and really 

429
00:22:21,900 --> 00:22:25,900
have joint ownership of them 
across with all of our teams. 

430
00:22:26,200 --> 00:22:29,400
The other thing that I think is 
really interesting is just how 

431
00:22:29,400 --> 00:22:33,500
do they reinforce one another 
and it devops technology 

432
00:22:33,500 --> 00:22:36,800
practices. 
We learn from other disciplines 

433
00:22:36,800 --> 00:22:39,000
as well. 
And I think the biggest lesson 

434
00:22:39,000 --> 00:22:41,400
or one of the biggest lessons 
that we've taken from another 

435
00:22:41,400 --> 00:22:44,900
industry, is that from lean 
manufacturing and lean 

436
00:22:44,900 --> 00:22:47,500
manufacturing says, do things in
small batches. 

437
00:22:47,800 --> 00:22:50,800
So when we apply that to the 
delivery and operations of 

438
00:22:50,800 --> 00:22:55,300
software, we know that when we 
have a small change it, Always 

439
00:22:55,300 --> 00:22:58,200
heading to production. 
That's a small change. 

440
00:22:58,200 --> 00:23:01,700
It's easier to reason about when
it lands in production, it's 

441
00:23:01,700 --> 00:23:05,100
less likely to have a huge 
negative impact. 

442
00:23:05,100 --> 00:23:08,600
We also bring in practices like 
Progressive, deploys, where you 

443
00:23:08,600 --> 00:23:11,600
might deploy that change 25 
percent of your users, and see, 

444
00:23:11,600 --> 00:23:16,000
how did that go before you roll 
it out, globally, to all of your

445
00:23:16,000 --> 00:23:19,900
users by making those smaller 
changes, you're less likely to 

446
00:23:19,900 --> 00:23:24,200
have a big impact, your more 
easy to reason about it and move

447
00:23:24,200 --> 00:23:27,200
that. 
Change through the system as for

448
00:23:27,200 --> 00:23:30,200
those two summary because that 
actually explains the gist of 

449
00:23:30,200 --> 00:23:32,800
the devops itself. 
So when we traditionally used to

450
00:23:32,800 --> 00:23:36,100
have fights between developers 
and operate this now with the 

451
00:23:36,100 --> 00:23:39,300
devops concept and culture. 
So basically those two teams 

452
00:23:39,300 --> 00:23:42,000
need to have a joint account 
ability, like what you said and 

453
00:23:42,000 --> 00:23:44,200
also incentivised to actually 
work together, make the 

454
00:23:44,200 --> 00:23:47,900
customers happy at the end of 
the day, speaking about how the 

455
00:23:47,900 --> 00:23:50,300
state of that was report 
classify, what they call 

456
00:23:50,300 --> 00:23:52,900
performers, right? 
So they are few categories. 

457
00:23:53,200 --> 00:23:56,000
They are the elites and the low.
Up to low performers. 

458
00:23:56,200 --> 00:23:58,500
So can you explain a little bit?
What are these categories? 

459
00:23:58,500 --> 00:24:01,900
And what do you see, the 
significant difference between 

460
00:24:02,000 --> 00:24:05,000
Elite and maybe low performance?
Yes. 

461
00:24:05,000 --> 00:24:07,400
For sure. 
So again this kind of gets back 

462
00:24:07,400 --> 00:24:11,400
to the sort of academic rigor, 
of the research itself. 

463
00:24:11,400 --> 00:24:14,500
So what we've done each year, as
part of the research program is 

464
00:24:14,600 --> 00:24:18,300
asked respondents about how were
they doing against those four 

465
00:24:18,300 --> 00:24:20,400
key metrics, or those five key 
metrics. 

466
00:24:20,400 --> 00:24:24,100
Now, of course, and what we do 
is we take their answers and we 

467
00:24:24,100 --> 00:24:26,600
throw them down onto a plot 
essentially. 

468
00:24:26,800 --> 00:24:28,800
So we lay them all out on a 
grid. 

469
00:24:28,900 --> 00:24:33,900
And we see these clusters 
emerge, these clusters, show us 

470
00:24:33,900 --> 00:24:36,700
that there were three 
statistically significant, or 

471
00:24:36,700 --> 00:24:40,200
for statistically, significant 
groups of performers. 

472
00:24:40,600 --> 00:24:43,700
I said three first because 
actually, in the beginning, part

473
00:24:43,700 --> 00:24:46,800
of the research program itself, 
there were three different 

474
00:24:46,800 --> 00:24:52,300
distinct groups but in 2018, a 
fourth group started to emerge, 

475
00:24:52,300 --> 00:24:54,500
but subset of those top 
performers. 

476
00:24:54,900 --> 00:24:58,100
What we've seen are or what we 
decided to do in 2018 was 

477
00:24:58,100 --> 00:25:01,600
identifying call those out as 
Elite performers. 

478
00:25:02,000 --> 00:25:07,600
So today and since 2018, we've 
had low, medium high, and delete

479
00:25:07,600 --> 00:25:10,600
performers, four different 
clusters of performance. 

480
00:25:11,100 --> 00:25:14,800
So what we do is we look at how 
are they doing across each of 

481
00:25:14,808 --> 00:25:17,200
those metrics? 
So at a very high level, I'll 

482
00:25:17,200 --> 00:25:19,600
tell you a little bit about the 
elite performers in the low 

483
00:25:19,600 --> 00:25:21,800
performers on that deployment 
frequency. 

484
00:25:21,800 --> 00:25:26,500
Elite performers are able to 
deploy on Demand, that may mean 

485
00:25:26,600 --> 00:25:31,500
even multiple deploys per day, 
but a low performer in 2021 will

486
00:25:31,500 --> 00:25:34,300
do fewer. 
Deployments, then once per six 

487
00:25:34,300 --> 00:25:38,100
months, so it might take seven 
eight months maybe yearly for 

488
00:25:38,100 --> 00:25:40,500
them to do a single code 
deployment. 

489
00:25:40,700 --> 00:25:43,700
The flip side of that of course 
is our time to restore service 

490
00:25:43,800 --> 00:25:46,600
or change fail rate on the time 
to restore service. 

491
00:25:46,600 --> 00:25:49,700
I'll give you the Deltas there. 
Between the two time to restore 

492
00:25:49,700 --> 00:25:53,400
service for an elite performer 
less than an hour for a low 

493
00:25:53,400 --> 00:25:56,600
performer. 
Take more than six months to 

494
00:25:56,600 --> 00:25:58,900
fully restore service. 
When there is an outage or 

495
00:25:58,900 --> 00:26:02,000
something that interrupts their.
Now, the other thing about those

496
00:26:02,000 --> 00:26:06,300
four categories is because we've
had them for many years, we can 

497
00:26:06,300 --> 00:26:08,800
see changes in the shape of 
those. 

498
00:26:09,100 --> 00:26:11,400
So what defined Elite 
performers? 

499
00:26:11,400 --> 00:26:15,200
Three years ago, maybe only 
defines High performers today 

500
00:26:15,400 --> 00:26:18,800
because as an industry we are 
always getting better. 

501
00:26:19,100 --> 00:26:22,600
We've also seen that in 2018, 
the elite performers were about 

502
00:26:22,600 --> 00:26:27,400
seven percent of the sample. 
In 2021, they're 26 percent of 

503
00:26:27,408 --> 00:26:30,400
the sample. 
So that lead performers, not 

504
00:26:30,400 --> 00:26:33,200
only, are they getting better, 
but the number of people are 

505
00:26:33,200 --> 00:26:36,100
number of teams that are able to
achieve that is growing. 

506
00:26:36,700 --> 00:26:39,800
Wow, that's a very Stark 
difference between the elite and

507
00:26:39,800 --> 00:26:42,400
low performers. 
So if any of you are interested 

508
00:26:42,400 --> 00:26:46,100
to assess yourself or your team 
where you are at, go check the 

509
00:26:46,100 --> 00:26:49,100
state of devops report. 
I think each of the four Matrix,

510
00:26:49,100 --> 00:26:51,800
you will have some statistics, 
what will be each of the 

511
00:26:51,800 --> 00:26:54,100
performer? 
Kind of like performing at that 

512
00:26:54,100 --> 00:26:56,700
particular Tricks. 
So, for example, just now Nathan

513
00:26:56,700 --> 00:26:59,200
mention about deployment 
frequency where Elite 

514
00:26:59,200 --> 00:27:02,300
Performance can do only one 
multiple deploys per day. 

515
00:27:02,600 --> 00:27:05,200
So the low performers probably 
somewhere around six months for 

516
00:27:05,200 --> 00:27:07,900
deployment frequencies and 
that's really bad if you can 

517
00:27:07,900 --> 00:27:10,000
classify yourself. 
Of course measure where you are 

518
00:27:10,000 --> 00:27:13,000
at now and you can look forward 
how to improve it. 

519
00:27:13,000 --> 00:27:15,400
That's kind of like the roadmap 
out of these findings. 

520
00:27:16,000 --> 00:27:17,800
Absolutely. 
If you can absolutely check the 

521
00:27:17,800 --> 00:27:20,800
state of devops report but we 
also have a tool Henry that's 

522
00:27:20,800 --> 00:27:23,600
available to anyone. 
If you go to cloud.google.com. 

523
00:27:24,600 --> 00:27:27,900
Cam devops. 
You'll see there's a button 

524
00:27:27,900 --> 00:27:30,200
there that allows you to take a 
quick check. 

525
00:27:30,500 --> 00:27:34,100
So this quick Jack is the Dora, 
devops Quick Check and we will 

526
00:27:34,100 --> 00:27:38,300
ask you questions about your 
team's performance today and 

527
00:27:38,300 --> 00:27:39,900
help you assess. 
Where are you? 

528
00:27:40,100 --> 00:27:43,200
You can then compare yourself to
other Elite performers or high 

529
00:27:43,200 --> 00:27:45,500
performers. 
You can compare yourself to 

530
00:27:45,500 --> 00:27:48,700
others within your industry and 
across all of the survey 

531
00:27:48,700 --> 00:27:51,200
respondents. 
So definitely check out the 

532
00:27:51,200 --> 00:27:53,600
quick check, thanks for the plug
they. 

533
00:27:53,600 --> 00:27:55,300
I'll make sure to put The show 
notes. 

534
00:27:55,600 --> 00:27:58,000
I wasn't aware of that tool, but
yeah, definitely, it will be 

535
00:27:58,000 --> 00:28:00,200
great if there's an automated 
tool that can help you to 

536
00:28:00,200 --> 00:28:02,300
assess. 
Yes, so speaking about this 

537
00:28:02,300 --> 00:28:05,000
year's report, what are the new 
key findings? 

538
00:28:05,100 --> 00:28:06,900
I saw a couple of new key 
findings. 

539
00:28:06,900 --> 00:28:09,300
Maybe you can share. 
What are the most important 

540
00:28:09,300 --> 00:28:12,600
significant findings this year? 
Yeah, absolutely. 

541
00:28:12,600 --> 00:28:15,700
Because when we look at these 
clusters of performance, that's 

542
00:28:15,700 --> 00:28:18,500
really good to know and help 
understand where you are. 

543
00:28:18,800 --> 00:28:21,200
But the real question is, how do
I get better? 

544
00:28:21,500 --> 00:28:24,500
That's really where I find the 
research to be very powerful. 

545
00:28:24,600 --> 00:28:28,600
Powerful, because we dig into 
different capabilities. 

546
00:28:28,600 --> 00:28:31,900
The teams should invest in. 
Now, those capabilities might be

547
00:28:31,900 --> 00:28:35,400
technical capabilities, but 
they're also process 

548
00:28:35,400 --> 00:28:38,700
capabilities, measurement, 
capabilities, and cultural 

549
00:28:38,700 --> 00:28:41,500
capabilities. 
We really want to take a full 

550
00:28:41,500 --> 00:28:45,800
systems view, not just that 
systems, like the computers, but

551
00:28:45,800 --> 00:28:49,300
the systems that include you and
me that people in the system 

552
00:28:49,300 --> 00:28:53,100
Henry where they're. 
So at a very high level, there 

553
00:28:53,100 --> 00:28:54,500
are a number of different 
things. 

554
00:28:54,600 --> 00:28:58,100
That we investigated this year, 
we touched briefly on a sorry, 

555
00:28:58,300 --> 00:29:01,600
so SRE and devops. 
We wanted to investigate. 

556
00:29:01,600 --> 00:29:03,000
What's the difference between 
them? 

557
00:29:03,000 --> 00:29:05,400
Are they working together? 
And in fact, we found that they 

558
00:29:05,400 --> 00:29:08,600
are complementary. 
We also continued our Research 

559
00:29:08,600 --> 00:29:12,800
into Cloud, not surprisingly. 
We find that cloud is one of 

560
00:29:12,800 --> 00:29:16,900
those capabilities that drives 
performance but it's not just 

561
00:29:16,900 --> 00:29:20,700
paying a cloud bill. 
You have to do Cloud the right 

562
00:29:20,700 --> 00:29:22,800
way. 
And in fact, we lean on other 

563
00:29:22,800 --> 00:29:26,300
research from the national Toot 
of standards and technology, 

564
00:29:26,700 --> 00:29:29,700
which helps to find the key 
characteristics of cloud 

565
00:29:29,700 --> 00:29:31,900
computing. 
The other things that we 

566
00:29:31,900 --> 00:29:35,400
investigated security, no 
surprise here. 

567
00:29:35,800 --> 00:29:39,400
Security is on everyone's mind 
right now, especially if you 

568
00:29:39,400 --> 00:29:43,000
look back over the last 12 
months, 24 months, the number of

569
00:29:43,000 --> 00:29:46,600
attacks and vulnerabilities, 
that are out there were all 

570
00:29:46,600 --> 00:29:49,800
thinking about security a lot. 
And so, we dug into that. 

571
00:29:50,100 --> 00:29:52,700
And then another one that was 
really interesting this year, 

572
00:29:52,700 --> 00:29:54,400
that's brand-new this year, in 
fact. 

573
00:29:54,800 --> 00:29:58,900
Is we looked at documentation? 
Everyone knows documentation. 

574
00:29:59,200 --> 00:30:01,200
We need to do better with 
documentation. 

575
00:30:01,400 --> 00:30:04,000
Well, we wanted to make sure 
that was actually true. 

576
00:30:04,000 --> 00:30:07,100
Yeah, we feel like Doc's could 
be better or that these docks 

577
00:30:07,100 --> 00:30:10,900
are bad, but does documentation 
actually drive performance. 

578
00:30:10,900 --> 00:30:13,800
And so we're able to draw a 
predictive correlation or a 

579
00:30:13,808 --> 00:30:18,500
predictive connection between 
good, documentation, it enables 

580
00:30:18,500 --> 00:30:22,500
the right technical practices to
help you hit those goals and 

581
00:30:22,500 --> 00:30:24,400
then of course, I can't talk to 
anyone. 

582
00:30:24,500 --> 00:30:26,500
About devops without talking 
about culture. 

583
00:30:26,600 --> 00:30:29,800
So, yes, of course, we 
investigated culture. 

584
00:30:30,000 --> 00:30:33,700
Specifically, we looked this 
year at how teams are doing with

585
00:30:33,700 --> 00:30:37,100
burnout, what sort of things can
we put in place to help? 

586
00:30:37,100 --> 00:30:39,700
Mitigate burnout, from a 
cultural perspective. 

587
00:30:39,900 --> 00:30:42,200
So, those are some of the 
high-level quick findings there.

588
00:30:42,200 --> 00:30:45,400
And I'm happy to dig into any of
them with you Henry, that by the

589
00:30:45,400 --> 00:30:48,600
late 1950s, the most surprising 
thing is the documentation, 

590
00:30:48,600 --> 00:30:50,500
right? 
It was never before in the state

591
00:30:50,500 --> 00:30:53,200
of devops report, but this year,
there was this new thing. 

592
00:30:53,500 --> 00:30:56,300
So why do you think 
Documentation, can actually be a

593
00:30:56,300 --> 00:31:00,200
predictive measures of how 
performing an organization could

594
00:31:00,200 --> 00:31:01,900
be. 
Is it because people just need 

595
00:31:01,900 --> 00:31:06,300
to find a summary of the things 
within the company or is about 

596
00:31:06,300 --> 00:31:08,900
Playbook and run book? 
Or is there other types of 

597
00:31:08,900 --> 00:31:11,900
documentation? 
Yeah, this is a really good 

598
00:31:11,900 --> 00:31:15,200
question and of course or a lots
and lots of different types of 

599
00:31:15,200 --> 00:31:17,700
documentation, we kind of 
investigated. 

600
00:31:17,700 --> 00:31:21,800
What are the practices in 
particular around documentation?

601
00:31:21,800 --> 00:31:25,500
That matter can what we found 
was predicted Of connection 

602
00:31:25,500 --> 00:31:29,400
between things like having clear
ownership and clear. 

603
00:31:29,400 --> 00:31:32,100
Guidelines. 
For when documentation should be

604
00:31:32,100 --> 00:31:36,100
updated making sure that it is 
part of the developers daily 

605
00:31:36,100 --> 00:31:38,100
work. 
If we go back to security, we 

606
00:31:38,100 --> 00:31:42,200
talked about this concept of 
shift left shift left on 

607
00:31:42,200 --> 00:31:44,600
security. 
Make the developers or help 

608
00:31:44,700 --> 00:31:48,200
enable the developers to bring 
better security practices. 

609
00:31:48,500 --> 00:31:51,800
We want to do the same thing 
with documentation and in fact 

610
00:31:51,800 --> 00:31:54,300
we want our developers as 
they're making changes. 

611
00:31:54,600 --> 00:31:57,200
Are the docks being updated. 
This is a question that we 

612
00:31:57,200 --> 00:31:59,400
should be asking as part of our 
pipeline. 

613
00:31:59,900 --> 00:32:02,900
But another thing that's really 
important Henry is we have to 

614
00:32:02,900 --> 00:32:06,600
incentivize it properly, right? 
If I'm going to an annual 

615
00:32:06,600 --> 00:32:10,900
performance review and my 
manager discounts any work, I've

616
00:32:10,900 --> 00:32:13,600
done around documentation, 
that's not good. 

617
00:32:13,800 --> 00:32:16,700
Why would I be motivated to keep
the docks up-to-date? 

618
00:32:16,900 --> 00:32:20,400
So it goes all the way up to 
like incentive structures and 

619
00:32:20,400 --> 00:32:24,300
then down to daily practices of 
the team. 

620
00:32:24,500 --> 00:32:26,800
Is responsible for building an 
operating that software. 

621
00:32:27,000 --> 00:32:29,800
We also looked at things like 
when there is an outage or an 

622
00:32:29,800 --> 00:32:32,800
incident, do you trust the 
documentation? 

623
00:32:33,100 --> 00:32:37,200
Can you use that as a tool to 
help you recover and restore 

624
00:32:37,200 --> 00:32:39,700
service to your users? 
So, yeah. 

625
00:32:39,700 --> 00:32:42,500
Speaking about incentivizing 
where I think at least from my 

626
00:32:42,500 --> 00:32:45,200
experience, I can see that 
documentation sometimes and the 

627
00:32:45,200 --> 00:32:48,500
collected so people like to do 
action-oriented stuff where 

628
00:32:48,500 --> 00:32:51,700
documentation is used to be like
well academically slow and 

629
00:32:51,700 --> 00:32:53,300
there's nothing really out of 
that. 

630
00:32:53,400 --> 00:32:56,700
But in this pandemic, Era where 
everyone probably has remote. 

631
00:32:56,700 --> 00:32:59,700
I think documentation is key 
because we want to be able to 

632
00:32:59,700 --> 00:33:02,400
find things properly without 
having to interact. 

633
00:33:02,400 --> 00:33:05,700
All the time meetings, these 
days are a lot and you'll be 

634
00:33:05,700 --> 00:33:09,100
getting burnt out if you always 
meet people and also, yes, like 

635
00:33:09,100 --> 00:33:12,200
what you said during optic 
incidents happening, do you 

636
00:33:12,200 --> 00:33:13,900
actually trust your from 
documentation? 

637
00:33:14,100 --> 00:33:15,900
Where? 
Someone else who probably not 

638
00:33:15,900 --> 00:33:19,100
familiar with the incident, may 
be able to perform the same kind

639
00:33:19,100 --> 00:33:22,600
of restrictive actions without 
actually needing the same person

640
00:33:22,600 --> 00:33:25,600
doing all over again. 
So I think That's really key for

641
00:33:25,600 --> 00:33:27,900
documentation. 
How about software related 

642
00:33:27,900 --> 00:33:29,500
things? 
Is there anything about 

643
00:33:29,500 --> 00:33:33,000
architecture diagram or software
related documentation? 

644
00:33:33,600 --> 00:33:37,600
Yeah, we didn't really dig in so
specifically into which types of

645
00:33:37,600 --> 00:33:40,800
documentation. 
But more on the availability of 

646
00:33:40,800 --> 00:33:43,800
that documentation in the 
process around, keeping it up to

647
00:33:43,800 --> 00:33:46,600
date. 
But as we talk to customers as I

648
00:33:46,600 --> 00:33:49,600
work with people and teams of my
own experience and I'm sure 

649
00:33:49,600 --> 00:33:52,600
you've experienced this as well,
Henry, there are lots of 

650
00:33:52,600 --> 00:33:54,300
different types of documentation
like you. 

651
00:33:54,500 --> 00:33:57,700
And architecture. 
Diagrams are they up to date or 

652
00:33:57,700 --> 00:34:00,600
the architecture diagrams? 
Maybe they're automatically 

653
00:34:00,600 --> 00:34:03,200
generated from the system's 
themselves, maybe I don't have 

654
00:34:03,200 --> 00:34:05,900
to look to a document. 
There's documentation in the 

655
00:34:05,900 --> 00:34:10,500
wiki is that kept up to date. 
There's even documentation in 

656
00:34:10,500 --> 00:34:13,900
the commit messages in your 
version control system. 

657
00:34:14,100 --> 00:34:17,100
So while we didn't really 
investigate the various types of

658
00:34:17,100 --> 00:34:20,199
documentation and try to draw 
any predictive connections 

659
00:34:20,199 --> 00:34:24,199
there, I think it is important 
that we as practitioners think. 

660
00:34:24,500 --> 00:34:27,000
About the scope of 
documentation. 

661
00:34:27,100 --> 00:34:29,500
And it really comes down to this
question, right? 

662
00:34:29,600 --> 00:34:33,699
Of, how do we enable the best 
technical practices that drive, 

663
00:34:33,699 --> 00:34:36,600
those outcomes that we talked 
about this for key metrics? 

664
00:34:36,900 --> 00:34:39,900
And you can start to see how 
documentation really can play a 

665
00:34:39,900 --> 00:34:43,199
critical role in that? 
So, yeah, I mean like, those are

666
00:34:43,199 --> 00:34:45,900
the examples that you mentioned 
architecture diagram, that can 

667
00:34:45,900 --> 00:34:48,300
be Auto generated. 
I heard some people doing 

668
00:34:48,300 --> 00:34:51,000
architecture decision registry 
or decision records. 

669
00:34:51,000 --> 00:34:53,800
That you also comments along 
with your source code, you can 

670
00:34:53,800 --> 00:34:56,800
also put some Malaysian in the 
commit messages are for people 

671
00:34:56,900 --> 00:34:59,000
to actually see the historical 
changes. 

672
00:34:59,300 --> 00:35:01,900
So moving on from documentation,
that's another finding that I 

673
00:35:01,900 --> 00:35:05,300
find also interesting which is 
about secure software supply 

674
00:35:05,300 --> 00:35:07,100
chain. 
How do you make sure security is

675
00:35:07,100 --> 00:35:09,100
embedded inside your delivery 
pipeline? 

676
00:35:09,500 --> 00:35:12,000
So can you talk more about that?
How does it predict Elite 

677
00:35:12,000 --> 00:35:15,200
Performance? 
Yeah so what we found was that 

678
00:35:15,200 --> 00:35:20,200
the teams that are embracing and
actually putting into practice 

679
00:35:20,200 --> 00:35:24,700
the security practices that we 
investigate were 1.6 times more 

680
00:35:24,700 --> 00:35:27,600
likely to exceed their 
organizational goals. 

681
00:35:27,700 --> 00:35:31,200
We also found that Elite 
performers who met or exceeded 

682
00:35:31,200 --> 00:35:34,200
their reliability targets. 
I'm going to lead performer 

683
00:35:34,200 --> 00:35:36,100
software delivery a meeting or 
exceeding. 

684
00:35:36,100 --> 00:35:40,000
My reliability targets. 
I'm twice as likely to have 

685
00:35:40,000 --> 00:35:42,900
security integrated into my 
development process. 

686
00:35:43,200 --> 00:35:46,300
That's huge. 
I think we often think of 

687
00:35:46,300 --> 00:35:50,300
security as the thing to slow us
down and let security as the 

688
00:35:50,300 --> 00:35:53,200
department of. 
No that's not what security 

689
00:35:53,200 --> 00:35:54,400
should be. 
It's not work security. 

690
00:35:54,500 --> 00:35:57,400
Has to be. 
And in fact that when we Embrace

691
00:35:57,500 --> 00:36:00,700
better, security practices, when
we really shift left on 

692
00:36:00,700 --> 00:36:04,400
security, we see that could help
us speed everything up. 

693
00:36:04,700 --> 00:36:08,700
So we really investigated 
specific practices like testing 

694
00:36:08,700 --> 00:36:11,200
for security. 
Can your developers run a test? 

695
00:36:11,200 --> 00:36:13,900
That would validate that the 
code that they've written 

696
00:36:14,000 --> 00:36:16,200
follows the right security 
policies? 

697
00:36:16,500 --> 00:36:19,300
Are you working together with 
the Security Professionals 

698
00:36:19,300 --> 00:36:23,200
within your organization? 
I really look at this as my role

699
00:36:23,200 --> 00:36:26,900
is a security and Engineer or 
security, professional has 

700
00:36:26,900 --> 00:36:31,000
changed from I'm responsible for
everything too. 

701
00:36:31,300 --> 00:36:35,600
I'm responsible for enabling the
developers and enabling The 

702
00:36:35,600 --> 00:36:41,500
Operators to build and run more.
Secure systems may be as a 

703
00:36:41,500 --> 00:36:44,500
security professional. 
I'm also responsible for 

704
00:36:44,500 --> 00:36:49,000
providing pre-approved code 
whether that's libraries or open

705
00:36:49,000 --> 00:36:52,700
source packages, that week 
certified you can use these 

706
00:36:52,700 --> 00:36:54,300
without having to go through 
another word. 

707
00:36:54,500 --> 00:36:57,700
You process. 
These are agreed upon standards 

708
00:36:57,700 --> 00:37:00,900
that we can use within the 
organization, all of that really

709
00:37:00,900 --> 00:37:03,900
helps Drive the security 
practices and then that 

710
00:37:03,900 --> 00:37:07,800
organizational performance. 
Yeah, I can now see the relation

711
00:37:07,800 --> 00:37:10,600
with the key metrics. 
So, reliabilities one aspect 

712
00:37:10,600 --> 00:37:13,500
where security I should, he's 
helping a lot where if you are 

713
00:37:13,500 --> 00:37:16,400
more reliable, basically, you 
are also more secure in terms of

714
00:37:16,400 --> 00:37:19,900
maybe a software deployment and 
maybe architecture in the sense 

715
00:37:19,900 --> 00:37:22,300
that people won't be able to 
attack it so much. 

716
00:37:22,600 --> 00:37:25,500
Speaking about culture, the most
Bonding and devops. 

717
00:37:25,500 --> 00:37:28,400
So this year, there's also 
things about burnout and maybe 

718
00:37:28,400 --> 00:37:31,200
due to pandemic as well, we can 
see the relation to that. 

719
00:37:31,300 --> 00:37:34,000
So what are the key highlights 
of this cultural aspect this 

720
00:37:34,000 --> 00:37:36,000
year? 
Yeah, for sure. 

721
00:37:36,200 --> 00:37:39,800
The first thing that I want to 
just be very specific on the 

722
00:37:39,800 --> 00:37:41,400
door. 
Research program is about 

723
00:37:41,400 --> 00:37:45,600
software delivery operations. 
We are all globally working 

724
00:37:45,600 --> 00:37:49,200
under a pandemic. 
We leave the research to how has

725
00:37:49,200 --> 00:37:51,800
the pandemic affected software 
delivery teams. 

726
00:37:51,800 --> 00:37:56,600
We leave that to the pandemic 
researchers but We focus on, is 

727
00:37:56,600 --> 00:37:59,800
this other question? 
So first did we see a downturn 

728
00:37:59,800 --> 00:38:03,400
or a drop in software delivery 
performance overall, we did not 

729
00:38:03,400 --> 00:38:06,300
see, in fact, we see teams 
continuing to improve. 

730
00:38:06,500 --> 00:38:09,600
Actually, we could look to our 
peers, the peers that are also 

731
00:38:09,600 --> 00:38:12,900
studying developers. 
So GitHub actually released a 

732
00:38:12,908 --> 00:38:15,700
report in 2020. 
That shows an increase in 

733
00:38:15,700 --> 00:38:19,000
developer activity as measured 
by things like pushes pull 

734
00:38:19,000 --> 00:38:21,400
requests reviewed, pull 
requests, all of this. 

735
00:38:21,700 --> 00:38:24,300
So even GitHub is seeing these 
numbers. 

736
00:38:24,400 --> 00:38:27,400
Improving. 
We also looked at this question 

737
00:38:27,400 --> 00:38:31,000
of burnout, how are you feeling?
And really for Burnout. 

738
00:38:31,000 --> 00:38:34,300
One of the things that we talk 
about is what is your ability to

739
00:38:34,300 --> 00:38:37,300
disconnect from work? 
Because if you can't disconnect 

740
00:38:37,300 --> 00:38:40,400
from work, like work is 
occupying, your mental space. 

741
00:38:40,400 --> 00:38:43,000
All the time. 
What we found was that teams 

742
00:38:43,000 --> 00:38:46,500
with a generative team culture, 
where a team culture, that's 

743
00:38:46,500 --> 00:38:50,800
really focused on the mission. 
Those teams that also were 

744
00:38:50,800 --> 00:38:55,000
composed of people who felt 
included, and like they, Long 

745
00:38:55,000 --> 00:38:59,000
time on part of their team, 
those teams were half as likely 

746
00:38:59,000 --> 00:39:02,200
to experience, burnout, even 
during the pandemic. 

747
00:39:02,700 --> 00:39:06,400
So, overall, we saw burnt-out go
up but we saw that those teams 

748
00:39:06,400 --> 00:39:10,200
with generative culture, where 
the individuals on the team felt

749
00:39:10,200 --> 00:39:13,400
included, like they belong to 
this part of the team that cut 

750
00:39:13,400 --> 00:39:16,200
burnout in half. 
So I can also relate to it. 

751
00:39:16,400 --> 00:39:19,000
One of the episodes that I have 
in the past, with the present, 

752
00:39:19,000 --> 00:39:21,800
also covers about the research 
that done by Google. 

753
00:39:22,100 --> 00:39:24,600
So things like generative 
culture, you mentioned Right 

754
00:39:24,600 --> 00:39:27,000
things like being included, have
a sense of mission, 

755
00:39:27,000 --> 00:39:28,900
psychological safety, and things
like that. 

756
00:39:29,100 --> 00:39:32,200
So I think if people wants to 
improve their cultural aspect as

757
00:39:32,200 --> 00:39:34,500
well, I'll make sure to put that
in the show notes as well so 

758
00:39:34,500 --> 00:39:36,700
that you can also refer how to 
improve it. 

759
00:39:36,900 --> 00:39:39,900
We're talking a lot about the 
findings, the key Matrix. 

760
00:39:40,200 --> 00:39:43,300
I know that some people may not 
be there in terms of performance

761
00:39:43,300 --> 00:39:46,200
and all that. 
So what will be some of your key

762
00:39:46,200 --> 00:39:49,300
advice for them to get started? 
Or where should they improve 

763
00:39:49,300 --> 00:39:51,900
first? 
Yeah, this is a really good 

764
00:39:51,900 --> 00:39:54,500
question, unfortunately. 
Henry, the answer is Where 

765
00:39:54,500 --> 00:39:58,000
should they improve first? 
It depends, but the door 

766
00:39:58,000 --> 00:39:59,900
framework can help you with 
this. 

767
00:40:00,300 --> 00:40:03,100
Because what we actually do is 
investigate these various 

768
00:40:03,100 --> 00:40:07,300
capabilities and help draw those
predictive connections. 

769
00:40:07,600 --> 00:40:11,300
So I can say, for example, that 
we know that, if we want to 

770
00:40:11,300 --> 00:40:14,200
improve our organizational 
performance software, delivery 

771
00:40:14,200 --> 00:40:17,100
and operations, performance 
drives, organizational 

772
00:40:17,100 --> 00:40:19,000
performance. 
Well, how do we get better at 

773
00:40:19,000 --> 00:40:20,500
software delivery and 
operations? 

774
00:40:20,800 --> 00:40:23,500
One way is by practicing 
continuous delivery. 

775
00:40:23,900 --> 00:40:25,100
Okay. 
But how do we get better at 

776
00:40:25,100 --> 00:40:27,000
continuous delivery? 
Well, there are bunch of 

777
00:40:27,000 --> 00:40:30,700
technical practices that drive 
continuous delivery, things like

778
00:40:30,900 --> 00:40:33,600
trunk base development or 
continuous integration. 

779
00:40:34,000 --> 00:40:38,100
The research program itself 
looks into about 30 different 

780
00:40:38,100 --> 00:40:41,700
capabilities like this whether 
it's truck-based development or 

781
00:40:42,200 --> 00:40:46,000
generative culture or 
documentation, lots and lots of 

782
00:40:46,000 --> 00:40:48,900
different capabilities. 
So I want to take you back to 

783
00:40:48,900 --> 00:40:51,500
that quick check. 
Not only will the Quick Check, 

784
00:40:51,500 --> 00:40:55,200
tell you, where do you sit? 
But it will also So make a 

785
00:40:55,200 --> 00:40:58,700
recommendation for you if you 
are a medium performer, here are

786
00:40:58,700 --> 00:41:03,300
the three capabilities that are 
likely to have a big impact on 

787
00:41:03,300 --> 00:41:07,600
your team and then there's even 
further, follow-up questions 

788
00:41:07,600 --> 00:41:10,000
into each one of those 
capabilities to help you 

789
00:41:10,000 --> 00:41:14,300
prioritize but at the end of the
day, the best thing to do is to 

790
00:41:14,300 --> 00:41:18,700
sit back and look at the body, 
all of the capabilities and have

791
00:41:18,700 --> 00:41:21,100
an honest assessment of your 
team. 

792
00:41:21,400 --> 00:41:24,200
How are we doing with each one 
of these capabilities? 

793
00:41:24,300 --> 00:41:27,100
These what you're looking for, 
is the one that's holding you 

794
00:41:27,100 --> 00:41:31,200
back that constraint what's 
constraining, you focus your 

795
00:41:31,200 --> 00:41:33,800
improvement there. 
So that might mean, you need to 

796
00:41:33,800 --> 00:41:36,700
focus your improvement by 
improving your testing. 

797
00:41:37,100 --> 00:41:40,300
It might mean, you need to lean 
into something like blameless, 

798
00:41:40,300 --> 00:41:42,200
post-mortems. 
And what can you learn from 

799
00:41:42,200 --> 00:41:44,900
incidents? 
One of these things, maybe is 

800
00:41:44,900 --> 00:41:48,600
the thing that's holding you 
back, so make an investment in 

801
00:41:48,600 --> 00:41:52,700
improving in that area. 
And so together with the report 

802
00:41:52,700 --> 00:41:55,900
and the quick check, you can 
Really good insights into what 

803
00:41:55,900 --> 00:41:59,400
the various capabilities are and
then decide, which is right for 

804
00:41:59,400 --> 00:42:02,600
your team. 
That finally, it depends on the 

805
00:42:02,600 --> 00:42:05,300
context of each team. 
So I really agree with that. 

806
00:42:05,500 --> 00:42:08,500
Speaking about a quick check 
again, make sure to try it out 

807
00:42:08,600 --> 00:42:10,600
because there will be 
recommendations as well. 

808
00:42:10,800 --> 00:42:13,200
The state of Devil's report 
itself covers a lot of these 

809
00:42:13,200 --> 00:42:16,200
technical aspect and if I may I 
add one more thing which is the 

810
00:42:16,200 --> 00:42:19,500
accelerate book written by the 
original authors of the Dora 

811
00:42:19,500 --> 00:42:22,900
report in the cold porcelain. 
So, in the accident book, it 

812
00:42:22,900 --> 00:42:26,000
also covers all the The 
fundamental basic important 

813
00:42:26,000 --> 00:42:29,200
technical practices, including 
also the cultural aspect which I

814
00:42:29,200 --> 00:42:31,700
think is a good resource for 
people to get started. 

815
00:42:32,200 --> 00:42:35,000
Absolutely agree that accelerate
book is is incredible. 

816
00:42:35,000 --> 00:42:38,300
You should absolutely read that.
The other thing, I think while 

817
00:42:38,300 --> 00:42:41,300
we're on the topic on this site,
you have access to all of the 

818
00:42:41,300 --> 00:42:45,100
state of devops reports. 
And just because the report says

819
00:42:45,100 --> 00:42:49,400
2017 on, it does not mean that 
report is outdated, some of the 

820
00:42:49,400 --> 00:42:52,700
capabilities investigated. 
There are really important. 

821
00:42:52,800 --> 00:42:54,800
And I think, at the end of the 
day, Really what? 

822
00:42:54,800 --> 00:42:59,000
The door research program is 
trying to instill in all of us. 

823
00:42:59,100 --> 00:43:04,000
As an industry, is the practice 
and the mindset of continuous 

824
00:43:04,000 --> 00:43:06,900
Improvement. 
Let's design an experiment. 

825
00:43:06,900 --> 00:43:09,900
We believe that by getting 
better at truck-based 

826
00:43:09,900 --> 00:43:12,700
development. 
We will improve our software, 

827
00:43:12,700 --> 00:43:14,900
delivery operations, 
performance, and drive our 

828
00:43:14,900 --> 00:43:19,000
organizational performance. 
Let's test that theory and 

829
00:43:19,000 --> 00:43:21,900
improve our truck based 
development, and then reassess. 

830
00:43:22,200 --> 00:43:25,800
So let's measure again, we Find 
what's holding us back. 

831
00:43:25,900 --> 00:43:29,500
Make an improvement. 
We reassess so get into this 

832
00:43:29,600 --> 00:43:33,400
Loop in this practice of 
identifying where are we? 

833
00:43:33,500 --> 00:43:36,600
What's holding us back? 
Let's make a change to improve. 

834
00:43:37,200 --> 00:43:39,500
I love that the way you 
mentioned about continuous 

835
00:43:39,500 --> 00:43:42,400
Improvement aspect. 
It comes back to the lean and 

836
00:43:42,400 --> 00:43:46,000
agile principles and raised that
way you need to also do 

837
00:43:46,000 --> 00:43:49,600
experiments test it out, any 
proof based on that findings. 

838
00:43:49,900 --> 00:43:53,500
Citing these feedback loop is 
really critical in devops lean 

839
00:43:53,600 --> 00:43:55,100
and agile. 
Mindset. 

840
00:43:55,300 --> 00:43:57,700
So, Nathan has been a really 
Pleasant conversation. 

841
00:43:57,700 --> 00:44:00,300
I learned a lot about the state 
of divorce report especially for

842
00:44:00,300 --> 00:44:02,600
this year. 
So unfortunately we reach the 

843
00:44:02,600 --> 00:44:06,000
end of our conversation, but 
before I let you go, I have this

844
00:44:06,000 --> 00:44:07,800
one. 
Normal question that I ask all 

845
00:44:07,800 --> 00:44:10,700
my guests which is to share your
three technical leadership with 

846
00:44:10,700 --> 00:44:12,600
the. 
So think of it, like an advice 

847
00:44:12,600 --> 00:44:14,500
for the listeners hear from your
experience. 

848
00:44:14,500 --> 00:44:16,800
What are the things that they 
should be thinking about? 

849
00:44:17,300 --> 00:44:19,000
Yes. 
All right, you freeze. 

850
00:44:19,000 --> 00:44:22,000
It also is technical leadership,
so I'm going to start with some 

851
00:44:22,000 --> 00:44:23,900
really strong advice for 
leaders. 

852
00:44:24,300 --> 00:44:28,200
And that advice is this your 
team knows, what needs to be 

853
00:44:28,200 --> 00:44:33,500
done to improve, listen to them,
ask them, what do we need to do 

854
00:44:33,500 --> 00:44:36,900
to improve? 
Give them audacious goals and 

855
00:44:36,900 --> 00:44:40,200
let them get to work. 
So your job as a leader is to 

856
00:44:40,200 --> 00:44:43,600
create that time and space and 
give them the resources that 

857
00:44:43,600 --> 00:44:47,300
they need to improve. 
Now, on the flip side of that, 

858
00:44:47,400 --> 00:44:50,000
I'll give some advice for the 
practitioners, the individual 

859
00:44:50,000 --> 00:44:52,900
contributors, you know what 
needs to be done. 

860
00:44:52,900 --> 00:44:56,300
Speak up. 
Share this with your leadership.

861
00:44:56,300 --> 00:45:00,700
So drive that message forward 
consult with your team and learn

862
00:45:00,700 --> 00:45:03,200
from each other and that lured 
from each other. 

863
00:45:03,300 --> 00:45:06,900
To me, that's the third and 
probably the most important each

864
00:45:06,900 --> 00:45:10,600
and every one of us comes to 
work with a completely different

865
00:45:10,600 --> 00:45:13,700
set of lived experience, a 
completely different set of 

866
00:45:13,700 --> 00:45:16,500
knowledge. 
It's really important that we 

867
00:45:16,500 --> 00:45:20,000
all share and learn from one 
another throw out. 

868
00:45:20,000 --> 00:45:22,200
The org chart throw out the 
structure. 

869
00:45:22,500 --> 00:45:25,800
Let's have those conversations. 
Ins make sure that everyone 

870
00:45:25,800 --> 00:45:29,900
feels included and like they 
belong as part of this team 

871
00:45:30,200 --> 00:45:34,500
because in truth, they do and 
we're better because of all of 

872
00:45:34,500 --> 00:45:36,800
us. 
And when we share our insights, 

873
00:45:36,800 --> 00:45:40,200
in our ideas, with one another 
side, we don't get my three. 

874
00:45:40,700 --> 00:45:43,000
Now, I must say it's a beautiful
way of sharing about this 

875
00:45:43,000 --> 00:45:45,000
wisdom. 
It's all interrelated. 

876
00:45:45,100 --> 00:45:48,000
So the first is like, your team 
probably knows what to improve. 

877
00:45:48,000 --> 00:45:51,300
So, do ask the teeth and for the
team members itself speak out, 

878
00:45:51,300 --> 00:45:54,500
actually, what to improve just 
speak up to your leaders and The

879
00:45:54,500 --> 00:45:55,800
end we all learn from each 
other. 

880
00:45:56,000 --> 00:45:59,000
So really beautiful way of 
explaining this wisdom so 

881
00:45:59,000 --> 00:46:02,400
blatant for people who loves to 
connect more with you talking 

882
00:46:02,400 --> 00:46:05,500
more about devops report or 
anything related to devops or 

883
00:46:05,500 --> 00:46:08,400
Dora or maybe Google Cloud, when
they can find you online. 

884
00:46:09,100 --> 00:46:10,800
Yes. 
The best place to find me is 

885
00:46:10,800 --> 00:46:13,300
Twitter and their I'm at Nathan 
Harvey. 

886
00:46:13,700 --> 00:46:17,300
I will just warn you that my 
father, misspelled my name or 

887
00:46:17,300 --> 00:46:21,300
chosen non-traditional spelling 
so it's n-ath. 

888
00:46:24,200 --> 00:46:27,300
Ey, that's my Twitter handle and
then you can find me on LinkedIn

889
00:46:27,300 --> 00:46:30,100
as well. 
So, search for my name, Nathan 

890
00:46:30,100 --> 00:46:32,400
Harvey with Annie, and you'll 
find me. 

891
00:46:32,600 --> 00:46:35,100
So, those are two good ways and 
Henry, I'm sure you can put some

892
00:46:35,100 --> 00:46:37,600
links in the show notes there on
how folks can reach me as well. 

893
00:46:38,300 --> 00:46:39,900
Definitely, I'll put it in the 
show notes. 

894
00:46:39,900 --> 00:46:42,200
So Nathan, thanks so much again 
for sharing your knowledge and 

895
00:46:42,200 --> 00:46:44,100
expertise year. 
Thank you so much. 

896
00:46:44,600 --> 00:46:46,800
Anyway, it's my pleasure. 
Thank you so much for having me,

897
00:46:46,800 --> 00:46:49,800
and thank you for your 
dedication to Tech lead Journal.

898
00:46:49,800 --> 00:46:53,000
I think we're going these types 
of insights and conversations to

899
00:46:53,000 --> 00:46:55,900
the broader community. 
You're doing a real service to 

900
00:46:55,900 --> 00:46:57,300
everyone. 
Thank you so much. 

901
00:46:57,700 --> 00:47:03,000
It's been my pleasure. 
Thank you for listening to this 

902
00:47:03,000 --> 00:47:05,700
episode and for staying right 
till the end. 

903
00:47:05,800 --> 00:47:08,800
If you're highly enjoyed, please
share it with your friends and 

904
00:47:08,800 --> 00:47:12,100
colleagues who you think would 
also benefit from listening to 

905
00:47:12,100 --> 00:47:14,400
this episode. 
And if you're new to the 

906
00:47:14,400 --> 00:47:17,700
podcast, make sure to subscribe 
and leave me your valuable 

907
00:47:17,700 --> 00:47:21,100
review and feedback. 
It really, really helps me a lot

908
00:47:21,100 --> 00:47:23,600
in order to grow these podcasts 
better. 

909
00:47:24,200 --> 00:47:27,400
You can also find the full show 
notes of this conversation on 

910
00:47:27,400 --> 00:47:31,100
the episode page, at Tech Legion
of the death website including 

911
00:47:31,200 --> 00:47:34,200
Doing the full transcript, 
interesting quotes, and links to

912
00:47:34,200 --> 00:47:37,100
the resources and mentions from 
the conversation. 

913
00:47:37,600 --> 00:47:40,500
And lastly make sure to 
subscribe to the shows mailing 

914
00:47:40,500 --> 00:47:44,300
list on technology know the deaf
to get notified for any future 

915
00:47:44,300 --> 00:47:46,500
episodes. 
Stay tuned for the next 

916
00:47:46,500 --> 00:47:49,700
technique Journal episode. 
And until then goodbye,