1
00:00:02,939 --> 00:00:05,819
Narrator: You're listening to
the humans of DevOps podcast, a

2
00:00:05,819 --> 00:00:09,449
podcast focused on advancing the
humans of DevOps through skills,

3
00:00:09,479 --> 00:00:13,799
knowledge, ideas, and learning,
or the skil framework.

4
00:00:16,859 --> 00:00:21,839
Luca Galante: So usually, it's
already quite a hurdle to

5
00:00:21,839 --> 00:00:25,739
convince the executive and all
different internal stakeholders

6
00:00:25,739 --> 00:00:30,359
to start and drive a platform
initiative that can and should

7
00:00:30,419 --> 00:00:31,559
last for years.

8
00:00:33,960 --> 00:00:37,470
Eveline Oehrlich: Welcome to the
humans of DevOps Podcast. I'm

9
00:00:37,470 --> 00:00:40,950
Evelyn early Chief Research
Officer at DevOps Institute.

10
00:00:41,700 --> 00:00:47,040
Today we have with us drumroll,
Luca Galanti is a product owner.

11
00:00:47,490 --> 00:00:51,510
And our title of our podcast is
a conversation with a thought

12
00:00:51,510 --> 00:00:56,460
leader on platform engineering,
I just talked to look at finding

13
00:00:56,460 --> 00:01:00,600
out from where he is coming to
to us, I will not give it away.

14
00:01:00,630 --> 00:01:05,250
But he's in a very beautiful
place. Hopefully, all of you

15
00:01:05,250 --> 00:01:09,690
listening into us will be in a
beautiful place, having a nice

16
00:01:09,690 --> 00:01:14,640
cup of whatever in front of you
enjoying our conversation. So

17
00:01:15,270 --> 00:01:18,960
let me give you a little bit of
background on Luca, he actually

18
00:01:18,960 --> 00:01:22,710
routinely speaks to 10s of
engineering teams every month,

19
00:01:22,740 --> 00:01:26,850
tons of engineering teams, not
10s. But tons. Every month, he

20
00:01:26,850 --> 00:01:29,490
summarizes his learnings and
takeaways from looking at

21
00:01:29,490 --> 00:01:33,750
hundreds of DevOps setups into
very crisp and insightful reads

22
00:01:33,750 --> 00:01:38,760
for everyone in the industry.
And that from beginner ops to

23
00:01:38,790 --> 00:01:42,630
cloud experts. So Luke, welcome
to our podcast.

24
00:01:43,710 --> 00:01:47,010
Luca Galante: Thank you. Thank
you for having me. And hello to

25
00:01:47,010 --> 00:01:49,710
everybody from Tenerife. A
really nice place.

26
00:01:49,949 --> 00:01:53,330
Eveline Oehrlich: Yeah, he gave
it away, thank you give it away.

27
00:01:53,403 --> 00:01:57,960
That is your choice of giving
that away. I've been to tenerife

28
00:01:58,034 --> 00:02:02,297
myself and it is a beautiful
place. So enjoy it. Thank you

29
00:02:02,371 --> 00:02:06,193
give us a little bit more
background on your current

30
00:02:06,266 --> 00:02:09,060
position and what you do Luca, totally

31
00:02:09,509 --> 00:02:14,429
Luca Galante: happy to so I run
product at humanI tech. But I

32
00:02:14,429 --> 00:02:18,179
guess I'm more known in this
pace as one of the core

33
00:02:18,179 --> 00:02:21,239
contributors to the platform
engineering community. I

34
00:02:21,269 --> 00:02:24,719
moderate the slack there where
we have almost 10,000 People

35
00:02:24,749 --> 00:02:28,319
actually I think we're going
across 10,000 Next week, I host

36
00:02:28,319 --> 00:02:31,199
platform con which is the first
ever platform engineering

37
00:02:31,199 --> 00:02:36,029
conference, I write a newsletter
that goes out to six or 7000

38
00:02:36,029 --> 00:02:38,609
people. It's called Platform
weekly, it goes out every week.

39
00:02:38,669 --> 00:02:44,969
And yeah, so I talk a lot about
platform engineering. And as you

40
00:02:44,969 --> 00:02:48,929
mentioned in the intro, also
kind of discuss what the

41
00:02:48,929 --> 00:02:52,439
benefits can be with a lot of
sort of like infrastructure,

42
00:02:52,439 --> 00:02:54,119
DevOps, and so on teams

43
00:02:54,389 --> 00:02:57,719
Eveline Oehrlich: all over the
world. Fantastic. And I think

44
00:02:57,719 --> 00:03:01,079
that's why of course, we are
very interested in talking to

45
00:03:01,079 --> 00:03:06,389
you. Just again, for your
benefit Luca, our audience is

46
00:03:06,479 --> 00:03:10,739
really wide spectrum from
beginners, DevOps from more

47
00:03:10,739 --> 00:03:14,939
advanced, we have practitioners,
we've got site reliability

48
00:03:14,939 --> 00:03:18,329
engineers, we probably got a few
platform engineers on the call

49
00:03:18,659 --> 00:03:24,659
on our on our podcasts listening
in, we've got testers, we've got

50
00:03:25,199 --> 00:03:29,159
system administrators, we've got
leaders, we've got individual

51
00:03:29,159 --> 00:03:32,309
contributors. So just so that
you have a bit of a bit of a

52
00:03:32,309 --> 00:03:36,929
background. Now, the term
platform engineering has gained

53
00:03:36,959 --> 00:03:42,539
steam, and to the tune of folks,
manual players. And Matthew

54
00:03:42,539 --> 00:03:46,379
Skelton who I both know,
mentioned, actually this topic

55
00:03:46,799 --> 00:03:52,649
in their book, in 2019. I did
some research with a vendor

56
00:03:52,649 --> 00:03:56,939
partner of the DevOps Institute,
also in 2020, on site

57
00:03:56,939 --> 00:04:01,349
reliability engineering, and we
saw the term show up there, then

