1
00:00:00,500 --> 00:00:06,300
I think the strength of Surrey 
is exactly in the ability to 

2
00:00:06,300 --> 00:00:10,300
bring about that alignment on 
operation concerns between the 

3
00:00:10,300 --> 00:00:12,800
product management product 
development and product 

4
00:00:12,800 --> 00:00:16,500
operations, whereas other 
methodologies, and great work 

5
00:00:16,500 --> 00:00:19,000
that we talked about before, I 
had bought their strings, even 

6
00:00:19,000 --> 00:00:23,600
other areas, like I didn't call 
bit their strength is designed 

7
00:00:23,600 --> 00:00:26,000
the ID functional Enterprise 
develops. 

8
00:00:26,100 --> 00:00:28,900
The strength is in the 
philosophy of or like delivery, 

9
00:00:29,200 --> 00:00:32,299
whereas Sorry, really. 
I think the strength of the 

10
00:00:32,299 --> 00:00:37,900
methodology is in the alignment 
on operational concerns, the 

11
00:00:37,900 --> 00:00:46,700
entire organization. 
Hey, everyone, my name is Henry 

12
00:00:46,700 --> 00:00:50,500
Surya with Robin. 
And you're listening to the 

13
00:00:50,500 --> 00:00:53,800
technology, you know, podcast 
the show where I'll be bringing 

14
00:00:53,800 --> 00:00:56,900
you the greatest technical 
leaders practitioners and 

15
00:00:56,900 --> 00:01:00,700
thought leaders in the industry 
to discuss about their Journey 

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

17
00:01:05,400 --> 00:01:08,900
highly performing technical team
and to make an impact in your 

18
00:01:08,900 --> 00:01:12,200
personal work. 
So let's dive into our Journal. 

19
00:01:17,200 --> 00:01:20,500
Hello again, my friends and my 
listeners, welcome to the peclet

20
00:01:20,500 --> 00:01:23,500
you know, podcast the show where
you can learn about technical 

21
00:01:23,500 --> 00:01:26,900
leadership and Excellence from 
my conversations with great 

22
00:01:26,900 --> 00:01:28,700
thought leaders in the tech 
industry. 

23
00:01:29,100 --> 00:01:31,500
If this is your first time 
listening to tackle a journal, 

24
00:01:31,900 --> 00:01:35,200
Please Subscribe and follow the 
show on your podcast app and on 

25
00:01:35,200 --> 00:01:38,600
LinkedIn, Twitter and Instagram 
and to support my journey. 

26
00:01:38,600 --> 00:01:42,400
Creating this podcast, subscribe
as a patron at technology node. 

27
00:01:42,600 --> 00:01:46,700
Dev slash Patron. 
My guest for today's episode is 

28
00:01:46,700 --> 00:01:50,100
dr. 
Vladislav UK's, doctor Vlad is 

29
00:01:50,100 --> 00:01:53,800
the head of R&D at Siemens 
health and years and the author 

30
00:01:53,800 --> 00:01:58,200
of establishing a sorry 
foundations in this episode dr. 

31
00:01:58,200 --> 00:02:01,800
Flat shared insights on how to 
establish a sorry foundations 

32
00:02:01,800 --> 00:02:05,400
from scratch based on his 
first-hand experience at Siemens

33
00:02:05,400 --> 00:02:08,699
Health in years and the concepts
described in his book. 

34
00:02:09,300 --> 00:02:12,500
We started by discussing the 
basic Sr a concept and how 

35
00:02:12,700 --> 00:02:17,000
Differs from the other related 
Concepts such as I tell Co bit 

36
00:02:17,000 --> 00:02:20,700
and devops Doctor flat then 
explained in depth. 

37
00:02:20,700 --> 00:02:24,200
How is our implementation can 
help to create an alignment 

38
00:02:24,300 --> 00:02:27,600
between the product management, 
product development, and product

39
00:02:27,600 --> 00:02:31,400
operations teams. 
He also shared the importance of

40
00:02:31,400 --> 00:02:35,500
having internal SRE coaches to 
facilitate this transformation. 

41
00:02:35,800 --> 00:02:39,500
And when an organization can 
start to realize the benefits of

42
00:02:39,500 --> 00:02:43,600
implementing a, sorry in the 
latter half of Our conversation,

43
00:02:43,800 --> 00:02:46,100
dr. 
Philip walked us through how we 

44
00:02:46,100 --> 00:02:47,800
can begin. 
Aracari journey. 

45
00:02:48,300 --> 00:02:51,800
Make further progress in the 
journey and measure the success 

46
00:02:51,800 --> 00:02:56,600
of our SRE implementation. 
Also do not miss his sharing on 

47
00:02:56,600 --> 00:03:00,400
how a sorry implementation can 
help to improve reliability in a

48
00:03:00,408 --> 00:03:02,800
stringent industry, such as 
health care. 

49
00:03:03,500 --> 00:03:05,800
I really enjoyed my conversation
with dr. 

50
00:03:05,800 --> 00:03:09,100
Vlad though, there are quite a 
number of resources, explaining 

51
00:03:09,100 --> 00:03:12,500
about SRE concept, not many 
provides practical. 

52
00:03:12,600 --> 00:03:16,300
A step-by-step guide on how to 
implement it especially for the 

53
00:03:16,300 --> 00:03:19,900
traditional organizations that 
need to evolve from their legacy

54
00:03:19,900 --> 00:03:24,200
operations and practices I 
especially admired octave left 

55
00:03:24,200 --> 00:03:27,800
for writing an SRE book despite 
not having the experience 

56
00:03:27,800 --> 00:03:30,900
working at Google. 
The place where the SRE concept 

57
00:03:30,900 --> 00:03:35,500
and practices were created dr. 
Vlad successfully, embark on the

58
00:03:35,500 --> 00:03:39,300
journey to implement a sorry, in
his organization and shared his 

59
00:03:39,300 --> 00:03:43,100
first-hand experience in his 
book and this episode So, if you

60
00:03:43,100 --> 00:03:46,500
liked this episode, make sure to
also check out his book as well.

61
00:03:47,100 --> 00:03:50,500
And as always, if you find this 
episode useful, please help 

62
00:03:50,500 --> 00:03:52,300
share it with your friends and 
colleagues. 

63
00:03:52,500 --> 00:03:55,300
So they can also benefit from 
listening to this episode. 

64
00:03:55,700 --> 00:03:58,900
I always appreciate your support
in sharing and spreading this 

65
00:03:58,900 --> 00:04:02,600
podcast, and the knowledge to 
more people, and don't forget to

66
00:04:02,600 --> 00:04:05,500
give this podcast a rating. 
If you are listening on a 

67
00:04:05,500 --> 00:04:09,400
podcast and Spotify. 
Let's continue the conversation 

68
00:04:09,400 --> 00:04:11,700
with dr. 
Blab, after hearing some words 

69
00:04:11,700 --> 00:04:15,600
from our answers, today's 
episode is proudly sponsored by 

70
00:04:15,600 --> 00:04:18,500
skills matter. 
The global community and events 

71
00:04:18,500 --> 00:04:21,100
platform. 
With more than 100,000 software 

72
00:04:21,100 --> 00:04:24,800
professionals here members. 
Can organize their learning 

73
00:04:24,800 --> 00:04:27,200
experiences around the 
technology topics. 

74
00:04:27,200 --> 00:04:31,000
They care about most you get 
on-demand access to their latest

75
00:04:31,000 --> 00:04:34,300
content thought, leadership 
insights, as well, as the 

76
00:04:34,300 --> 00:04:38,500
exciting schedule of tech events
running across all time zones. 

77
00:04:38,900 --> 00:04:42,400
So whether devops our data 
science is your bus or you are 

78
00:04:42,600 --> 00:04:46,300
And a functional programming or 
all things Cloud you can make 

79
00:04:46,300 --> 00:04:50,100
real connections with people who
share your interests head on 

80
00:04:50,100 --> 00:04:53,100
over to skills method or Cam to 
become part of the tech 

81
00:04:53,100 --> 00:04:55,200
community that matters most to 
you. 

82
00:04:55,500 --> 00:04:58,700
It's free to join and you will 
find it easy to keep up with the

83
00:04:58,700 --> 00:05:03,400
latest tech Trends. 
Hello everyone. 

84
00:05:03,400 --> 00:05:05,400
Welcome back to another new 
episode of the package. 

85
00:05:05,400 --> 00:05:08,700
You know, podcast today, I'm 
very excited to meet someone who

86
00:05:08,700 --> 00:05:12,100
wrote a book about SRE which is 
titled establishing a sorry 

87
00:05:12,100 --> 00:05:12,900
Foundation. 
Action. 

88
00:05:12,900 --> 00:05:16,400
But he is actually not someone 
coming from Google as probably 

89
00:05:16,400 --> 00:05:18,700
most of you would have known as 
there is a concept that is 

90
00:05:18,700 --> 00:05:20,700
introduced and widely 
popularized by Google. 

91
00:05:21,000 --> 00:05:23,800
But today we'll meet someone who
actually didn't come from Google

92
00:05:23,800 --> 00:05:27,100
but wrote a good book about heh,
sorry his name is dr. 

93
00:05:27,100 --> 00:05:30,600
Vladislav yuccas. 
He is currently the head of R&D 

94
00:05:30,600 --> 00:05:34,200
at Siemens Health in ears, so 
I'm looking forward for this 

95
00:05:34,200 --> 00:05:36,000
conversation. 
Dr. Flat and hopefully we have a

96
00:05:36,008 --> 00:05:38,300
great conversation about SRE in 
general. 

97
00:05:39,500 --> 00:05:40,700
Yep. 
Definitely. 

98
00:05:40,800 --> 00:05:43,600
I really thank you very much for
having me on the show. 

99
00:05:43,700 --> 00:05:48,400
I'm really happy that it worked 
out that we can talk about SRE 

100
00:05:48,400 --> 00:05:53,000
on this really wonderful podcast
which I wasn't aware of before. 

101
00:05:53,000 --> 00:05:56,800
And now that I've seen all the 
great speakers from previous 

102
00:05:56,800 --> 00:06:01,100
episodes, I'm really honored to 
be able to talk to you and be on

103
00:06:01,100 --> 00:06:03,800
the show. 
I keep for your kind words. 

104
00:06:04,100 --> 00:06:06,900
So dr. 
Flat, I always love to ask my 

105
00:06:06,900 --> 00:06:09,100
guess to actually share a little
bit more about yourself. 

106
00:06:09,600 --> 00:06:12,600
Maybe sharing more about your 
career highlights, or any 

107
00:06:12,600 --> 00:06:15,300
turning points that you think 
are interesting for us to learn 

108
00:06:15,300 --> 00:06:17,100
from. 
Yeah. 

109
00:06:17,200 --> 00:06:22,500
So I spent my career so far in 
the healthcare domain with the 

110
00:06:22,500 --> 00:06:25,500
Siemens healthiest, Siemens held
in years is a german-based 

111
00:06:25,500 --> 00:06:29,900
company that produces Walt solve
Medical Imaging devices. 

112
00:06:29,900 --> 00:06:32,400
So things like, for instance can
hit it from older files or 

113
00:06:32,400 --> 00:06:36,000
magnetic, resonance devices or 
ultrasound devices. 

114
00:06:36,000 --> 00:06:40,500
And so on there is lots of 
software that associated with 

115
00:06:40,500 --> 00:06:42,700
those devices. 
So there is a lot of one premise

116
00:06:42,700 --> 00:06:45,700
software. 
First of all, that's driving the

117
00:06:45,700 --> 00:06:49,700
devices themselves so that you 
can do scans on those machines. 

118
00:06:50,100 --> 00:06:53,200
Then there is what's a post 
processing on-premise software 

119
00:06:53,200 --> 00:06:56,200
which is software that is used 
by the Physicians inside the 

120
00:06:56,200 --> 00:06:59,500
hospital departments but not 
necessarily directly at the 

121
00:06:59,500 --> 00:07:01,700
scandalous. 
Then there is also Cloud 

122
00:07:01,700 --> 00:07:06,800
software that software, usually 
manages, the fleet's of those 

123
00:07:06,900 --> 00:07:12,800
cameras and helps Personnel in 
the hospitals to around the 

124
00:07:12,800 --> 00:07:15,900
machines, more efficiently in 
the inside. 