58
00:04:01,409 --> 00:04:05,849
as well. So you've been, as you
said, a core contributor to this

59
00:04:05,849 --> 00:04:09,629
platform engineering community.
And we'll have later on for all

60
00:04:09,629 --> 00:04:15,929
the listeners a more details on
where you can get involved. But

61
00:04:15,959 --> 00:04:19,649
before we go any further, I
always love to make sure that we

62
00:04:19,649 --> 00:04:24,689
have a definition. So what is
the definition of platform

63
00:04:24,719 --> 00:04:28,379
engineering? Totally. So

64
00:04:29,400 --> 00:04:31,500
Luca Galante: the way I think
about it is platform engineering

65
00:04:31,500 --> 00:04:35,970
is really the art because it's
more of an art than a science,

66
00:04:35,970 --> 00:04:40,500
in my opinion, of effectively
taking all the tech and tools

67
00:04:40,500 --> 00:04:43,860
that you have, especially in an
enterprise engineer

68
00:04:43,860 --> 00:04:50,700
organizations and binding them
into a golden path that enables

69
00:04:50,790 --> 00:04:54,780
developers cell service and in
general reduces the cognitive

70
00:04:54,780 --> 00:05:00,180
load for the individual
contributor and the sum of This

71
00:05:00,180 --> 00:05:04,740
golden path that are built by
the platform engineering team

72
00:05:04,740 --> 00:05:07,410
for the rest of the junior
organizations is often referred

73
00:05:07,410 --> 00:05:14,010
to as an intern developer, or
IDP for short. And the focus of

74
00:05:14,010 --> 00:05:18,060
an IDP is really that of
improving developer experience,

75
00:05:18,600 --> 00:05:21,990
by lowering cognitive load to
developers, while also

76
00:05:22,530 --> 00:05:25,830
streamlining the kind of like
infrastructure and operational

77
00:05:25,830 --> 00:05:31,770
setup, on the other side of
things. And a sort of like key

78
00:05:31,770 --> 00:05:35,970
principle that we advocate for
in the community is platform as

79
00:05:35,970 --> 00:05:43,050
a product. And so really have
platform teams focus on building

80
00:05:43,050 --> 00:05:47,340
and shipping a platform as any
other product to the rest of the

81
00:05:47,340 --> 00:05:51,000
G organizations, which is really
their internal customers and the

82
00:05:51,000 --> 00:05:55,890
developers. And so that's kind
of how we define platform

83
00:05:55,890 --> 00:05:59,280
engineering, in turn developer
platform, which is the product

84
00:05:59,310 --> 00:06:04,020
of platform engineering, and the
two main actors in that

85
00:06:04,020 --> 00:06:06,870
transaction, which is the
platform team, on the one hand,

86
00:06:07,080 --> 00:06:10,380
apart from engineers, and the
developers, their internal

87
00:06:10,380 --> 00:06:11,490
customers on the outer.

88
00:06:12,990 --> 00:06:16,470
Eveline Oehrlich: So IDP, that's
something for everybody to do

89
00:06:16,500 --> 00:06:20,250
note down. And so typically,
where does such a team sit? If I

90
00:06:20,250 --> 00:06:25,410
think of the organization,
today, reporting to application

91
00:06:25,410 --> 00:06:29,850
development, infrastructure
operations DevOps, and you

92
00:06:29,850 --> 00:06:34,020
cannot say it depends on what's
the typical. What's the typical

93
00:06:34,020 --> 00:06:38,970
team these folks sit in, in
terms of the organization?

94
00:06:41,130 --> 00:06:44,550
Luca Galante: It's gonna be hard
without the independence, about

95
00:06:44,550 --> 00:06:51,000
answer. So, you know, the
reality is, we see very

96
00:06:51,000 --> 00:06:54,840
different kind of, sort of, like
organizational designs,

97
00:06:54,840 --> 00:06:58,770
depending on really the size.
More importantly, right. So

98
00:06:58,920 --> 00:07:03,540
you'll have teams of 100 200,
engineers, where they report

99
00:07:03,540 --> 00:07:07,740
directly to the CTO, you have,
you know, come massive companies

100
00:07:07,770 --> 00:07:11,400
that we work with 1000s of
engineers, and obviously, the

101
00:07:11,400 --> 00:07:14,700
platform team does not report
directly to the seat to but to

102
00:07:14,700 --> 00:07:18,600
some VP level, probably
responsible on developer

103
00:07:18,600 --> 00:07:21,990
experience, or cloud
infrastructure, or cloud ops.

104
00:07:22,650 --> 00:07:25,260
You know, you have your kind of,
like, Director of dev x had a

105
00:07:25,260 --> 00:07:29,010
plot firm, those are the type of
like titles that usually lead

106
00:07:29,010 --> 00:07:29,880
these initiatives.

107
00:07:31,350 --> 00:07:35,250
Eveline Oehrlich: So to some
extent, I have also seen them as

108
00:07:35,250 --> 00:07:38,400
a shared services group, of
course, that name is not really

109
00:07:38,400 --> 00:07:42,240
Vogue, right? Who wants to be a
shared services group, but I've

110
00:07:42,240 --> 00:07:47,880
seen them as a as a as an added
value to, to that team, it kind

111
00:07:47,880 --> 00:07:52,200
of depends on as you said, so I
said, it depends. I didn't tell

112
00:07:52,200 --> 00:07:55,620
myself, I was not supposed to
say that. So but thank you, that

113
00:07:55,620 --> 00:08:00,420
was really, really good. Now,
again, the goals of this team,

114
00:08:00,420 --> 00:08:04,380
you alluded to it a little bit
already, but give us what are

115
00:08:04,380 --> 00:08:05,160
their goals?

116
00:08:06,930 --> 00:08:13,800
Luca Galante: Totally. So the
the main goal of the platform

117
00:08:13,800 --> 00:08:18,960
team really is that of figuring
out what the what is the minimum

118
00:08:18,960 --> 00:08:23,910
common denominator, across their
entire engineer organizations

119
00:08:24,090 --> 00:08:27,750
have problems that the
developers have, right? So you