125
00:07:16,400 --> 00:07:20,400
So I worked in the on-premise 
software at Siemens Health in 

126
00:07:20,407 --> 00:07:22,700
years. 
And then, at some point, I moved

127
00:07:22,800 --> 00:07:25,800
into the cloud software. 
That was also. 

128
00:07:25,800 --> 00:07:29,700
The very beginning of the cloud 
Journey for simultaneous. 

129
00:07:29,700 --> 00:07:33,200
Basically, over the years, we 
built the first cloud-based 

130
00:07:33,200 --> 00:07:35,600
platform for medical 
applications for the entire 

131
00:07:35,600 --> 00:07:41,600
organization and now every This 
units that wants to build a 

132
00:07:41,600 --> 00:07:43,900
cloud application, they build it
on top. 

133
00:07:43,900 --> 00:07:47,100
Also the teamplay digital Health
platform, which would build. 

134
00:07:47,500 --> 00:07:51,200
And that was also the product 
where we started exploring how 

135
00:07:51,200 --> 00:07:54,000
to, actually operate. 
Such a platform at scale and 

136
00:07:54,000 --> 00:07:56,600
this is where it's a reclaim it 
and this is where the whole 

137
00:07:56,600 --> 00:07:59,000
story started that led to the 
book. 

138
00:08:00,400 --> 00:08:02,800
Thanks for sharing your journey.
So one thing that I pick up you 

139
00:08:02,800 --> 00:08:05,700
have been in this healthcare 
industry for a long time and 

140
00:08:05,700 --> 00:08:09,100
actually you implement SRE 
Concept in it, I think. 

141
00:08:09,200 --> 00:08:12,100
Most of us are educated about 
implementing a sorry for 

142
00:08:12,100 --> 00:08:14,700
cloud-based systems. 
So hopefully today we'll be 

143
00:08:14,700 --> 00:08:17,200
discussing a little bit more, 
maybe from your journey in 

144
00:08:17,200 --> 00:08:18,900
terminating it. 
In the healthcare industry which

145
00:08:18,900 --> 00:08:21,600
is probably quite stringent and 
it's kind of like 

146
00:08:21,600 --> 00:08:23,700
mission-critical, right? 
So you can't have it to be 

147
00:08:23,700 --> 00:08:26,200
failure. 
First of all, how did you come 

148
00:08:26,200 --> 00:08:29,400
about with this as re concept 
because you didn't come from 

149
00:08:29,400 --> 00:08:31,500
Google? 
And obviously, you come from a 

150
00:08:31,500 --> 00:08:33,900
healthcare industry which is 
traditional maybe tell us more a

151
00:08:33,908 --> 00:08:36,500
little bit on this journey. 
Yep. 

152
00:08:36,500 --> 00:08:41,299
Yep, so as I mentioned before, 
the build up all day, pimply 

153
00:08:41,299 --> 00:08:45,500
digital Health platform was new 
for the company. 

154
00:08:45,800 --> 00:08:50,900
We didn't have Cloud operations 
before and then also we didn't 

155
00:08:50,900 --> 00:08:55,500
have the skills in order to be 
able to operate such a black 

156
00:08:55,500 --> 00:08:59,200
pump because so far, the 
majority of the software 

157
00:08:59,300 --> 00:09:01,200
produced by the company was on 
brevis. 

158
00:09:01,200 --> 00:09:04,400
And as a development team, you 
don't operate on Brenda software

159
00:09:04,400 --> 00:09:07,600
that is done by professionals. 
Personal services, which is 

160
00:09:07,600 --> 00:09:11,000
telling another organization 
that was a total paradigm shift 

161
00:09:11,000 --> 00:09:12,600
for us. 
When we understood that 

162
00:09:12,600 --> 00:09:14,500
actually, it will automatically 
work. 

163
00:09:14,800 --> 00:09:18,500
We need the development 
organization to do operations. 

164
00:09:19,300 --> 00:09:22,900
So then the next step on that 
Journey was to see. 

165
00:09:22,900 --> 00:09:26,500
Okay, how could we do this? 
We have try to operate the 

166
00:09:26,500 --> 00:09:29,200
platform. 
Just using means that came to 

167
00:09:29,200 --> 00:09:31,300
our minds. 
So we started setting up a 

168
00:09:31,308 --> 00:09:34,000
loads. 
We started promoting the idea 

169
00:09:34,000 --> 00:09:35,400
that actually, the development 
teams. 

170
00:09:35,700 --> 00:09:39,300
Need to be also to be into the 
operational aspects and not just

171
00:09:39,300 --> 00:09:42,200
developing features and we kind 
of have tried doing this for 

172
00:09:42,200 --> 00:09:45,000
several years. 
But we saw that, this is a 

173
00:09:45,000 --> 00:09:49,200
difficult idea to grow in a 
development organization that 

174
00:09:49,200 --> 00:09:50,800
has never done operations 
before. 

175
00:09:51,400 --> 00:09:55,500
Because in the mines, all the 
developers who had never touched

176
00:09:55,500 --> 00:09:57,700
operations. 
Their job is to develop 

177
00:09:57,700 --> 00:10:01,100
something in the minds of 
product managers than their job 

178
00:10:01,100 --> 00:10:03,200
is to tell the developers who 
work to develop. 

179
00:10:03,600 --> 00:10:06,400
Basically, everybody's thinking 
that there is This operations 

180
00:10:06,400 --> 00:10:10,000
Department that will do 
operations, and the operations 

181
00:10:10,000 --> 00:10:12,200
Department cannot do this 
because they don't have the 

182
00:10:12,200 --> 00:10:16,200
context and you don't have the 
internal knowledge necessary to 

183
00:10:16,300 --> 00:10:19,000
operate services. 
At some point. 

184
00:10:19,000 --> 00:10:21,700
I kind of understood that we 
need to do something different 

185
00:10:21,700 --> 00:10:26,500
in order to really grasp the 
operational aspect on the black.

186
00:10:27,000 --> 00:10:29,500
So I went to all the que con 
conference. 

187
00:10:29,500 --> 00:10:32,200
In London. 
There, there was a whole track 

188
00:10:32,200 --> 00:10:35,100
on a surgery. 
So I stayed near the delete 

189
00:10:35,100 --> 00:10:36,700
icon. 
It's on that track because I 

190
00:10:36,700 --> 00:10:39,700
knew that was the pain point 
that the organization had of the

191
00:10:39,700 --> 00:10:43,200
type. 
Then I learned a lot about it. 

192
00:10:43,200 --> 00:10:45,100
Sorry. 
But of course, that was just 

193
00:10:45,100 --> 00:10:48,300
conference knowledge after the 
conference, I kind of understood

194
00:10:48,300 --> 00:10:51,100
that this is something real. 
That there are lots of companies

195
00:10:51,100 --> 00:10:54,500
in the software industry at 
large going that way and trying 

196
00:10:54,500 --> 00:10:58,000
out this Arena. 
And since you have some success,

197
00:10:58,100 --> 00:11:01,700
however you define it with it. 
So basically I thought, okay, 

198
00:11:01,700 --> 00:11:03,600
that might be worth it. 
Right? 

199
00:11:03,600 --> 00:11:07,200
For us as well, the navigate I'm
back in the sort of started 

200
00:11:07,200 --> 00:11:09,100
learning more and more about 
this living. 

201
00:11:09,200 --> 00:11:11,000
The Google has a read books, of 
course. 

202
00:11:11,400 --> 00:11:14,800
But the trouble was that that 
was Nicholas read books while 

203
00:11:14,800 --> 00:11:16,600
great. 
I kind of saw that they were 

204
00:11:16,600 --> 00:11:20,100
describing the high end of what 
you do when you're really 

205
00:11:20,100 --> 00:11:22,100
operate services at Google 
scale. 

206
00:11:22,600 --> 00:11:25,700
Then I also read a couple of 
other books but all they were 

207
00:11:25,700 --> 00:11:28,700
kind of describing was already 
at a level that was far away 

208
00:11:28,700 --> 00:11:32,200
from where we used to be so then
I understood. 

209
00:11:32,200 --> 00:11:36,800
Okay, fine, this is great but we
need to So we're gonna start 

210
00:11:36,800 --> 00:11:40,400
small and really start seeing 
whether it's a re would be 

211
00:11:40,400 --> 00:11:43,600
applicable in an environment 
like us, which is obviously 

212
00:11:43,600 --> 00:11:47,300
different culture than Google in
different context than Google 

213
00:11:47,700 --> 00:11:50,000
and basically different 
everything compared to. 

214
00:11:51,000 --> 00:11:54,400
So then we kind of started 
adopting a sorry slowly but 

215
00:11:54,400 --> 00:11:57,300
surely making small steps 
implementing a little bit of 

216
00:11:57,300 --> 00:12:01,000
infrastructure and that them boo
to the entire organization. 

217
00:12:01,000 --> 00:12:04,900
Then operating the entire 
platform using a Serene, this is

218
00:12:04,900 --> 00:12:07,500
only joy. 
Ernie was shape, really 

219
00:12:07,500 --> 00:12:09,700
exciting, right? 
So, you learn about it in a 

220
00:12:09,700 --> 00:12:12,600
conference, you went through 
like one whole day, probably, 

221
00:12:12,800 --> 00:12:15,400
but you let it from the 
conference and you started 

222
00:12:15,400 --> 00:12:18,100
implementing it and you become 
like an author of it. 

223
00:12:18,300 --> 00:12:20,900
So I think that really speaks 
like a tremendous Journey. 

224
00:12:21,300 --> 00:12:23,900
But so far, I think many 
organizations would have been in

225
00:12:23,900 --> 00:12:26,600
your position as well, right 
from traditional company, maybe 

226
00:12:26,600 --> 00:12:29,300
from Health Care, maybe from 
some companies, which are not 

227
00:12:29,300 --> 00:12:32,200
born on the internet era. 
In the first few chapters of the

228
00:12:32,200 --> 00:12:34,100
book. 
You actually try to compare a 

229
00:12:34,100 --> 00:12:38,000
sorry with the No way off you 
doing it operations, which are 

230
00:12:38,000 --> 00:12:42,000
like, ideal covid and also 
devops in general as a culture. 

231
00:12:42,000 --> 00:12:45,700
So maybe if you can give some 
context and summary what is the 

232
00:12:45,700 --> 00:12:48,400
difference of a sorry with all 
these other Frameworks? 

233
00:12:48,600 --> 00:12:51,500
Yeah. 
So when I was writing the 

234
00:12:51,500 --> 00:12:54,900
introduction to the book, I 
understood that there is no just

235
00:12:54,900 --> 00:12:58,200
a sorry which kind of was my 
focus before because I was the 

236
00:12:58,200 --> 00:13:00,400
focus for many years on just 
doing a sorry. 

237
00:13:00,400 --> 00:13:03,500
But then when writing book, of 
course, I needed to zoom out and

238
00:13:03,500 --> 00:13:05,300
see what else is out there in 
order. 

239
00:13:05,400 --> 00:13:07,000
Has been introduced. 
I'm sorry. 

240
00:13:07,000 --> 00:13:10,600
Well, in the context of the 
existing methodologies. 

241
00:13:11,100 --> 00:13:16,500
So then I saw that especially 
prevalent today is the isil 

242
00:13:16,500 --> 00:13:20,100
implementation. 
This is basically a framework 

243
00:13:20,100 --> 00:13:24,800
for how you set up the 
operations, the it function of 

244
00:13:24,800 --> 00:13:27,500
an organization. 
And then, there are also a 

245
00:13:27,500 --> 00:13:30,800
couple of other problems like 
this like, cold meats and 

246
00:13:30,800 --> 00:13:33,800
others. 
What they do well is to 

247
00:13:33,800 --> 00:13:40,100
basically, How and it function 
or a big organization can be 

248
00:13:40,100 --> 00:13:44,300
established and can be around, 
but then there are other kind of

249
00:13:44,300 --> 00:13:47,500
related things like, for 
instance, Devil's, right? 

250
00:13:47,500 --> 00:13:51,100
So devops is it very, very high 
content in the industry. 

251
00:13:51,400 --> 00:13:54,800
This is kind of a philosophy. 
How you run the product 

252
00:13:54,800 --> 00:13:59,900
delivery, especially with the 
shorts recycles and feedback 

253
00:13:59,900 --> 00:14:02,900
along the way from different 
environments and from different 

254
00:14:02,900 --> 00:14:07,100
people, including the customer 
and So on but then generally 

255
00:14:07,100 --> 00:14:09,900
develops stays at the 
philosophical level. 

256
00:14:10,000 --> 00:14:12,500
So basically it's a philosophy 
or fast. 

257
00:14:12,500 --> 00:14:16,100
So quick delivery and fast 
feedback loops especially in the

258
00:14:16,100 --> 00:14:19,200
area of operations. 
But also in other areas it 

259
00:14:19,200 --> 00:14:23,100
doesn't prescribe you enough to 
get started so just sleep. 

260
00:14:23,400 --> 00:14:27,000
So basically you can think of 
devops is an overarching 

261
00:14:27,000 --> 00:14:31,000
philosophy of running product 
delivery and then you can think 

262
00:14:31,000 --> 00:14:35,400
of other Frameworks like I tell 
and Corbett as Frameworks for I 

263
00:14:35,500 --> 00:14:37,300
think the, I key function of the
Enterprise. 

264
00:14:37,700 --> 00:14:40,200
So now, when does the sorry, can
in that context? 

265
00:14:40,800 --> 00:14:46,200
So actually as a really is a and
opinionated implementation of 

266
00:14:46,200 --> 00:14:50,700
the Ops part of demos. 
So you can also take a very 

267
00:14:50,700 --> 00:14:54,500
narrow, kind of view on devils 
and say that just based on the 

268
00:14:54,500 --> 00:14:58,100
name, devil tries to bring 
together development and 

269
00:14:58,100 --> 00:15:00,000
operations. 
Although I think it's brought 

270
00:15:00,000 --> 00:15:03,300
up, but you can kind of take 
that assumption say devops based

271
00:15:03,300 --> 00:15:05,200
on the main tries to unite them 
all. 

272
00:15:05,400 --> 00:15:08,100
Building operations, so that 
they work well together. 

273
00:15:08,500 --> 00:15:11,200
But then again, this is kind of 
staying at the philosophical 

274
00:15:11,200 --> 00:15:13,000
level development and 
operations. 

275
00:15:13,000 --> 00:15:15,400
They should be working together.
But, how should they do? 

276
00:15:15,400 --> 00:15:18,400
Bad programming? 
Should they do pay operations, 

277
00:15:18,400 --> 00:15:20,500
watch your video. 
How should they work together? 

278
00:15:21,100 --> 00:15:24,100
So, actually, it's already as a 
concrete implementation of the 

279
00:15:24,100 --> 00:15:28,900
devops philosophy. 
Is this opinionated framework to

280
00:15:28,900 --> 00:15:32,600
implement the Ops part of devops
so to speak. 

281
00:15:33,200 --> 00:15:34,700
It's got concrete prescription 
Souls. 

282
00:15:35,500 --> 00:15:40,600
Should be put in place and also 
roughly by room in order to 

283
00:15:40,600 --> 00:15:42,800
bring development and operation 
stick. 

284
00:15:43,000 --> 00:15:48,700
This is also coming from the 
origins of SRE which is trying 

285
00:15:48,700 --> 00:15:53,500
as software Engineers to come up
with the framework for operating

286
00:15:53,500 --> 00:15:56,300
services. 
So this is then sort of software

287
00:15:56,300 --> 00:16:00,400
engineer lead approach to 
operations. 

288
00:16:00,400 --> 00:16:03,900
This is what is the reason then 
if you take those things like my

289
00:16:03,900 --> 00:16:06,700
tail and Corbett for For 
organizing the ID function of 

290
00:16:06,708 --> 00:16:09,700
the Enterprise, then develops as
the overarching philosophy of 

291
00:16:09,700 --> 00:16:12,000
drug delivery. 
And then as a rig, being a 

292
00:16:12,000 --> 00:16:15,900
concrete implementation of the 
devops was a bit then you can 

293
00:16:15,900 --> 00:16:19,000
say okay? 
So actually I sorry can live 

294
00:16:19,000 --> 00:16:22,600
very nicely in parallel with 
Italian Corbett because with 

295
00:16:22,600 --> 00:16:26,100
item covid you just set up the 
idea of action of Enterprise and

296
00:16:26,100 --> 00:16:29,200
then with that object sets, the 
overarching philosophy for 

297
00:16:29,200 --> 00:16:32,700
program delivery. 
And then a sari is a piece in 

298
00:16:32,700 --> 00:16:37,400
order to enable the She's lot of
your product delivery 

299
00:16:37,400 --> 00:16:40,500
organization. 
Well, well, thanks for this 

300
00:16:40,500 --> 00:16:43,800
explanation, so we can see 
clearly where it fits into this 

301
00:16:43,800 --> 00:16:47,400
overall along with the other ID 
and operations Frameworks. 

302
00:16:47,600 --> 00:16:51,000
So, thanks for sharing that you 
mention a phrase, which is very 

303
00:16:51,000 --> 00:16:53,200
popularly. 
Described as area, a sari is 

304
00:16:53,200 --> 00:16:56,300
like a way of operating software
if you give it to a software 

305
00:16:56,300 --> 00:16:58,200
Engineers, right? 
I think it's a code from been 

306
00:16:58,200 --> 00:16:58,900
trainers. 
Lost. 

307
00:16:59,200 --> 00:17:01,100
I'm also interested to listen 
from you. 

308
00:17:01,100 --> 00:17:04,200
What is your definition of s? 
Are you coming outside of 

309
00:17:04,200 --> 00:17:06,599
Google? 
How do you Describe a sorry, is 

310
00:17:06,599 --> 00:17:09,300
there anything that you probably
have different in terms of 

311
00:17:09,300 --> 00:17:13,000
perspectives of opinions? 
I think you can definitely see 

312
00:17:13,000 --> 00:17:15,000
that. 
It's coming from the software 

313
00:17:15,000 --> 00:17:17,900
engineering world. 
I would agree that this is what 

314
00:17:17,900 --> 00:17:21,300
happens when you touch this 
operation ears with doing 

315
00:17:21,300 --> 00:17:25,200
operations and actually very 
interestingly, this kind of 

316
00:17:25,200 --> 00:17:28,200
thinking when you Cast Operation
ears with doing something and be

317
00:17:28,200 --> 00:17:31,400
also applied to other areas. 
So for example, being 

318
00:17:31,400 --> 00:17:35,200
specifically in health care with
what a lot of agriculture, 

319
00:17:35,400 --> 00:17:38,200
Button. 
So we've got a lot of Regulatory

320
00:17:38,200 --> 00:17:42,200
Compliance regulations that we 
have to fulfill traditionally. 

321
00:17:42,400 --> 00:17:45,100
These regulations are not 
fulfilled. 

322
00:17:45,100 --> 00:17:48,000
From this equation, has point of
view so they are basically 

323
00:17:48,000 --> 00:17:50,500
fulfilled from the original tree
person, point of view and 

324
00:17:50,500 --> 00:17:53,100
therefore there are lots of 
documents that you had to write 

325
00:17:53,400 --> 00:17:55,700
in order to demonstrate your 
compliance. 

326
00:17:55,700 --> 00:17:58,200
With the regulations, those 
documents have to be handled in 

327
00:17:58,200 --> 00:18:01,400
a certain way in order for you 
to be able to provide evidence 

328
00:18:01,500 --> 00:18:04,000
during what it's that. 
You actually comply with the 

329
00:18:04,000 --> 00:18:06,300
process and so on. 
Additionally, if you task a 

330
00:18:06,308 --> 00:18:09,300
software engineer to design the 
regulatory function, it will be 

331
00:18:09,300 --> 00:18:11,100
done something completely 
different. 

332
00:18:12,600 --> 00:18:15,800
Certainly, I think you can apply
that kind of thinking, just a 

333
00:18:15,800 --> 00:18:20,300
software engineer with designing
X and that leads to a totally 

334
00:18:20,300 --> 00:18:23,800
different implementation than if
it comes from a place where it's

335
00:18:23,800 --> 00:18:25,600
all inspired by software 
engineering. 

336
00:18:25,900 --> 00:18:28,700
So I think there's generally a 
great potential to apply that 

337
00:18:28,700 --> 00:18:32,100
kind of thinking also in other 
areas and we also started 

338
00:18:32,100 --> 00:18:35,200
actually changing our regulatory
process with ending. 

339
00:18:35,400 --> 00:18:39,100
With the maintenance on that. 
It is definitely makes the whole

340
00:18:39,100 --> 00:18:41,700
process. 
Much leaner makes the whole 

341
00:18:41,700 --> 00:18:46,700
process much easier to apply it 
and then leads to actually a 

342
00:18:46,700 --> 00:18:49,700
great acceleration of products 
delivery. 

343
00:18:50,200 --> 00:18:52,800
Because if you are less 
constrained by the regulatory 

344
00:18:52,800 --> 00:18:54,900
burden that we can, we'll patch 
box them. 

345
00:18:55,500 --> 00:18:59,300
So we're all definitely would 
still agree with the original 

346
00:18:59,300 --> 00:19:03,600
definition by Google posed by 
been touring has lost that this 

347
00:19:03,600 --> 00:19:05,200
is what happens when you touch 
them. 

348
00:19:05,300 --> 00:19:08,300
Software engineer to design be 
operations function. 

349
00:19:08,600 --> 00:19:11,300
Yes, it definitely would be 
happy to apply that kind of 

350
00:19:11,300 --> 00:19:14,900
thinking. 
Also, in other areas, thanks for

351
00:19:14,900 --> 00:19:17,900
the an interesting perspective. 
So if you want to improve 

352
00:19:17,900 --> 00:19:21,200
something, you can also applies 
of engineering, 2x problem, 

353
00:19:21,200 --> 00:19:22,400
right? 
So maybe one day we'll see 

354
00:19:22,400 --> 00:19:24,400
Regulatory Compliance 
engineering. 

355
00:19:24,400 --> 00:19:26,600
When you apply software 
engineering to some area. 

356
00:19:26,900 --> 00:19:30,300
You mention about last time in 
it, the Ops team will be its own

357
00:19:30,300 --> 00:19:32,700
Silo development team. 
Its own Silo, and product 

358
00:19:32,700 --> 00:19:35,500
manager its own Silo. 
So, in the book, you Today, 

359
00:19:35,500 --> 00:19:39,500
explain how a sorry actually is 
able to unify these three 

360
00:19:39,500 --> 00:19:42,300
different teams. 
So tell us more how asari 

361
00:19:42,300 --> 00:19:46,100
actually helps bring alignment 
into this three different areas.

362
00:19:47,000 --> 00:19:52,300
So, I think the strength of a 
surgery is exactly in the 

363
00:19:52,400 --> 00:19:55,900
ability to bring about that 
alignment on operational 

364
00:19:55,900 --> 00:19:59,300
concerns between the product 
management or development and 

365
00:19:59,300 --> 00:20:03,100
product operations, whereas 
other methodologies and 

366
00:20:03,100 --> 00:20:05,200
framework that we talked about 
before, I have bought their 

367
00:20:05,300 --> 00:20:09,300
Things even other areas, like I 
tell in Corbett, their strength 

368
00:20:09,300 --> 00:20:13,500
is designed the ID, functional 
Enterprise devops the strength 

369
00:20:13,500 --> 00:20:17,500
is in the philosophy of orluk 
delivery, where it's a really, 

370
00:20:17,500 --> 00:20:21,500
really I think the strength of 
the methodology is in the 

371
00:20:21,500 --> 00:20:25,500
alignment on operational 
concerns, the entire 

372
00:20:25,500 --> 00:20:27,500
organization. 
The cool thing about this. 

373
00:20:27,500 --> 00:20:31,700
I read that also benefits us a 
lot in the employee digital 

374
00:20:31,700 --> 00:20:34,200
Health platform. 
Is that it prescribes that? 

375
00:20:34,200 --> 00:20:37,200
See, we need to have Level 
objectives for your services 

376
00:20:37,800 --> 00:20:40,400
which are then based on service 
level indicators. 

377
00:20:40,700 --> 00:20:43,600
Then once you've got service, 
level indicators and service 

378
00:20:43,600 --> 00:20:46,500
level objectives, then we 
automatically, you've got so 