120
00:08:27,750 --> 00:08:31,290
really want to start from not
Oh, hey, let me through, like

121
00:08:31,290 --> 00:08:34,470
build a platform with the latest
shiny new tech, because I've

122
00:08:34,470 --> 00:08:37,380
heard somewhere that it's cool.
And I should, I should take a

123
00:08:37,380 --> 00:08:41,520
look at that. But really take a
look at you know, the complexity

124
00:08:41,610 --> 00:08:44,310
and the reality of your
brownfield enterprise setup,

125
00:08:44,430 --> 00:08:48,660
where you usually have, you
know, many different development

126
00:08:48,660 --> 00:08:53,460
teams with very different stacks
and delivery setups, you know,

127
00:08:53,460 --> 00:08:57,360
you have the ones that prefer
using your circle CI applies

128
00:08:57,360 --> 00:09:00,690
aren't go, the ones that are on
Jenkins, the other ones are

129
00:09:00,690 --> 00:09:05,160
using something again. And so
you kind of want to take a look

130
00:09:05,160 --> 00:09:08,790
at all of that and get an
understanding, alright, what is

131
00:09:08,790 --> 00:09:13,560
the minimum common denominator
that souls the attacks, the

132
00:09:13,620 --> 00:09:17,100
largest possible problem
surface, and that's really the

133
00:09:17,100 --> 00:09:23,280
starting point of a platform
team, together with pinning down

134
00:09:23,310 --> 00:09:27,900
precisely a mission and a role
for the platform team that gets

135
00:09:28,080 --> 00:09:31,140
marketed internally to the rest
of the organization, because

136
00:09:31,140 --> 00:09:35,640
that's really important. In
order to make sure that your

137
00:09:35,640 --> 00:09:40,410
platform initiative is
successful, is to make clear

138
00:09:40,410 --> 00:09:44,220
that everybody makes sure that
everybody understands, hey, you

139
00:09:44,220 --> 00:09:47,640
know, this is not another
infrastructure SRE team. This is

140
00:09:47,640 --> 00:09:50,670
a product team. And so this
reconnects to what I was

141
00:09:50,670 --> 00:09:53,550
mentioning in the beginning,
which is really the core tenet

142
00:09:53,760 --> 00:09:57,060
of platform engineering and what
clearly differentiates a

143
00:09:57,060 --> 00:10:01,890
platform team from a DevOps
infrastruc Archer essary team is

144
00:10:01,890 --> 00:10:07,530
this product mindset, right? So
is the idea that you need to

145
00:10:07,530 --> 00:10:10,980
build a very tight feedback loop
with the rest of the engineer

146
00:10:10,980 --> 00:10:15,270
organizations, which again, are
your your customers, and make

147
00:10:15,270 --> 00:10:18,930
sure that you iterate on top of
this minimum common denominator

148
00:10:18,930 --> 00:10:22,890
are problems that you identified
at the beginning. And keep

149
00:10:22,920 --> 00:10:27,930
shipping teachers and keep
improving the platform by

150
00:10:27,930 --> 00:10:30,480
building different is different
types of golden paths that we

151
00:10:30,480 --> 00:10:34,320
mentioned different in the
definition. And this is really,

152
00:10:34,620 --> 00:10:38,730
the I think the make or break
for a successful platform team

153
00:10:38,970 --> 00:10:42,900
is the ability of listening and
communicating clearly,

154
00:10:42,930 --> 00:10:47,430
internally, internally to the
organization. And understanding

155
00:10:48,120 --> 00:10:51,810
what are the best golden paths
that I can design for different

156
00:10:51,810 --> 00:10:55,440
types of users across different
types of teams. Right. So as an

157
00:10:55,440 --> 00:10:58,770
example, you'll have, you know,
your senior backend engineer

158
00:10:58,770 --> 00:11:03,180
that really enjoys handling
their Helm charts and icy

159
00:11:03,180 --> 00:11:06,840
modules and some weird Yamo
files and scripts that they've

160
00:11:06,930 --> 00:11:12,990
put together. If you, you know,
build a platform that is very

161
00:11:12,990 --> 00:11:17,550
you, hi, Avi, and completely
abstracts all of that away from

162
00:11:17,550 --> 00:11:21,870
them, they'll fill, you know,
they have no context, and

163
00:11:21,900 --> 00:11:24,960
they'll push back on your path
from initiatives and that

164
00:11:24,960 --> 00:11:29,790
platform initiative will
probably fail. On the flip side

165
00:11:29,790 --> 00:11:33,120
of that you might have, you
know, a junior front end

166
00:11:33,120 --> 00:11:36,570
engineer, that doesn't care
whether you're running on

167
00:11:36,600 --> 00:11:41,070
Kubernetes, or somewhere else,
they just want to deploy their

168
00:11:41,070 --> 00:11:44,310
code, see, you know, test some
changes, and if you go and so

169
00:11:45,000 --> 00:11:48,660
for them, it might make sense to
have a much higher level of

170
00:11:48,690 --> 00:11:51,960
structuring, whether it's
through UI, or usually what we

171
00:11:51,960 --> 00:11:55,860
find, on average is still you
want to do something code base,

172
00:11:55,860 --> 00:11:59,430
because developers don't like to
be abstracted away into UI. But

173
00:11:59,430 --> 00:12:03,120
that clearly shows you meet two
different types of golden paths,

174
00:12:03,120 --> 00:12:06,360
and two different levels of
contexts that you provide to

175
00:12:06,360 --> 00:12:11,940
people. And, and so the key
ability of a platform

176
00:12:11,940 --> 00:12:21,690
engineering team, is that of is
that of? Sorry, is that a

177
00:12:22,620 --> 00:12:27,120
listening and, you know, being
able to put together this

178
00:12:27,480 --> 00:12:31,080
different golden paths for for
different apps to users?

179
00:12:31,950 --> 00:12:34,530
Eveline Oehrlich: You know, what
it makes me think of a Rubik's