379
00:20:46,500 --> 00:20:49,500
called Arrow budgets, which are 
given budgets for errors. 

380
00:20:49,800 --> 00:20:53,600
And then if you exceed your 
given budget for errors, then 

381
00:20:53,700 --> 00:20:57,200
you can do data-driven 
decision-making about whether we

382
00:20:57,200 --> 00:21:02,100
invest now injury liability, or 
whether we continue investing in

383
00:21:02,100 --> 00:21:04,400
features. 
So basically you've got these 

384
00:21:04,400 --> 00:21:07,400
kind of primitive Oops, that you
can work with and that you can 

385
00:21:07,400 --> 00:21:11,100
use to guide your thinking. 
So now, how does as a really 

386
00:21:11,100 --> 00:21:14,400
then bring about the alignment 
of different bodies on 

387
00:21:14,400 --> 00:21:17,100
operational concerns. 
First of all, under the SRE 

388
00:21:17,100 --> 00:21:22,100
framework, the developers, they 
need to go on call for their 

389
00:21:22,100 --> 00:21:26,400
services, to the extent agreed 
in the organization. 

390
00:21:26,700 --> 00:21:29,700
So that means that the 
developers need to experience 

391
00:21:29,700 --> 00:21:33,300
firsthand what? 
It's like to run their services 

392
00:21:33,300 --> 00:21:37,000
in production and that can be 
Just a little bit, if the 

393
00:21:37,000 --> 00:21:40,400
agreements to provide the 
services is such, that probably 

394
00:21:40,400 --> 00:21:42,700
loving is just a little bit 
involved in operations. 

395
00:21:42,800 --> 00:21:46,100
And it may be that the 
development teams are fully only

396
00:21:46,100 --> 00:21:48,600
called for their services. 
So we can arrange, sort of 

397
00:21:48,700 --> 00:21:51,800
between 10 and 100 percents, can
be done by the developers 

398
00:21:51,800 --> 00:21:55,400
themselves. 
The product management typically

399
00:21:55,400 --> 00:21:58,500
is not involved in product 
operations, but under the sari 

400
00:21:58,500 --> 00:22:01,200
framework, they need to be 
involved in correct operations 

401
00:22:01,200 --> 00:22:04,800
in order to actually make those 
decisions when we invest in 

402
00:22:04,800 --> 00:22:07,000
there like that. 
It's you versus what we invest 

403
00:22:07,000 --> 00:22:10,500
in product features, but these 
decisions are then done based on

404
00:22:10,500 --> 00:22:14,300
sound data frame production and 
that's based on the error budget

405
00:22:14,300 --> 00:22:17,000
consumption. 
So, if there is no error budget 

406
00:22:17,000 --> 00:22:20,500
left anymore, what do we do the 
product management needs to be 

407
00:22:20,500 --> 00:22:23,200
involved or the definition of 
the so-called Arrow budget 

408
00:22:23,200 --> 00:22:26,800
policies that state service by 
service and team by team. 

409
00:22:27,000 --> 00:22:30,000
What do we do if there is no, 
error budget left anymore? 

410
00:22:30,000 --> 00:22:33,600
Do we value invest in the 
ability to invest in reliability

411
00:22:33,600 --> 00:22:36,400
than how do we do this? 
Do we take One engineered wood 

412
00:22:36,400 --> 00:22:38,900
on the reliability or do we re 
paralyze the back? 

413
00:22:38,900 --> 00:22:40,600
Opens on. 
As you can see, the product 

414
00:22:40,600 --> 00:22:44,400
management becomes totally part 
of this entire conversation, how

415
00:22:44,400 --> 00:22:47,600
to guide investment on 
reliability, the product 

416
00:22:47,600 --> 00:22:52,100
operations. 
They usually not involved in 

417
00:22:52,100 --> 00:22:55,600
enabling others to do 
operations, but under the 

418
00:22:55,600 --> 00:22:57,800
authority framework. 
That's exactly what they need to

419
00:22:57,800 --> 00:22:59,100
do. 
So basically, they don't 

420
00:22:59,100 --> 00:23:02,600
necessarily need to run services
in production but they need to 

421
00:23:02,600 --> 00:23:06,800
provide as our infrastructure to
enable the Developers to go on 

422
00:23:06,800 --> 00:23:10,900
call and the efficient to, 
basically, a traditional 

423
00:23:10,900 --> 00:23:14,100
organization puts their 
responsibilities on the head, 

424
00:23:14,100 --> 00:23:17,000
simply because the developers, 
they never went on call, but 

425
00:23:17,000 --> 00:23:20,400
they need to go and call down 
the operations people, they 

426
00:23:20,400 --> 00:23:23,200
never enabled others to do 
operations, and they need to 

427
00:23:23,200 --> 00:23:26,200
enable developers. 
Now, the operations, the product

428
00:23:26,200 --> 00:23:28,200
management. 
They were never involved in 

429
00:23:28,200 --> 00:23:30,600
operations, but now, they are 
part of the conversation. 

430
00:23:30,800 --> 00:23:33,000
How do we guide the investment 
in the reliability? 

431
00:23:33,000 --> 00:23:35,000
As you can see, it gives each 
party. 

432
00:23:35,300 --> 00:23:39,200
Certain set of tasks and aligns 
them using those Primitives like

433
00:23:39,200 --> 00:23:42,000
is alone zero budget, zero, 
budget, bonuses, and so on. 

434
00:23:42,300 --> 00:23:45,600
So that the whole organization 
then is aligned on those 

435
00:23:45,600 --> 00:23:49,300
operational, concerns ideally 
before hitting production. 

436
00:23:50,200 --> 00:23:53,100
So I think you refer to this as 
a collective ownership in your 

437
00:23:53,100 --> 00:23:54,700
book. 
So from three different 

438
00:23:54,700 --> 00:23:57,900
perspectives from development 
from operations and so product 

439
00:23:57,900 --> 00:24:00,800
management and I like, when you 
set that now, the three 

440
00:24:00,800 --> 00:24:03,200
different groups actually 
aligned on what kind of 

441
00:24:03,200 --> 00:24:06,400
reliability that they would want
to, Offer for their services. 

442
00:24:06,600 --> 00:24:09,500
And if there's something wrong 
about reliability, for example, 

443
00:24:09,500 --> 00:24:11,900
your error budget is exceeded, 
then you make a certain 

444
00:24:11,900 --> 00:24:15,200
decisions, should you invest in 
reliability, more, or should you

445
00:24:15,200 --> 00:24:18,600
continue investing on features? 
Knowing that your error budget 

446
00:24:18,600 --> 00:24:22,100
is succeeding. 
So, I think this misalignment is

447
00:24:22,100 --> 00:24:24,100
pretty common in many 
organizations, right? 

448
00:24:24,100 --> 00:24:27,100
So maybe from your journey, tell
us, how did you solve this? 

449
00:24:27,100 --> 00:24:30,100
Because when you introduce a 
sorry, it's a totally radical 

450
00:24:30,100 --> 00:24:31,700
concept. 
I assume for traditional 

451
00:24:31,700 --> 00:24:34,600
companies, and some people would
even think of this works in 

452
00:24:34,600 --> 00:24:35,800
Google. 
Not ask. 

453
00:24:35,800 --> 00:24:38,200
So how did you overcome that 
misalignment? 

454
00:24:38,200 --> 00:24:41,200
And make sure three different 
groups actually can align on 

455
00:24:41,200 --> 00:24:45,000
this same implementation. 
He had specifically related to 

456
00:24:45,000 --> 00:24:48,000
make healthy years. 
Was that first of all we placed 

457
00:24:48,100 --> 00:24:52,500
a sorry into the portfolio of 
things that we do in the 

458
00:24:52,500 --> 00:24:55,100
blackphone. 
We are in agreement that this is

459
00:24:55,100 --> 00:24:59,100
an important topic, it's 
important for us to improve the 

460
00:24:59,100 --> 00:25:03,600
operations of the platform and 
therefore we'll try a sorry 

461
00:25:03,700 --> 00:25:06,500
because everything that we've 
Right before wouldn't add 

462
00:25:06,500 --> 00:25:08,600
success. 
So we'll give it a try but 

463
00:25:08,600 --> 00:25:11,700
couldn't into the portfolio of 
things that will work on with 

464
00:25:11,700 --> 00:25:14,300
that. 
Then we are able to allocate 

465
00:25:14,300 --> 00:25:18,800
resources across the board. 
We were able to stop the 

466
00:25:18,800 --> 00:25:22,300
development of the sr&ed 
infrastructure in the operations

467
00:25:22,300 --> 00:25:26,100
teams. 
We were able to start talking to

468
00:25:26,100 --> 00:25:29,700
you the development teams and 
literally go kind of team by 

469
00:25:29,700 --> 00:25:34,400
team and introduced the concept 
there and take each team won. 

470
00:25:34,400 --> 00:25:37,300
Its tgb. 
Journey towards operations 

471
00:25:37,300 --> 00:25:40,200
improvements using a surgery 
that kind of team. 

472
00:25:40,200 --> 00:25:45,000
Based coaching was also key to 
establishing a sorry in the 

473
00:25:45,000 --> 00:25:47,600
organization because every team 
is different. 

474
00:25:47,900 --> 00:25:52,200
Also, every team is using the 
server infrastructure slightly 

475
00:25:52,200 --> 00:25:56,000
differently. 
So basically, taking the people 

476
00:25:56,000 --> 00:25:58,500
who are implementing their 
infrastructure in going, kind of

477
00:25:58,500 --> 00:26:03,400
T by Tau into the product teams,
including the product owner was 

478
00:26:03,400 --> 00:26:08,400
key to actually being Unable to 
establish at sorry, broadly in 

479
00:26:08,400 --> 00:26:11,400
the organization. 
It's very interesting because, 

480
00:26:11,400 --> 00:26:13,600
yeah, like you said every team 
is different. 

481
00:26:13,600 --> 00:26:16,700
Some may be more advanced in 
terms of understanding. 

482
00:26:17,100 --> 00:26:20,300
So for those people who haven't 
really understood about SRE 

483
00:26:20,300 --> 00:26:24,200
concept, I do have an episode in
episode 96, which covers the 

484
00:26:24,200 --> 00:26:27,100
basic ideas principles and 
Concepts in a sorry. 

485
00:26:27,400 --> 00:26:30,200
So today we will not be covering
that because you can refer to 

486
00:26:30,208 --> 00:26:32,900
that episode. 
Do check it out if you want to 

487
00:26:32,900 --> 00:26:35,000
learn about what we are talking 
about, SLO error. 

488
00:26:35,200 --> 00:26:37,300
Jet SLI right. 
So, dr. 

489
00:26:37,300 --> 00:26:39,400
Flap and you actually tried to 
implement this. 

490
00:26:39,400 --> 00:26:42,000
I guess some people may be 
puzzled about a sorry. 

491
00:26:42,300 --> 00:26:44,900
So it's like how do you actually
educate people? 

492
00:26:44,900 --> 00:26:47,900
You mentioned about the role of 
a sorry, coach tell us more 

493
00:26:47,900 --> 00:26:50,400
about this role. 
The significance of it. 

494
00:26:50,400 --> 00:26:52,300
Like, how do you actually 
recruit them? 

495
00:26:52,400 --> 00:26:54,700
Is this coming from external or 
is the internal? 

496
00:26:54,700 --> 00:26:57,700
So maybe tell us more about this
important role of a sorry coach,

497
00:26:58,300 --> 00:27:01,300
he has only to embark on the. 
Is there a transformation? 

498
00:27:01,300 --> 00:27:03,700
Want to establish a real 
organization? 

499
00:27:04,000 --> 00:27:07,300
Then you need Somebody who would
be driving the transformation 

500
00:27:07,300 --> 00:27:11,200
and this is, they're all sorry, 
coach, that needs to be somebody

501
00:27:11,200 --> 00:27:14,900
who's really driven to improve 
operations and who can 

502
00:27:14,900 --> 00:27:19,600
understand the organization well
enough in order to nail what you

503
00:27:19,600 --> 00:27:23,700
need to do, to establish it that
all the different organization 

504
00:27:23,700 --> 00:27:26,600
by organization, and especially 
that'll be indifferent. 

505
00:27:26,600 --> 00:27:30,200
Also Culture by culture, 
therefore, I think it means to 

506
00:27:30,200 --> 00:27:34,000
be somebody in total. 
I wouldn't think that somebody 

507
00:27:34,000 --> 00:27:38,300
external would Able to do this 
because you need to know too 

508
00:27:38,300 --> 00:27:42,000
much all inner workings of an 
organization in order to make it

509
00:27:42,000 --> 00:27:44,500
happen. 
Also, I think there might be in 

510
00:27:44,500 --> 00:27:48,500
just not enough, trust between 
the teams and be its own coach 

511
00:27:48,500 --> 00:27:50,700
in all that you'll make that 
change. 

512
00:27:51,000 --> 00:27:54,700
And also another thing typically
something like this is a 

513
00:27:54,708 --> 00:27:58,900
multi-year journey and usually 
somebody external is not there 

514
00:27:58,900 --> 00:28:02,800
to spend years with a focused. 
So I think you need to be 

515
00:28:02,800 --> 00:28:05,000
somebody in total. 
Somebody's drinking too. 

516
00:28:05,100 --> 00:28:08,800
Group operations and somebody 
convinced that sorry might be a 

517
00:28:08,808 --> 00:28:12,800
good approach that person needs 
to be a mediator between the 

518
00:28:12,800 --> 00:28:15,000
operations team. 
In The Mending, their 

519
00:28:15,000 --> 00:28:18,200
infrastructure development 
teams, adopting a sorry at 

520
00:28:18,200 --> 00:28:22,000
different bases and the 
management team endorsing the 

521
00:28:22,000 --> 00:28:24,900
transformation. 
And also providing it on below 

522
00:28:24,900 --> 00:28:26,800
budget for this. 
So, I think this is definitely 

523
00:28:26,800 --> 00:28:32,300
cure-all and must be there for 
quite a long time until and 

524
00:28:32,300 --> 00:28:37,400
sorry, becomes the usual ways of
working or For any team and also

525
00:28:37,400 --> 00:28:41,100
to the point where even Yugi has
started, then they kind of don't

526
00:28:41,100 --> 00:28:43,500
think about how to do 
operations, but they just use 

527
00:28:43,500 --> 00:28:46,000
the existing as our 
infrastructure and approach 

528
00:28:46,000 --> 00:28:49,800
everything from the three point 
of view from the beginning when 

529
00:28:49,800 --> 00:28:53,400
they set up new services. 
And you mentioned, this could be

530
00:28:53,400 --> 00:28:56,000
multi a journey, right? 
So maybe from your experience, 

531
00:28:56,000 --> 00:28:59,400
how many years did it take you 
to actually really start seeing 

532
00:28:59,400 --> 00:29:02,500
the effect and benefits across 
maybe one or two teams? 

533
00:29:02,600 --> 00:29:06,800
If not the whole company? 
So I think you can see the 

534
00:29:06,800 --> 00:29:11,700
benefits pretty quickly because 
if you are coming from a 

535
00:29:11,700 --> 00:29:13,600
traditional development 
organization that has never done

536
00:29:13,600 --> 00:29:17,300
operations before, then there 
will be basic things that you 

537
00:29:17,300 --> 00:29:20,200
can improve immediately just to 
talk about basics. 

538
00:29:20,200 --> 00:29:24,900
For example, you need Uniformly,
logging across all services that

539
00:29:24,900 --> 00:29:27,900
you've got typically in a 
traditional organization, you 

540
00:29:27,900 --> 00:29:30,100
will not have uniform logging 
everywhere. 

541
00:29:30,300 --> 00:29:33,000
They will be always, you know, 
one team does it in one way and 

542
00:29:33,000 --> 00:29:34,300
the team does it in some other 
way. 

543
00:29:34,600 --> 00:29:37,200
And there is this new service 
where the logging has not been 

544
00:29:37,200 --> 00:29:39,800
yet enabled and so on. 
So basically, you can 

545
00:29:39,800 --> 00:29:43,500
immediately can Elevate the 
maturity a little bit. 

546
00:29:44,100 --> 00:29:48,000
Then the next question is, okay,
when did you really start seeing

547
00:29:48,000 --> 00:29:51,400
improvements at the management 
level, where the management team

548
00:29:51,400 --> 00:29:52,200
members will see? 
Yes. 

549
00:29:52,200 --> 00:29:55,800
So actually before we had this, 
and before the teams were doing 

550
00:29:55,800 --> 00:29:59,900
operations, the services weren't
enter liable as now, something 

551
00:29:59,900 --> 00:30:04,100
like, this will take a longer of
course, but not necessarily that

552
00:30:04,100 --> 00:30:08,100
long, I would say, because, 
typically, in order for this 

553
00:30:08,100 --> 00:30:12,700
perception to be developed, you 
need to see some external 

554
00:30:12,700 --> 00:30:15,900
change. 
And usually, the external change

555
00:30:15,900 --> 00:30:19,700
is measured based on the 
customer complaints, right? 

556
00:30:19,700 --> 00:30:21,800
So usually would be a management
team. 

557
00:30:22,000 --> 00:30:25,400
Um, notices is that okay? 
Somebody's complaining because 

558
00:30:25,400 --> 00:30:28,500
something is not working. 
So you'd be amount of external 

559
00:30:28,500 --> 00:30:32,100
complaints gets reduced, this is
what the people will stop 

560
00:30:32,100 --> 00:30:34,400
noticing. 
I actually, this is already kind

561
00:30:34,400 --> 00:30:37,600
of best some fruit. 
Although from the azeri coaches 

562
00:30:37,600 --> 00:30:39,100
going to do they of course will 
know. 

563
00:30:39,100 --> 00:30:41,700
Okay, we're just actually at the
beginning of the journey but 

564
00:30:41,700 --> 00:30:45,400
already if the development team 
is stuck, taking production, 

565
00:30:45,400 --> 00:30:49,700
seriously, if they start really 
kind of looking into how this in

566
00:30:49,700 --> 00:30:53,100
his surrounding, even if it's 
not The best and sorry. 

567
00:30:53,100 --> 00:30:58,000
We then that's usually already 
brings a huge effect in terms of

568
00:30:58,000 --> 00:31:00,800
reliability. 
Yeah, I can totally relate with 

569
00:31:00,800 --> 00:31:03,100
what you said. 
So previously if you haven't 

570
00:31:03,100 --> 00:31:05,900
done any kind of a sorry, for 
example, there are typically 

571
00:31:05,900 --> 00:31:08,700
many kind of implementations 
especially across teams in the 

572
00:31:08,700 --> 00:31:11,400
same company, right? 
So like logging is one thing, 

573
00:31:11,400 --> 00:31:14,600
observability, whatever that is 
you will have so many tools and 

574
00:31:14,600 --> 00:31:17,200
they are not uniform as well as 
pretty difficult to trace from 

575
00:31:17,200 --> 00:31:20,000
one service to the other and I 
think with the sorry concept 

576
00:31:20,000 --> 00:31:21,800
that you start, maybe 
standardizing all this. 

577
00:31:21,900 --> 00:31:24,700
Having conventions. 
And I think, like what you said 

578
00:31:24,700 --> 00:31:26,600
at the end of the day, it 
impacts the customers, right? 

579
00:31:26,700 --> 00:31:29,300
Users have been as. 
So from the management point of 

580
00:31:29,300 --> 00:31:31,900
view, I think, once you start 
seeing reduction in customer, 

581
00:31:31,900 --> 00:31:34,900
complains of customer related 
issues, maybe that is the sign 

582
00:31:34,900 --> 00:31:37,600
when you actually implemented 
SRE successfully. 

583
00:31:38,000 --> 00:31:40,500
So you have explained as re 
concept to everyone. 

584
00:31:40,700 --> 00:31:43,500
Everyone seems to understood 
about the concept. 

585
00:31:43,500 --> 00:31:45,800
So how do we start by laying the
foundations? 

586
00:31:45,800 --> 00:31:48,700
If I understand SRA correctly. 
It always revolves around 

587
00:31:48,700 --> 00:31:51,800
service level objectives when we
discuss about Collective, 

588
00:31:52,000 --> 00:31:54,700
Bishop, I think from the product
development for the operations 

589
00:31:54,700 --> 00:31:57,500
and product management. 
We also agree on the same 

590
00:31:57,500 --> 00:32:00,500
service level objectives, right?
So, we have the same definition.

591
00:32:00,700 --> 00:32:03,200
We have the same understanding 
about a consequence of not 

592
00:32:03,200 --> 00:32:05,300
meeting that objective and 
things like that. 

593
00:32:05,600 --> 00:32:09,000
So tell us more what should be 
the step-by-step foundational 

594
00:32:09,000 --> 00:32:12,400
steps for people who are trying 
to implement a sorry in their 

595
00:32:12,400 --> 00:32:16,400
company or team. 
I think a couple things need to 

596
00:32:16,400 --> 00:32:20,100
be done at one important thing 
is that I think it's important 

597
00:32:20,100 --> 00:32:24,200
for the initiative to be taken. 
Seriously that requires a 

598
00:32:24,200 --> 00:32:28,200
surgery to be put onto the list 
all organizational priorities 

599
00:32:28,300 --> 00:32:30,200
that they'll get ization wants 
to explore. 

600
00:32:30,900 --> 00:32:34,200
So every organization has got 
some list old big topics that 

601
00:32:34,200 --> 00:32:37,100
they're working on. 
Ten topics roughly that we are 

602
00:32:37,100 --> 00:32:40,600
working on right now and that 
needs to be on the list because 

603
00:32:40,600 --> 00:32:43,800
this is such a profound change 
the development team, use 

604
00:32:43,800 --> 00:32:47,000
suddenly starts going on all for
their services and the 

605
00:32:47,000 --> 00:32:51,600
operations team starts suddenly 
to implement some free Works in 

606
00:32:51,600 --> 00:32:54,300
order to Enable the developer 
team Studio operations to 

607
00:32:54,300 --> 00:32:57,800
basically the development team 
start doing some operations for 

608
00:32:58,300 --> 00:33:02,600
and the operations team started 
doing some development work and 

609
00:33:02,600 --> 00:33:05,300
visit Aunt will kind of 
transformation for both parties.

610
00:33:05,300 --> 00:33:08,200
Then be organized when suddenly 
is in the middle of the 

611
00:33:08,200 --> 00:33:11,000
discussions about reliability 
which is still being used to 

612
00:33:11,000 --> 00:33:13,500
that. 
So I don't think you can really 

613
00:33:13,500 --> 00:33:17,300
bring this about if the 
organization is not serious 

614
00:33:17,300 --> 00:33:21,000
enough about being judged. 
So I think the first thing put 

615
00:33:21,000 --> 00:33:23,100
this on the list, Of 
initiatives, you are 

616
00:33:23,100 --> 00:33:27,100
undertaking, then the second 
thing, wind a possibility in the

617
00:33:27,100 --> 00:33:30,200
racial team to implement a 
little bit of a mess, our 

618
00:33:30,200 --> 00:33:33,200
infrastructure and really the 
very, very minimum. 

619
00:33:33,600 --> 00:33:35,800
So I would say just start with 
one SL. 

620
00:33:35,800 --> 00:33:38,800
I say availability, because 
that's kind of the most common 

621
00:33:38,800 --> 00:33:42,700
ones in the most fundamental one
and then he just Implement some 

622
00:33:42,700 --> 00:33:46,300
infrastructure that can take 
some logs and calculate the 

623
00:33:46,300 --> 00:33:50,800
availability of a service based 
on those logs and then can alert

624
00:33:50,800 --> 00:33:55,300
on say Certain thresholds that 
third layer is already enough, 

625
00:33:55,500 --> 00:33:59,100
that big say, one development 
key that is responsible for some

626
00:33:59,100 --> 00:34:04,500
services that would be kind of 
open to exploring a new way to 

627
00:34:04,500 --> 00:34:07,100
do operations. 
From then onwards kind of 

628
00:34:07,100 --> 00:34:09,300
operate. 
This re circulate very 

629
00:34:09,300 --> 00:34:12,600
frequently between what the 
development team actually means.

630
00:34:12,600 --> 00:34:14,500
And what there's our 
infrastructure needs to provide,

631
00:34:15,000 --> 00:34:19,600
basically bring together that 
one team and the operations team