180
00:12:34,530 --> 00:12:38,130
Cube when you were talking about
these examples, right? We have

181
00:12:38,130 --> 00:12:44,040
very different types of paths as
you sit for these different

182
00:12:44,040 --> 00:12:49,560
types of teams. So that's quite
a challenge for for such a team

183
00:12:49,560 --> 00:12:53,970
or that gets me to another
question, or I'm assuming that

184
00:12:54,480 --> 00:12:57,150
multiple platform teams are
there?

185
00:12:59,039 --> 00:13:03,539
Luca Galante: That's a great
question. It depends, if I can

186
00:13:03,539 --> 00:13:08,519
use that, sure, you know, so
usually, in the vast majority of

187
00:13:08,519 --> 00:13:15,209
cases, no, actually, you know,
it's, it's already quite a

188
00:13:15,539 --> 00:13:19,499
hurdle to get over to convince,
you know, to get the executive

189
00:13:19,529 --> 00:13:23,339
and all different internal
stakeholders buy in, to start

190
00:13:23,339 --> 00:13:27,899
and drive a platform initiative
that can and should last for

191
00:13:27,899 --> 00:13:31,949
years. So usually, in the vast
majority organization, we

192
00:13:31,949 --> 00:13:35,549
actually see one team, but
obviously, the ideal scenario is

193
00:13:35,549 --> 00:13:38,309
actually having multiple teams
competing with each other. And

194
00:13:38,309 --> 00:13:43,739
so we, I can, I can link in the
show notes there. I've spoken a

195
00:13:43,739 --> 00:13:48,839
couple of times with Arne
Erickson is a also really key

196
00:13:48,839 --> 00:13:51,209
contributor of the platform
engineering community and other

197
00:13:51,209 --> 00:13:57,389
platform engineer.org blog, and
he has a rolled out the what was

198
00:13:57,389 --> 00:14:00,809
the successful platform
initiative of Salesforce about

199
00:14:00,809 --> 00:14:05,669
five to eight years ago. And in
our conversation, he tells a

200
00:14:05,669 --> 00:14:09,119
story of how they work
internally with I believe three

201
00:14:09,119 --> 00:14:12,899
or four outer different platform
teams. And this you know,

202
00:14:12,899 --> 00:14:15,839
highlights again, what I was
talking about earlier, which is

203
00:14:15,839 --> 00:14:19,379
the importance of you know,
communication and internal

204
00:14:19,379 --> 00:14:23,279
marketing skills, which really
positions the the platform

205
00:14:23,309 --> 00:14:27,779
engineer to have a different
skill set and your kind of like

206
00:14:27,779 --> 00:14:31,949
usual infrastructure SRE that is
more focus on you know,

207
00:14:31,949 --> 00:14:35,699
reliability, scalability,
maintenance, and so on. Because

208
00:14:35,729 --> 00:14:38,699
really, you again, you are
shipping a product and a key

209
00:14:38,699 --> 00:14:41,159
part of shipping a product for
everybody that has done so well

210
00:14:41,159 --> 00:14:45,059
know, is distribution, right,
and building that relationship

211
00:14:45,059 --> 00:14:50,819
to your customers. And so
nowhere is that Sure. And then

212
00:14:50,819 --> 00:14:54,449
in larger organizations where
you're actually competing and so

213
00:14:54,449 --> 00:14:59,669
you're basically building a
almost a go to market motion.

214
00:14:59,999 --> 00:15:02,099
within your law firm design,

215
00:15:04,409 --> 00:15:07,139
Narrator: you want to get ahead
in your career and we can help.

216
00:15:07,499 --> 00:15:11,039
DevOps Institute certifications
will validate your knowledge and

217
00:15:11,039 --> 00:15:14,699
give you the skills you need to
succeed in a key area of DevOps.

218
00:15:14,999 --> 00:15:18,269
With our certifications, you'll
be able to prove your subject

219
00:15:18,269 --> 00:15:21,719
matter expertise, and enhance
your professional credibility.

220
00:15:22,199 --> 00:15:25,829
advance your career today with
DevOps Institute certifications,

221
00:15:25,979 --> 00:15:28,889
get started by visiting DevOps
institute.com.

222
00:15:31,260 --> 00:15:33,840
Eveline Oehrlich: So you
mentioned already a variety of

223
00:15:33,840 --> 00:15:38,100
benefits of platform engineering
team, let's not dwell further on

224
00:15:38,100 --> 00:15:41,760
that one. Because I think there
is plenty of good things you

225
00:15:41,760 --> 00:15:46,230
already said. But challenges and
your when you mentioned one

226
00:15:46,260 --> 00:15:50,850
already, which is the actual
making sure that executive

227
00:15:50,850 --> 00:15:55,950
spying? So two prong question
first, what are some other

228
00:15:55,950 --> 00:16:00,930
challenges besides making sure
that you market that? And then

229
00:16:01,230 --> 00:16:05,100
how and what is the best way to
actually market that if I'm the

230
00:16:05,100 --> 00:16:09,330
CIO of company X, and you are
now coming to me? How would you

231
00:16:09,330 --> 00:16:10,410
market that?

232
00:16:10,919 --> 00:16:15,089
Luca Galante: To me? Yeah,
that's a great question. So I

233
00:16:15,089 --> 00:16:18,689
think the you know, there are
two basically set of challenges.

234
00:16:18,689 --> 00:16:23,249
One is a, you know, set of
technical challenges. And again,

235
00:16:23,249 --> 00:16:30,209
I think the, the best sort of
like starting point is looking

236
00:16:30,209 --> 00:16:35,399
at the current reality of your
engineer organizations and find

237
00:16:35,399 --> 00:16:38,729
that lowest common tech
denominator that can be used

238
00:16:38,729 --> 00:16:42,779
across all different teams and
start from there. And that by

239
00:16:42,779 --> 00:16:45,959
the way, just as a quick
tangent, is something that we

240
00:16:45,959 --> 00:16:52,289
see a lot of people miss, as a
as an idea. Because I feel like

241
00:16:52,319 --> 00:16:55,709
the fallacy is a lot of people
think, hey, if I could only

242
00:16:55,709 --> 00:16:59,399
start Greenfield, right, and so
I'm a new platform teams and

243
00:16:59,399 --> 00:17:03,089
your platform initiative, let's
start from scratch, right. But

244
00:17:03,299 --> 00:17:06,479
by starting from scratch, and
kind of dreaming up of your

245
00:17:06,479 --> 00:17:10,559
ideal bathroom stack, you are
missing out on a key piece of

246
00:17:10,559 --> 00:17:15,449
the puzzle, which is listening
and, and effectively building on

247
00:17:15,449 --> 00:17:18,929
top of the information that you
already have available. And so

248
00:17:19,049 --> 00:17:23,759
actually, almost paradoxically,
we've see the most successful

249
00:17:23,759 --> 00:17:27,779
part from initiatives really are
in very complex enterprise

250
00:17:27,779 --> 00:17:36,539
setups, there are very, that are
very sort of nuanced, and the in

251
00:17:36,539 --> 00:17:40,769
the different stacks that people
use, and then learn and build on

252
00:17:40,769 --> 00:17:44,009
top of that, and then and then
from their, from their they get

253
00:17:44,009 --> 00:17:48,149
started. The other set of
challenges is what we mentioned,

254
00:17:48,149 --> 00:17:52,769
which is basically internal
marketing. And then there there

255
00:17:52,769 --> 00:17:56,369
are, there are two, I think
different levels. One is the

256
00:17:56,369 --> 00:17:59,819
first one that you mentioned,
which is basically you know,

257
00:17:59,849 --> 00:18:05,279
your your kind of like executive
buy in. And I think the main

258
00:18:05,309 --> 00:18:11,099
line of argumentation there is
one around ROI. And especially

259
00:18:11,099 --> 00:18:15,839
in you know, times like now and
the macro situations that we're

260
00:18:15,839 --> 00:18:21,389
living through is paramount, I
think for engineering management

261
00:18:21,419 --> 00:18:25,409
to understand the impact that a
platform can have. And the

262
00:18:25,409 --> 00:18:29,939
impact is not only on your kind
of Dora metrics, right? So

263
00:18:29,939 --> 00:18:33,479
obviously your lead time
deployment frequency, what is it

264
00:18:33,479 --> 00:18:36,659
change failure rate and MTTR?
They all improve? Right?

265
00:18:36,899 --> 00:18:42,959
Massively, you have a crazy drop
in OPS overhead in ticket what

266
00:18:42,989 --> 00:18:47,309
we call ticket ops, right? So
basically, operations team

267
00:18:47,309 --> 00:18:51,629
constantly being stuck. And then
on the other side of the fence,

268
00:18:52,229 --> 00:18:56,819
developers having to wait so you
know, waiting times drop ups,

269
00:18:56,819 --> 00:19:00,749
overhead drops, you also have
your kind of slo metrics,

270
00:19:00,749 --> 00:19:04,019
improving like security,
stability, reliability, all

271
00:19:04,019 --> 00:19:07,949
improved because you get a much
better audit of who deploys

272
00:19:08,129 --> 00:19:10,979
what, where you can easily do
dis rollbacks between

273
00:19:10,979 --> 00:19:15,029
deployments. And so your entire
delivery setup gets extremely

274
00:19:15,179 --> 00:19:19,799
more efficient. But I think the
other thing that sometimes can

275
00:19:19,799 --> 00:19:23,369
be a little bit, maybe harder,
like it's a little bit less

276
00:19:23,369 --> 00:19:28,829
quantitative, potentially, but
it's the, you know, crazy drop

277
00:19:28,859 --> 00:19:32,459
in frustration across the
engineer organization, right?

278
00:19:32,459 --> 00:19:39,209
Because in a lot of in a lot of
teams right now, the reality of

279
00:19:39,239 --> 00:19:43,919
DevOps is developers being
completely overwhelmed by

280
00:19:43,919 --> 00:19:46,949
increasingly complex cloud
native tool chains that adults

281
00:19:46,949 --> 00:19:49,709
fully understand and in fact
shouldn't because it's not their

282
00:19:49,709 --> 00:19:54,089
job. And so when they just want
to, you know, spin up a pre

283
00:19:54,089 --> 00:19:56,699
environment to test a little
changed is now all of a sudden

284
00:19:56,699 --> 00:19:59,969
need to touch 1015 different
tools and three or four

285
00:19:59,999 --> 00:20:03,209
different scripts and
completely, are completely

286
00:20:03,209 --> 00:20:06,839
overwhelmed by what we call, you
know, this cognitive overload.

287
00:20:07,769 --> 00:20:11,009
And, and on the flip side of
that, so what happens is then

288
00:20:11,009 --> 00:20:14,219
they basically either ping their
most senior colleague, that

289
00:20:14,219 --> 00:20:16,739
senior backend engineer we
mentioned earlier that likes,

290
00:20:16,769 --> 00:20:19,439
you know, messing around with
their Yamo files, maybe. But

291
00:20:19,439 --> 00:20:24,089
then what you end up having is
your most senior and most

292
00:20:24,149 --> 00:20:28,109
expensive resources, shall I
say, being effectively blocked

293
00:20:28,109 --> 00:20:31,319
and blocking outers and becoming
a bottleneck. So that's another

294
00:20:31,319 --> 00:20:34,349
point for your kind of like sea
level conversation. Yeah. And

295
00:20:34,349 --> 00:20:36,989
then on the flip, the
alternative with that, again, as

296
00:20:36,989 --> 00:20:39,929
you're like infrastructure and
ops team completely stuck,

297
00:20:39,959 --> 00:20:42,299
basically constantly fighting
ticket ops and putting out

298
00:20:42,299 --> 00:20:47,369
fires. And so there's really
widespread frustration on both

299
00:20:47,369 --> 00:20:50,579
sides of the aisle. And that's
really what platform engineering