632
00:34:19,600 --> 00:34:21,699
in the wedding ditra structure 
and bring it. 

633
00:34:21,900 --> 00:34:26,100
To a point where that one team 
would say, we actually make 

634
00:34:26,100 --> 00:34:28,300
sense. 
It's an improvement compared to 

635
00:34:28,300 --> 00:34:31,699
before it's better now and we 
want from this our 

636
00:34:31,699 --> 00:34:34,300
infrastructure additional 10 
features. 

637
00:34:34,699 --> 00:34:36,300
I think that's a good starting 
point. 

638
00:34:36,300 --> 00:34:39,500
So that's solid already. 
You've got an owner of this rail

639
00:34:39,500 --> 00:34:42,500
tracks are two new chords 
infrastructure used by a Regal 

640
00:34:42,500 --> 00:34:46,699
Team and if they want more, this
is actually a good point to say.

641
00:34:46,699 --> 00:34:48,500
Okay. 
Now we know we are on to 

642
00:34:48,500 --> 00:34:54,000
something useful and let's go 
find the T then the second team 

643
00:34:54,300 --> 00:34:57,000
can already make use of this for
infrastructure. 

644
00:34:57,000 --> 00:34:58,600
That was built for the first 
team. 

645
00:34:58,900 --> 00:35:01,800
They will, of course, have some 
different context and this is 

646
00:35:01,800 --> 00:35:05,500
where you can then decide, which
additional features to implement

647
00:35:05,500 --> 00:35:08,300
into this or infrastructure from
then onwards. 

648
00:35:08,300 --> 00:35:12,700
It's about going team by team 
and talking to them, discussing 

649
00:35:12,700 --> 00:35:14,500
with them. 
Whether it's very would be 

650
00:35:14,500 --> 00:35:17,100
something bought them but you 
should make the more teams you 

651
00:35:17,100 --> 00:35:19,900
on both the easier it gets 
because they are infrastructure.

652
00:35:19,900 --> 00:35:22,800
Is already more mature every 
time To take on a new team 

653
00:35:22,800 --> 00:35:25,400
because you've got more features
there and, you know, the day 

654
00:35:25,400 --> 00:35:29,100
useful because also, there is a 
kind of social proof that this 

655
00:35:29,100 --> 00:35:31,700
new thing. 
It's a really kind of helps with

656
00:35:31,700 --> 00:35:34,700
the services operations. 
I would say this is kind of 

657
00:35:34,700 --> 00:35:36,900
roughly the journey that you 
would need to take. 

658
00:35:36,900 --> 00:35:40,000
And this is also where the SRE 
coaches are essential, 

659
00:35:40,300 --> 00:35:44,100
especially at the beginning. 
So I think that totally makes 

660
00:35:44,100 --> 00:35:45,800
sense. 
Why you just do it gradually 

661
00:35:45,800 --> 00:35:47,300
building the infrastructure as 
well. 

662
00:35:47,300 --> 00:35:50,300
Don't forget about that because 
you can't just tell the team. 

663
00:35:50,300 --> 00:35:54,000
A you go Implement without 
Structure or platform invited by

664
00:35:54,000 --> 00:35:56,300
the SRE best practices because 
otherwise people will 

665
00:35:56,300 --> 00:35:59,000
implemented differently. 
I totally can relate as well 

666
00:35:59,000 --> 00:36:02,200
because I did try, similarly 
leaving the teams to implement 

667
00:36:02,200 --> 00:36:05,600
it, but I guess people's 
understanding varies you would 

668
00:36:05,600 --> 00:36:08,100
start seeing some themes which 
implemented properly some 

669
00:36:08,100 --> 00:36:11,200
themes, which probably just 
follow the request of the order.

670
00:36:11,200 --> 00:36:14,400
So to speak, some actually just 
finish and then forget about 

671
00:36:14,400 --> 00:36:18,400
that filter, which brings us to 
the key concept of SRU. 

672
00:36:18,400 --> 00:36:22,300
So when your SLO is actually 
being breached, what do you do 

673
00:36:22,300 --> 00:36:24,400
about it? 
Because I think that is maybe 

674
00:36:24,400 --> 00:36:27,200
the Tipping Point how the 
culture change our because if 

675
00:36:27,200 --> 00:36:30,700
you have an error budget it got 
breached but nobody cares about 

676
00:36:30,700 --> 00:36:33,500
it or do any action. 
So maybe from your experience 

677
00:36:33,500 --> 00:36:35,900
how do you handle this? 
Such that it becomes a Tipping 

678
00:36:35,900 --> 00:36:37,100
Point where people understand. 
Okay. 

679
00:36:37,100 --> 00:36:39,800
This we have to take seriously. 
Yeah. 

680
00:36:39,800 --> 00:36:44,200
So several step step, step one 
is involved the product owner 

681
00:36:44,300 --> 00:36:47,100
into the sorry coaching sessions
from the beginning. 

682
00:36:47,200 --> 00:36:50,500
The product owner is totally a 
full member of these 

683
00:36:50,500 --> 00:36:53,000
discussions. 
Number two rule. 

684
00:36:53,600 --> 00:36:58,300
Once the pill you moon is mature
enough to come up with the arrow

685
00:36:58,300 --> 00:37:02,300
budget policy. 
That this is something that's 

686
00:37:02,400 --> 00:37:06,300
really helpful, because it 
forces the team to think exactly

687
00:37:06,300 --> 00:37:09,500
about this question. 
What will we do when there is no

688
00:37:09,500 --> 00:37:12,400
error budget left of this 
service or for that service? 

689
00:37:13,200 --> 00:37:17,300
It does this ahead of time 
before you exhausted your error 

690
00:37:17,300 --> 00:37:22,100
budget and that provokes really 
good discussions that also Just 

691
00:37:22,100 --> 00:37:25,700
upon other things that the team 
is doing, for example, the team 

692
00:37:25,700 --> 00:37:30,400
might be say planning to do some
Workshop in order to plan the 

693
00:37:30,400 --> 00:37:33,600
next increment. 
What happens if your error 

694
00:37:33,600 --> 00:37:35,300
budget gets exhausted exactly on
that? 

695
00:37:35,300 --> 00:37:38,600
They do you then this time the 
workshop or what do we do with 

696
00:37:38,600 --> 00:37:41,300
our planning, something that 
provokes a big discussion, you 

697
00:37:41,300 --> 00:37:43,400
need to basically put it on 
paper. 

698
00:37:43,700 --> 00:37:46,700
I Aro budget policy is if this 
happens. 

699
00:37:46,700 --> 00:37:48,700
That's what we do at that 
happens to that one. 

700
00:37:49,300 --> 00:37:51,500
So that's already definitely the
next level of maturity. 

701
00:37:51,700 --> 00:37:55,800
T, but I think it's important, 
it's not to start with the whole

702
00:37:55,800 --> 00:37:59,500
error budget policy before the 
team is actually ready for this 

703
00:37:59,500 --> 00:38:01,300
because that's a pretty Advanced
concept. 

704
00:38:01,500 --> 00:38:03,900
That's also how I put it in the 
book. 

705
00:38:03,900 --> 00:38:08,000
So I'm talking about the basic 
SRE commendations and advanced 

706
00:38:08,000 --> 00:38:09,800
as a repo indications. 
And the basic answer 

707
00:38:09,800 --> 00:38:13,800
recommendations are SL is Loz 
and error budget. 

708
00:38:14,100 --> 00:38:16,300
The advanced. 
That's very foundations of the 

709
00:38:16,300 --> 00:38:19,900
error, budget, policies, and 
error, budget, based decision 

710
00:38:19,900 --> 00:38:21,600
making. 
So, here we are. 

711
00:38:21,700 --> 00:38:24,900
Day in the advanced space, and 
we need to be aware of this. 

712
00:38:25,100 --> 00:38:28,100
It doesn't make sense for the 
sorry coaches to force the 

713
00:38:28,100 --> 00:38:30,900
discussion about the error 
budget policy, because either 

714
00:38:30,900 --> 00:38:33,500
people will just follow this 
fashion and forget about it the 

715
00:38:33,500 --> 00:38:37,300
next day, or they will just not 
be able to talk about this 

716
00:38:37,300 --> 00:38:39,000
because they're just too far 
away from this. 

717
00:38:39,400 --> 00:38:41,600
We know that for you to talk 
about the error budget policy, 

718
00:38:41,600 --> 00:38:43,900
you need already. 
Everybody's understanding about 

719
00:38:43,900 --> 00:38:45,800
PS allies. 
Everybody's understanding about 

720
00:38:45,800 --> 00:38:48,000
this fellow's. 
Everybody's understanding about 

721
00:38:48,000 --> 00:38:51,600
the era of budget and the solos.
Need to make sense you need. 

722
00:38:51,700 --> 00:38:54,500
To already have several 
iterations about the whole thing

723
00:38:54,600 --> 00:38:57,500
and then you need to reach a 
point where it's a point, okay? 

724
00:38:57,500 --> 00:39:00,100
So now we've exhausted every 
budget, but we haven't talked 

725
00:39:00,100 --> 00:39:03,700
about yet what we'll do now. 
And this is where you bring the 

726
00:39:03,700 --> 00:39:06,500
discussion not before once they 
ever budget. 

727
00:39:06,500 --> 00:39:10,300
Policy is in place, that's done 
good enough but then the real 

728
00:39:10,300 --> 00:39:13,000
test is okay. 
So we'll that error budget 

729
00:39:13,000 --> 00:39:16,600
policy, the executed, once it's 
really reaches the point where 

730
00:39:16,600 --> 00:39:19,100
we don't have that Arrow budget 
anymore of the service and 

731
00:39:19,100 --> 00:39:21,600
that's important. 
Does the team really follow what

732
00:39:21,700 --> 00:39:23,700
They have done. 
That's the next step. 

733
00:39:24,100 --> 00:39:28,300
And then, this step after is the
error budget, based decision 

734
00:39:28,300 --> 00:39:29,900
made. 
I think that's the cool step 

735
00:39:29,900 --> 00:39:33,800
backs at the talk of the three 
concepts remain in the book, I 

736
00:39:33,800 --> 00:39:36,100
put all those Concepts in the 
parameter and that's kind of 

737
00:39:36,107 --> 00:39:40,100
been the tip of the pyramid. 
It's all basically what you do 

738
00:39:40,200 --> 00:39:44,900
you start tracking your error 
budget consumption or your SLO 

739
00:39:44,900 --> 00:39:48,400
adherents over time, you divide 
the time into narrow budget 

740
00:39:48,400 --> 00:39:50,800
periods. 
So, could be one error, budget. 

741
00:39:50,800 --> 00:39:52,000
Period is just 1. 
Month. 

742
00:39:52,300 --> 00:39:56,200
And then you pour all your 
services and there is a little 

743
00:39:56,200 --> 00:39:58,200
red hearings by error budget 
you. 

744
00:39:58,700 --> 00:40:00,900
So you can have a group there 
you know you've got all your 

745
00:40:00,900 --> 00:40:04,400
services on the y-axis. 
And on the x-axis you could say 

746
00:40:04,600 --> 00:40:08,800
half a year's time line so would
be 60 budget periods and then 

747
00:40:08,800 --> 00:40:12,500
you see where you broke your 
slos and it's where you didn't 

748
00:40:12,500 --> 00:40:16,000
break them and Zone. 
If you break the SLO, for the 

749
00:40:16,000 --> 00:40:19,200
error budgetary, it's actually 
useful to see whether you broke 

750
00:40:19,200 --> 00:40:21,900
it but just a couple of 
percentages or whether Really 

751
00:40:21,900 --> 00:40:23,300
kind of broke it up 
significantly. 

752
00:40:23,700 --> 00:40:27,700
The same also applies, if you 
are fulfilling your SLO, then 

753
00:40:27,800 --> 00:40:30,700
you can fulfill it with a lot of
Arrow budget left at the end of 

754
00:40:30,700 --> 00:40:34,000
their budget Baron, or whether 
you nearly exhausted your error 

755
00:40:34,000 --> 00:40:36,300
budget. 
And therefore you kind of nearly

756
00:40:36,300 --> 00:40:39,700
broke their solo, those, the 
details are useful as well, but 

757
00:40:39,700 --> 00:40:42,000
the cool thing about that kind 
of high-level bash. 

758
00:40:42,000 --> 00:40:43,600
What is that? 
Especially in the product 

759
00:40:43,600 --> 00:40:47,700
managers, they are enabled to 
work with this because then you 

760
00:40:47,700 --> 00:40:51,200
can say all the time from 
experience, we actually thought 

761
00:40:51,200 --> 00:40:54,700
that We would have this certain 
service level but we are not 

762
00:40:54,700 --> 00:40:57,900
fulfilling this and therefore we
need to prioritize some 

763
00:40:57,900 --> 00:41:01,100
significant work in order to 
build a reliability into this 

764
00:41:01,100 --> 00:41:03,900
particular Services. 
The cool thing is that once you 

765
00:41:03,900 --> 00:41:07,300
make those decisions for your 
Based on data and not just on 

766
00:41:07,300 --> 00:41:10,600
the opinion of the architect on 
the Obion, all the developments 

767
00:41:10,600 --> 00:41:15,800
on which depending on the team 
culture, May weigh a lot or not,

768
00:41:15,800 --> 00:41:19,500
a lot to the product manager. 
So I can totally understand. 

769
00:41:19,500 --> 00:41:21,900
Once you have this cool 
dashboard where you can see each

770
00:41:21,900 --> 00:41:24,800
different Services, how they're 
performing the SLO, their 

771
00:41:24,800 --> 00:41:28,000
budget, whether they are bridge 
or healthy, I aspire to go that 

772
00:41:28,000 --> 00:41:29,600
way. 
One day like you said, it's a 

773
00:41:29,607 --> 00:41:32,700
data-driven approach of knowing 
where to improve and went to 

774
00:41:32,700 --> 00:41:34,400
improve your across different 
teams. 

775
00:41:34,500 --> 00:41:37,400
And don't forget the SLO. 
Here is a representation of 

776
00:41:37,400 --> 00:41:40,400
users happiness, The Summit AT 
internal metrics that you just 

777
00:41:40,400 --> 00:41:43,200
want to capture a, but it's 
actually a representation of the

778
00:41:43,207 --> 00:41:45,800
users happiness. 
So when you see it's being 

779
00:41:45,800 --> 00:41:49,100
Bridge, basically, the user 
should be unhappy As well, which

780
00:41:49,100 --> 00:41:51,300
is coming to my next question 
because in the healthcare 

781
00:41:51,300 --> 00:41:55,100
industry, I always assumed that 
healthcare industry must be very

782
00:41:55,100 --> 00:41:57,200
reliable. 
All these devices that you 

783
00:41:57,207 --> 00:42:00,200
mentioned they should function 
perfectly, but we know in a 

784
00:42:00,207 --> 00:42:02,900
sorry that hundred percent 
reliability is totally 

785
00:42:02,900 --> 00:42:05,900
impossible. 
Maybe can you tell us more about

786
00:42:05,900 --> 00:42:08,800
from your experience? 
Implementing in healthcare is 

787
00:42:08,800 --> 00:42:13,700
Healthcare, always like 99.9% 
reliable, or is there any kind 

788
00:42:13,700 --> 00:42:17,900
of explanation that you can give
here there are different device?

789
00:42:18,000 --> 00:42:21,000
Since and Associated software 
systems in health care. 

790
00:42:21,000 --> 00:42:25,800
There are Hardware scanners, 
there was your availability and 

791
00:42:25,800 --> 00:42:27,700
reliability, requirements are 
the highest. 

792
00:42:28,100 --> 00:42:31,900
There are very strict medical 
device regulations that oblige 

793
00:42:31,900 --> 00:42:35,500
you to perform certain tests and
so on in order to reach that 

794
00:42:35,500 --> 00:42:38,900
high level of reliability, then 
there are so bold 

795
00:42:38,900 --> 00:42:42,400
post-processing workstations. 
These are still on premise 

796
00:42:42,400 --> 00:42:45,900
software systems that of course 
need to also work your Lively 

797
00:42:45,900 --> 00:42:49,800
because they work in a hospital.
Very fast a decently persistent.

798
00:42:49,800 --> 00:42:52,300
Doesn't warn them that can block
the entire workload. 

799
00:42:52,300 --> 00:42:56,100
But at least it doesn't harm 
human life anymore if it doesn't

800
00:42:56,100 --> 00:42:59,100
want. 
So then there is the clouds or 

801
00:42:59,100 --> 00:43:04,300
wet which are services that 
enable you to run your fleets of

802
00:43:04,300 --> 00:43:07,300
scanners more efficiently. 
If that doesn't work. 

803
00:43:07,300 --> 00:43:10,600
Then at least you don't block 
immediately the work in the 

804
00:43:10,600 --> 00:43:14,300
hospital department, but you 
would block for instance, the 

805
00:43:14,400 --> 00:43:18,900
operations person we see all of 
the hospital Who is now trying 

806
00:43:18,900 --> 00:43:23,200
to optimize the assignment of 
the patients to this cameras in 

807
00:43:23,200 --> 00:43:25,400
order to be more efficient? 
So there are different kind of 

808
00:43:25,400 --> 00:43:27,600
levels. 
All reliability that you need to

809
00:43:27,600 --> 00:43:30,800
have that and all that is 
governed by the medical device 

810
00:43:30,800 --> 00:43:33,200
regulations. 
They are also a bit different 

811
00:43:33,200 --> 00:43:37,800
depending on the criticality of 
the system to the human lives 

812
00:43:38,600 --> 00:43:41,000
and interested very much 
interested in the hardware 

813
00:43:41,000 --> 00:43:42,500
scanners. 
When you mention it has to be 

814
00:43:42,500 --> 00:43:44,900
the most reliable. 
What happens when the error 

815
00:43:44,900 --> 00:43:47,900
budget is about to be breached 
or maybe there's an alert. 

816
00:43:48,100 --> 00:43:50,800
Being other people scrambling 
because it could affect people's

817
00:43:50,800 --> 00:43:52,700
live, right? 
So, tell us, when this situation

818
00:43:52,700 --> 00:43:54,500
happens, what actually really 
happens? 

819
00:43:55,600 --> 00:43:58,600
Well, first of all, we only 
applied so far as a retail 

820
00:43:58,600 --> 00:44:01,900
software, but I think it's a 
good idea to also, think about 

821
00:44:01,900 --> 00:44:05,300
how that could apply to on where
the scammers themselves. 

822
00:44:05,300 --> 00:44:09,000
They've got lots of checks and 
balances in order, not to harm 

823
00:44:09,000 --> 00:44:11,600
the patient. 
So for example, you can really 

824
00:44:11,600 --> 00:44:15,500
think of a complete tomography 
CT scanner. 

825
00:44:15,900 --> 00:44:20,500
That's a discolored injects. 
Some acceptable radiation dose 

826
00:44:20,500 --> 00:44:24,400
of radiation into the patient in
order to acquire images from the

827
00:44:24,400 --> 00:44:27,200
patient. 
Of course, if the scanner would 

828
00:44:27,200 --> 00:44:30,800
notice that now, the patient 
would be hard because there is 

829
00:44:30,800 --> 00:44:33,600
scary too much. 
Radiation about to be exposed 

830
00:44:33,600 --> 00:44:35,400
than the machine will stop the 
scan. 

831
00:44:35,600 --> 00:44:37,700
So immediately, the stop will be
notified. 

832
00:44:37,800 --> 00:44:40,700
Please sample. 
Then remove the patient from the

833
00:44:40,700 --> 00:44:42,400
ringing, where the scanner is 
installed. 

834
00:44:42,400 --> 00:44:44,700
And so on. 
So there are definitely lots of 

835
00:44:44,700 --> 00:44:49,000
precautionary measures that then
additionally, What the cloud 

836
00:44:49,000 --> 00:44:53,300
software can do where we apply 
this theory is that we have got?

837
00:44:53,400 --> 00:44:55,200
For example, those management 
software. 

838
00:44:55,600 --> 00:44:57,900
Those management is a 
cloud-based application. 

839
00:44:58,400 --> 00:45:02,700
It can also monitor, although 
not kind of in real time. 

840
00:45:02,700 --> 00:45:06,900
What's going on with the scans 
being done right now but it can 

841
00:45:06,900 --> 00:45:10,300
monitor things. 
Like, for example, imagine you 

842
00:45:10,300 --> 00:45:15,100
are a patient that requires 
several scans that means that 

843
00:45:15,100 --> 00:45:19,400
actually your accumulated 
radiation those Over time can 

844
00:45:19,400 --> 00:45:23,000
actually be exceeding a certain 
threshold that is also about 

845
00:45:23,000 --> 00:45:25,200
meat by the government 
regulations. 

846
00:45:25,500 --> 00:45:29,200
So actually you need to keep 
track of the radiation not just 

847
00:45:29,200 --> 00:45:32,700
during a particular scan, but 
also overall, over a period of 

848
00:45:32,700 --> 00:45:34,700
time. 
If you've got some serious 

849
00:45:34,700 --> 00:45:38,200
disease, then you might be 
prescribed to do certain scans 

850
00:45:38,300 --> 00:45:42,100
within say a year or so. 
So what that software can do it 

851
00:45:42,100 --> 00:45:46,600
can actually keep track of your 
accumulated dose and then also 

852
00:45:46,600 --> 00:45:49,100
issue warnings. 
You the hospital Stout. 

853
00:45:49,100 --> 00:45:52,500
Actually that Beijing already 
got so much, and therefore, be 

854
00:45:52,500 --> 00:45:55,800
careful insult. 
As you can see, this is very 

855
00:45:55,800 --> 00:45:59,100
interesting industry where the 
different levels you require 

856
00:45:59,100 --> 00:46:02,300
liability and that can be on the
one hand, really kind of Life 

857
00:46:02,300 --> 00:46:05,900
critical right now too. 
Okay, so it's not like preschool

858
00:46:05,900 --> 00:46:09,000
right now, but you still need to
have some monitoring. 

859
00:46:09,000 --> 00:46:12,000
Also, the patient in order not 
to expose the patients to 

860
00:46:12,000 --> 00:46:15,300
somehow control treatment Thanks
for sharing all this. 

861
00:46:15,300 --> 00:46:17,700
The reason I ask is because some
people might have perception. 

862
00:46:17,700 --> 00:46:20,800
Okay, this may only work for 
certain cases maybe internet 

863
00:46:20,800 --> 00:46:23,000
based software, right? 
But actually you can apply it 

864
00:46:23,000 --> 00:46:25,200
almost in anything, especially 
in technology. 

865
00:46:25,600 --> 00:46:28,300
So let's go back to the 
discussion about implementing a 

866
00:46:28,300 --> 00:46:31,300
sorry in your organization. 
So let's say you have done it. 

867
00:46:31,500 --> 00:46:34,000
The teams have already 
implemented, maybe from your 

868
00:46:34,000 --> 00:46:36,000
view. 
How do you actually measure that

869
00:46:36,000 --> 00:46:38,400
this asari transformation is 
successful? 

870
00:46:38,500 --> 00:46:42,100
Are there any indicators that 
you probably check periodically 

871
00:46:42,100 --> 00:46:43,800
to say that? 
Okay, this is sorry. 

872
00:46:43,800 --> 00:46:46,000
Bill Addition is actually 
progressing really well? 

873
00:46:46,200 --> 00:46:48,700
Maybe some tips here. 
I know that you have some dips 

874
00:46:48,700 --> 00:46:50,900
in the books as well. 
Maybe you can give some summary.

875
00:46:51,000 --> 00:46:54,100
What kind of measurement that 
you do in order to find out that

876
00:46:54,100 --> 00:46:55,700
your transformation is 
successful? 

877
00:46:56,600 --> 00:46:58,800
The so, especially the 
beginning. 

878
00:46:59,100 --> 00:47:03,200
It's a good idea to just see how
many services the teams are 

879
00:47:03,200 --> 00:47:04,800
onboarding on to the 
infrastructure. 

880
00:47:05,600 --> 00:47:08,700
This is non outcome-based course
because you still don't know 

881
00:47:08,700 --> 00:47:10,200
whether it's a group 
reliability. 

882
00:47:10,600 --> 00:47:13,800
But at least this output based 
indicators in the beginning 

883
00:47:13,800 --> 00:47:14,700
there. 
Suddenly good. 