300
00:20:50,579 --> 00:20:59,009
sets out to improve is really
living and enabling true DevOps,

301
00:20:59,099 --> 00:21:03,389
true, you build it, you run it,
and not the kind of like half

302
00:21:03,389 --> 00:21:07,409
baked version that we ended up
with in the last decade,

303
00:21:07,469 --> 00:21:11,249
effectively. And so that's
really kind of like your pitch

304
00:21:11,279 --> 00:21:15,719
to sea level. And obviously, you
know, you can, you can take

305
00:21:16,229 --> 00:21:20,609
smaller parts of that and go
pitch to your developers and

306
00:21:20,849 --> 00:21:24,599
operations team on the other.
After that, I think what's

307
00:21:24,599 --> 00:21:28,289
important there on the
operations side of things is

308
00:21:28,289 --> 00:21:31,169
that you make really clear
again, that you you're

309
00:21:31,169 --> 00:21:36,449
differentiating between sort of
more traditional operation role,

310
00:21:36,479 --> 00:21:39,989
right. So it's not like a
platform team replaces an SRE

311
00:21:39,989 --> 00:21:45,419
team, you still need to care
about how your load out your

312
00:21:45,419 --> 00:21:48,269
load balancing across all your
production regions, and

313
00:21:48,269 --> 00:21:52,649
clusters, and all that good
stuff. But you need to spin up

314
00:21:52,649 --> 00:21:56,459
this separate set of skill sets
and roles that really focus on

315
00:21:56,459 --> 00:22:00,209
shipping a product and you need
to make sure that that is really

316
00:22:00,209 --> 00:22:04,679
aligned the mission. And the
vision of the platform

317
00:22:04,679 --> 00:22:09,119
engineering org is aligned with
the rest of the serve like

318
00:22:09,119 --> 00:22:12,839
infrastructure teams to make
sure that there are no friction,

319
00:22:12,839 --> 00:22:17,009
there's no friction there. And
then the third sort of group of

320
00:22:17,009 --> 00:22:19,439
stakeholders, obviously, as
developers, and we kind of

321
00:22:19,439 --> 00:22:23,699
touched on this earlier, but the
idea here is, you just need to

322
00:22:23,699 --> 00:22:31,829
listen a lot and make sure that
developers have a clear idea

323
00:22:31,829 --> 00:22:37,439
that you are improving their day
to day math and lead by enabling

324
00:22:37,499 --> 00:22:42,059
them to self serve the tech and
tools they need to run and

325
00:22:42,089 --> 00:22:44,939
operate their operations in
fulsome service completely

326
00:22:44,939 --> 00:22:49,649
independently. But at the same
time, you're not doing that by

327
00:22:49,649 --> 00:22:53,819
providing them some past like,
some class like tool that

328
00:22:53,819 --> 00:22:57,149
abstracts them away from the
underlying tech and tools. And

329
00:22:57,149 --> 00:23:01,559
again, this will matter more or
less, depending on the user. If

330
00:23:01,559 --> 00:23:06,419
it's a more senior user that is,
you know, used to handling low

331
00:23:06,419 --> 00:23:11,339
code stuff then. Or just like
low level configuration stuff,

332
00:23:11,759 --> 00:23:17,369
they will be very sensitive to
the type of golden path that you

333
00:23:17,369 --> 00:23:20,639
design for them. And that's
where it's really key that that

334
00:23:21,509 --> 00:23:26,969
you know that that information
flow is really optimized. And

335
00:23:26,969 --> 00:23:29,939
then also, finally, I think
there is a conversational roll

336
00:23:29,939 --> 00:23:33,389
up strategy. Again, you can
think of it as any sort of like

337
00:23:33,389 --> 00:23:37,919
go to market, who are your early
adopters, where you start. And I

338
00:23:37,919 --> 00:23:41,219
think, you know, we've seen a
lot of successful platform

339
00:23:41,219 --> 00:23:45,839
initiatives starting by working
with the more advanced

340
00:23:45,869 --> 00:23:49,529
development teams that usually
are the ones who are going to be

341
00:23:49,529 --> 00:23:53,339
more comfortable with your cloud
native stack, you know, they're

342
00:23:53,369 --> 00:23:57,029
not afraid of Helm charts, or
TerraForm, modules, and so on.

343
00:23:57,299 --> 00:24:02,759
And so it will be easier to
start by sort of like with them,

344
00:24:02,789 --> 00:24:06,509
laying that foundation with
something that is not so

345
00:24:06,509 --> 00:24:11,399
abstracted, and then
progressively move to maybe more

346
00:24:11,399 --> 00:24:14,429
junior or less experienced teams
or just teams that frankly,

347
00:24:14,429 --> 00:24:18,839
don't need to be so deeply in
touch with the underlying stack

348
00:24:18,839 --> 00:24:23,639
of things. And for them build a
potentially more abstracted,

349
00:24:24,359 --> 00:24:28,139
simpler golden path. So those
three groups,

350
00:24:28,500 --> 00:24:31,440
Eveline Oehrlich: I can just
hear your passion on this topic

351
00:24:31,470 --> 00:24:35,460
is just phenomenal. Luca, you
are phenomenal. I want to say

352
00:24:35,460 --> 00:24:39,030
that one more time. You are
phenomenal. Now I have two more

353
00:24:39,030 --> 00:24:43,050
questions. One is related to the
platform engineering and that

354
00:24:43,050 --> 00:24:46,560
individual skills. And the last
one is a fun question. So let's

355
00:24:46,560 --> 00:24:51,360
do the hard work first. skills
as you know, we hear the DevOps

356
00:24:51,360 --> 00:24:57,030
Institute are really engaged in
skill building upskilling and

357
00:24:57,030 --> 00:25:01,350
all those wonderful topics and
you mentioned one Skill already,

358
00:25:01,380 --> 00:25:05,160
which was listening something I
have to tell my husband, he

359
00:25:05,160 --> 00:25:07,230
should become maybe a platform
engineer, and then he would

360
00:25:07,230 --> 00:25:11,220
improve his listening skills.
But no, he has no chance. But