884
00:47:14,700 --> 00:47:18,400
Because if teams are not willing
to put their services onto the 

885
00:47:18,500 --> 00:47:20,700
Surrey infrastructure, then 
there's no use in the 

886
00:47:20,700 --> 00:47:23,900
infrastructure that's one day 
once you see, okay? 

887
00:47:23,900 --> 00:47:26,400
So the number of services is 
growing on the infrastructure, 

888
00:47:26,400 --> 00:47:29,400
so that's good means teams have 
finding the infrastructure 

889
00:47:29,400 --> 00:47:32,700
useful. 
Then the next thing is okay. 

890
00:47:32,700 --> 00:47:37,000
So do the team's Define this 
ellos in the number of its ellos

891
00:47:37,000 --> 00:47:39,700
actually growing. 
Then the next thing, okay? 

892
00:47:39,700 --> 00:47:43,200
Now that the slos and there but 
are they being fulfilled if 

893
00:47:43,200 --> 00:47:45,100
there is a load? 
But the majority of them are 

894
00:47:45,100 --> 00:47:47,900
broken, then that means the 
teams just forget about them, 

895
00:47:48,200 --> 00:47:50,600
they basically don't make sense,
then DC? 

896
00:47:50,600 --> 00:47:53,500
Okay, so, what is the percentage
of his fellows that have been 

897
00:47:53,500 --> 00:47:55,900
fulfilled? 
Then the next step is coming 

898
00:47:55,900 --> 00:47:58,400
back to those customized 
collations that we were talking 

899
00:47:58,400 --> 00:48:01,000
about earlier. 
It can easily happen that all 

900
00:48:01,000 --> 00:48:04,300
your solos and perfect green. 
So that's all cool but because 

901
00:48:04,300 --> 00:48:07,500
the must keep calling, these are
the measures that you can take 

902
00:48:07,500 --> 00:48:12,200
in order to monitor the process 
of the sorry introduction. 

903
00:48:12,900 --> 00:48:15,700
I like the way you describe it, 
your error budget can be all 

904
00:48:15,700 --> 00:48:17,500
green but the customers keep 
complaining. 

905
00:48:17,500 --> 00:48:20,400
So I think that is also like a 
big sign that actually, you 

906
00:48:20,400 --> 00:48:23,400
might have missed the most 
important slos of all, right? 

907
00:48:23,800 --> 00:48:26,200
Because the true measure of 
implementing a, sorry correctly 

908
00:48:26,200 --> 00:48:28,400
or consumers, should be happy 
and then your error budget is 

909
00:48:28,400 --> 00:48:30,200
representation of that in their 
book. 

910
00:48:30,200 --> 00:48:32,700
You also mention a couple of 
other things, like, for example,

911
00:48:32,800 --> 00:48:35,300
perception from the partners 
that you work with, not just the

912
00:48:35,300 --> 00:48:38,200
users, I think that also matters
because sometimes if you are 

913
00:48:38,200 --> 00:48:40,900
like access provider, right? 
So some Partners connecting to 

914
00:48:40,900 --> 00:48:44,200
you also matters whether they 
come, Not so thanks for all this

915
00:48:44,200 --> 00:48:46,400
measurement. 
Dr. Pratt is been a great 

916
00:48:46,400 --> 00:48:49,300
conversation so far but 
unfortunately due to time we 

917
00:48:49,300 --> 00:48:51,700
have to wrap up. 
But before I let you go, I have 

918
00:48:51,700 --> 00:48:55,100
one last question that I always 
love to ask my guess which is to

919
00:48:55,100 --> 00:48:57,900
share your version of three 
technical leadership system. 

920
00:48:58,300 --> 00:49:00,500
Is there something that you want
to share with us here dr. 

921
00:49:00,500 --> 00:49:04,100
Blood let me think of something 
that would be in the context of 

922
00:49:04,100 --> 00:49:06,800
this Rich information but still 
kind of applicable. 

923
00:49:06,800 --> 00:49:10,100
See General technical work. 
One thing that's important is 

924
00:49:10,100 --> 00:49:14,100
pure lag in context. 
I think that's important because

925
00:49:14,100 --> 00:49:17,200
there are very many 
Technologies, methodologies and 

926
00:49:17,200 --> 00:49:20,900
so on, but it's the context that
actually decides whether this 

927
00:49:20,900 --> 00:49:23,600
particular thing that you will 
have heard about everything 

928
00:49:23,600 --> 00:49:26,000
about have thought about would 
actually fit. 

929
00:49:26,400 --> 00:49:30,000
So, I think this kind of acting 
in context is an important, I'd 

930
00:49:30,000 --> 00:49:34,700
say evade principal to follow. 
Another important aspect, I 

931
00:49:34,700 --> 00:49:38,900
would say is to practice servant
leadership. 

932
00:49:39,100 --> 00:49:43,900
That means that on the one hand,
trying to Show the way to the 

933
00:49:43,900 --> 00:49:48,500
organization to teams but on the
other hand also being very well 

934
00:49:48,500 --> 00:49:53,900
aware of their context and 
therefore kind of inviting them 

935
00:49:53,900 --> 00:49:57,600
to go on a certain Journey 
instead of coercing them to 

936
00:49:57,600 --> 00:50:00,900
adopt a particular thing on one 
end league. 

937
00:50:00,900 --> 00:50:03,000
But on the other hand, do this 
in a servant. 

938
00:50:03,000 --> 00:50:07,600
Wait, I think that's important. 
They start thing would be. 

939
00:50:07,600 --> 00:50:11,000
I'd say all these things that 
we've talked about they're kind 

940
00:50:11,000 --> 00:50:13,200
of not easy. 
For the developers. 

941
00:50:13,200 --> 00:50:15,500
It's not easy to just jump on 
cold, right? 

942
00:50:15,500 --> 00:50:18,700
It's a totally different game. 
If you've never done this world 

943
00:50:18,700 --> 00:50:23,200
for the operations people to 
start suddenly act as a real 

944
00:50:23,200 --> 00:50:26,100
software developers providing 
Frameworks to the other teams 

945
00:50:26,100 --> 00:50:30,300
and so on it's a totally 
different world and for the 

946
00:50:30,300 --> 00:50:33,400
product managers to suddenly be 
involved in operations. 

947
00:50:33,400 --> 00:50:37,300
It's also you know out of their 
world so far so I think I do 

948
00:50:37,500 --> 00:50:42,000
acknowledging that this is not 
easy empathizing with the 

949
00:50:42,000 --> 00:50:45,100
people. 
Specifically is a third Point, 

950
00:50:45,100 --> 00:50:47,600
kind of looking for ways to 
motivate people. 

951
00:50:48,000 --> 00:50:51,800
I think this is really important
to make some change thick 

952
00:50:51,800 --> 00:50:53,400
especially on this Region's 
formation. 

953
00:50:53,400 --> 00:50:57,300
During there are so many ways 
where you can point out very 

954
00:50:57,300 --> 00:51:01,300
small wins, I think a really 
pointing out those small wins 

955
00:51:01,300 --> 00:51:04,700
that now is a team, we've done 
this, that really motivates. 

956
00:51:04,700 --> 00:51:08,600
The people are taking this 
serious from the asari those for

957
00:51:08,600 --> 00:51:11,800
you to do and really seeking 
things that people can be 

958
00:51:11,800 --> 00:51:14,200
thanked for. 
For them by driving the 

959
00:51:14,200 --> 00:51:16,400
motivation. 
I think it's really really 

960
00:51:16,400 --> 00:51:19,100
people. 
Well, I love the last one. 

961
00:51:19,300 --> 00:51:22,900
So first you have to acknowledge
people situation empathize with 

962
00:51:22,900 --> 00:51:25,800
them and find motivations and 
celebrate the small wins. 

963
00:51:26,100 --> 00:51:29,300
I think that's always important 
for any kind of data dr. 

964
00:51:29,300 --> 00:51:31,000
Flat. 
If people want to learn from 

965
00:51:31,000 --> 00:51:34,000
your journey or so maybe they 
want to establish the same as 

966
00:51:34,000 --> 00:51:36,700
sorry transformation in their 
organization and they want to 

967
00:51:36,700 --> 00:51:38,300
learn from you. 
Is there a place where they can 

968
00:51:38,300 --> 00:51:40,800
find you online connect with you
or ask questions? 

969
00:51:41,600 --> 00:51:43,700
Yeah, definitely. 
Can be easily followed on 

970
00:51:43,700 --> 00:51:46,900
LinkedIn now with LinkedIn. 
There are several conversation 

971
00:51:46,900 --> 00:51:49,300
threads about the book. 
I think that would be also the 

972
00:51:49,300 --> 00:51:52,600
best way to just join those 
threads or start new ones where 

973
00:51:52,600 --> 00:51:55,600
we can discuss those things. 
And also thank our watch all the

974
00:51:55,600 --> 00:51:58,400
conversation on the questions. 
I think that brought out early, 

975
00:51:58,400 --> 00:52:01,000
good aspects, and was really fun
to talk about. 

976
00:52:01,200 --> 00:52:03,400
And while we were doing this, I 
was thinking that there is 

977
00:52:03,400 --> 00:52:06,000
formulate another Myriad of 
things that we could talk about 

978
00:52:06,000 --> 00:52:09,800
because that topic stove us. 
Yeah, when I saw your book is 

979
00:52:09,800 --> 00:52:12,300
very thick and lots of good 
information there. 

980
00:52:12,300 --> 00:52:15,300
I even finished reading it 
definitely, but people do check 

981
00:52:15,300 --> 00:52:16,900
it out. 
So I think it's really like 

982
00:52:16,900 --> 00:52:19,500
transformation based kind of 
learnings, right? 

983
00:52:19,700 --> 00:52:22,500
It provides you like, the 
rationale of how you implement 

984
00:52:22,500 --> 00:52:25,300
necessary, the step-by-step 
Journey, including to the end 

985
00:52:25,300 --> 00:52:27,400
measuring the transformation, 
making sure that you are 

986
00:52:27,400 --> 00:52:29,900
successful in your journey. 
So thanks to dr. 

987
00:52:29,900 --> 00:52:32,000
Vlad for this conversation, I 
really love it. 

988
00:52:32,300 --> 00:52:35,400
So good luck with their future 
Improvement for your, a sorry 

989
00:52:35,400 --> 00:52:38,700
transformations in your company.
Thank you very much. 

990
00:52:38,700 --> 00:52:42,000
Thanks a lot for having me and 
thanks to everyone who took the 

991
00:52:42,000 --> 00:52:45,100
time to Listen to this episode. 
Thank you very much everything, 

992
00:52:45,100 --> 00:52:46,700
like to improve operations 
together. 

993
00:52:49,500 --> 00:52:52,700
Thank you for listening to this 
episode and for staying, right 

994
00:52:52,700 --> 00:52:55,200
until the end if you highly 
enjoyed it. 

995
00:52:55,400 --> 00:52:57,700
I would appreciate if you share 
it with your friends and 

996
00:52:57,700 --> 00:53:00,700
colleagues who you think would 
also benefit from listening to 

997
00:53:00,700 --> 00:53:02,700
this episode. 
And if you're new to the 

998
00:53:02,700 --> 00:53:05,700
podcast, make sure to subscribe 
and leave me your valuable 

999
00:53:05,700 --> 00:53:08,300
review and feedback. 
It helps me a lot. 

1000
00:53:08,300 --> 00:53:10,300
In order to grow this podcast 
better. 

1001
00:53:10,700 --> 00:53:13,600
You can also find the full show 
notes of this conversation on 

1002
00:53:13,600 --> 00:53:17,700
the episode page, at Tech Legion
o.f website, including the full 

1003
00:53:17,700 --> 00:53:20,600
transcript, With interesting 
quotes and links to the 

1004
00:53:20,600 --> 00:53:23,000
resources mentioned, from the 
conversation. 

1005
00:53:23,400 --> 00:53:26,400
And lastly, make sure to 
subscribe to the shows mailing 

1006
00:53:26,400 --> 00:53:29,800
list on technology. 
No dot f to get notified for any

1007
00:53:29,800 --> 00:53:32,500
future episodes. 
Stay tuned for the next 

1008
00:53:32,500 --> 00:53:33,900
technology. 
No episode. 

1009
00:53:34,200 --> 00:53:35,800
And until then goodbye.