361
00:25:11,220 --> 00:25:15,570
that was one skill. You said,
what are some additional two,

362
00:25:15,570 --> 00:25:20,070
maybe two other skills you want
to highlight? If I want to turn

363
00:25:20,070 --> 00:25:23,850
into a platform engineer, what
should I have as a skill?

364
00:25:25,170 --> 00:25:28,290
Luca Galante: Totally well, so I
mean, from a technical

365
00:25:28,290 --> 00:25:31,200
perspective, obviously, you want
to have a solid understanding of

366
00:25:31,200 --> 00:25:34,290
all your kind of, you know,
infrastructure, especially cloud

367
00:25:34,290 --> 00:25:38,400
native tool chain, right. So
your Kubernetes I see

368
00:25:38,400 --> 00:25:42,690
infrastructures code, see ICD
workflows, good ops, you know,

369
00:25:42,690 --> 00:25:49,260
throw your boss word of dude,
you were, you know, obviously,

370
00:25:49,260 --> 00:25:52,260
you wanna, you want to have
those bases covered. But I think

371
00:25:52,290 --> 00:25:55,650
the vast majority of people that
will approach to platform

372
00:25:55,650 --> 00:26:01,560
engineering, sort of topics
coming from a, kind of like,

373
00:26:01,560 --> 00:26:03,780
your infrastructure DevOps role
will already be familiar with

374
00:26:03,780 --> 00:26:08,490
that. I think, really, and I
want to kind of de risk of

375
00:26:08,520 --> 00:26:12,540
repeating myself, but I think
that there are two main things

376
00:26:12,540 --> 00:26:16,410
really, that I see. One is
product mindset. And so that's

377
00:26:16,410 --> 00:26:20,970
really the shift that maybe if
you are coming, sort of like,

378
00:26:21,930 --> 00:26:26,910
more green to this is, or,
again, from building and

379
00:26:26,910 --> 00:26:30,360
shipping products, that's not a
big shift. But I think if you

380
00:26:30,360 --> 00:26:34,350
aren't coming from your kind of
more traditional infrastructure

381
00:26:34,350 --> 00:26:40,410
and DevOps role, it might be a
more important shift, mindset

382
00:26:40,410 --> 00:26:43,830
wise that you need to make. And,
and that's, I think, really key,

383
00:26:43,860 --> 00:26:49,350
right? And, and so that's
obviously like the part of the

384
00:26:49,410 --> 00:26:53,580
listening and having this
mindset and really starting to

385
00:26:53,580 --> 00:26:57,240
think, Hey, your developers are
your customers. And that's all

386
00:26:57,240 --> 00:27:00,390
that matters. And so then
obviously, there are oldest

387
00:27:00,390 --> 00:27:03,450
topics that have emerged from
there. The the kind of

388
00:27:03,450 --> 00:27:06,330
fundamentals of product
management, right, that we all

389
00:27:06,330 --> 00:27:10,500
know, so user research product,
roadmap, MVP being, how you

390
00:27:10,500 --> 00:27:13,590
think about adoption, and that's
just to mention a few, right? So

391
00:27:13,890 --> 00:27:16,530
really just taking everything
we've learned in the last few

392
00:27:16,530 --> 00:27:19,770
decades around product
management and applying it to

393
00:27:19,800 --> 00:27:22,830
effectively infrastructure and
gluing together your tool chain

394
00:27:23,070 --> 00:27:28,440
into a product, a platform that
makes sense for your end users.

395
00:27:28,950 --> 00:27:32,370
And then the other one is
communication broadly, and, you

396
00:27:32,370 --> 00:27:34,860
know, obviously, part of vision
is listening. But the other part

397
00:27:34,860 --> 00:27:38,910
is speaking. And so the speaking
part is again, like how do you

398
00:27:38,910 --> 00:27:42,180
think about internal marketing?
How do you think about

399
00:27:42,180 --> 00:27:47,100
stakeholder buy in? And how do
you make sure that you are

400
00:27:47,130 --> 00:27:51,840
adapting to the different type
of lingo to communicate

401
00:27:51,840 --> 00:27:55,380
incentives clearly, right. So
the way you communicate to sea

402
00:27:55,380 --> 00:27:59,370
level, and you talk about ROI,
and you talk about, you know,

403
00:27:59,370 --> 00:28:04,830
your decrease time to market,
you know, developers don't care

404
00:28:04,830 --> 00:28:08,490
about that. Right. So then when
you talk to developers, it's

405
00:28:08,490 --> 00:28:14,220
really about, you know, their
developer, velocity, I mean,

406
00:28:14,220 --> 00:28:17,340
even velocity productivity or
more stuff for sea level, it's

407
00:28:17,340 --> 00:28:20,700
really about just getting them
stuck and talking about, Hey,

408
00:28:20,700 --> 00:28:24,720
your waiting times will drop.
And, you know, this is how this

409
00:28:24,720 --> 00:28:29,340
is how we can improve your day
to day immediately. And I think

410
00:28:29,340 --> 00:28:36,030
they're a key. A key part of the
communication is how you plug

411
00:28:36,060 --> 00:28:39,360
into their current workflow, we
thought without interrupting.

412
00:28:40,260 --> 00:28:43,650
And so that's, I think, is
really important. But yeah,

413
00:28:43,680 --> 00:28:46,200
those those two things, really
product mindset and

414
00:28:46,200 --> 00:28:49,650
communication skills are, I
think, the major thing and if

415
00:28:49,650 --> 00:28:55,980
you were to plot on a graph,
your kind of evolution of that

416
00:28:55,980 --> 00:29:00,510
buzzworthy sort of roles and
titles from your SIS admin, to

417
00:29:00,510 --> 00:29:03,090
your infrastructure to your
doubts in the near future, apart

418
00:29:03,090 --> 00:29:07,470
from engineer, you know, if you
had time on the x axis and sort

419
00:29:07,470 --> 00:29:10,890
of like communication on the y
axis, then you know, they would

420
00:29:10,890 --> 00:29:14,940
plot on to the right, and
that's, that's, I think, kind of

421
00:29:14,940 --> 00:29:17,460
how you want to think about it,
right? Like platform engineer is

422
00:29:17,460 --> 00:29:21,240
basically a DevOps engineer that
listens and communicates better.

423
00:29:21,840 --> 00:29:24,450
Eveline Oehrlich: Beautiful.
Wow, that sounds like a really

424
00:29:24,450 --> 00:29:28,830
exciting career choice to make
if anybody out there wants to

425
00:29:28,830 --> 00:29:33,690
know more, there is plenty more
to get involved in. I just say

426
00:29:33,690 --> 00:29:36,630
that there is a fantastic report
and I think you will look about

427
00:29:36,630 --> 00:29:39,150
the author of it. It's called
the state of platform

428
00:29:39,150 --> 00:29:43,470
engineering. So if anybody is
interested in then just look for

429
00:29:43,470 --> 00:29:47,700
Luca Galanti and type in state
of platform engineering, because

430
00:29:47,700 --> 00:29:51,270
there is all these different
ways of getting involved in

431
00:29:51,270 --> 00:29:56,220
Slack channels and communities
and events. Super. This was

432
00:29:56,250 --> 00:30:01,860
extremely insightful. I think.
Now Now comes the fun part. So

433
00:30:01,890 --> 00:30:05,910
besides doing these great
thought leadership pieces, doing

434
00:30:05,910 --> 00:30:09,210
your work, talking to people
like me and platform

435
00:30:09,210 --> 00:30:11,100
engineering, what do you do for
fun Luca?

436
00:30:13,080 --> 00:30:16,320
Luca Galante: Um, well, so as I
mentioned at the beginning, I'm

437
00:30:16,320 --> 00:30:20,700
currently on Tenerife. And so
it's been really fun over here.

438
00:30:20,730 --> 00:30:24,240
I've been living out of event
actually, for the last couple of

439
00:30:24,240 --> 00:30:28,620
weeks and surfing mostly, really
early in the morning, because

440
00:30:28,620 --> 00:30:33,450
we're one hour behind here. But
that's, I think, one of the

441
00:30:33,450 --> 00:30:36,420
things that I do for fun, you
know, just just being in the

442
00:30:36,420 --> 00:30:39,540
water being in nature, that's,
that's really good times for me.

443
00:30:39,540 --> 00:30:43,650
And the other one, frankly, as a
good Italian is just eating and

444
00:30:43,680 --> 00:30:47,520
drinking good wine. So, you
know, simple, simple person

445
00:30:47,520 --> 00:30:51,120
simple needs, but does go pretty
far for me.

446
00:30:51,720 --> 00:30:54,360
Eveline Oehrlich: Fantastic. We
have to meet in person, I have a

447
00:30:54,360 --> 00:30:58,980
van. I love Italian food. Oh,
amazing. I cannot serve you with

448
00:30:58,980 --> 00:31:03,960
so I do like the water. So maybe
we get to meet one time

449
00:31:03,990 --> 00:31:06,990
somewhere in a place. Maybe
Jennifer, this has been

450
00:31:06,990 --> 00:31:11,040
fantastic. Thank you. We've been
talking to Luke. I like Galanti

451
00:31:11,040 --> 00:31:15,540
product owner, product master,
and really a great thought

452
00:31:15,540 --> 00:31:19,320
leader on platform engineering.
Luca, thank you again so much

453
00:31:19,320 --> 00:31:22,410
for joining me today on humans
of DevOps podcast.

454
00:31:23,400 --> 00:31:26,130
Luca Galante: Thank you so much
for having me. And if they can,

455
00:31:26,160 --> 00:31:30,450
if I may, just because you
mentioned the the events. If

456
00:31:30,450 --> 00:31:34,200
people want to learn more about
platform engineering, I would

457
00:31:34,350 --> 00:31:38,130
encourage them to check out
platform eg.org. And that's

458
00:31:38,130 --> 00:31:41,850
really the home of the community
and platform khan.com. That's

459
00:31:41,850 --> 00:31:45,540
the event that's coming up in
June this year. It's free,

460
00:31:45,540 --> 00:31:48,960
anybody can sign up and we'll
have the best of the best really

461
00:31:48,990 --> 00:31:51,750
of DevOps and platform
engineering thought leaders

462
00:31:51,810 --> 00:31:55,500
there. So I invite everybody to
join us over there.

463
00:31:56,130 --> 00:32:00,690
Eveline Oehrlich: Great, thank
you, humans. Yes, humans of

464
00:32:00,690 --> 00:32:04,710
DevOps podcast is produced by
DevOps Institute. Our audio

465
00:32:04,710 --> 00:32:08,940
production team includes Julia
pape, Daniel Newman, Schultz and

466
00:32:08,940 --> 00:32:12,630
Brendon lay. Those are the three
folks I want to have a shout out

467
00:32:12,630 --> 00:32:16,350
to because they're wonderful. I
am humans of DevOps podcast,

468
00:32:16,350 --> 00:32:20,220
executive producer Evelyn
earlyish. If you would like to

469
00:32:20,220 --> 00:32:25,380
join us on a podcast, please
contact us at humans have dev

470
00:32:25,410 --> 00:32:30,990
ops podcast at DevOps
institute.com. Do I sound like a

471
00:32:31,260 --> 00:32:35,700
virtual agent? Maybe? Anyway,
have a great day. I'm Emily,

472
00:32:36,060 --> 00:32:37,050
talk to you soon.

473
00:32:39,960 --> 00:32:42,060
Narrator: Thanks for listening
to this episode of the humans of

474
00:32:42,060 --> 00:32:45,600
DevOps podcast. Don't forget to
join our global community to get

475
00:32:45,600 --> 00:32:48,930
access to even more great
resources like this. Until next

476
00:32:48,930 --> 00:32:52,410
time, remember, you are part of
something bigger than yourself.

477
00:32:52,710 --> 00:32:53,490
You belong