1
00:00:00,000 --> 00:00:01,800
DevOps were supposed to solve a problem.

2
00:00:01,800 --> 00:00:04,200
The promise was simple, shared responsibility,

3
00:00:04,200 --> 00:00:06,280
developers and operations working together.

4
00:00:06,280 --> 00:00:08,600
No more silos, no more throwing code over the wall

5
00:00:08,600 --> 00:00:11,800
and waiting for ops to approve it, speed, autonomy,

6
00:00:11,800 --> 00:00:13,440
faster delivery.

7
00:00:13,440 --> 00:00:15,680
But in reality, it just moved the bottleneck.

8
00:00:15,680 --> 00:00:17,080
It didn't eliminate it.

9
00:00:17,080 --> 00:00:19,480
For years, operations teams were the constraint.

10
00:00:19,480 --> 00:00:21,520
Developers would request an environment,

11
00:00:21,520 --> 00:00:24,360
then ops would review it, schedule it, and provision it.

12
00:00:24,360 --> 00:00:26,520
This process took weeks or sometimes months

13
00:00:26,520 --> 00:00:27,800
because the bottleneck was clear.

14
00:00:27,800 --> 00:00:28,600
It was ops.

15
00:00:28,600 --> 00:00:29,480
So we fixed that.

16
00:00:29,480 --> 00:00:32,120
We gave developers the tools, infrastructure as code,

17
00:00:32,120 --> 00:00:34,040
container orchestration, cloud platforms,

18
00:00:34,040 --> 00:00:35,800
the ability to provision their own resources.

19
00:00:35,800 --> 00:00:36,640
And what happened?

20
00:00:36,640 --> 00:00:38,360
Developers started waiting for infrastructure

21
00:00:38,360 --> 00:00:40,160
the same way ops waited for approvals

22
00:00:40,160 --> 00:00:42,360
because now developers own more than just code.

23
00:00:42,360 --> 00:00:45,320
They own networking, security, compliance, policy, monitoring,

24
00:00:45,320 --> 00:00:46,400
and troubleshooting.

25
00:00:46,400 --> 00:00:48,120
The cognitive load exploded.

26
00:00:48,120 --> 00:00:49,840
And the ticket queues didn't disappear.

27
00:00:49,840 --> 00:00:50,760
They just changed hands.

28
00:00:50,760 --> 00:00:52,240
The structural floor isn't people.

29
00:00:52,240 --> 00:00:53,320
It's the operating model.

30
00:00:53,320 --> 00:00:55,920
Platform engineering fixes this by treating infrastructure

31
00:00:55,920 --> 00:00:58,400
not as a service you request, but as a product

32
00:00:58,400 --> 00:00:59,280
you consume.

33
00:00:59,280 --> 00:01:02,240
This episode explores how that shift changes everything.

34
00:01:02,240 --> 00:01:04,960
How golden parts eliminate choice, how governance becomes

35
00:01:04,960 --> 00:01:07,040
automatic, how the bottleneck gets eliminated

36
00:01:07,040 --> 00:01:08,640
instead of just relocated.

37
00:01:08,640 --> 00:01:11,840
Subscribe to the M365FM podcast for deep dives

38
00:01:11,840 --> 00:01:14,400
into the systems that drive enterprise velocity.

39
00:01:14,400 --> 00:01:15,920
Why DevOps failed at scale?

40
00:01:15,920 --> 00:01:16,880
DevOps worked.

41
00:01:16,880 --> 00:01:18,800
For small teams, it was remarkable.

42
00:01:18,800 --> 00:01:20,480
A few developers and a few operators

43
00:01:20,480 --> 00:01:22,680
shared ownership and direct communication.

44
00:01:22,680 --> 00:01:25,000
These fast feedback loops accelerated delivery,

45
00:01:25,000 --> 00:01:26,560
and at that scale, the model actually

46
00:01:26,560 --> 00:01:28,000
did eliminate the bottleneck.

47
00:01:28,000 --> 00:01:29,640
But then organizations scaled.

48
00:01:29,640 --> 00:01:32,600
50 developers, 100, 500, and the model broke.

49
00:01:32,600 --> 00:01:34,120
DevOps promised shared responsibility,

50
00:01:34,120 --> 00:01:37,200
but what it actually delivered was distributed complexity.

51
00:01:37,200 --> 00:01:39,400
Developers inherited the entire operational stack,

52
00:01:39,400 --> 00:01:42,720
not just code, infrastructure, security policy, identity

53
00:01:42,720 --> 00:01:45,880
and access management, monitoring, incident response.

54
00:01:45,880 --> 00:01:48,040
All of it sitting in the developers' mental model

55
00:01:48,040 --> 00:01:50,160
alongside the application logic they were supposed

56
00:01:50,160 --> 00:01:51,000
to be building.

57
00:01:51,000 --> 00:01:53,480
The cognitive load explosion happened quietly.

58
00:01:53,480 --> 00:01:56,440
Research shows developers spend 40% to 50% of their time

59
00:01:56,440 --> 00:01:59,560
on undifferentiated, heavy lifting, not on product features,

60
00:01:59,560 --> 00:02:02,720
not on solving business problems, on infrastructure toil,

61
00:02:02,720 --> 00:02:04,680
on figuring out which security group to attach,

62
00:02:04,680 --> 00:02:07,000
on debugging networking issues that have nothing to do

63
00:02:07,000 --> 00:02:07,880
with their code.

64
00:02:07,880 --> 00:02:10,680
On waiting for approvals that should have been automated,

65
00:02:10,680 --> 00:02:11,960
the tickets didn't disappear.

66
00:02:11,960 --> 00:02:13,320
They just changed form.

67
00:02:13,320 --> 00:02:15,240
Instead of asking to provision an environment,

68
00:02:15,240 --> 00:02:17,920
the question became, why a deployment wasn't working?

69
00:02:17,920 --> 00:02:20,640
Developers had to become operators just to find the answer.

70
00:02:20,640 --> 00:02:22,840
They were context switching between code review,

71
00:02:22,840 --> 00:02:25,520
infrastructure debugging, compliance documentation,

72
00:02:25,520 --> 00:02:27,040
and incident response.

73
00:02:27,040 --> 00:02:29,600
Each switch costs focus and drains cognitive capacity,

74
00:02:29,600 --> 00:02:31,600
so by the time they get back to the actual build,

75
00:02:31,600 --> 00:02:32,720
the context is gone.

76
00:02:32,720 --> 00:02:33,960
Dora metrics improved.

77
00:02:33,960 --> 00:02:36,560
Deployment frequency went up, lead time went down,

78
00:02:36,560 --> 00:02:38,120
on paper everything looked faster.

79
00:02:38,120 --> 00:02:39,880
But developer satisfaction dropped,

80
00:02:39,880 --> 00:02:42,080
because being faster doesn't matter if you're burned out.

81
00:02:42,080 --> 00:02:43,840
It doesn't matter if you are spending your time

82
00:02:43,840 --> 00:02:46,520
on repetitive setup tasks instead of building things

83
00:02:46,520 --> 00:02:47,200
that matter.

84
00:02:47,200 --> 00:02:49,360
This is the trap DevOps created at scale.

85
00:02:49,360 --> 00:02:51,600
The model works for a startup, a team of 10 people

86
00:02:51,600 --> 00:02:52,840
all wearing multiple hats.

87
00:02:52,840 --> 00:02:54,440
Everyone understands the full stack.

88
00:02:54,440 --> 00:02:57,320
Communication is direct, feedback is immediate.

89
00:02:57,320 --> 00:03:00,120
It breaks for an enterprise, because an enterprise

90
00:03:00,120 --> 00:03:02,040
isn't a startup with more people.

91
00:03:02,040 --> 00:03:03,440
It's a different structural problem.

92
00:03:03,440 --> 00:03:05,560
You have dozens of teams and competing priorities.

93
00:03:05,560 --> 00:03:07,200
You have different compliance requirements

94
00:03:07,200 --> 00:03:08,600
for different applications.

95
00:03:08,600 --> 00:03:10,960
Shared infrastructure serves multiple workloads

96
00:03:10,960 --> 00:03:12,440
and different levels of risk tolerance

97
00:03:12,440 --> 00:03:14,640
mean policy needs to be enforced consistently.

98
00:03:14,640 --> 00:03:17,040
Try solving all that by sharing responsibility,

99
00:03:17,040 --> 00:03:20,640
try managing hundreds of database access requests manually,

100
00:03:20,640 --> 00:03:22,760
try ensuring every developer in the organization

101
00:03:22,760 --> 00:03:24,880
knows the current network topology.

102
00:03:24,880 --> 00:03:26,800
Try keeping security policies consistent

103
00:03:26,800 --> 00:03:28,920
across a hundred different infrastructure decisions

104
00:03:28,920 --> 00:03:30,720
made by a hundred different teams who

105
00:03:30,720 --> 00:03:32,200
have slightly different interpretations

106
00:03:32,200 --> 00:03:33,680
of what least privilege means.

107
00:03:33,680 --> 00:03:35,960
You can't, the model breaks.

108
00:03:35,960 --> 00:03:37,400
And that's where enterprises still are.

109
00:03:37,400 --> 00:03:38,440
They've adopted DevOps.

110
00:03:38,440 --> 00:03:40,080
They've built CI/CD pipelines.

111
00:03:40,080 --> 00:03:41,960
They've given developers cloud access.

112
00:03:41,960 --> 00:03:43,720
But the cognitive load keeps growing.

113
00:03:43,720 --> 00:03:45,680
The approval processes keep multiplying.

114
00:03:45,680 --> 00:03:46,920
The ticket queues just moved.

115
00:03:46,920 --> 00:03:48,880
They didn't disappear.

116
00:03:48,880 --> 00:03:50,760
The operational model didn't change.

117
00:03:50,760 --> 00:03:52,960
Only the form of the bottleneck, platform engineering

118
00:03:52,960 --> 00:03:54,480
doesn't try to fix DevOps.

119
00:03:54,480 --> 00:03:57,200
It replaces the operating model entirely.

120
00:03:57,200 --> 00:03:58,720
The cognitive load crisis.

121
00:03:58,720 --> 00:04:00,600
Cognitive load is easy to define.

122
00:04:00,600 --> 00:04:02,520
It is the mental effort you need to understand

123
00:04:02,520 --> 00:04:06,000
and run a system, not physical effort, mental effort.

124
00:04:06,000 --> 00:04:07,440
It is the number of different concepts

125
00:04:07,440 --> 00:04:09,040
you have to juggle in your head at once.

126
00:04:09,040 --> 00:04:10,760
It is the constant context switching.

127
00:04:10,760 --> 00:04:12,120
It is the depth of knowledge you need

128
00:04:12,120 --> 00:04:14,600
just to make a simple decision without breaking the whole

129
00:04:14,600 --> 00:04:15,520
environment.

130
00:04:15,520 --> 00:04:17,120
In the old world of infrastructure,

131
00:04:17,120 --> 00:04:18,800
this load was localized.

132
00:04:18,800 --> 00:04:20,360
Operators understood the hardware,

133
00:04:20,360 --> 00:04:22,040
developers understood the apps.

134
00:04:22,040 --> 00:04:23,240
The domains were separate.

135
00:04:23,240 --> 00:04:25,320
A developer did not need to know how to fix a network

136
00:04:25,320 --> 00:04:27,200
misconfiguration because they just wrote the code

137
00:04:27,200 --> 00:04:28,600
and let ops handle the rest.

138
00:04:28,600 --> 00:04:30,520
That boundary dissolved.

139
00:04:30,520 --> 00:04:32,320
Modern cloud infrastructure now demands

140
00:04:32,320 --> 00:04:34,040
that you know five different worlds.

141
00:04:34,040 --> 00:04:38,360
Networking, security, policy, identity, monitoring.

142
00:04:38,360 --> 00:04:40,000
A developer on a modern platform

143
00:04:40,000 --> 00:04:42,200
has to understand virtual networks and security groups.

144
00:04:42,200 --> 00:04:44,640
They have to know Azure policy and which resources

145
00:04:44,640 --> 00:04:46,080
are allowed in which regions.

146
00:04:46,080 --> 00:04:48,400
They have to manage identities and role-based access.

147
00:04:48,400 --> 00:04:50,200
They have to figure out logging strategies

148
00:04:50,200 --> 00:04:52,360
just to see why something failed in production.

149
00:04:52,360 --> 00:04:54,360
And all of that sits on top of the actual code

150
00:04:54,360 --> 00:04:55,720
they are supposed to be writing.

151
00:04:55,720 --> 00:04:57,960
The problem is not that one domain is too hard.

152
00:04:57,960 --> 00:04:59,040
It is that they compound.

153
00:04:59,040 --> 00:05:01,280
You do not get to choose between networking or security.

154
00:05:01,280 --> 00:05:02,280
You need both.

155
00:05:02,280 --> 00:05:03,800
You need them to talk to each other.

156
00:05:03,800 --> 00:05:05,440
If you mess up an identity, the app

157
00:05:05,440 --> 00:05:07,720
deploys but cannot talk to the database.

158
00:05:07,720 --> 00:05:10,080
If you click the wrong security group rule,

159
00:05:10,080 --> 00:05:12,960
the app runs but cannot find its dependencies.

160
00:05:12,960 --> 00:05:14,560
If you trip a policy violation,

161
00:05:14,560 --> 00:05:16,600
the whole deployment fails at the last second

162
00:05:16,600 --> 00:05:18,080
after you have put in hours of work.

163
00:05:18,080 --> 00:05:20,200
So developers' context switch, constantly.

164
00:05:20,200 --> 00:05:22,080
They are writing code, something breaks.

165
00:05:22,080 --> 00:05:22,840
Is it the code?

166
00:05:22,840 --> 00:05:23,960
Is it the infrastructure?

167
00:05:23,960 --> 00:05:24,960
Is it a policy issue?

168
00:05:24,960 --> 00:05:26,320
Is it a permission problem?

169
00:05:26,320 --> 00:05:28,720
They jump into the Azure portal to check the topology.

170
00:05:28,720 --> 00:05:30,360
They verify role assignments.

171
00:05:30,360 --> 00:05:32,400
They dig through policy audit logs, nothing.

172
00:05:32,400 --> 00:05:33,600
So they jump back to the code.

173
00:05:33,600 --> 00:05:35,120
Maybe it is an environment variable.

174
00:05:35,120 --> 00:05:35,960
They search templates.

175
00:05:35,960 --> 00:05:37,040
They check bicep files.

176
00:05:37,040 --> 00:05:39,160
They verify parameters.

177
00:05:39,160 --> 00:05:41,240
Finally, they find it.

178
00:05:41,240 --> 00:05:44,600
Now they need to redeploy but the policy will not allow it.

179
00:05:44,600 --> 00:05:45,760
They request an exception.

180
00:05:45,760 --> 00:05:46,960
They wait for approval.

181
00:05:46,960 --> 00:05:49,160
The approval comes back with three new conditions.

182
00:05:49,160 --> 00:05:50,400
They redesign the approach.

183
00:05:50,400 --> 00:05:51,360
They redeploy.

184
00:05:51,360 --> 00:05:52,760
This time it works.

185
00:05:52,760 --> 00:05:55,360
But an eight hour day just became 30 minutes of coding

186
00:05:55,360 --> 00:05:57,560
and seven and a half hours of switching tabs.

187
00:05:57,560 --> 00:05:58,920
That is not an exaggeration.

188
00:05:58,920 --> 00:06:01,400
That is the daily reality for developers and organizations

189
00:06:01,400 --> 00:06:02,640
that have not fixed this.

190
00:06:02,640 --> 00:06:04,400
The cost is compounding.

191
00:06:04,400 --> 00:06:07,280
Every time you switch tasks, there is a real price to pay.

192
00:06:07,280 --> 00:06:09,800
Research shows it takes 15 to 25 minutes

193
00:06:09,800 --> 00:06:12,040
to get back into deep focus after an interruption.

194
00:06:12,040 --> 00:06:14,720
If a developer switches context six times a day,

195
00:06:14,720 --> 00:06:17,920
they have lost three hours just trying to remember what they were doing.

196
00:06:17,920 --> 00:06:19,320
They never get back to deep work.

197
00:06:19,320 --> 00:06:21,000
They just stay in a fragmented mode.

198
00:06:21,000 --> 00:06:22,880
Then the error start.

199
00:06:22,880 --> 00:06:24,880
When you are fragmented, you miss the details.

200
00:06:24,880 --> 00:06:26,800
You deploy without testing everything.

201
00:06:26,800 --> 00:06:28,360
You overlook a small configuration.

202
00:06:28,360 --> 00:06:30,440
You assume it is working when it is not.

203
00:06:30,440 --> 00:06:32,240
You start introducing bugs that would not exist

204
00:06:32,240 --> 00:06:34,240
if you just had an hour of quiet focus.

205
00:06:34,240 --> 00:06:35,640
And then burnout.

206
00:06:35,640 --> 00:06:36,920
Not because the work is too hard

207
00:06:36,920 --> 00:06:40,360
but because the work is impossible to do well.

208
00:06:40,360 --> 00:06:42,320
You cannot build high quality software

209
00:06:42,320 --> 00:06:45,040
when 70% of your time is spent on infrastructure toil.

210
00:06:45,040 --> 00:06:47,400
You cannot feel productive when eight hours of effort

211
00:06:47,400 --> 00:06:49,360
only moves the needle 30 minutes.

212
00:06:49,360 --> 00:06:51,920
You cannot stay engaged when every single task requires

213
00:06:51,920 --> 00:06:54,040
jumping between five different systems,

214
00:06:54,040 --> 00:06:56,600
each with its own logic and its own way of failing.

215
00:06:56,600 --> 00:06:58,320
This is the cognitive load crisis.

216
00:06:58,320 --> 00:06:59,640
It is not a tooling problem.

217
00:06:59,640 --> 00:07:01,320
Better monitoring will not fix this.

218
00:07:01,320 --> 00:07:02,640
Better logging will not fix it.

219
00:07:02,640 --> 00:07:04,320
Faster deployments will not fix it.

220
00:07:04,320 --> 00:07:05,920
Those tools only treat the symptoms.

221
00:07:05,920 --> 00:07:07,600
The cause is the operating model.

222
00:07:07,600 --> 00:07:10,360
Asking developers to own the full infrastructure stack

223
00:07:10,360 --> 00:07:12,280
means asking them to master domains

224
00:07:12,280 --> 00:07:13,560
that are not their specialty.

225
00:07:13,560 --> 00:07:16,600
It means spreading complexity out instead of containing it.

226
00:07:16,600 --> 00:07:19,200
It means building a system that looks great on a slide deck

227
00:07:19,200 --> 00:07:20,840
but breaks in the real world.

228
00:07:20,840 --> 00:07:22,800
Platform engineering fixes this.

229
00:07:22,800 --> 00:07:25,040
By moving complexity to the right place.

230
00:07:25,040 --> 00:07:27,000
What platform engineering actually is?

231
00:07:27,000 --> 00:07:29,280
Platform engineering starts with a different assumption.

232
00:07:29,280 --> 00:07:31,520
It does not ask developers to master infrastructure.

233
00:07:31,520 --> 00:07:33,320
It does not ask them to own every domain

234
00:07:33,320 --> 00:07:34,640
from networking to monitoring.

235
00:07:34,640 --> 00:07:37,160
Instead, it treats infrastructure as something to be consumed,

236
00:07:37,160 --> 00:07:38,480
not something to be learned.

237
00:07:38,480 --> 00:07:40,480
This is a fundamental shift in how you operate.

238
00:07:40,480 --> 00:07:41,560
DevOps is a culture.

239
00:07:41,560 --> 00:07:43,080
It is a set of practices.

240
00:07:43,080 --> 00:07:45,000
It is about shared responsibility.

241
00:07:45,000 --> 00:07:47,760
You can do DevOps and keep the same messy structure

242
00:07:47,760 --> 00:07:49,520
and the same manual systems.

243
00:07:49,520 --> 00:07:51,160
You are just asking people to talk more

244
00:07:51,160 --> 00:07:52,600
and automate a few scripts.

245
00:07:52,600 --> 00:07:54,600
Platform engineering is a discipline.

246
00:07:54,600 --> 00:07:57,120
It is the act of building an internal platform.

247
00:07:57,120 --> 00:07:59,720
A product where the developers are the customers.

248
00:07:59,720 --> 00:08:01,480
This requires a dedicated team.

249
00:08:01,480 --> 00:08:04,560
Their only job is to take complexity away from the product teams.

250
00:08:04,560 --> 00:08:06,840
Not by hiding it, but by building secure,

251
00:08:06,840 --> 00:08:09,760
opinionated pathways that developers follow naturally.

252
00:08:09,760 --> 00:08:12,280
Because the path is easier than doing it the old way.

253
00:08:12,280 --> 00:08:14,040
The relationship changes.

254
00:08:14,040 --> 00:08:16,560
In a DevOps model, the infrastructure team reacts.

255
00:08:16,560 --> 00:08:17,880
Deploy this database.

256
00:08:17,880 --> 00:08:18,880
Fix this network.

257
00:08:18,880 --> 00:08:20,120
Review this policy.

258
00:08:20,120 --> 00:08:22,320
The request might be a pull request instead of a ticket,

259
00:08:22,320 --> 00:08:24,000
but the dynamic is the same.

260
00:08:24,000 --> 00:08:24,760
Someone asks.

261
00:08:24,760 --> 00:08:26,480
Someone else approves and delivers.

262
00:08:26,480 --> 00:08:27,760
In a platform engineering model,

263
00:08:27,760 --> 00:08:30,440
the team anticipates the request and eliminates it.

264
00:08:30,440 --> 00:08:33,280
Instead of waiting for a developer to ask for a new environment,

265
00:08:33,280 --> 00:08:35,720
the platform team builds an environment factory.

266
00:08:35,720 --> 00:08:36,720
You click a button.

267
00:08:36,720 --> 00:08:37,720
You get an environment.

268
00:08:37,720 --> 00:08:39,160
The governance is already there.

269
00:08:39,160 --> 00:08:40,480
The security is baked in.

270
00:08:40,480 --> 00:08:41,880
The monitoring is already running.

271
00:08:41,880 --> 00:08:43,560
The developer does not need to ask for permission

272
00:08:43,560 --> 00:08:46,800
because the system was designed so that the right way is the only way.

273
00:08:46,800 --> 00:08:50,080
Platform teams stop processing tickets and start studying pain.

274
00:08:50,080 --> 00:08:51,080
They talk to developers.

275
00:08:51,080 --> 00:08:52,080
They watch how they work.

276
00:08:52,080 --> 00:08:55,000
They find the patterns that get built over and over again.

277
00:08:55,000 --> 00:08:58,840
And they turn those patterns into products, self-service products.

278
00:08:58,840 --> 00:09:01,960
Tools that developers choose to use because they are faster and safer

279
00:09:01,960 --> 00:09:03,160
than doing it by hand.

280
00:09:03,160 --> 00:09:04,800
This is where golden paths come in.

281
00:09:04,800 --> 00:09:08,320
A golden path is the simplest, most supported way to get a task done.

282
00:09:08,320 --> 00:09:09,320
It is not the only way.

283
00:09:09,320 --> 00:09:11,960
You still have escape hatches for the weird edge cases.

284
00:09:11,960 --> 00:09:14,640
But for 80% of the work, there is a clear root

285
00:09:14,640 --> 00:09:16,240
with all the controls built in.

286
00:09:16,240 --> 00:09:19,280
Security, compliance, observability.

287
00:09:19,280 --> 00:09:22,920
It is all automatic because the path was designed that way from the start.

288
00:09:22,920 --> 00:09:25,480
Developers follow the path because it is easier.

289
00:09:25,480 --> 00:09:28,080
Using the path means you have an environment in minutes.

290
00:09:28,080 --> 00:09:31,280
Trying to do it manually means weeks of waiting for security audits

291
00:09:31,280 --> 00:09:32,480
and manual approvals.

292
00:09:32,480 --> 00:09:34,000
The choice becomes obvious.

293
00:09:34,000 --> 00:09:35,440
This requires a product mindset.

294
00:09:35,440 --> 00:09:36,640
Platform teams have roadmaps.

295
00:09:36,640 --> 00:09:37,840
They do user research.

296
00:09:37,840 --> 00:09:40,360
They track how many people are actually using the features.

297
00:09:40,360 --> 00:09:44,320
When developers ignore a new tool, the platform team does not blame the developers.

298
00:09:44,320 --> 00:09:45,880
They ask why the tool failed.

299
00:09:45,880 --> 00:09:47,800
They ask why the manual way was easier.

300
00:09:47,800 --> 00:09:49,680
Success looks different now.

301
00:09:49,680 --> 00:09:52,320
Traditional teams measure how many tickets they closed.

302
00:09:52,320 --> 00:09:55,280
That matters, but it does not tell you if you are actually helping.

303
00:09:55,280 --> 00:09:57,280
Platform teams measure adoption.

304
00:09:57,280 --> 00:09:59,480
What percentage of the company is using the platform?

305
00:09:59,480 --> 00:10:00,400
Are they satisfied?

306
00:10:00,400 --> 00:10:02,440
Is it actually making delivery faster?

307
00:10:02,440 --> 00:10:04,560
The platform that nobody uses is a failure.

308
00:10:04,560 --> 00:10:08,160
A platform that everyone is forced to use, but hates is also a failure.

309
00:10:08,160 --> 00:10:12,560
Success means developers choose the platform because it solves their problems better than anything else.

310
00:10:12,560 --> 00:10:15,040
The shift from gatekeeper to enabler changes everything.

311
00:10:15,040 --> 00:10:16,160
It changes what you measure.

312
00:10:16,160 --> 00:10:17,960
It changes how you spend your day.

313
00:10:17,960 --> 00:10:19,680
It changes how you know you are winning.

314
00:10:19,680 --> 00:10:22,920
It removes the bottleneck because the bottleneck was not the people.

315
00:10:22,920 --> 00:10:25,800
It was the model and the model just changed.

316
00:10:25,800 --> 00:10:27,200
The golden path concept.

317
00:10:27,200 --> 00:10:30,080
We need to be concrete about what a golden path actually is.

318
00:10:30,080 --> 00:10:34,120
Because this concept shifts the entire conversation around how infrastructure should work, a golden

319
00:10:34,120 --> 00:10:39,160
path is the opinionated, secure and well maintained route through your infrastructure.

320
00:10:39,160 --> 00:10:41,240
It isn't a guideline, it isn't a recommendation.

321
00:10:41,240 --> 00:10:45,200
It's the path designed, tested and optimized for your most common scenarios.

322
00:10:45,200 --> 00:10:49,440
When a developer needs to deploy a microservice, they don't evaluate five different architectures

323
00:10:49,440 --> 00:10:50,800
and pick the best one.

324
00:10:50,800 --> 00:10:53,000
They follow the golden path for microservices.

325
00:10:53,000 --> 00:10:55,240
That path already encodes every decision.

326
00:10:55,240 --> 00:10:56,240
Network topology.

327
00:10:56,240 --> 00:10:57,240
Storage configuration.

328
00:10:57,240 --> 00:10:58,240
Identity setup.

329
00:10:58,240 --> 00:10:59,680
Working and monitoring.

330
00:10:59,680 --> 00:11:00,680
Security baselines.

331
00:11:00,680 --> 00:11:02,160
Backup strategy.

332
00:11:02,160 --> 00:11:03,720
Everything is predetermined.

333
00:11:03,720 --> 00:11:07,920
The beauty of the golden path is that it encodes organizational standards without requiring

334
00:11:07,920 --> 00:11:10,200
developers to memorize them.

335
00:11:10,200 --> 00:11:13,080
Security teams don't need to audit every single deployment.

336
00:11:13,080 --> 00:11:15,200
Compliance requirements don't need manual reviews.

337
00:11:15,200 --> 00:11:18,040
Governance policies don't need to be understood by every engineer.

338
00:11:18,040 --> 00:11:21,560
The path was designed by people who understand security and compliance.

339
00:11:21,560 --> 00:11:23,440
And then it was embedded into the path itself.

340
00:11:23,440 --> 00:11:26,640
When you follow the golden path, you're automatically compliant.

341
00:11:26,640 --> 00:11:27,840
You're automatically secure.

342
00:11:27,840 --> 00:11:30,400
You're automatically meeting organizational policy.

343
00:11:30,400 --> 00:11:34,640
Not because you know the policy, but because the path makes it impossible to violate it.

344
00:11:34,640 --> 00:11:36,440
This is the fundamental inversion.

345
00:11:36,440 --> 00:11:39,960
Traditional infrastructure asks developers to learn policy and then follow it.

346
00:11:39,960 --> 00:11:42,560
The responsibility for compliance lives with the developer.

347
00:11:42,560 --> 00:11:46,800
They need to understand which security groups to attach, which roles to assign, which logging

348
00:11:46,800 --> 00:11:48,120
settings are required.

349
00:11:48,120 --> 00:11:49,680
They're responsible for getting it right.

350
00:11:49,680 --> 00:11:53,000
And when something fails in audit, they are the ones who fail to follow the rules.

351
00:11:53,000 --> 00:11:54,840
Golden paths flip this responsibility.

352
00:11:54,840 --> 00:11:57,280
The path is designed, so compliance is automatic.

353
00:11:57,280 --> 00:12:00,000
The developer doesn't need to know why certain decisions were made.

354
00:12:00,000 --> 00:12:03,600
They don't need to understand as your policy syntax or memorize which identity patterns

355
00:12:03,600 --> 00:12:04,600
are allowed.

356
00:12:04,600 --> 00:12:05,600
They follow the path.

357
00:12:05,600 --> 00:12:06,840
And compliance just happens.

358
00:12:06,840 --> 00:12:09,480
The developer's only responsibility is to understand.

359
00:12:09,480 --> 00:12:11,880
Does this path fit my use case?

360
00:12:11,880 --> 00:12:13,880
That's a dramatically different cognitive burden.

361
00:12:13,880 --> 00:12:17,960
For the 80% of workloads that fit predictable patterns, the answer is yes.

362
00:12:17,960 --> 00:12:20,920
They follow the path, 15 minutes of setup, and they're done.

363
00:12:20,920 --> 00:12:22,240
The environment is built.

364
00:12:22,240 --> 00:12:23,840
The security baseline is applied.

365
00:12:23,840 --> 00:12:25,000
The monitoring is configured.

366
00:12:25,000 --> 00:12:26,200
You can start writing code.

367
00:12:26,200 --> 00:12:29,200
For the 20% that don't fit the pattern, escape hatches exist.

368
00:12:29,200 --> 00:12:33,320
A developer can request an exception and explain why they need a different approach.

369
00:12:33,320 --> 00:12:35,200
But that request goes through an actual review.

370
00:12:35,200 --> 00:12:38,240
Not because every request is reviewed, but because requests are rare.

371
00:12:38,240 --> 00:12:40,520
When a request comes in, it gets attention.

372
00:12:40,520 --> 00:12:43,360
This mechanism has a profound psychological effect.

373
00:12:43,360 --> 00:12:44,960
Following the golden path isn't a constraint.

374
00:12:44,960 --> 00:12:45,960
It's a relief.

375
00:12:45,960 --> 00:12:46,960
You don't have to make decisions.

376
00:12:46,960 --> 00:12:49,680
You don't have to understand networking to configure networking.

377
00:12:49,680 --> 00:12:52,480
You don't have to be a security expert to deploy securely.

378
00:12:52,480 --> 00:12:55,440
The path was designed by experts and you're following their decisions.

379
00:12:55,440 --> 00:12:59,880
That's actually faster and safer than trying to design it yourself while learning the domain.

380
00:12:59,880 --> 00:13:01,520
The impact on onboarding is measurable.

381
00:13:01,520 --> 00:13:03,680
A new developer joins your organization.

382
00:13:03,680 --> 00:13:06,400
In the old model, they spend weeks understanding infrastructure.

383
00:13:06,400 --> 00:13:07,720
They read documentation.

384
00:13:07,720 --> 00:13:08,720
They ask questions.

385
00:13:08,720 --> 00:13:10,120
They build test environments.

386
00:13:10,120 --> 00:13:11,440
They learn from mistakes.

387
00:13:11,440 --> 00:13:13,640
They gradually build mental models of how things work.

388
00:13:13,640 --> 00:13:16,280
It takes three months before they are independently productive.

389
00:13:16,280 --> 00:13:17,960
With golden paths, they follow the path.

390
00:13:17,960 --> 00:13:20,560
They deploy their first service to production in days.

391
00:13:20,560 --> 00:13:23,840
They don't understand everything about the infrastructure yet, but they don't need to.

392
00:13:23,840 --> 00:13:25,160
The path handles it.

393
00:13:25,160 --> 00:13:28,600
They are productive immediately while learning the deeper context over time.

394
00:13:28,600 --> 00:13:30,840
On-boarding time drops by 50% or more.

395
00:13:30,840 --> 00:13:33,240
This efficiency compounds across the organization.

396
00:13:33,240 --> 00:13:36,920
When every developer can self-serve their infrastructure without waiting for approval,

397
00:13:36,920 --> 00:13:42,000
without needing to understand policy, without having to make dozens of configuration decisions.

398
00:13:42,000 --> 00:13:43,000
Velocity changes.

399
00:13:43,000 --> 00:13:46,640
Not just slightly, dramatically, because the constraint disappears.

400
00:13:46,640 --> 00:13:51,240
Golden paths eliminate the constraint by removing choice where choice adds no value.

401
00:13:51,240 --> 00:13:53,520
Developers make decisions about their application.

402
00:13:53,520 --> 00:13:56,040
The infrastructure team made the decisions about infrastructure.

403
00:13:56,040 --> 00:13:57,520
The two decisions are separate.

404
00:13:57,520 --> 00:14:00,160
And both happen in parallel, instead of sequentially.

405
00:14:00,160 --> 00:14:02,360
This is what platform engineering actually accomplishes.

406
00:14:02,360 --> 00:14:03,840
It doesn't just accelerate delivery.

407
00:14:03,840 --> 00:14:05,440
It restructures the operating model.

408
00:14:05,440 --> 00:14:09,080
So the constraint, the bottleneck that plagued DevOps at scale, doesn't exist in the

409
00:14:09,080 --> 00:14:10,080
first place.

410
00:14:10,080 --> 00:14:11,520
The self-service shift.

411
00:14:11,520 --> 00:14:15,080
The mechanical difference between the old operating model and the new one is where this

412
00:14:15,080 --> 00:14:16,360
becomes tangible.

413
00:14:16,360 --> 00:14:20,240
In the traditional infrastructure as a service model, the workflow is sequential.

414
00:14:20,240 --> 00:14:23,880
A developer needs an environment, so they submit a ticket describing what they need.

415
00:14:23,880 --> 00:14:24,880
Then they wait.

416
00:14:24,880 --> 00:14:27,200
Someone from the operations team receives the ticket and reviews it.

417
00:14:27,200 --> 00:14:30,640
They might ask clarifying questions, which leads to email back and forth.

418
00:14:30,640 --> 00:14:33,040
Eventually they approve it or request changes.

419
00:14:33,040 --> 00:14:34,840
Then they build the environment.

420
00:14:34,840 --> 00:14:35,840
Configuration takes time.

421
00:14:35,840 --> 00:14:36,840
They test it.

422
00:14:36,840 --> 00:14:37,840
They hand it back to the developer.

423
00:14:37,840 --> 00:14:38,840
Days have passed.

424
00:14:38,840 --> 00:14:39,840
Sometimes weeks.

425
00:14:39,840 --> 00:14:41,680
The developer has been waiting.

426
00:14:41,680 --> 00:14:43,320
Context switching between other work.

427
00:14:43,320 --> 00:14:47,480
Having email for updates, getting pulled back into focus when the environment finally arrives.

428
00:14:47,480 --> 00:14:50,200
Then discovering it's not quite configured the way they needed.

429
00:14:50,200 --> 00:14:51,200
Another ticket.

430
00:14:51,200 --> 00:14:52,200
More waiting.

431
00:14:52,200 --> 00:14:53,720
This is the bottleneck we talked about.

432
00:14:53,720 --> 00:14:54,720
It's not malicious.

433
00:14:54,720 --> 00:14:55,720
It's structural.

434
00:14:55,720 --> 00:14:58,720
Operations teams are responsible for infrastructure stability and security.

435
00:14:58,720 --> 00:15:00,680
So every request gets reviewed.

436
00:15:00,680 --> 00:15:02,200
Every configuration gets verified.

437
00:15:02,200 --> 00:15:06,800
The process exists to prevent mistakes that could crash production or expose data.

438
00:15:06,800 --> 00:15:08,800
But the cost of that process is time.

439
00:15:08,800 --> 00:15:09,800
Waiting time.

440
00:15:09,800 --> 00:15:14,680
It's a process that will be eliminated across hundreds of developers that waiting time becomes a permanent break on velocity.

441
00:15:14,680 --> 00:15:16,680
The platform model inverts this completely.

442
00:15:16,680 --> 00:15:18,440
The developer doesn't submit a ticket.

443
00:15:18,440 --> 00:15:20,480
They go to their internal developer platform.

444
00:15:20,480 --> 00:15:22,320
They see a list of available templates.

445
00:15:22,320 --> 00:15:24,040
They pick the one that matches what they need.

446
00:15:24,040 --> 00:15:25,960
A microservice deployment environment.

447
00:15:25,960 --> 00:15:26,960
A data platform.

448
00:15:26,960 --> 00:15:27,760
A web application.

449
00:15:27,760 --> 00:15:28,760
They click it.

450
00:15:28,760 --> 00:15:29,920
A form appears with parameters.

451
00:15:29,920 --> 00:15:31,240
What's the application name?

452
00:15:31,240 --> 00:15:32,240
What's the resource group?

453
00:15:32,240 --> 00:15:33,640
What's the environment, tier?

454
00:15:33,640 --> 00:15:35,560
They fill out the form and review the summary.

455
00:15:35,560 --> 00:15:37,880
It shows them exactly what will be created.

456
00:15:37,880 --> 00:15:39,040
Then they click deploy.

457
00:15:39,040 --> 00:15:44,000
Infrastructure provisions automatically, not in weeks, in minutes, while they're still sitting at their desk.

458
00:15:44,000 --> 00:15:47,360
The security groups are configured the way the organization requires them.

459
00:15:47,360 --> 00:15:50,000
The identity setup matches organizational standards.

460
00:15:50,000 --> 00:15:53,240
The logging configuration is whatever the organization mandated.

461
00:15:53,240 --> 00:15:54,720
The monitoring is already connected.

462
00:15:54,720 --> 00:15:56,520
The backup policy is already in place.

463
00:15:56,520 --> 00:15:58,760
All automatic.

464
00:15:58,760 --> 00:16:00,800
The developer didn't need to understand any of this.

465
00:16:00,800 --> 00:16:03,600
They didn't need to know networking or understand as your policy.

466
00:16:03,600 --> 00:16:06,280
They didn't need to make decisions about what's secure and what isn't.

467
00:16:06,280 --> 00:16:09,560
The infrastructure team made those decisions once when they built the template.

468
00:16:09,560 --> 00:16:11,720
The template makes them for every deployment.

469
00:16:11,720 --> 00:16:15,320
This requires one fundamental shift in how you think about governance.

470
00:16:15,320 --> 00:16:16,880
Traditional governance is reactive.

471
00:16:16,880 --> 00:16:18,080
A deployment happens.

472
00:16:18,080 --> 00:16:19,840
A compliance audit reviews it.

473
00:16:19,840 --> 00:16:22,400
And if something's wrong, you fix it after the fact.

474
00:16:22,400 --> 00:16:25,720
Governance is something that happens to your infrastructure after it's already built.

475
00:16:25,720 --> 00:16:26,920
It's a gate you pass through.

476
00:16:26,920 --> 00:16:27,920
A checkpoint.

477
00:16:27,920 --> 00:16:29,600
Automated governance is preventive.

478
00:16:29,600 --> 00:16:31,240
Governance is built into the deployment itself.

479
00:16:31,240 --> 00:16:34,800
The system won't allow a violation because the violation is architecturally impossible.

480
00:16:34,800 --> 00:16:38,200
You can't misconfigure security because there's no way to configure it.

481
00:16:38,200 --> 00:16:40,880
The security is applied automatically as part of the template.

482
00:16:40,880 --> 00:16:44,800
You can't deploy to an unapproved region because the template only allows approved regions.

483
00:16:44,800 --> 00:16:48,160
You can't forget to enable logging because logging is enabled by default.

484
00:16:48,160 --> 00:16:49,760
Not optional.

485
00:16:49,760 --> 00:16:52,520
This changes what self-service actually means.

486
00:16:52,520 --> 00:16:56,880
Self-service in the old model meant less structured or less controlled.

487
00:16:56,880 --> 00:16:59,320
Developers serving themselves with minimal oversight.

488
00:16:59,320 --> 00:17:00,320
More risk.

489
00:17:00,320 --> 00:17:01,320
Less governance.

490
00:17:01,320 --> 00:17:02,320
That's a false dichotomy.

491
00:17:02,320 --> 00:17:05,400
Information is developers serve themselves while governance is completely automated and

492
00:17:05,400 --> 00:17:06,400
inescapable.

493
00:17:06,400 --> 00:17:08,120
You get speed and compliance simultaneously.

494
00:17:08,120 --> 00:17:09,960
The impact on context switching is immediate.

495
00:17:09,960 --> 00:17:13,000
A developer used to spend significant time waiting for infrastructure.

496
00:17:13,000 --> 00:17:15,600
They'd submit a ticket and shift focus to something else.

497
00:17:15,600 --> 00:17:19,560
An hour later, the infrastructure will be ready and they'd shift focus back.

498
00:17:19,560 --> 00:17:20,560
Another context switch.

499
00:17:20,560 --> 00:17:21,560
Now?

500
00:17:21,560 --> 00:17:24,880
They submit the request and the infrastructure is ready while they're still on the same

501
00:17:24,880 --> 00:17:25,880
page.

502
00:17:25,880 --> 00:17:26,960
No context switch.

503
00:17:26,960 --> 00:17:27,960
Just continuous flow.

504
00:17:27,960 --> 00:17:28,960
They click deploy.

505
00:17:28,960 --> 00:17:31,120
They read the documentation while it's provisioning.

506
00:17:31,120 --> 00:17:33,920
And they're ready to start using it before the coffee gets cold.

507
00:17:33,920 --> 00:17:35,840
The measurable impact is dramatic.

508
00:17:35,840 --> 00:17:39,120
Organizations implementing platform engineering with self-service infrastructure see time to

509
00:17:39,120 --> 00:17:41,800
first deployment improve by three to five times.

510
00:17:41,800 --> 00:17:43,440
Not three to five percent times.

511
00:17:43,440 --> 00:17:46,760
A team that used to take two weeks from idea to deployed code in production now does

512
00:17:46,760 --> 00:17:48,000
it in three days.

513
00:17:48,000 --> 00:17:50,600
The difference isn't that developers got faster at their job.

514
00:17:50,600 --> 00:17:52,600
It's that the bottleneck disappeared.

515
00:17:52,600 --> 00:17:54,320
Developers focus on product work again.

516
00:17:54,320 --> 00:17:56,000
They're not managing infrastructure requests.

517
00:17:56,000 --> 00:17:57,920
They're not context switching between code and tickets.

518
00:17:57,920 --> 00:17:58,920
They're not waiting.

519
00:17:58,920 --> 00:17:59,920
They're building.

520
00:17:59,920 --> 00:18:00,920
That's the work that matters.

521
00:18:00,920 --> 00:18:02,680
They're not working on the work that creates business value.

522
00:18:02,680 --> 00:18:05,160
And that's what they're finally getting time to do.

523
00:18:05,160 --> 00:18:08,640
Internal developer platforms IDPs as the delivery mechanism.

524
00:18:08,640 --> 00:18:12,440
Everything we've talked about, golden paths, self-service infrastructure, automated governance

525
00:18:12,440 --> 00:18:13,440
needs a home.

526
00:18:13,440 --> 00:18:17,680
It needs a place where developers go to find it, to discover it, to understand what's available,

527
00:18:17,680 --> 00:18:18,680
to actually use it.

528
00:18:18,680 --> 00:18:20,880
That's what an internal developer platform is.

529
00:18:20,880 --> 00:18:22,440
An IDP isn't infrastructure.

530
00:18:22,440 --> 00:18:24,000
It's the interface to infrastructure.

531
00:18:24,000 --> 00:18:27,520
It's the user-facing portal where developers interact with everything the platform team

532
00:18:27,520 --> 00:18:28,520
has built.

533
00:18:28,520 --> 00:18:30,600
It's where developers come to find service catalogs.

534
00:18:30,600 --> 00:18:32,280
They see a template for a web application.

535
00:18:32,280 --> 00:18:33,600
They see one for an API.

536
00:18:33,600 --> 00:18:35,800
They see one for a data pipeline.

537
00:18:35,800 --> 00:18:37,560
Documentation is bundled with each one.

538
00:18:37,560 --> 00:18:39,320
Examples show exactly how to use the template.

539
00:18:39,320 --> 00:18:40,520
The parameters are clear.

540
00:18:40,520 --> 00:18:41,520
It's organized.

541
00:18:41,520 --> 00:18:42,520
It's discoverable.

542
00:18:42,520 --> 00:18:46,120
You're not hunting through a Wiki or email lists trying to figure out what's available.

543
00:18:46,120 --> 00:18:50,240
The IDP centralizes what used to be scattered across five different tools and three different

544
00:18:50,240 --> 00:18:51,240
processes.

545
00:18:51,240 --> 00:18:54,680
Before a developer needs an environment, they check a Wiki for documentation.

546
00:18:54,680 --> 00:18:55,680
It's outdated.

547
00:18:55,680 --> 00:18:56,960
The email someone asking what's current.

548
00:18:56,960 --> 00:18:58,040
They wait for a response.

549
00:18:58,040 --> 00:19:01,040
They check a GitHub repository for example configurations.

550
00:19:01,040 --> 00:19:04,640
They find three different examples that do almost the same thing, but not quite.

551
00:19:04,640 --> 00:19:06,360
They pick the closest one and modify it.

552
00:19:06,360 --> 00:19:08,160
They submit a request to a different system.

553
00:19:08,160 --> 00:19:09,160
They wait for approval.

554
00:19:09,160 --> 00:19:12,480
They get the environment and it's not what they expected because the documentation didn't

555
00:19:12,480 --> 00:19:13,760
match the actual setup.

556
00:19:13,760 --> 00:19:15,640
With an IDP, they go to one place.

557
00:19:15,640 --> 00:19:16,760
They select what they need.

558
00:19:16,760 --> 00:19:19,240
They see the exact configuration that will be applied.

559
00:19:19,240 --> 00:19:21,200
They see the security baseline that's included.

560
00:19:21,200 --> 00:19:22,720
They can preview the costs.

561
00:19:22,720 --> 00:19:23,720
Everything is transparent.

562
00:19:23,720 --> 00:19:25,200
Then they deploy.

563
00:19:25,200 --> 00:19:27,560
The portal reduces cognitive load in two ways.

564
00:19:27,560 --> 00:19:29,360
First, it centralizes information.

565
00:19:29,360 --> 00:19:32,160
You're not searching for documentation or guessing what's available because everything

566
00:19:32,160 --> 00:19:34,600
is in one place, organized and searchable.

567
00:19:34,600 --> 00:19:37,800
The cognitive cost of finding what you need drops to nearly zero.

568
00:19:37,800 --> 00:19:39,680
Second, it makes choices obvious.

569
00:19:39,680 --> 00:19:43,680
The platform team has already decided what the standard is and the IDP shows you that

570
00:19:43,680 --> 00:19:44,680
standard.

571
00:19:44,680 --> 00:19:48,400
You don't have to evaluate options or research best practices or debate with colleagues

572
00:19:48,400 --> 00:19:49,680
about the right approach.

573
00:19:49,680 --> 00:19:51,080
The approach is already chosen.

574
00:19:51,080 --> 00:19:53,320
That reduces decision fatigue significantly.

575
00:19:53,320 --> 00:19:54,840
But here's where adoption gets tricky.

576
00:19:54,840 --> 00:19:57,160
The presence of an IDP doesn't guarantee use.

577
00:19:57,160 --> 00:19:58,160
You can build a platform.

578
00:19:58,160 --> 00:19:59,800
You can expose all the golden paths.

579
00:19:59,800 --> 00:20:01,760
You can create beautiful documentation.

580
00:20:01,760 --> 00:20:03,240
And developers still won't use it.

581
00:20:03,240 --> 00:20:06,120
This is the adoption trap that kills most platform initiatives.

582
00:20:06,120 --> 00:20:07,920
An organization launches an IDP.

583
00:20:07,920 --> 00:20:10,400
They see 80% of their developers have access to it.

584
00:20:10,400 --> 00:20:11,600
Adoption is 80%.

585
00:20:11,600 --> 00:20:12,440
Management is happy.

586
00:20:12,440 --> 00:20:14,480
We launched the platform successfully.

587
00:20:14,480 --> 00:20:16,080
But then you measure actual usage.

588
00:20:16,080 --> 00:20:18,240
How many developers actively use it each week?

589
00:20:18,240 --> 00:20:19,240
30%.

590
00:20:19,240 --> 00:20:20,720
How many services are deployed through it?

591
00:20:20,720 --> 00:20:21,720
20%.

592
00:20:21,720 --> 00:20:24,440
The rest are using workarounds, custom scripts and manual approaches.

593
00:20:24,440 --> 00:20:26,280
80% adoption, 10% usage.

594
00:20:26,280 --> 00:20:27,280
That's the trap.

595
00:20:27,280 --> 00:20:29,120
The platform didn't fail because of the technology.

596
00:20:29,120 --> 00:20:32,800
It failed because it didn't solve the problem developers actually cared about.

597
00:20:32,800 --> 00:20:35,200
Maybe the templates don't match how teams actually work.

598
00:20:35,200 --> 00:20:36,600
Maybe the interface is confusing.

599
00:20:36,600 --> 00:20:39,720
Maybe the documentation assumes knowledge that new developers don't have.

600
00:20:39,720 --> 00:20:42,200
A platform with low usage isn't a successful platform.

601
00:20:42,200 --> 00:20:43,200
It's a tool.

602
00:20:43,200 --> 00:20:44,200
Nobody wants to use.

603
00:20:44,200 --> 00:20:45,400
And forcing adoption doesn't work.

604
00:20:45,400 --> 00:20:47,360
You can mandate that teams use the platform.

605
00:20:47,360 --> 00:20:50,560
But if it doesn't solve their problem better than alternatives, they'll find ways around

606
00:20:50,560 --> 00:20:51,560
it.

607
00:20:51,560 --> 00:20:53,720
This is why IDPs need to be treated as actual products.

608
00:20:53,720 --> 00:20:56,240
A successful IDP has a product manager.

609
00:20:56,240 --> 00:20:59,000
Someone whose job is to understand what developers need.

610
00:20:59,000 --> 00:21:00,160
To track satisfaction.

611
00:21:00,160 --> 00:21:02,560
To measure what templates are used in which are ignored.

612
00:21:02,560 --> 00:21:06,480
To talk to teams about friction, the IDP isn't built once and then maintained.

613
00:21:06,480 --> 00:21:07,480
It's designed.

614
00:21:07,480 --> 00:21:08,480
It's tested with users.

615
00:21:08,480 --> 00:21:09,920
It's refined based on feedback.

616
00:21:09,920 --> 00:21:14,000
It's evolved as the organization's needs change, when an IDP is treated this way adoption

617
00:21:14,000 --> 00:21:15,320
follows naturally.

618
00:21:15,320 --> 00:21:19,320
Not because it's mandated, but because developers choose it, because it solves their problem

619
00:21:19,320 --> 00:21:22,000
better than the alternative, because it makes their work easier.

620
00:21:22,000 --> 00:21:25,920
That's the difference between a platform that exists and a platform that works.

621
00:21:25,920 --> 00:21:28,240
How Azure Bicep enables golden paths?

622
00:21:28,240 --> 00:21:32,240
Everything we've described automated governance, self-service infrastructure, golden paths that

623
00:21:32,240 --> 00:21:36,400
encode organizational standards requires something concrete to make it work.

624
00:21:36,400 --> 00:21:41,080
You can't build an IDP and a library of golden paths using documentation or manual processes.

625
00:21:41,080 --> 00:21:42,480
You need infrastructure as code.

626
00:21:42,480 --> 00:21:46,720
And specifically, you need something that makes it practical to create, maintain, and distribute

627
00:21:46,720 --> 00:21:48,800
infrastructure templates at scale.

628
00:21:48,800 --> 00:21:51,240
That's where Azure Bicep enters the picture.

629
00:21:51,240 --> 00:21:55,160
Bicep is a domain-specific language built specifically for Azure infrastructure.

630
00:21:55,160 --> 00:21:56,240
You write Bicep code.

631
00:21:56,240 --> 00:22:00,200
It compiles down to ARM templates as your native deployment format.

632
00:22:00,200 --> 00:22:01,920
But here's the critical difference.

633
00:22:01,920 --> 00:22:03,240
Bicep is human readable.

634
00:22:03,240 --> 00:22:04,880
ARM templates are JSON.

635
00:22:04,880 --> 00:22:08,320
Hundreds of lines of nested objects, brackets, and syntax that's technically correct, but

636
00:22:08,320 --> 00:22:09,480
cognitively dense.

637
00:22:09,480 --> 00:22:10,480
Bicep strips that away.

638
00:22:10,480 --> 00:22:14,000
You're writing something closer to how you actually think about infrastructure.

639
00:22:14,000 --> 00:22:15,480
Define a virtual network.

640
00:22:15,480 --> 00:22:16,480
Attach subnets.

641
00:22:16,480 --> 00:22:17,840
Configure network security groups.

642
00:22:17,840 --> 00:22:18,840
Link.

643
00:22:18,840 --> 00:22:19,840
Identity.

644
00:22:19,840 --> 00:22:21,240
Permissions.

645
00:22:21,240 --> 00:22:25,840
And Bicep, those statements read like infrastructure thinking, not like JSON passing.

646
00:22:25,840 --> 00:22:28,600
The readability matters more than you'd expect.

647
00:22:28,600 --> 00:22:32,480
When infrastructure is defined in Bicep, reviewers can actually understand it.

648
00:22:32,480 --> 00:22:34,200
Pull requests on Bicep code are legible.

649
00:22:34,200 --> 00:22:38,480
A security engineer can read through a module and verify that it enforces the right policies.

650
00:22:38,480 --> 00:22:41,840
A compliance officer can see that logging is configured correctly.

651
00:22:41,840 --> 00:22:45,480
Another developer can look at an existing module and understand how it works well enough

652
00:22:45,480 --> 00:22:47,000
to modify it or build on it.

653
00:22:47,000 --> 00:22:49,040
This is impossibly hard with raw ARM templates.

654
00:22:49,040 --> 00:22:50,280
The syntax gets in the way.

655
00:22:50,280 --> 00:22:53,240
The real power of Bicep for platform engineering is modules.

656
00:22:53,240 --> 00:22:57,520
A Bicep module is a reusable unit that encapsulates infrastructure logic.

657
00:22:57,520 --> 00:22:58,720
You write a module once.

658
00:22:58,720 --> 00:23:00,200
You use it hundreds of times.

659
00:23:00,200 --> 00:23:02,880
That module is the building block of your golden parts.

660
00:23:02,880 --> 00:23:06,320
Let's say your organization has a standard way to deploy a web application.

661
00:23:06,320 --> 00:23:10,880
It needs a certain network configuration, specific identity and access controls.

662
00:23:10,880 --> 00:23:14,440
Monitoring connected to your centralized logging, a security baseline applied, all of

663
00:23:14,440 --> 00:23:15,760
that becomes a single module.

664
00:23:15,760 --> 00:23:17,920
A developer doesn't write any of that themselves.

665
00:23:17,920 --> 00:23:19,120
They reference the module.

666
00:23:19,120 --> 00:23:23,120
They provide a few parameters, application name, environment, resource group.

667
00:23:23,120 --> 00:23:24,440
The module handles everything else.

668
00:23:24,440 --> 00:23:25,920
A module has a clear contract.

669
00:23:25,920 --> 00:23:27,920
It accepts inputs, parameters.

670
00:23:27,920 --> 00:23:29,560
What should the application be named?

671
00:23:29,560 --> 00:23:30,920
What tier of resources do you need?

672
00:23:30,920 --> 00:23:31,920
What region?

673
00:23:31,920 --> 00:23:35,600
The module specifies exactly which parameters are required and what values are allowed.

674
00:23:35,600 --> 00:23:36,600
It has outputs.

675
00:23:36,600 --> 00:23:40,320
The resources it creates expose identifiers that other infrastructure can reference.

676
00:23:40,320 --> 00:23:44,760
A database connection string, a service endpoint, a managed identity that the application

677
00:23:44,760 --> 00:23:45,760
can use.

678
00:23:45,760 --> 00:23:47,560
This structure makes modules composable.

679
00:23:47,560 --> 00:23:48,800
One module can use another.

680
00:23:48,800 --> 00:23:50,600
A landing zone module sets up networking.

681
00:23:50,600 --> 00:23:52,960
A service module sits on top of that networking.

682
00:23:52,960 --> 00:23:54,920
A deployment module orchestrates both.

683
00:23:54,920 --> 00:23:57,040
Each has a clear input output contract.

684
00:23:57,040 --> 00:23:58,640
Each is independently testable.

685
00:23:58,640 --> 00:24:00,680
Each is independently maintainable.

686
00:24:00,680 --> 00:24:02,840
Versioning transforms how infrastructure evolves.

687
00:24:02,840 --> 00:24:04,480
A module isn't a static artifact.

688
00:24:04,480 --> 00:24:05,480
It's versioned.

689
00:24:05,480 --> 00:24:09,880
The organization releases version 1.0 of the web application module.

690
00:24:09,880 --> 00:24:10,880
Teams adopted.

691
00:24:10,880 --> 00:24:13,480
Months later, there's a security update.

692
00:24:13,480 --> 00:24:14,480
Logging needs to be enhanced.

693
00:24:14,480 --> 00:24:16,200
A compliance requirement changes.

694
00:24:16,200 --> 00:24:18,720
The platform team releases version 1.1.

695
00:24:18,720 --> 00:24:21,640
Teams that haven't updated still use version 1.0.

696
00:24:21,640 --> 00:24:23,280
New teams use 1.1.

697
00:24:23,280 --> 00:24:25,600
There's no forced migration that breaks everything.

698
00:24:25,600 --> 00:24:27,640
No sudden change that requires rework.

699
00:24:27,640 --> 00:24:30,280
Teams can plan their upgrade when it fits their schedule.

700
00:24:30,280 --> 00:24:32,800
This is how you maintain consistency without rigidity.

701
00:24:32,800 --> 00:24:34,000
The standard evolves.

702
00:24:34,000 --> 00:24:36,040
But teams control their own pace.

703
00:24:36,040 --> 00:24:38,000
Distribution through registries makes this scalable.

704
00:24:38,000 --> 00:24:40,760
Bicep modules are published to Azure Container Registry.

705
00:24:40,760 --> 00:24:42,400
Think of it like a package repository.

706
00:24:42,400 --> 00:24:47,200
The platform team builds modules, test them, and publishes them to the registry with version

707
00:24:47,200 --> 00:24:48,200
tags.

708
00:24:48,200 --> 00:24:50,000
That's what the management teams discover those modules.

709
00:24:50,000 --> 00:24:52,640
They pull specific versions into their infrastructure code.

710
00:24:52,640 --> 00:24:53,640
They reference them.

711
00:24:53,640 --> 00:24:56,920
The registry becomes the source of truth for approved standard patterns.

712
00:24:56,920 --> 00:24:57,920
It's secure.

713
00:24:57,920 --> 00:24:59,920
Only authorized teams can publish modules.

714
00:24:59,920 --> 00:25:00,920
It's discoverable.

715
00:25:00,920 --> 00:25:02,240
Teams can browse what's available.

716
00:25:02,240 --> 00:25:03,240
It's governed.

717
00:25:03,240 --> 00:25:04,240
You can see who uses which versions.

718
00:25:04,240 --> 00:25:05,240
Track deprecation.

719
00:25:05,240 --> 00:25:07,240
Enforced that old versions eventually get retired.

720
00:25:07,240 --> 00:25:10,600
The final advantage is day zero support for new Azure features.

721
00:25:10,600 --> 00:25:12,840
Azure releases new services constantly.

722
00:25:12,840 --> 00:25:13,840
New capabilities.

723
00:25:13,840 --> 00:25:15,080
New security features.

724
00:25:15,080 --> 00:25:18,560
And as you are releases something, bicep supports it immediately.

725
00:25:18,560 --> 00:25:21,840
Terraform providers often lag, sometimes weeks behind, sometimes months.

726
00:25:21,840 --> 00:25:23,160
But bicep is Azure native.

727
00:25:23,160 --> 00:25:26,600
When Microsoft releases a feature, bicep can use it the same day.

728
00:25:26,600 --> 00:25:29,640
That matters for golden parts because it means your standard deployment templates stay

729
00:25:29,640 --> 00:25:30,640
current.

730
00:25:30,640 --> 00:25:32,960
New security capabilities get added to modules quickly.

731
00:25:32,960 --> 00:25:35,240
New compliance requirements can be encoded immediately.

732
00:25:35,240 --> 00:25:38,480
Your infrastructure standards evolve as fast as the platform itself.

733
00:25:38,480 --> 00:25:42,920
This is the technical foundation that makes platform engineering possible at scale.

734
00:25:42,920 --> 00:25:44,080
Modules as products.

735
00:25:44,080 --> 00:25:46,080
This is where the thinking fundamentally shifts.

736
00:25:46,080 --> 00:25:48,560
A bicep module isn't just a reusable piece of code.

737
00:25:48,560 --> 00:25:49,560
It's a product.

738
00:25:49,560 --> 00:25:50,560
It has users.

739
00:25:50,560 --> 00:25:51,560
It has a life cycle.

740
00:25:51,560 --> 00:25:53,680
It gets designed based on what customers actually need.

741
00:25:53,680 --> 00:25:56,760
In the old model, modules are just maintenance artifacts.

742
00:25:56,760 --> 00:25:58,440
Someone writes them to avoid repeating code.

743
00:25:58,440 --> 00:26:00,040
They check them into a repo.

744
00:26:00,040 --> 00:26:01,040
And they just exist.

745
00:26:01,040 --> 00:26:02,800
If developers find them, they use them.

746
00:26:02,800 --> 00:26:04,400
But nobody owns them.

747
00:26:04,400 --> 00:26:07,560
If a module breaks, the first person who notices it has to fix it.

748
00:26:07,560 --> 00:26:10,200
If the documentation is missing, you're on your own.

749
00:26:10,200 --> 00:26:13,360
If it doesn't solve your specific problem, you just build a workaround.

750
00:26:13,360 --> 00:26:14,480
That's where the model breaks.

751
00:26:14,480 --> 00:26:18,960
This mindset creates technical debt at scale because you end up with dozens of similar modules

752
00:26:18,960 --> 00:26:20,360
doing almost the same thing.

753
00:26:20,360 --> 00:26:26,280
You get different naming conventions, inconsistent security baselines, and a mess of parameter structures.

754
00:26:26,280 --> 00:26:29,440
A developer looking for a networking module finds three different options.

755
00:26:29,440 --> 00:26:31,520
They pick one without really understanding it.

756
00:26:31,520 --> 00:26:34,360
And then a week later, someone else builds a fourth version because they couldn't find

757
00:26:34,360 --> 00:26:35,360
the first three.

758
00:26:35,360 --> 00:26:36,520
Now you have redundancy.

759
00:26:36,520 --> 00:26:38,560
You have inconsistency.

760
00:26:38,560 --> 00:26:42,760
Every new hire walks into this chaos and has to guess which module is the actual standard.

761
00:26:42,760 --> 00:26:44,720
The product mindset eliminates this.

762
00:26:44,720 --> 00:26:47,360
When a module is a product, it has a clear owner.

763
00:26:47,360 --> 00:26:51,800
Someone is responsible for the quality, the documentation, and the evolution of that code.

764
00:26:51,800 --> 00:26:53,520
This owner understands the users.

765
00:26:53,520 --> 00:26:55,040
They know what problems people are solving.

766
00:26:55,040 --> 00:26:58,800
They track which versions are active and they communicate when a change is coming.

767
00:26:58,800 --> 00:27:01,160
They are accountable for the module's success.

768
00:27:01,160 --> 00:27:04,920
And because of that, the inputs and outputs become contracts that are honored.

769
00:27:04,920 --> 00:27:07,480
When a module is just code, you can change it whenever you want.

770
00:27:07,480 --> 00:27:08,680
You break the interface.

771
00:27:08,680 --> 00:27:10,080
You add new requirements.

772
00:27:10,080 --> 00:27:11,960
And you force everyone else to adapt.

773
00:27:11,960 --> 00:27:14,320
And when a module is a product, the interface is sacred.

774
00:27:14,320 --> 00:27:17,760
If you need to change how it works, you trigger a major version bump.

775
00:27:17,760 --> 00:27:20,000
You give users time to plan the migration.

776
00:27:20,000 --> 00:27:22,040
You provide clear notes on what changed.

777
00:27:22,040 --> 00:27:24,920
And you keep things backward compatible as long as you can.

778
00:27:24,920 --> 00:27:27,040
Users aren't surprised by breaking changes.

779
00:27:27,040 --> 00:27:28,160
They plan for them.

780
00:27:28,160 --> 00:27:31,480
This discipline creates consistency across the entire organization.

781
00:27:31,480 --> 00:27:33,240
The module encodes your standards.

782
00:27:33,240 --> 00:27:36,920
A database module always sets up backups based on your retention policy.

783
00:27:36,920 --> 00:27:39,680
And it always configures monitoring to the company standard.

784
00:27:39,680 --> 00:27:43,560
Every time a developer uses that module, they get those standards automatically.

785
00:27:43,560 --> 00:27:47,600
They don't need to memorize the backup frequency or the tagging scheme, because the module already

786
00:27:47,600 --> 00:27:48,880
made those decisions.

787
00:27:48,880 --> 00:27:53,000
This is how you get consistency without forcing every developer to become a policy expert.

788
00:27:53,000 --> 00:27:54,800
The separation of concerns is profound.

789
00:27:54,800 --> 00:27:56,280
Platform teams own the modules.

790
00:27:56,280 --> 00:28:00,360
They understand the infrastructure, the policy and the security baselines that need to be

791
00:28:00,360 --> 00:28:01,520
enforced.

792
00:28:01,520 --> 00:28:03,240
Product teams own the applications.

793
00:28:03,240 --> 00:28:05,000
They understand the business problem.

794
00:28:05,000 --> 00:28:06,800
And they just need infrastructure that works.

795
00:28:06,800 --> 00:28:10,320
They pick a module, they provide the inputs and the infrastructure appears.

796
00:28:10,320 --> 00:28:11,720
They don't need to know the internals.

797
00:28:11,720 --> 00:28:13,560
They don't need to worry about compliance.

798
00:28:13,560 --> 00:28:16,160
This eliminates duplicated work at an organizational level.

799
00:28:16,160 --> 00:28:19,880
Without this structure, teams reinvent the same solutions over and over.

800
00:28:19,880 --> 00:28:22,560
One team builds a backup logic for databases.

801
00:28:22,560 --> 00:28:24,240
Another team does it for storage.

802
00:28:24,240 --> 00:28:25,840
And a third team does it for apps.

803
00:28:25,840 --> 00:28:27,880
It's the same problem solved three different ways.

804
00:28:27,880 --> 00:28:28,880
That's tripled effort.

805
00:28:28,880 --> 00:28:29,880
It's tripled bugs.

806
00:28:29,880 --> 00:28:31,240
It's a tripled support burden.

807
00:28:31,240 --> 00:28:33,440
With modules as products, you solve it once.

808
00:28:33,440 --> 00:28:34,440
Properly.

809
00:28:34,440 --> 00:28:36,680
You document it, you test it, and everyone uses it.

810
00:28:36,680 --> 00:28:40,920
The effort is shared across the whole company instead of being wasted by individual teams.

811
00:28:40,920 --> 00:28:44,160
The module becomes the interface that makes scale possible.

812
00:28:44,160 --> 00:28:46,360
In a small shop, everyone can know everything.

813
00:28:46,360 --> 00:28:48,200
But as you grow, that assumption fails.

814
00:28:48,200 --> 00:28:53,240
You can't ask 500 developers to master infrastructure, and you can't ask 100 operators to understand

815
00:28:53,240 --> 00:28:54,240
every app.

816
00:28:54,240 --> 00:28:55,720
You need clear boundaries.

817
00:28:55,720 --> 00:28:57,680
Modules are the tools that bridge those boundaries.

818
00:28:57,680 --> 00:29:01,440
They allow an organization to grow from being small and coordinated to being large and

819
00:29:01,440 --> 00:29:02,440
distributed.

820
00:29:02,440 --> 00:29:05,880
They let you maintain consistency without requiring everyone to work exactly the same

821
00:29:05,880 --> 00:29:06,880
way.

822
00:29:06,880 --> 00:29:09,840
And that's why treating them as products matters.

823
00:29:09,840 --> 00:29:12,960
Azure verified modules, AVM, as the standard.

824
00:29:12,960 --> 00:29:14,840
Building modules from scratch is expensive.

825
00:29:14,840 --> 00:29:16,760
You have to design them, test them, and document them.

826
00:29:16,760 --> 00:29:20,160
You have to maintain them and debug them when they fail in production.

827
00:29:20,160 --> 00:29:22,880
If you're starting this process for the first time, it takes months.

828
00:29:22,880 --> 00:29:26,240
You're looking at six to nine months just to get a solid baseline for your most common

829
00:29:26,240 --> 00:29:27,240
scenarios.

830
00:29:27,240 --> 00:29:30,160
And even then, you're probably just reinventing things Microsoft solved years ago.

831
00:29:30,160 --> 00:29:33,640
You're duplicating effort that's already been done by thousands of other companies.

832
00:29:33,640 --> 00:29:36,760
Azure verified modules changed this equation entirely.

833
00:29:36,760 --> 00:29:38,920
AVM isn't a collection of example templates.

834
00:29:38,920 --> 00:29:42,640
It's a Microsoft curated library of production ready bicep modules.

835
00:29:42,640 --> 00:29:46,520
These are modules that Microsoft designed and tested extensively so that enterprises

836
00:29:46,520 --> 00:29:48,040
could use them as a foundation.

837
00:29:48,040 --> 00:29:52,040
They looked at the patterns that repeat across every organization from security baselines

838
00:29:52,040 --> 00:29:54,800
to networking standards, and they codified them.

839
00:29:54,800 --> 00:29:56,360
Then they published them for everyone.

840
00:29:56,360 --> 00:29:59,280
The modules follow strict patterns that make them predictable.

841
00:29:59,280 --> 00:30:03,960
When you pull down an AVM module for a storage account, you already know what it looks like.

842
00:30:03,960 --> 00:30:07,360
The parameters and outputs follow a naming convention that matches every other module

843
00:30:07,360 --> 00:30:08,360
in the library.

844
00:30:08,360 --> 00:30:10,360
This consistency matters.

845
00:30:10,360 --> 00:30:14,560
Once a developer learns how one AVM module works, they can use any of them.

846
00:30:14,560 --> 00:30:15,880
The input patterns are the same.

847
00:30:15,880 --> 00:30:17,080
The documentation is the same.

848
00:30:17,080 --> 00:30:18,760
The learning curve just disappears.

849
00:30:18,760 --> 00:30:20,800
And these modules are battle tested at scale.

850
00:30:20,800 --> 00:30:21,800
They aren't theoretical.

851
00:30:21,800 --> 00:30:24,920
They've been used by Microsoft internally and by massive enterprise customers.

852
00:30:24,920 --> 00:30:26,520
Bugs have been found and fixed.

853
00:30:26,520 --> 00:30:30,880
When Microsoft releases a new feature that changes how a resource works, the AVM modules get

854
00:30:30,880 --> 00:30:32,520
updated to account for it.

855
00:30:32,520 --> 00:30:34,840
You aren't adopting code that's going to be abandoned.

856
00:30:34,840 --> 00:30:38,240
You're adopting a foundation that Microsoft actively maintains.

857
00:30:38,240 --> 00:30:41,480
This means organizations don't have to start from zero anymore.

858
00:30:41,480 --> 00:30:45,560
The old way was to decide on a pattern, build it, test it, and then deploy it.

859
00:30:45,560 --> 00:30:46,800
That's months of work.

860
00:30:46,800 --> 00:30:48,760
With AVM you start with what's already built.

861
00:30:48,760 --> 00:30:51,760
Your organization needs networking, identity and logging.

862
00:30:51,760 --> 00:30:53,280
AVM already has those modules.

863
00:30:53,280 --> 00:30:54,280
You adopt them.

864
00:30:54,280 --> 00:30:57,240
You add your specific layers on top and you move on.

865
00:30:57,240 --> 00:30:58,760
You aren't building from scratch.

866
00:30:58,760 --> 00:31:01,680
You're customizing something that's already proven.

867
00:31:01,680 --> 00:31:04,520
This accelerates your governance baseline dramatically.

868
00:31:04,520 --> 00:31:07,440
Defining which resources are allowed and how they should be configured usually takes

869
00:31:07,440 --> 00:31:08,480
a long time.

870
00:31:08,480 --> 00:31:11,760
You have to design the policy and refine it based on mistakes.

871
00:31:11,760 --> 00:31:13,560
With AVM the baseline is already there.

872
00:31:13,560 --> 00:31:15,360
It aligns with the cloud adoption framework.

873
00:31:15,360 --> 00:31:19,720
It incorporates security best practices and compliance patterns for regulated industries.

874
00:31:19,720 --> 00:31:20,800
You adopt the framework.

875
00:31:20,800 --> 00:31:23,720
You add your own requirements and months of work turn into weeks.

876
00:31:23,720 --> 00:31:26,720
The modules are aligned with how Microsoft recommends you build.

877
00:31:26,720 --> 00:31:30,480
The cloud adoption framework is the gold standard for enterprise cloud strategy.

878
00:31:30,480 --> 00:31:33,240
AVM modules implement those calf patterns directly.

879
00:31:33,240 --> 00:31:35,880
When you use them, you aren't just getting code.

880
00:31:35,880 --> 00:31:38,360
You're getting a platform that's built for the long term.

881
00:31:38,360 --> 00:31:40,200
Your infrastructure won't just work.

882
00:31:40,200 --> 00:31:43,960
It will work the way Microsoft recommends large organizations structure their cloud.

883
00:31:43,960 --> 00:31:46,640
This is how enterprises avoid reinventing the wheel.

884
00:31:46,640 --> 00:31:48,880
Every company thinks their situation is unique.

885
00:31:48,880 --> 00:31:51,280
But the core patterns are almost always the same.

886
00:31:51,280 --> 00:31:54,680
Before you connect networks and manage identity doesn't change that much from one company

887
00:31:54,680 --> 00:31:55,680
to the next.

888
00:31:55,680 --> 00:31:59,400
AVM solved those problems once with security and scale in mind.

889
00:31:59,400 --> 00:32:02,560
Using those solutions means you aren't wasting time on work that's already been done

890
00:32:02,560 --> 00:32:03,560
well.

891
00:32:03,560 --> 00:32:07,240
You're leveraging a foundation that works so you can focus on your specific business problems.

892
00:32:07,240 --> 00:32:08,880
The leverage here is enormous.

893
00:32:08,880 --> 00:32:13,240
An organization with hundreds of developers can save thousands of engineering hours by adopting

894
00:32:13,240 --> 00:32:14,240
AVM.

895
00:32:14,240 --> 00:32:17,960
Those are hours not spent building modules or debugging homegrown patterns.

896
00:32:17,960 --> 00:32:20,800
Those are hours you don't have to spend explaining your custom approach to every new

897
00:32:20,800 --> 00:32:22,680
hire that time compounds.

898
00:32:22,680 --> 00:32:26,200
And it's time the organization can spend on actual innovation instead of rebuilding the

899
00:32:26,200 --> 00:32:27,200
basement.

900
00:32:27,200 --> 00:32:29,840
That's the value AVM brings.

901
00:32:29,840 --> 00:32:33,400
Policy as code and governance automation as your policy is the enforcement layer that

902
00:32:33,400 --> 00:32:34,680
makes everything else work.

903
00:32:34,680 --> 00:32:38,160
It defines what is allowed and what is forbidden in your environment.

904
00:32:38,160 --> 00:32:42,560
You can mandate that storage accounts have encryption enabled or that resources only exist

905
00:32:42,560 --> 00:32:43,600
in specific regions.

906
00:32:43,600 --> 00:32:48,280
You can require managed identities for database access block public IP addresses or mandate

907
00:32:48,280 --> 00:32:49,520
specific tags.

908
00:32:49,520 --> 00:32:53,560
As your policy is the system that checks if your resources actually follow those rules.

909
00:32:53,560 --> 00:32:57,560
But in reality traditional policy enforcement is just a gate at the end.

910
00:32:57,560 --> 00:33:02,080
You deploy infrastructure then someone a security officer or an architect reviews it.

911
00:33:02,080 --> 00:33:03,160
They check for encryption.

912
00:33:03,160 --> 00:33:04,280
They look for tags.

913
00:33:04,280 --> 00:33:05,280
They verify the region.

914
00:33:05,280 --> 00:33:07,480
If something is wrong, they reject the deployment.

915
00:33:07,480 --> 00:33:08,480
You fix it.

916
00:33:08,480 --> 00:33:09,480
You resubmit.

917
00:33:09,480 --> 00:33:10,480
They review it again.

918
00:33:10,480 --> 00:33:13,040
The process is slow and it is external to the infrastructure itself.

919
00:33:13,040 --> 00:33:15,560
The infrastructure has no idea the policy exists.

920
00:33:15,560 --> 00:33:19,280
Policy is just something that happens to the resources after they are already there.

921
00:33:19,280 --> 00:33:21,720
It is called the policy as code flips this relationship.

922
00:33:21,720 --> 00:33:25,160
Instead of a separate review, you codify the policy and deploy it like any other piece

923
00:33:25,160 --> 00:33:26,160
of software.

924
00:33:26,160 --> 00:33:27,160
You write definitions.

925
00:33:27,160 --> 00:33:28,160
You version them.

926
00:33:28,160 --> 00:33:29,520
You review them in pull requests.

927
00:33:29,520 --> 00:33:33,120
Once that policy is live, it applies to everything in its scope automatically.

928
00:33:33,120 --> 00:33:36,160
You cannot deploy something that violates the rules because Azure will not allow the

929
00:33:36,160 --> 00:33:37,320
deployment to start.

930
00:33:37,320 --> 00:33:40,440
The check happens at the moment of deployment, not weeks later.

931
00:33:40,440 --> 00:33:42,600
This is a structural shift that changes everything.

932
00:33:42,600 --> 00:33:44,720
When policy is code, it becomes maintainable.

933
00:33:44,720 --> 00:33:49,240
A security team can own policy definitions the same way a platform team owns modules.

934
00:33:49,240 --> 00:33:52,680
As requirements change, the policy gets updated and deployed.

935
00:33:52,680 --> 00:33:54,880
Other teams do not need to memorize new rules.

936
00:33:54,880 --> 00:33:56,080
The new policy just works.

937
00:33:56,080 --> 00:34:00,360
There are no announcements, no training sessions, no emails telling everyone to adjust their

938
00:34:00,360 --> 00:34:03,320
infrastructure because compliance requirements changed.

939
00:34:03,320 --> 00:34:06,840
Bicep makes encoding this policy into modules feel natural.

940
00:34:06,840 --> 00:34:09,560
Bicep modules are the building blocks of your infrastructure.

941
00:34:09,560 --> 00:34:12,360
When you use a module, you are referencing a reusable pattern.

942
00:34:12,360 --> 00:34:15,520
The author of that module can bake compliance directly into the code.

943
00:34:15,520 --> 00:34:18,840
A storage module always enables encryption and always applies the right logging.

944
00:34:18,840 --> 00:34:20,680
The developer does not even have to think about it.

945
00:34:20,680 --> 00:34:22,440
The module already accounted for the rule.

946
00:34:22,440 --> 00:34:26,640
This makes governance a property of the infrastructure, not something external.

947
00:34:26,640 --> 00:34:30,640
When you use a compliant module, the infrastructure is inherently compliant.

948
00:34:30,640 --> 00:34:34,080
You cannot misconfigure it because the module does not allow that option.

949
00:34:34,080 --> 00:34:35,800
The security baseline is embedded.

950
00:34:35,800 --> 00:34:37,200
The logging is pre-configured.

951
00:34:37,200 --> 00:34:40,200
The developer follows the golden path and compliance just happens.

952
00:34:40,200 --> 00:34:41,400
Compare this to the old model.

953
00:34:41,400 --> 00:34:42,600
A developer writes code.

954
00:34:42,600 --> 00:34:43,720
Someone reviews it.

955
00:34:43,720 --> 00:34:44,880
Issues are found.

956
00:34:44,880 --> 00:34:48,960
The developer does not understand the policy, so they guess at a fix and resubmit.

957
00:34:48,960 --> 00:34:51,720
The reviewer still sees problems more back and forth.

958
00:34:51,720 --> 00:34:52,720
Frustration builds.

959
00:34:52,720 --> 00:34:57,200
Eventually, it passes, but the developer still does not know why certain settings matter.

960
00:34:57,200 --> 00:34:59,320
Next time they will make the same mistakes.

961
00:34:59,320 --> 00:35:02,800
With modules, the developer does not make the mistake in the first place.

962
00:35:02,800 --> 00:35:05,120
Understanding policy is no longer their responsibility.

963
00:35:05,120 --> 00:35:06,640
It is built into the pattern.

964
00:35:06,640 --> 00:35:11,160
This removes the most painful part of governance, the cycle of rejection and resubmission that

965
00:35:11,160 --> 00:35:13,680
makes developers hate the security team.

966
00:35:13,680 --> 00:35:16,600
Some compliance becomes architecturally impossible.

967
00:35:16,600 --> 00:35:18,360
This matters for the culture of the team.

968
00:35:18,360 --> 00:35:20,600
In the old model, compliance is a constraint.

969
00:35:20,600 --> 00:35:23,400
It is something imposed on you that you try to work around.

970
00:35:23,400 --> 00:35:26,280
With built-in compliance, it is just how the system works.

971
00:35:26,280 --> 00:35:27,520
You are not fighting the rules.

972
00:35:27,520 --> 00:35:29,160
You are building on a solid foundation.

973
00:35:29,160 --> 00:35:30,520
The enforcement happens silently.

974
00:35:30,520 --> 00:35:32,000
A developer deploys their code.

975
00:35:32,000 --> 00:35:34,600
They do not get a violation report or a flag in an audit.

976
00:35:34,600 --> 00:35:37,240
They simply could not have violated the policy if they tried.

977
00:35:37,240 --> 00:35:38,320
The module prevented it.

978
00:35:38,320 --> 00:35:39,800
The policy prevented it.

979
00:35:39,800 --> 00:35:42,680
Everything that exists was always compliant from the start.

980
00:35:42,680 --> 00:35:46,760
This closes the gap between what you have deployed and what your policy requires.

981
00:35:46,760 --> 00:35:48,800
In traditional setups, there is always drift.

982
00:35:48,800 --> 00:35:53,120
You find resources that do not match the rules or exceptions that were never documented.

983
00:35:53,120 --> 00:35:54,680
Compliance becomes a game of catch-up.

984
00:35:54,680 --> 00:35:58,920
You end up with a score like 80% compliant and you spend all your time trying to fix the

985
00:35:58,920 --> 00:36:00,400
other 20%.

986
00:36:00,400 --> 00:36:04,120
When policy is in the modules, new infrastructure is compliant by design.

987
00:36:04,120 --> 00:36:06,040
The compliance problem becomes a legacy problem.

988
00:36:06,040 --> 00:36:09,160
As teams move to the new modules, your score rises.

989
00:36:09,160 --> 00:36:13,320
Eventually, it hits 100% because new deployments are never wrong.

990
00:36:13,320 --> 00:36:16,320
This is how you scale governance without scaling the bureaucracy.

991
00:36:16,320 --> 00:36:18,560
The shift from tickets to templates.

992
00:36:18,560 --> 00:36:22,320
The mechanical difference between these two models is stark, but the structural difference

993
00:36:22,320 --> 00:36:24,000
is what actually matters.

994
00:36:24,000 --> 00:36:26,880
In the traditional ticket-based system, there is an approval gate.

995
00:36:26,880 --> 00:36:28,400
A developer needs a database.

996
00:36:28,400 --> 00:36:29,480
They write a request.

997
00:36:29,480 --> 00:36:30,680
They describe what they need.

998
00:36:30,680 --> 00:36:32,560
That request goes into a queue and waits.

999
00:36:32,560 --> 00:36:33,760
Eventually, someone picks it up.

1000
00:36:33,760 --> 00:36:36,160
They might need more info, so they send it back.

1001
00:36:36,160 --> 00:36:40,200
This goes back and forth until it is clear, then they approve it, then the work starts.

1002
00:36:40,200 --> 00:36:42,560
The infrastructure gets built, tested and handed over.

1003
00:36:42,560 --> 00:36:44,560
The approval gate creates a dependency.

1004
00:36:44,560 --> 00:36:45,960
The developer is blocked.

1005
00:36:45,960 --> 00:36:47,080
Waiting for a yes.

1006
00:36:47,080 --> 00:36:49,600
The operations person is a bottleneck for the whole company.

1007
00:36:49,600 --> 00:36:51,400
Neither side controls their own time.

1008
00:36:51,400 --> 00:36:54,640
The developer is waiting, and the operations person is overloaded.

1009
00:36:54,640 --> 00:36:58,080
Because everything is in a queue, even a five-minute task takes three days.

1010
00:36:58,080 --> 00:37:01,240
The template-based system removes the approval gate entirely.

1011
00:37:01,240 --> 00:37:02,240
There is no request.

1012
00:37:02,240 --> 00:37:03,240
There is no queue.

1013
00:37:03,240 --> 00:37:05,760
A developer goes to a portal and sees a list of templates.

1014
00:37:05,760 --> 00:37:06,760
They pick one.

1015
00:37:06,760 --> 00:37:09,000
They fill in the name, the environment and the region.

1016
00:37:09,000 --> 00:37:12,000
They see a summary of what will happen and they click deploy.

1017
00:37:12,000 --> 00:37:14,120
The infrastructure starts building immediately.

1018
00:37:14,120 --> 00:37:15,800
No human approval is required.

1019
00:37:15,800 --> 00:37:19,880
This only works because the template already holds all the decisions that used to be manual.

1020
00:37:19,880 --> 00:37:21,680
The security baseline is in the code.

1021
00:37:21,680 --> 00:37:23,200
The compliance rules are baked in.

1022
00:37:23,200 --> 00:37:24,800
The decisions were made once.

1023
00:37:24,800 --> 00:37:27,960
When the template was created, there is nothing left to approve.

1024
00:37:27,960 --> 00:37:31,640
The template either matches the standard or it does not exist in the catalog.

1025
00:37:31,640 --> 00:37:33,080
This is the structural shift.

1026
00:37:33,080 --> 00:37:35,800
When the approval model, every deployment is a unique event.

1027
00:37:35,800 --> 00:37:39,040
A developer makes choices and someone has to judge those choices.

1028
00:37:39,040 --> 00:37:40,760
Someone has to verify the securities.

1029
00:37:40,760 --> 00:37:43,840
Someone has to make a call on whether the deployment is acceptable.

1030
00:37:43,840 --> 00:37:47,400
In the template model, the developer makes no infrastructure decisions.

1031
00:37:47,400 --> 00:37:48,680
The template made them.

1032
00:37:48,680 --> 00:37:51,360
Those decisions were validated and approved months ago.

1033
00:37:51,360 --> 00:37:54,440
When a developer uses that template, they inherit those approvals.

1034
00:37:54,440 --> 00:37:57,240
The bottleneck disappears because there is nothing left to review.

1035
00:37:57,240 --> 00:37:59,720
This frees the operations team to do real work.

1036
00:37:59,720 --> 00:38:02,800
In the ticket model, operations people are just processes.

1037
00:38:02,800 --> 00:38:06,640
They spend their lives reading requests, asking questions and manually clicking buttons.

1038
00:38:06,640 --> 00:38:07,880
The work is reactive.

1039
00:38:07,880 --> 00:38:10,200
You are always responding to someone else's calendar.

1040
00:38:10,200 --> 00:38:13,280
In the template model, the operations team becomes a product team.

1041
00:38:13,280 --> 00:38:17,080
They spend their time studying common patterns and building templates to solve them.

1042
00:38:17,080 --> 00:38:18,200
They test the code.

1043
00:38:18,200 --> 00:38:20,480
They update the modules when the companies need change.

1044
00:38:20,480 --> 00:38:21,480
The work is proactive.

1045
00:38:21,480 --> 00:38:22,680
You are not answering tickets.

1046
00:38:22,680 --> 00:38:24,000
You are anticipating needs.

1047
00:38:24,000 --> 00:38:26,680
This is a total shift in what the team actually does.

1048
00:38:26,680 --> 00:38:30,760
Instead of being a human firewall, you are building self-service tools for your customers.

1049
00:38:30,760 --> 00:38:33,240
This work is more strategic and much more interesting.

1050
00:38:33,240 --> 00:38:36,880
It is where you actually get to innovate instead of just surviving the inbox.

1051
00:38:36,880 --> 00:38:38,520
The amount of time you save is massive.

1052
00:38:38,520 --> 00:38:42,000
A typical team might handle 10 requests a day and each one takes hours of talking and

1053
00:38:42,000 --> 00:38:43,000
building.

1054
00:38:43,000 --> 00:38:46,040
That is thousands of hours every year spent on reactive tasks.

1055
00:38:46,040 --> 00:38:48,840
When you kill the request process, those hours come back.

1056
00:38:48,840 --> 00:38:52,280
The team can now improve the templates or build new ones as new tech emerges.

1057
00:38:52,280 --> 00:38:53,880
The work becomes worth doing.

1058
00:38:53,880 --> 00:38:55,600
The infrastructure itself gets faster too.

1059
00:38:55,600 --> 00:38:59,480
When you build from a ticket, you are careful because you are dealing with uncertainty.

1060
00:38:59,480 --> 00:39:02,320
You over-provision because you aren't sure what the developer needs.

1061
00:39:02,320 --> 00:39:05,560
You test slowly because you don't want to hand over a broken environment.

1062
00:39:05,560 --> 00:39:07,080
It is a cautious, slow process.

1063
00:39:07,080 --> 00:39:08,960
With templates, the provisioning is automated.

1064
00:39:08,960 --> 00:39:13,200
A template deploys in minutes with no manual steps and no hand testing.

1065
00:39:13,200 --> 00:39:17,360
The time from "I need this" to "it's ready" drops from days to seconds.

1066
00:39:17,360 --> 00:39:19,440
The developer starts their work immediately.

1067
00:39:19,440 --> 00:39:24,560
The template model takes a manual, gated process and turns it into something instant.

1068
00:39:24,560 --> 00:39:26,400
Cognitive load reduction metrics.

1069
00:39:26,400 --> 00:39:27,560
Cognitive load is real.

1070
00:39:27,560 --> 00:39:28,400
But it's invisible.

1071
00:39:28,400 --> 00:39:29,400
You feel it.

1072
00:39:29,400 --> 00:39:30,400
Engineers experience it every day.

1073
00:39:30,400 --> 00:39:32,800
But if you can't measure it, you can't prove it exists.

1074
00:39:32,800 --> 00:39:36,840
And if you can't prove it exists, leadership won't fund the platform work needed to fix it.

1075
00:39:36,840 --> 00:39:40,080
So what's actually happening is we're trying to measure something as abstract as mental

1076
00:39:40,080 --> 00:39:41,080
effort.

1077
00:39:41,080 --> 00:39:43,120
The only way to do that is through indirect measurement.

1078
00:39:43,120 --> 00:39:47,960
By looking at the observable effects of that burden, start with time to first deployment.

1079
00:39:47,960 --> 00:39:51,840
When a new engineer joins the team, how long does it take them to ship their first change

1080
00:39:51,840 --> 00:39:52,840
to production?

1081
00:39:52,840 --> 00:39:57,040
In most organizations, without a solid platform, this takes two to four weeks.

1082
00:39:57,040 --> 00:40:00,740
The engineer spends the first week just learning tools, the second week trying to understand

1083
00:40:00,740 --> 00:40:05,160
infrastructure and the rest of the time, getting stuck on policies they don't understand.

1084
00:40:05,160 --> 00:40:08,720
But with a platform built on golden paths, that timeline collapses.

1085
00:40:08,720 --> 00:40:10,080
First deployment happens in days.

1086
00:40:10,080 --> 00:40:11,080
Or even hours.

1087
00:40:11,080 --> 00:40:14,680
The engineer uses a template, follows the path and the infrastructure just works.

1088
00:40:14,680 --> 00:40:19,180
This metric directly reflects a drop in cognitive load because less time spent on the how

1089
00:40:19,180 --> 00:40:22,000
means more mental energy for the what.

1090
00:40:22,000 --> 00:40:24,120
Environment provisioning tells a similar story.

1091
00:40:24,120 --> 00:40:28,400
In traditional setups, getting a dev environment ready means submitting a request and waiting

1092
00:40:28,400 --> 00:40:30,320
for manual approvals.

1093
00:40:30,320 --> 00:40:34,280
The engineer's mental load stays high because they're stuck in uncertainty, switching to other

1094
00:40:34,280 --> 00:40:38,760
tasks while they wait for operations to finish with self-service infrastructure that same process

1095
00:40:38,760 --> 00:40:40,000
happens in minutes.

1096
00:40:40,000 --> 00:40:44,080
The engineer hits a button, the platform provisions everything and the access just appears.

1097
00:40:44,080 --> 00:40:45,080
No waiting.

1098
00:40:45,080 --> 00:40:46,560
No context switching.

1099
00:40:46,560 --> 00:40:47,760
No uncertainty.

1100
00:40:47,760 --> 00:40:50,800
The load drops because the task is finally simple and fast.

1101
00:40:50,800 --> 00:40:52,240
Then there are support tickets.

1102
00:40:52,240 --> 00:40:55,000
These measure the friction that doesn't show up in deployment stats.

1103
00:40:55,000 --> 00:40:58,240
How many times does an engineer need help with a routine task?

1104
00:40:58,240 --> 00:40:59,800
Why did my compliance check fail?

1105
00:40:59,800 --> 00:41:01,200
How do I configure identity?

1106
00:41:01,200 --> 00:41:03,640
When you reduce cognitive load, these tickets disappear.

1107
00:41:03,640 --> 00:41:05,240
It's not because your engineer's got smarter.

1108
00:41:05,240 --> 00:41:08,280
It's because the platform eliminated the need for help in the first place.

1109
00:41:08,280 --> 00:41:10,920
The template solved the problem before it started.

1110
00:41:10,920 --> 00:41:13,800
Context switching is harder to track, but it's the real focus killer.

1111
00:41:13,800 --> 00:41:17,640
In a messy environment, one deployment might force an engineer to jump between five different

1112
00:41:17,640 --> 00:41:18,640
systems.

1113
00:41:18,640 --> 00:41:23,880
Force control, CI/SWRCD, infrastructure code, policy checkers, every switch breaks their

1114
00:41:23,880 --> 00:41:26,000
attention and resets their mental model.

1115
00:41:26,000 --> 00:41:29,880
A well-designed platform stops the bleeding by keeping everything in one flow.

1116
00:41:29,880 --> 00:41:32,800
To track the human side of this, use the space framework.

1117
00:41:32,800 --> 00:41:35,600
It breaks developer satisfaction into five areas.

1118
00:41:35,600 --> 00:41:37,560
Like well-being, performance and flow.

1119
00:41:37,560 --> 00:41:39,280
These aren't just feel-good metrics.

1120
00:41:39,280 --> 00:41:42,320
They're data points you validate against actual work outcomes.

1121
00:41:42,320 --> 00:41:45,800
You should also track your developer net promoter score for the platform itself.

1122
00:41:45,800 --> 00:41:48,200
Ask them, would you recommend this platform to appear?

1123
00:41:48,200 --> 00:41:51,160
A high score means you've actually solved their problems.

1124
00:41:51,160 --> 00:41:54,480
A low score means you're just adding more friction.

1125
00:41:54,480 --> 00:42:00,000
The most compelling case for an executive is combining time to first PR with satisfaction.

1126
00:42:00,000 --> 00:42:04,560
When you can show that new hires ship code in three days and 90% of them say the platform

1127
00:42:04,560 --> 00:42:05,760
makes work easier.

1128
00:42:05,760 --> 00:42:06,920
The argument is over.

1129
00:42:06,920 --> 00:42:08,960
You aren't talking about abstract feelings anymore.

1130
00:42:08,960 --> 00:42:12,120
You're showing faster onboarding and measurable productivity.

1131
00:42:12,120 --> 00:42:15,240
Research shows that platforms designed this way can cut the mental effort required

1132
00:42:15,240 --> 00:42:16,880
for the same work by nearly half.

1133
00:42:16,880 --> 00:42:20,120
That's the quantification that justifies the investment.

1134
00:42:20,120 --> 00:42:22,880
The business case, productivity and retention.

1135
00:42:22,880 --> 00:42:26,880
This is the moment where platform engineering stops being a technical choice and becomes

1136
00:42:26,880 --> 00:42:28,120
a business imperative.

1137
00:42:28,120 --> 00:42:32,360
The gains here are measurable in the financial terms that CFOs actually care about.

1138
00:42:32,360 --> 00:42:36,440
Every tiny improvement in the developer experience index saves about 13 minutes per developer

1139
00:42:36,440 --> 00:42:37,440
every week.

1140
00:42:37,440 --> 00:42:38,440
That sounds like nothing.

1141
00:42:38,440 --> 00:42:42,400
But for a 100 person team, that's $100,000 in reclaimed capacity every year.

1142
00:42:42,400 --> 00:42:44,200
That is a developer you didn't have to hire.

1143
00:42:44,200 --> 00:42:48,280
When you scale that to a thousand person organization, you're looking at a million dollars in

1144
00:42:48,280 --> 00:42:49,280
save time.

1145
00:42:49,280 --> 00:42:50,480
These aren't theoretical numbers.

1146
00:42:50,480 --> 00:42:53,760
They represent the hours people spend on real work instead of fighting the system.

1147
00:42:53,760 --> 00:42:56,840
But the true impact goes way beyond just saving hours.

1148
00:42:56,840 --> 00:42:59,440
Onboarding time is a massive part of hiring economics.

1149
00:42:59,440 --> 00:43:03,640
In the old model, you pay a senior salary for weeks, while a new hire contributes nothing

1150
00:43:03,640 --> 00:43:04,640
to the business.

1151
00:43:04,640 --> 00:43:06,840
The salary is just an expense with no return.

1152
00:43:06,840 --> 00:43:10,560
When you compress that onboarding from a month down to three days, you're accelerating

1153
00:43:10,560 --> 00:43:12,000
the value of that hire.

1154
00:43:12,000 --> 00:43:16,520
In a market where talent is expensive, getting someone productive in days instead of weeks,

1155
00:43:16,520 --> 00:43:20,040
changes the math on every person you bring in, you're essentially getting a massive head start

1156
00:43:20,040 --> 00:43:22,240
on your revenue for every new seat.

1157
00:43:22,240 --> 00:43:24,240
Retention economics are even bigger.

1158
00:43:24,240 --> 00:43:28,360
Replacing a senior engineer who quits costs roughly $250,000.

1159
00:43:28,360 --> 00:43:32,040
That includes recruitment fees, the gap in productivity, and the time spent training

1160
00:43:32,040 --> 00:43:36,160
a replacement if your engineers are leaving because of burnout and infrastructure friction.

1161
00:43:36,160 --> 00:43:39,280
You are paying that quarter million dollar penalty over and over again.

1162
00:43:39,280 --> 00:43:42,200
And the platform reduces that frustration, people stay.

1163
00:43:42,200 --> 00:43:45,680
The organization keeps its knowledge and avoids the massive cost of turnover.

1164
00:43:45,680 --> 00:43:48,040
This is especially true for your most senior people.

1165
00:43:48,040 --> 00:43:52,040
They are the ones most likely to leave when the operational friction gets too high.

1166
00:43:52,040 --> 00:43:53,600
Losing them isn't just losing a salary.

1167
00:43:53,600 --> 00:43:58,000
It's losing the organizational context and the multipliers who keep everyone else moving.

1168
00:43:58,000 --> 00:44:01,400
Most platform investments deliver a two to five times return within two years.

1169
00:44:01,400 --> 00:44:05,720
That return comes from smaller hiring needs, better retention, and faster feature delivery.

1170
00:44:05,720 --> 00:44:06,720
It's not a guess.

1171
00:44:06,720 --> 00:44:09,680
It's a documented range from companies that have already made the shift.

1172
00:44:09,680 --> 00:44:10,720
But here's the problem.

1173
00:44:10,720 --> 00:44:13,240
Most engineering teams talk about deployment frequency.

1174
00:44:13,240 --> 00:44:15,520
CFOs don't care about deployment frequency.

1175
00:44:15,520 --> 00:44:17,040
They care about revenue and retention.

1176
00:44:17,040 --> 00:44:20,640
The translation between those two worlds is what gets your platform funded.

1177
00:44:20,640 --> 00:44:25,520
If you can prove the platform will cut turnover by 20% and save $2 million in replacement

1178
00:44:25,520 --> 00:44:26,520
costs.

1179
00:44:26,520 --> 00:44:29,240
You've made a business case, not an engineering case, a business case.

1180
00:44:29,240 --> 00:44:31,040
This is why your metrics matter so much.

1181
00:44:31,040 --> 00:44:33,800
If you only measure door metrics, you'll struggle to justify the spend.

1182
00:44:33,800 --> 00:44:36,480
But if you measure retention, time to productive.

1183
00:44:36,480 --> 00:44:37,760
And hiring costs.

1184
00:44:37,760 --> 00:44:39,320
The investment becomes obvious.

1185
00:44:39,320 --> 00:44:41,720
Platform engineering isn't an expense you have to manage.

1186
00:44:41,720 --> 00:44:43,680
It's an investment in how your company functions.

1187
00:44:43,680 --> 00:44:46,480
It's how you scale your output without scaling your head count.

1188
00:44:46,480 --> 00:44:50,480
And how you turn your infrastructure into a competitive advantage, Bula.

1189
00:44:50,480 --> 00:44:52,320
Adoption and the product mindset.

1190
00:44:52,320 --> 00:44:55,320
The most dangerous assumption in platform engineering is simple.

1191
00:44:55,320 --> 00:44:57,160
If you build it, they will use it.

1192
00:44:57,160 --> 00:44:59,080
In reality, they probably won't.

1193
00:44:59,080 --> 00:45:02,160
You can build an elegant platform with golden paths and automated governance.

1194
00:45:02,160 --> 00:45:06,240
You can even set up an internal developer portal with perfect documentation and templates.

1195
00:45:06,240 --> 00:45:08,160
But developers will still find workarounds.

1196
00:45:08,160 --> 00:45:09,400
They will use their own scripts.

1197
00:45:09,400 --> 00:45:10,880
They will ask for exceptions.

1198
00:45:10,880 --> 00:45:14,040
They will find every possible way to avoid your platform entirely.

1199
00:45:14,040 --> 00:45:16,360
This happens constantly.

1200
00:45:16,360 --> 00:45:20,000
Organizations launch a new platform and the adoption metrics look healthy on paper.

1201
00:45:20,000 --> 00:45:23,880
80% of developers have access, so the spreadsheet says it's a success.

1202
00:45:23,880 --> 00:45:25,600
But then you look at actual usage.

1203
00:45:25,600 --> 00:45:28,360
Maybe only 30% of developers used it this week.

1204
00:45:28,360 --> 00:45:30,920
Only 20% of services went through the platform.

1205
00:45:30,920 --> 00:45:34,320
The rest of the organization used manual processes and workarounds.

1206
00:45:34,320 --> 00:45:35,640
This is the adoption trap.

1207
00:45:35,640 --> 00:45:38,680
It kills most platform initiatives before they can prove their worth.

1208
00:45:38,680 --> 00:45:40,760
The platform didn't fail because of the technology.

1209
00:45:40,760 --> 00:45:44,120
It failed because it didn't solve the problems developers actually cared about.

1210
00:45:44,120 --> 00:45:46,560
Maybe the templates were too rigid for real work.

1211
00:45:46,560 --> 00:45:49,920
Maybe they didn't fit how teams actually operate on a daily basis.

1212
00:45:49,920 --> 00:45:53,920
Maybe the documentation assumed knowledge that new engineers didn't have yet.

1213
00:45:53,920 --> 00:45:56,040
Whatever the reason developers chose alternatives.

1214
00:45:56,040 --> 00:45:58,560
The platform became theater, present but powerless.

1215
00:45:58,560 --> 00:45:59,560
But here's the problem.

1216
00:45:59,560 --> 00:46:01,160
You can't force adoption.

1217
00:46:01,160 --> 00:46:04,120
You can create policies and make it the official company standard.

1218
00:46:04,120 --> 00:46:08,480
And if it doesn't solve problems better than the alternatives, people will circumvent the rules.

1219
00:46:08,480 --> 00:46:11,520
Force adoption creates resentment, not usage.

1220
00:46:11,520 --> 00:46:14,360
The real solution is treating the platform as an actual product.

1221
00:46:14,360 --> 00:46:17,040
A product isn't something you build once and maintain.

1222
00:46:17,040 --> 00:46:19,640
It's something you design based on what customers actually need.

1223
00:46:19,640 --> 00:46:20,960
You build a minimum version.

1224
00:46:20,960 --> 00:46:21,960
You release it.

1225
00:46:21,960 --> 00:46:22,960
You watch how people use it.

1226
00:46:22,960 --> 00:46:24,160
You talk to them about friction.

1227
00:46:24,160 --> 00:46:27,640
You ask what's confusing or what didn't work the way they expected.

1228
00:46:27,640 --> 00:46:28,640
Then you iterate.

1229
00:46:28,640 --> 00:46:30,160
This requires a different structure.

1230
00:46:30,160 --> 00:46:34,080
You need a product manager whose entire job is to understand what developers need.

1231
00:46:34,080 --> 00:46:37,480
Not what they say in a survey, but what they actually need based on how they work.

1232
00:46:37,480 --> 00:46:41,360
This person watches how people use the platform to understand adoption patterns.

1233
00:46:41,360 --> 00:46:44,600
They know which templates are used constantly and which ones nobody touches.

1234
00:46:44,600 --> 00:46:46,680
You need user research before you build anything.

1235
00:46:46,680 --> 00:46:49,960
You don't want templates designed in isolation by infrastructure engineers.

1236
00:46:49,960 --> 00:46:53,440
You want them designed by understanding the constraints developers face every day.

1237
00:46:53,440 --> 00:46:54,840
This research informs the design.

1238
00:46:54,840 --> 00:46:56,080
You build what matters.

1239
00:46:56,080 --> 00:46:57,320
And you need feedback loops.

1240
00:46:57,320 --> 00:47:01,080
When you launch a new capability, you measure if it's actually being used.

1241
00:47:01,080 --> 00:47:04,520
You talk to the teams that didn't adopt it and ask what would have made it useful.

1242
00:47:04,520 --> 00:47:06,560
You don't just build a feature and assume it's valuable.

1243
00:47:06,560 --> 00:47:07,680
You validate it.

1244
00:47:07,680 --> 00:47:09,960
Someone has to be accountable for the platform's success.

1245
00:47:09,960 --> 00:47:13,760
Not just that it's technically sound, but that developers choose to use it.

1246
00:47:13,760 --> 00:47:15,760
Success is measured by adoption and satisfaction.

1247
00:47:15,760 --> 00:47:17,360
Not by how many features you shipped.

1248
00:47:17,360 --> 00:47:20,160
The product mindset changes how decisions get made.

1249
00:47:20,160 --> 00:47:23,880
When you treat infrastructure as code, you optimize for technical elegance and clean

1250
00:47:23,880 --> 00:47:24,880
architecture.

1251
00:47:24,880 --> 00:47:29,360
But when you treat the platform as a product, you optimize for developer experience.

1252
00:47:29,360 --> 00:47:31,560
These priorities conflict.

1253
00:47:31,560 --> 00:47:34,400
A technically elegant solution might be complex to use.

1254
00:47:34,400 --> 00:47:37,160
A simple solution might have architectural compromises.

1255
00:47:37,160 --> 00:47:39,200
With a product mindset, you choose simple.

1256
00:47:39,200 --> 00:47:41,240
Adoption matters more than perfect architecture.

1257
00:47:41,240 --> 00:47:42,720
You can refactor later.

1258
00:47:42,720 --> 00:47:44,760
But you can't succeed if nobody uses it.

1259
00:47:44,760 --> 00:47:48,560
This shift from engineering discipline to product discipline is what separates platforms

1260
00:47:48,560 --> 00:47:50,840
that work from platforms that just exist.

1261
00:47:50,840 --> 00:47:52,160
It's not about the technology.

1262
00:47:52,160 --> 00:47:55,880
It's about whether the platform solves problems that developers care about enough to choose

1263
00:47:55,880 --> 00:47:57,560
it over alternatives.

1264
00:47:57,560 --> 00:47:59,880
By-set modules in enterprise governance.

1265
00:47:59,880 --> 00:48:03,000
When you're building for 50 developers, governance is a conversation.

1266
00:48:03,000 --> 00:48:05,920
When you're building for 5,000, it's an operating model.

1267
00:48:05,920 --> 00:48:09,800
By-set modules are how you make governance scale without it becoming paralyzing.

1268
00:48:09,800 --> 00:48:11,560
Enterprise governance has a fundamental tension.

1269
00:48:11,560 --> 00:48:16,080
You need consistency for security and compliance, but you also need flexibility because different

1270
00:48:16,080 --> 00:48:18,080
business units have different requirements.

1271
00:48:18,080 --> 00:48:21,120
A governance model that's too rigid will always be circumvented.

1272
00:48:21,120 --> 00:48:24,200
Teams will find ways around it and you end up with shadow infrastructure that skips

1273
00:48:24,200 --> 00:48:25,280
governance entirely.

1274
00:48:25,280 --> 00:48:29,000
By-set modules solve this by making governance layered and composable.

1275
00:48:29,000 --> 00:48:30,480
At the foundation are landing zones.

1276
00:48:30,480 --> 00:48:34,480
A landing zone is a baseline environment that defines what a subscription looks like before

1277
00:48:34,480 --> 00:48:36,120
any application is deployed.

1278
00:48:36,120 --> 00:48:39,200
This includes the network foundation and identity configuration.

1279
00:48:39,200 --> 00:48:43,160
It includes the logging baseline to make sure diagnostics go to a central location.

1280
00:48:43,160 --> 00:48:45,520
This baseline is encoded in a by-set module.

1281
00:48:45,520 --> 00:48:49,240
When a new subscription is provisioned, it starts with the landing zone already applied.

1282
00:48:49,240 --> 00:48:51,040
On top of that site, policy modules.

1283
00:48:51,040 --> 00:48:54,120
These define organizational standards for specific concerns.

1284
00:48:54,120 --> 00:48:57,600
But making sure storage accounts always have public access denied.

1285
00:48:57,600 --> 00:49:01,520
They ensure databases have automated backups and monitoring enabled by default.

1286
00:49:01,520 --> 00:49:04,920
Each policy is a separate module that encodes a specific requirement.

1287
00:49:04,920 --> 00:49:08,040
Then you have R-back modules that standardize how access works.

1288
00:49:08,040 --> 00:49:09,320
Applications don't get admin access.

1289
00:49:09,320 --> 00:49:11,520
They get specific roles for specific operations.

1290
00:49:11,520 --> 00:49:15,160
A web application can read from a database but can't modify the schema.

1291
00:49:15,160 --> 00:49:19,000
These patterns are standardized in a by-set module that every team uses.

1292
00:49:19,000 --> 00:49:21,840
Access stays consistent across the entire organization.

1293
00:49:21,840 --> 00:49:24,320
These modules compose into larger patterns.

1294
00:49:24,320 --> 00:49:28,680
A data analytics landing zone builds on the base but adds networking for data connections

1295
00:49:28,680 --> 00:49:30,800
and specific security controls.

1296
00:49:30,800 --> 00:49:32,160
Each is built from the same library.

1297
00:49:32,160 --> 00:49:34,840
But they are combined in different ways based on specific needs.

1298
00:49:34,840 --> 00:49:37,200
This is how you get consistency without rigidity.

1299
00:49:37,200 --> 00:49:40,600
The modules enforce minimum standards but they are parameterized.

1300
00:49:40,600 --> 00:49:43,840
Teams can choose the performance tier or the retention period they need.

1301
00:49:43,840 --> 00:49:48,200
The module enforces that identity access works a certain way, but it allows teams to decide

1302
00:49:48,200 --> 00:49:50,000
which identities get which roles.

1303
00:49:50,000 --> 00:49:51,480
Scaling this is the real challenge.

1304
00:49:51,480 --> 00:49:56,120
An organization with hundreds of subscriptions managed manually would require a massive governance

1305
00:49:56,120 --> 00:49:57,120
team.

1306
00:49:57,120 --> 00:50:01,080
You would need hundreds of people reviewing configurations and verifying compliance.

1307
00:50:01,080 --> 00:50:03,240
By-set modules eliminate most of this work.

1308
00:50:03,240 --> 00:50:07,600
New subscriptions don't need manual review because they deploy with the landing zone module.

1309
00:50:07,600 --> 00:50:08,600
Compliance is built in.

1310
00:50:08,600 --> 00:50:12,760
Resources that don't use approved modules trigger violations at deployment time.

1311
00:50:12,760 --> 00:50:14,360
It's automatic enforcement.

1312
00:50:14,360 --> 00:50:17,040
This scales governance without scaling the bureaucracy.

1313
00:50:17,040 --> 00:50:19,960
In a manual world, the governance team becomes a bottleneck.

1314
00:50:19,960 --> 00:50:22,520
More teams mean more reviews and more monitoring.

1315
00:50:22,520 --> 00:50:26,680
With module-based governance, you build the modules once and they scale across the organization

1316
00:50:26,680 --> 00:50:28,000
with minimal effort.

1317
00:50:28,000 --> 00:50:30,080
This is also how you avoid security drift.

1318
00:50:30,080 --> 00:50:34,640
In manual governance, you might verify compliance at one point in time, but over time configurations

1319
00:50:34,640 --> 00:50:36,520
drift as teams make changes.

1320
00:50:36,520 --> 00:50:39,680
With module-based governance, drift is largely impossible.

1321
00:50:39,680 --> 00:50:42,280
Resources that don't follow the pattern simply fail to deploy.

1322
00:50:42,280 --> 00:50:44,560
The system enforces compliance continuously.

1323
00:50:44,560 --> 00:50:45,880
Not through periodic audits.

1324
00:50:45,880 --> 00:50:48,480
By-set modules make enterprise governance practical.

1325
00:50:48,480 --> 00:50:53,400
They make it standardized, scalable and transparent to the teams building on top of them.

1326
00:50:53,400 --> 00:50:56,080
By-set versus terraform, the strategic choice.

1327
00:50:56,080 --> 00:50:58,400
This is where strategy matters more than technology.

1328
00:50:58,400 --> 00:51:00,840
You have to make a choice about your ISE tooling.

1329
00:51:00,840 --> 00:51:04,720
And while that choice feels technical, it's actually about your business direction.

1330
00:51:04,720 --> 00:51:06,640
By-set versus terraform, which one is better?

1331
00:51:06,640 --> 00:51:08,360
Which one should you standardize on?

1332
00:51:08,360 --> 00:51:09,840
But the real question isn't technical.

1333
00:51:09,840 --> 00:51:11,520
It's strategic.

1334
00:51:11,520 --> 00:51:13,000
What's your cloud commitment?

1335
00:51:13,000 --> 00:51:15,440
How does your organization think about infrastructure?

1336
00:51:15,440 --> 00:51:17,160
What constraints matter most?

1337
00:51:17,160 --> 00:51:18,160
Automatism is multi-cloud.

1338
00:51:18,160 --> 00:51:22,160
It uses the same language and tooling across Azure, AWS, GCP and Kubernetes.

1339
00:51:22,160 --> 00:51:27,560
You write terraform code for your networking layer on AWS and then you use those same patterns

1340
00:51:27,560 --> 00:51:31,680
for your networking on Azure, same syntax, same team.

1341
00:51:31,680 --> 00:51:35,200
This matters for organizations that genuinely operate across multiple clouds.

1342
00:51:35,200 --> 00:51:38,080
You don't learn one language for AWS and another for Azure.

1343
00:51:38,080 --> 00:51:40,080
You learn terraform once and use it everywhere.

1344
00:51:40,080 --> 00:51:41,560
By-set is Azure native.

1345
00:51:41,560 --> 00:51:43,760
It designs specifically for Azure infrastructure.

1346
00:51:43,760 --> 00:51:45,400
It doesn't pretend to be multi-cloud.

1347
00:51:45,400 --> 00:51:48,360
It's not trying to be a general purpose tool that works everywhere.

1348
00:51:48,360 --> 00:51:51,560
It's a tool built for Azure by people who understand Azure deeply.

1349
00:51:51,560 --> 00:51:53,240
That focus creates advantages.

1350
00:51:53,240 --> 00:51:56,280
By-set has day zero support for new Azure features.

1351
00:51:56,280 --> 00:52:00,240
When Microsoft releases a new service, By-set can use it immediately.

1352
00:52:00,240 --> 00:52:03,560
Terraform providers often lag, sometimes weeks, sometimes months.

1353
00:52:03,560 --> 00:52:07,440
If you need the latest Azure feature for a security requirement, Terraform might not support

1354
00:52:07,440 --> 00:52:08,440
it yet.

1355
00:52:08,440 --> 00:52:09,440
This lag matters.

1356
00:52:09,440 --> 00:52:10,840
It's not just an inconvenience.

1357
00:52:10,840 --> 00:52:14,200
If you're building your governance baseline and you need a new Azure policy feature,

1358
00:52:14,200 --> 00:52:15,880
Terraform doesn't support it yet.

1359
00:52:15,880 --> 00:52:19,000
You're blocked, you can use By-set or you can wait for Terraform.

1360
00:52:19,000 --> 00:52:23,200
That dependency on a third party's timeline for your critical infrastructure is a real constraint.

1361
00:52:23,200 --> 00:52:26,360
For organizations that are Azure only, By-set is increasingly the default.

1362
00:52:26,360 --> 00:52:30,520
If your cloud strategy is Azure and it's going to stay Azure, why constrain yourself to

1363
00:52:30,520 --> 00:52:33,280
a tool optimized for multi-cloud parity?

1364
00:52:33,280 --> 00:52:34,760
By-set is optimized for Azure.

1365
00:52:34,760 --> 00:52:35,760
It's simpler.

1366
00:52:35,760 --> 00:52:38,200
It's more closely integrated with Azure native governance.

1367
00:52:38,200 --> 00:52:39,960
It supports new features faster.

1368
00:52:39,960 --> 00:52:41,280
Your modules are cleaner.

1369
00:52:41,280 --> 00:52:45,840
Your team can focus on Azure expertise instead of learning patterns that work across clouds.

1370
00:52:45,840 --> 00:52:47,040
The trend is clear.

1371
00:52:47,040 --> 00:52:50,160
New Azure focused organization standardize on By-set.

1372
00:52:50,160 --> 00:52:54,040
Existing organizations that have invested heavily in Terraform, sometimes stick with it because

1373
00:52:54,040 --> 00:52:55,680
migration costs are high.

1374
00:52:55,680 --> 00:53:00,080
But greenfield decisions in Azure-centric organizations increasingly choose By-set.

1375
00:53:00,080 --> 00:53:04,000
For organizations with genuine multi-cloud needs, Terraform remains the standard.

1376
00:53:04,000 --> 00:53:08,520
If you're running infrastructure on AWS and Azure and GCP, you need consistency.

1377
00:53:08,520 --> 00:53:11,720
You need teams that can move between clouds without relearning tools.

1378
00:53:11,720 --> 00:53:14,360
You need your networking patterns to work the same way everywhere.

1379
00:53:14,360 --> 00:53:16,720
You need policy enforcement that's cloud agnostic.

1380
00:53:16,720 --> 00:53:17,720
Terraform gives you that.

1381
00:53:17,720 --> 00:53:18,960
It's the common language.

1382
00:53:18,960 --> 00:53:21,600
Terraform governance tools work across providers.

1383
00:53:21,600 --> 00:53:24,520
Your remote state backend pattern is the same on all clouds.

1384
00:53:24,520 --> 00:53:26,520
Your module library patterns are identical.

1385
00:53:26,520 --> 00:53:30,880
The cost of maintaining multiple IAC languages, Terraform here, cloud formation there, By-set

1386
00:53:30,880 --> 00:53:34,920
somewhere else is higher than the cost of constraining yourself to Terraform's model.

1387
00:53:34,920 --> 00:53:37,920
You choose Terraform not because it's the best for any single cloud.

1388
00:53:37,920 --> 00:53:39,120
It's good for all clouds.

1389
00:53:39,120 --> 00:53:40,120
That's the value.

1390
00:53:40,120 --> 00:53:41,120
Consistency.

1391
00:53:41,120 --> 00:53:44,760
A single way of thinking about infrastructure regardless of where it runs.

1392
00:53:44,760 --> 00:53:46,960
Hybrid approaches are becoming increasingly common.

1393
00:53:46,960 --> 00:53:51,360
Some organizations use By-set for Azure-specific infrastructure and governance.

1394
00:53:51,360 --> 00:53:55,680
Landing zones, policy modules, security baselines, Azure-native patterns that you want day-zero

1395
00:53:55,680 --> 00:53:58,680
support for and deep integration with Azure-policy.

1396
00:53:58,680 --> 00:54:01,280
But they use Terraform for cross-cloud concerns.

1397
00:54:01,280 --> 00:54:06,040
Global networking, shared identity patterns, services that span multiple clouds.

1398
00:54:06,040 --> 00:54:09,160
The organization uses both tools with clear boundaries.

1399
00:54:09,160 --> 00:54:12,920
By-set owns Azure governance, Terraform owns cross-cloud orchestration.

1400
00:54:12,920 --> 00:54:14,280
This approach requires discipline.

1401
00:54:14,280 --> 00:54:15,760
You need clear boundaries.

1402
00:54:15,760 --> 00:54:17,240
Which team owns the By-set modules?

1403
00:54:17,240 --> 00:54:19,200
Which owns the Terraform infrastructure?

1404
00:54:19,200 --> 00:54:20,400
How do the two integrate?

1405
00:54:20,400 --> 00:54:21,760
What's the deployment order?

1406
00:54:21,760 --> 00:54:23,720
But when the boundaries are clean, it works.

1407
00:54:23,720 --> 00:54:25,640
You get the benefits of both approaches.

1408
00:54:25,640 --> 00:54:29,520
Azure-native velocity from By-set and multi-cloud consistency from Terraform.

1409
00:54:29,520 --> 00:54:32,200
The choice isn't about which tool is objectively better.

1410
00:54:32,200 --> 00:54:34,240
It's about matching the tool to your strategy.

1411
00:54:34,240 --> 00:54:36,800
What your organization's cloud commitment actually is.

1412
00:54:36,800 --> 00:54:40,920
Ask whether you have genuine multi-cloud needs or whether Azure is your primary platform.

1413
00:54:40,920 --> 00:54:43,480
Ask what timeline matters for new feature adoption.

1414
00:54:43,480 --> 00:54:46,400
The answers to those questions determine the right choice.

1415
00:54:46,400 --> 00:54:48,360
Not the technology, the strategy.

1416
00:54:48,360 --> 00:54:50,360
Module registries and distribution.

1417
00:54:50,360 --> 00:54:53,680
Distributing modules is the problem that looks simple until you try to scale it.

1418
00:54:53,680 --> 00:54:57,640
When a team writes a By-set module and stores it in their Git repository, distribution is

1419
00:54:57,640 --> 00:54:58,640
straightforward.

1420
00:54:58,640 --> 00:55:00,680
Other teams can access the Git repo.

1421
00:55:00,680 --> 00:55:01,800
They reference the module.

1422
00:55:01,800 --> 00:55:02,800
It works.

1423
00:55:02,800 --> 00:55:06,760
You scale beyond a few teams, Git-based distribution becomes unwieldy.

1424
00:55:06,760 --> 00:55:10,280
Teams don't know what modules exist, where they stored, who maintains them.

1425
00:55:10,280 --> 00:55:11,600
Which version are they using?

1426
00:55:11,600 --> 00:55:13,040
Is there a newer version available?

1427
00:55:13,040 --> 00:55:16,720
The module becomes scattered, duplicated, versions diverge.

1428
00:55:16,720 --> 00:55:20,400
Teams maintain separate copies and diverge from the organizational standard without realizing

1429
00:55:20,400 --> 00:55:21,400
it.

1430
00:55:21,400 --> 00:55:22,400
This is where registries change everything.

1431
00:55:22,400 --> 00:55:26,640
A registry is a central location where modules are published, versioned and discovered.

1432
00:55:26,640 --> 00:55:29,440
Azure Container Registry is the natural choice for By-set modules.

1433
00:55:29,440 --> 00:55:30,440
It's native to Azure.

1434
00:55:30,440 --> 00:55:32,800
It's built for storing and managing artifacts.

1435
00:55:32,800 --> 00:55:36,640
When a platform team finishes building and testing a module, they publish it to the registry

1436
00:55:36,640 --> 00:55:37,640
with a version tag.

1437
00:55:37,640 --> 00:55:38,640
Now it's discoverable.

1438
00:55:38,640 --> 00:55:39,640
Teams can find it.

1439
00:55:39,640 --> 00:55:41,400
They can see all available versions.

1440
00:55:41,400 --> 00:55:44,680
They can pull the specific version they need into their infrastructure code.

1441
00:55:44,680 --> 00:55:47,960
The registry becomes the source of truth for organizational standards.

1442
00:55:47,960 --> 00:55:51,560
When a team wants to know how the organization deploy storage accounts, they don't search

1443
00:55:51,560 --> 00:55:53,000
across repositories.

1444
00:55:53,000 --> 00:55:54,000
They look in the registry.

1445
00:55:54,000 --> 00:55:55,160
The storage module is there.

1446
00:55:55,160 --> 00:55:56,160
It has documentation.

1447
00:55:56,160 --> 00:55:57,360
It has examples.

1448
00:55:57,360 --> 00:56:00,360
It shows the current version and any previous versions.

1449
00:56:00,360 --> 00:56:02,720
They can see the difference between version one and two.

1450
00:56:02,720 --> 00:56:03,880
They understand what changed.

1451
00:56:03,880 --> 00:56:06,720
They decide whether to upgrade or stay on their current version.

1452
00:56:06,720 --> 00:56:09,320
The registry is not just a place to store code.

1453
00:56:09,320 --> 00:56:13,000
It's the place where organizational patterns become visible and discoverable.

1454
00:56:13,000 --> 00:56:15,040
This visibility alone changes adoption.

1455
00:56:15,040 --> 00:56:17,080
Teams use modules not because they're forced to.

1456
00:56:17,080 --> 00:56:20,200
They use them because they can find them and because they are cleaner than building from

1457
00:56:20,200 --> 00:56:21,200
scratch.

1458
00:56:21,200 --> 00:56:24,400
When everything is scattered across repositories, teams don't find the module that already

1459
00:56:24,400 --> 00:56:26,480
exists and they build their own.

1460
00:56:26,480 --> 00:56:29,440
When everything is in the registry, teams find it immediately.

1461
00:56:29,440 --> 00:56:31,960
Search increases, duplication drops.

1462
00:56:31,960 --> 00:56:36,160
Semantic versioning in the registry prevents silent breaking changes from destroying infrastructure.

1463
00:56:36,160 --> 00:56:40,200
When you publish a module to a registry with a version tag, that tag is immutable.

1464
00:56:40,200 --> 00:56:42,200
Version 1.0 never changes.

1465
00:56:42,200 --> 00:56:44,680
If you need to make a change to the module, you increment the version.

1466
00:56:44,680 --> 00:56:47,280
A bug fix becomes version 1.0.1.

1467
00:56:47,280 --> 00:56:49,400
A new parameter becomes version 1.1.

1468
00:56:49,400 --> 00:56:51,600
A breaking change becomes version 2.

1469
00:56:51,600 --> 00:56:56,720
Teams using version 1.0 keep using version 1.0 unless they explicitly choose to upgrade.

1470
00:56:56,720 --> 00:56:58,840
They're not suddenly broken because the module changed.

1471
00:56:58,840 --> 00:57:00,400
The registry enforces this.

1472
00:57:00,400 --> 00:57:01,960
Old versions stay available.

1473
00:57:01,960 --> 00:57:03,480
New versions exist alongside them.

1474
00:57:03,480 --> 00:57:05,560
This matters profoundly for large organizations.

1475
00:57:05,560 --> 00:57:09,240
Imagine 500 deployments across the organization using a storage module.

1476
00:57:09,240 --> 00:57:11,360
The module is upgraded to fix a bug.

1477
00:57:11,360 --> 00:57:14,480
Without version control, every deployment gets the new version.

1478
00:57:14,480 --> 00:57:18,920
If there's an unexpected consequence, you broke 500 things simultaneously.

1479
00:57:18,920 --> 00:57:22,720
With versioned registries, no deployment changes unless the team explicitly upgrades.

1480
00:57:22,720 --> 00:57:23,840
You release the new version.

1481
00:57:23,840 --> 00:57:25,480
You communicate what changed.

1482
00:57:25,480 --> 00:57:27,200
Teams evaluate whether to upgrade.

1483
00:57:27,200 --> 00:57:30,320
Some upgrade immediately, some wait, some never upgrade because they're happy with the

1484
00:57:30,320 --> 00:57:31,320
current version.

1485
00:57:31,320 --> 00:57:33,160
Upgrades are deliberate, not automatic.

1486
00:57:33,160 --> 00:57:34,280
You control your own fate.

1487
00:57:34,280 --> 00:57:38,640
Access controls on the registry ensure governance is enforced at distribution time.

1488
00:57:38,640 --> 00:57:41,400
Not everyone should be able to publish modules to the registry.

1489
00:57:41,400 --> 00:57:44,280
Publishing a module means establishing a standard that other teams will follow.

1490
00:57:44,280 --> 00:57:45,480
This should be controlled.

1491
00:57:45,480 --> 00:57:46,800
You define who can publish.

1492
00:57:46,800 --> 00:57:48,160
Maybe only the platform team.

1493
00:57:48,160 --> 00:57:50,680
Maybe the platform team and approved infrastructure teams.

1494
00:57:50,680 --> 00:57:51,960
Publishing requires code review.

1495
00:57:51,960 --> 00:57:52,960
It requires testing.

1496
00:57:52,960 --> 00:57:54,480
It requires documentation.

1497
00:57:54,480 --> 00:57:55,880
Teams can't just push modules.

1498
00:57:55,880 --> 00:57:58,320
The registry enforces governance at the source.

1499
00:57:58,320 --> 00:58:01,320
Only approved, tested, documented modules get published.

1500
00:58:01,320 --> 00:58:04,040
Teams consuming modules know they're getting something vetted.

1501
00:58:04,040 --> 00:58:07,360
This scales the governance burden horizontally across the organization.

1502
00:58:07,360 --> 00:58:11,520
Instead of vertically on a small group, every team using the module benefits from it.

1503
00:58:11,520 --> 00:58:14,160
If there's an issue, the platform team fixes it once.

1504
00:58:14,160 --> 00:58:15,400
The fix propagates.

1505
00:58:15,400 --> 00:58:19,160
But low quality or non-compliant modules never enter the registry because the gate is

1506
00:58:19,160 --> 00:58:20,960
enforced before publication.

1507
00:58:20,960 --> 00:58:24,800
The registry model scales from dozens of modules to thousands, as the organization grows

1508
00:58:24,800 --> 00:58:25,800
modules accumulate.

1509
00:58:25,800 --> 00:58:29,520
They don't become a chaos problem because they're organized, versioned and governed.

1510
00:58:29,520 --> 00:58:31,640
New teams discover what already exists.

1511
00:58:31,640 --> 00:58:33,480
Adoption accelerates.

1512
00:58:33,480 --> 00:58:36,120
Organizational standards compound and strengthen over time.

1513
00:58:36,120 --> 00:58:38,400
CI/CD integration and automation.

1514
00:58:38,400 --> 00:58:41,280
The magic of platform engineering isn't in the modules themselves.

1515
00:58:41,280 --> 00:58:42,560
It's in how they get deployed.

1516
00:58:42,560 --> 00:58:44,680
A module sitting in a repository is just code.

1517
00:58:44,680 --> 00:58:48,600
A module in a CI/CD pipeline is an organizational standard.

1518
00:58:48,600 --> 00:58:51,720
Think about the workflow for a developer using a golden path module.

1519
00:58:51,720 --> 00:58:53,000
They write the bicep file.

1520
00:58:53,000 --> 00:58:54,400
They reference the registry.

1521
00:58:54,400 --> 00:58:57,880
They plug in the parameters, application name, environment, region.

1522
00:58:57,880 --> 00:58:58,880
Then they push the code.

1523
00:58:58,880 --> 00:59:01,160
At that moment, the pipeline takes over.

1524
00:59:01,160 --> 00:59:03,160
Everything that follows is automated enforcement.

1525
00:59:03,160 --> 00:59:05,720
First, the pipeline validates the syntax.

1526
00:59:05,720 --> 00:59:09,360
It checks if the bicep code is valid and if the module actually exists.

1527
00:59:09,360 --> 00:59:12,040
This happens before a single resource is touched in Azure.

1528
00:59:12,040 --> 00:59:14,640
If there's a syntax error, the pipeline fails immediately.

1529
00:59:14,640 --> 00:59:17,320
The developer sees the error, fixes it and pushes it again.

1530
00:59:17,320 --> 00:59:19,640
It sounds basic, but it's powerful.

1531
00:59:19,640 --> 00:59:21,680
Errors are caught at the desk, not in production.

1532
00:59:21,680 --> 00:59:23,720
Next the pipeline runs security scans.

1533
00:59:23,720 --> 00:59:27,960
The infrastructure code is examined for vulnerabilities, public IPs where they shouldn't be.

1534
00:59:27,960 --> 00:59:30,560
Missing encryption, overly broad access.

1535
00:59:30,560 --> 00:59:32,120
The scans are automatic.

1536
00:59:32,120 --> 00:59:34,280
If an issue is found, the deployment stops.

1537
00:59:34,280 --> 00:59:37,280
The developer sees exactly what's wrong and fixes it right then.

1538
00:59:37,280 --> 00:59:40,680
The pipeline simply doesn't let non-compliant infrastructure through.

1539
00:59:40,680 --> 00:59:42,000
Then come the policy checks.

1540
00:59:42,000 --> 00:59:44,320
The code is validated against Azure policy.

1541
00:59:44,320 --> 00:59:46,280
Does it match the organization requirements?

1542
00:59:46,280 --> 00:59:48,160
Is it using approved resource types?

1543
00:59:48,160 --> 00:59:49,160
Is it in the right region?

1544
00:59:49,160 --> 00:59:50,760
Does it have the required tags?

1545
00:59:50,760 --> 00:59:52,920
The developer doesn't need to be a policy expert.

1546
00:59:52,920 --> 00:59:54,560
The pipeline handles the validation.

1547
00:59:54,560 --> 00:59:56,760
If a violation occurs, the deployment stops.

1548
00:59:56,760 --> 00:59:59,600
The default state is that the pipeline prevents non-compliance.

1549
00:59:59,600 --> 01:00:02,440
This is the structural difference from traditional workflows.

1550
01:00:02,440 --> 01:00:04,720
In the old model, a human reviews the code.

1551
01:00:04,720 --> 01:00:06,360
That review is subjective.

1552
01:00:06,360 --> 01:00:08,240
Different reviewers make different decisions.

1553
01:00:08,240 --> 01:00:09,240
The process is slow.

1554
01:00:09,240 --> 01:00:10,640
You submit, you wait.

1555
01:00:10,640 --> 01:00:11,640
The reviewer reads it.

1556
01:00:11,640 --> 01:00:12,960
They ask for clarification.

1557
01:00:12,960 --> 01:00:13,960
Back and forth.

1558
01:00:13,960 --> 01:00:14,800
A bottleneck.

1559
01:00:14,800 --> 01:00:17,440
In the automated model, the pipeline runs the checks.

1560
01:00:17,440 --> 01:00:19,080
The same checks every time.

1561
01:00:19,080 --> 01:00:20,240
Consistent, fast.

1562
01:00:20,240 --> 01:00:21,960
The developer gets feedback in minutes.

1563
01:00:21,960 --> 01:00:23,360
They know exactly what failed.

1564
01:00:23,360 --> 01:00:25,440
There is no subjective judgment or waiting for an email.

1565
01:00:25,440 --> 01:00:26,440
The policy is code.

1566
01:00:26,440 --> 01:00:27,960
The result is deterministic.

1567
01:00:27,960 --> 01:00:29,720
This shift left approach is profound.

1568
01:00:29,720 --> 01:00:31,320
Compliance happens at build time.

1569
01:00:31,320 --> 01:00:34,480
The developer sees the violation while they are still focused on the change.

1570
01:00:34,480 --> 01:00:37,880
They fix it before the problem ever exists in a real environment.

1571
01:00:37,880 --> 01:00:40,680
Automated testing also protects the modules themselves.

1572
01:00:40,680 --> 01:00:42,640
When a module is updated, the tests run.

1573
01:00:42,640 --> 01:00:43,640
Does it deploy?

1574
01:00:43,640 --> 01:00:45,040
Does it apply the correct policy?

1575
01:00:45,040 --> 01:00:47,240
Do the outputs match the documentation?

1576
01:00:47,240 --> 01:00:49,640
These tests run every time someone changes a module.

1577
01:00:49,640 --> 01:00:51,720
If anything breaks, the change is rejected.

1578
01:00:51,720 --> 01:00:53,400
No-con modules never reach the registry.

1579
01:00:53,400 --> 01:00:54,560
This also prevents drift.

1580
01:00:54,560 --> 01:00:57,280
A module that worked six months ago still works today.

1581
01:00:57,280 --> 01:01:00,000
If an Azure update invalidates a setting, the tests catch it.

1582
01:01:00,000 --> 01:01:02,840
The maintainer knows immediately that an update is required.

1583
01:01:02,840 --> 01:01:05,160
Automation reduces human error to near zero.

1584
01:01:05,160 --> 01:01:06,520
Humans, forget steps.

1585
01:01:06,520 --> 01:01:07,520
Humans make typos.

1586
01:01:07,520 --> 01:01:09,520
Humans take shortcuts when they're tired.

1587
01:01:09,520 --> 01:01:10,520
Pipelines don't.

1588
01:01:10,520 --> 01:01:12,560
They don't skip steps because they're in a hurry.

1589
01:01:12,560 --> 01:01:15,600
They don't apply policy differently on a Friday afternoon.

1590
01:01:15,600 --> 01:01:16,600
Consistency is enforced.

1591
01:01:16,600 --> 01:01:18,200
Reliability goes up.

1592
01:01:18,200 --> 01:01:20,560
This eliminates the approval bottleneck entirely.

1593
01:01:20,560 --> 01:01:23,120
There is no person standing between the developer and the cloud.

1594
01:01:23,120 --> 01:01:24,640
The pipeline is the approver.

1595
01:01:24,640 --> 01:01:26,240
If the check's passed, it deploys.

1596
01:01:26,240 --> 01:01:27,520
If they fail, it doesn't.

1597
01:01:27,520 --> 01:01:28,520
No human needed.

1598
01:01:28,520 --> 01:01:29,520
No queue.

1599
01:01:29,520 --> 01:01:30,760
No waiting.

1600
01:01:30,760 --> 01:01:32,000
The developer submits.

1601
01:01:32,000 --> 01:01:33,000
The pipeline runs.

1602
01:01:33,000 --> 01:01:35,000
And the result appears minutes later.

1603
01:01:35,000 --> 01:01:37,600
That is how you break the ticket-based model with.

1604
01:01:37,600 --> 01:01:40,560
The operational shift from gatekeeper to enabler.

1605
01:01:40,560 --> 01:01:43,240
The biggest change in platform engineering isn't technical.

1606
01:01:43,240 --> 01:01:44,240
It's cultural.

1607
01:01:44,240 --> 01:01:46,480
And that shift happens inside the operations team.

1608
01:01:46,480 --> 01:01:49,120
In the traditional model, the ops team is a protector.

1609
01:01:49,120 --> 01:01:51,000
Their job is to stop bad decisions.

1610
01:01:51,000 --> 01:01:52,080
Developers want to build.

1611
01:01:52,080 --> 01:01:53,560
Ops decides if it's allowed.

1612
01:01:53,560 --> 01:01:54,320
Is it secure?

1613
01:01:54,320 --> 01:01:55,080
Is it compliant?

1614
01:01:55,080 --> 01:01:55,960
Will it break something?

1615
01:01:55,960 --> 01:01:56,960
Ops acts as a gate.

1616
01:01:56,960 --> 01:01:58,040
Approve or deny.

1617
01:01:58,040 --> 01:01:59,200
The mindset is defensive.

1618
01:01:59,200 --> 01:02:02,760
Success is measured by how well you prevented things from going wrong.

1619
01:02:02,760 --> 01:02:05,440
That model made sense when infrastructure was expensive.

1620
01:02:05,440 --> 01:02:09,560
When a server took weeks to arrive and cost thousands of dollars, you needed a gatekeeper.

1621
01:02:09,560 --> 01:02:12,040
You couldn't have developers spinning up hardware carelessly.

1622
01:02:12,040 --> 01:02:13,160
The gate prevented waste.

1623
01:02:13,160 --> 01:02:14,520
But that context is gone.

1624
01:02:14,520 --> 01:02:16,360
Infrastructure is now cheap and fast.

1625
01:02:16,360 --> 01:02:18,960
A developer can build an entire environment in minutes.

1626
01:02:18,960 --> 01:02:21,520
The old gatekeeping doesn't protect against waste anymore.

1627
01:02:21,520 --> 01:02:22,880
It just creates friction.

1628
01:02:22,880 --> 01:02:24,760
The developer still needs the resources.

1629
01:02:24,760 --> 01:02:26,160
Ops still says yes or no.

1630
01:02:26,160 --> 01:02:28,600
Nothing has changed except the level of frustration.

1631
01:02:28,600 --> 01:02:30,560
Platform engineering inverts this role.

1632
01:02:30,560 --> 01:02:33,480
Instead of approving requests, ops builds products.

1633
01:02:33,480 --> 01:02:36,600
Instead of saying no, ops says yes automatically

1634
01:02:36,600 --> 01:02:38,720
by encoding decisions into the platform.

1635
01:02:38,720 --> 01:02:42,160
Instead of reviewing deployments, ops build systems that enforce standards.

1636
01:02:42,160 --> 01:02:44,360
This requires a completely different skill set.

1637
01:02:44,360 --> 01:02:47,160
A traditional ops person is good at policy and risk evaluation.

1638
01:02:47,160 --> 01:02:49,440
Platform engineer is good at product design.

1639
01:02:49,440 --> 01:02:50,800
They understand what developers need.

1640
01:02:50,800 --> 01:02:52,480
They build tools that solve problems.

1641
01:02:52,480 --> 01:02:54,240
They make the right way, the easy way.

1642
01:02:54,240 --> 01:02:55,560
It's a different way of thinking.

1643
01:02:55,560 --> 01:02:57,280
Gatekeepers think about control.

1644
01:02:57,280 --> 01:02:58,840
Platform engineers think about enablement.

1645
01:02:58,840 --> 01:03:00,680
This shift is harder than it sounds.

1646
01:03:00,680 --> 01:03:02,840
Many teams have spent decades as gatekeepers.

1647
01:03:02,840 --> 01:03:03,840
It's what they know.

1648
01:03:03,840 --> 01:03:05,080
It's how they feel competent.

1649
01:03:05,080 --> 01:03:07,600
Switching to enablement can feel like a loss of authority.

1650
01:03:07,600 --> 01:03:09,840
It can feel like the organization doesn't trust them.

1651
01:03:09,840 --> 01:03:10,960
But it's actually the opposite.

1652
01:03:10,960 --> 01:03:13,400
The organization is asking them to solve a much harder problem.

1653
01:03:13,400 --> 01:03:14,960
Not is this deployment okay or?

1654
01:03:14,960 --> 01:03:17,920
How do we build a system where a bad deployment is impossible?

1655
01:03:17,920 --> 01:03:19,520
The metrics change to reflect this.

1656
01:03:19,520 --> 01:03:21,800
In the old model, success was tickets closed.

1657
01:03:21,800 --> 01:03:23,240
How many requests did we process?

1658
01:03:23,240 --> 01:03:24,960
How many approvals did we give?

1659
01:03:24,960 --> 01:03:27,080
In the platform model, success is adoption.

1660
01:03:27,080 --> 01:03:28,520
Do developers use the platform?

1661
01:03:28,520 --> 01:03:29,360
Do they like it?

1662
01:03:29,360 --> 01:03:30,720
Does it actually solve their problems?

1663
01:03:30,720 --> 01:03:31,600
It's harder to measure.

1664
01:03:31,600 --> 01:03:34,800
It's easier to count tickets than it is to measure satisfaction.

1665
01:03:34,800 --> 01:03:35,880
But it's more meaningful.

1666
01:03:35,880 --> 01:03:37,480
A team that closes a thousand tickets

1667
01:03:37,480 --> 01:03:39,840
but leaves developers frustrated is failing.

1668
01:03:39,840 --> 01:03:42,800
A team that enables self-service and delivers value is succeeding.

1669
01:03:42,800 --> 01:03:44,240
The role becomes strategic.

1670
01:03:44,240 --> 01:03:47,160
Instead of reacting to tickets, the team anticipates needs.

1671
01:03:47,160 --> 01:03:48,600
They study how developers work.

1672
01:03:48,600 --> 01:03:50,160
They identify pain points.

1673
01:03:50,160 --> 01:03:51,520
They iterate based on feedback.

1674
01:03:51,520 --> 01:03:53,240
It's product work. It's proactive.

1675
01:03:53,240 --> 01:03:55,000
This also changes career paths.

1676
01:03:55,000 --> 01:03:56,400
In the old world, you became senior

1677
01:03:56,400 --> 01:03:58,320
by having better judgment on approvals.

1678
01:03:58,320 --> 01:04:00,040
In the new world, you become senior

1679
01:04:00,040 --> 01:04:02,240
by building products that more teams adopt.

1680
01:04:02,240 --> 01:04:05,040
Scenority comes from enabling work, not controlling it.

1681
01:04:05,040 --> 01:04:06,520
The results are profound.

1682
01:04:06,520 --> 01:04:09,120
Ops teams that make this shift become more engaged.

1683
01:04:09,120 --> 01:04:10,640
They are solving interesting problems

1684
01:04:10,640 --> 01:04:12,280
instead of being a human firewall.

1685
01:04:12,280 --> 01:04:14,080
They are building instead of preventing.

1686
01:04:14,080 --> 01:04:15,920
Even though the ops team has less control,

1687
01:04:15,920 --> 01:04:17,240
they become more valuable.

1688
01:04:17,240 --> 01:04:19,080
Because now, they are the engine

1689
01:04:19,080 --> 01:04:22,040
that allows the entire company to move faster.

1690
01:04:22,040 --> 01:04:23,720
Measuring platform ROI.

1691
01:04:23,720 --> 01:04:25,880
Measuring the success of a platform is difficult

1692
01:04:25,880 --> 01:04:28,360
because no single metric tells the whole story.

1693
01:04:28,360 --> 01:04:30,200
You need multiple angles.

1694
01:04:30,200 --> 01:04:31,840
Each one reveals something different.

1695
01:04:31,840 --> 01:04:33,360
And together, they create a picture

1696
01:04:33,360 --> 01:04:35,640
that executives actually understand and fund.

1697
01:04:35,640 --> 01:04:37,360
Start with door metrics.

1698
01:04:37,360 --> 01:04:39,480
These are the most concrete numbers you have.

1699
01:04:39,480 --> 01:04:40,720
You look at deployment frequency

1700
01:04:40,720 --> 01:04:42,600
to see how often you release to production

1701
01:04:42,600 --> 01:04:44,120
and you track lead time for changes

1702
01:04:44,120 --> 01:04:47,040
to measure the gap between a code commit and going live.

1703
01:04:47,040 --> 01:04:48,560
Then you monitor the change failure rate

1704
01:04:48,560 --> 01:04:51,080
to see what percentage of deployments cause incidents,

1705
01:04:51,080 --> 01:04:52,520
alongside the mean time to recovery

1706
01:04:52,520 --> 01:04:54,920
to see how fast you fix problems when they happen.

1707
01:04:54,920 --> 01:04:57,040
These are operational metrics that show how fast

1708
01:04:57,040 --> 01:04:59,240
and safely your organization ships software.

1709
01:04:59,240 --> 01:05:00,400
When you implement a platform,

1710
01:05:00,400 --> 01:05:01,880
these numbers typically improve.

1711
01:05:01,880 --> 01:05:04,040
Deployment frequency usually increases

1712
01:05:04,040 --> 01:05:06,600
while lead time drops because golden paths eliminate

1713
01:05:06,600 --> 01:05:08,760
the friction that used to slow your teams down.

1714
01:05:08,760 --> 01:05:11,760
The pipeline automates what used to require manual approval

1715
01:05:11,760 --> 01:05:13,960
and that shift shows up immediately in the data.

1716
01:05:13,960 --> 01:05:15,560
But door metrics alone are incomplete.

1717
01:05:15,560 --> 01:05:16,880
You can improve deployment frequency

1718
01:05:16,880 --> 01:05:19,560
by shipping small, low risk changes constantly,

1719
01:05:19,560 --> 01:05:20,600
which is a good thing.

1720
01:05:20,600 --> 01:05:22,000
But if your developers are miserable

1721
01:05:22,000 --> 01:05:23,880
and the organization is burning out engineers

1722
01:05:23,880 --> 01:05:26,360
to achieve that speed, you haven't actually solved anything.

1723
01:05:26,360 --> 01:05:29,040
The platform has just created the wrong kind of velocity.

1724
01:05:29,040 --> 01:05:30,840
This is why you need satisfaction metrics

1725
01:05:30,840 --> 01:05:32,040
alongside delivery metrics.

1726
01:05:32,040 --> 01:05:33,560
Developer satisfaction tells you

1727
01:05:33,560 --> 01:05:36,160
whether people actually value what you built.

1728
01:05:36,160 --> 01:05:37,960
A net promoter score for the platform

1729
01:05:37,960 --> 01:05:41,040
is a simple question that captures adoption intent.

1730
01:05:41,040 --> 01:05:43,320
When developers love the platform, the NPS is high.

1731
01:05:43,320 --> 01:05:45,160
When they resent it or see it as bureaucracy,

1732
01:05:45,160 --> 01:05:46,000
the NPS is low.

1733
01:05:46,000 --> 01:05:48,840
A high score tells you the platform is solving real problems.

1734
01:05:48,840 --> 01:05:51,560
While a low score tells you the platform is just friction,

1735
01:05:51,560 --> 01:05:53,840
regardless of what the deployment metrics say.

1736
01:05:53,840 --> 01:05:55,440
Adoption rate completes this picture.

1737
01:05:55,440 --> 01:05:57,800
Our developers actually choosing to use the platform.

1738
01:05:57,800 --> 01:05:59,720
You need to know what percentage of new services

1739
01:05:59,720 --> 01:06:01,280
are deployed through the golden paths

1740
01:06:01,280 --> 01:06:03,840
and how many teams use the self-service capabilities.

1741
01:06:03,840 --> 01:06:06,360
Adoption shows whether developers believe the platform

1742
01:06:06,360 --> 01:06:08,360
is worth using, you can't force adoption.

1743
01:06:08,360 --> 01:06:09,480
You can mandate it.

1744
01:06:09,480 --> 01:06:11,680
But developers will always find workarounds.

1745
01:06:11,680 --> 01:06:13,240
When adoption is high and voluntary,

1746
01:06:13,240 --> 01:06:15,760
it means the platform is genuinely valuable.

1747
01:06:15,760 --> 01:06:18,680
Time to first deployment measures a specific friction point.

1748
01:06:18,680 --> 01:06:20,800
How long does it take for when a new engineer starts

1749
01:06:20,800 --> 01:06:22,960
until they ship their first production change?

1750
01:06:22,960 --> 01:06:26,120
In organizations without a platform, this often takes weeks.

1751
01:06:26,120 --> 01:06:27,920
With a platform and solid golden paths,

1752
01:06:27,920 --> 01:06:30,400
it compresses to days or even hours.

1753
01:06:30,400 --> 01:06:32,800
This metric directly translates to onboarding cost

1754
01:06:32,800 --> 01:06:34,480
and time to productivity.

1755
01:06:34,480 --> 01:06:38,000
Short time to first deployment means new hires are valuable sooner

1756
01:06:38,000 --> 01:06:40,440
and it serves as a concrete proxy for whether the platform

1757
01:06:40,440 --> 01:06:42,920
is actually reducing cognitive load.

1758
01:06:42,920 --> 01:06:45,600
Cost avoidance metrics quantify the financial impact.

1759
01:06:45,600 --> 01:06:47,280
Fewer incidents mean less firefighting

1760
01:06:47,280 --> 01:06:48,760
and less lost productivity.

1761
01:06:48,760 --> 01:06:50,920
Fewer support tickets mean the platform team spends

1762
01:06:50,920 --> 01:06:52,960
less time answering routine questions.

1763
01:06:52,960 --> 01:06:55,080
Less manual infrastructure setup means

1764
01:06:55,080 --> 01:06:58,280
ops teams focus on innovation instead of repetitive provisioning.

1765
01:06:58,280 --> 01:06:59,560
These savings are real.

1766
01:06:59,560 --> 01:07:02,160
They are hard to measure precisely, but they are substantial.

1767
01:07:02,160 --> 01:07:04,760
An organization that previously spent 50 hours a week

1768
01:07:04,760 --> 01:07:06,520
on manual infrastructure setup

1769
01:07:06,520 --> 01:07:10,400
and now spends five hours is avoiding 45 hours of waste.

1770
01:07:10,400 --> 01:07:12,160
If you multiply that by labor cost,

1771
01:07:12,160 --> 01:07:13,880
you have a real financial saving.

1772
01:07:13,880 --> 01:07:15,800
The power emerges when you combine these metrics

1773
01:07:15,800 --> 01:07:17,240
into a single narrative.

1774
01:07:17,240 --> 01:07:20,240
Tell executives that deployment frequency increased 40%

1775
01:07:20,240 --> 01:07:23,040
while lead time dropped from three days to eight hours.

1776
01:07:23,040 --> 01:07:24,640
Developers satisfaction with the platform

1777
01:07:24,640 --> 01:07:27,960
improved from 40 out of 180.

1778
01:07:27,960 --> 01:07:30,960
90% of new services use the golden paths.

1779
01:07:30,960 --> 01:07:33,720
Time to first deployment dropped from four weeks to three days.

1780
01:07:33,720 --> 01:07:35,960
Support requests decreased by 60%

1781
01:07:35,960 --> 01:07:37,640
and incidents involving infrastructure

1782
01:07:37,640 --> 01:07:39,920
misconfiguration dropped by 70%.

1783
01:07:39,920 --> 01:07:41,080
That is a complete story.

1784
01:07:41,080 --> 01:07:42,920
Speed improved, quality improved.

1785
01:07:42,920 --> 01:07:44,960
People are happy, adoption is high.

1786
01:07:44,960 --> 01:07:46,600
Developers are choosing this approach

1787
01:07:46,600 --> 01:07:48,440
and the organization is saving money.

1788
01:07:48,440 --> 01:07:50,320
This is how you justify continued investment.

1789
01:07:50,320 --> 01:07:52,200
Not because the technology is elegant,

1790
01:07:52,200 --> 01:07:54,400
but because the organization is measurably better

1791
01:07:54,400 --> 01:07:55,800
as a result of the platform.

1792
01:07:55,800 --> 01:07:57,760
The metrics must be tracked continuously.

1793
01:07:57,760 --> 01:07:59,000
This isn't a one-time assessment.

1794
01:07:59,000 --> 01:08:00,840
Every quarter you should publish the numbers

1795
01:08:00,840 --> 01:08:02,000
and show the trends.

1796
01:08:02,000 --> 01:08:03,480
Did adoption increase this quarter?

1797
01:08:03,480 --> 01:08:05,000
Did satisfaction improve?

1798
01:08:05,000 --> 01:08:06,960
Did lead time continue to decline?

1799
01:08:06,960 --> 01:08:08,280
Transparency builds confidence

1800
01:08:08,280 --> 01:08:10,160
that the platform is delivering value.

1801
01:08:10,160 --> 01:08:11,640
It also guides the platform team.

1802
01:08:11,640 --> 01:08:13,440
If adoption's stalled, that is a signal.

1803
01:08:13,440 --> 01:08:15,840
If satisfaction dropped, something needs fixing.

1804
01:08:15,840 --> 01:08:17,680
The metrics are feedback.

1805
01:08:17,680 --> 01:08:19,840
They tell you whether you are building the right things.

1806
01:08:19,840 --> 01:08:21,680
Executives understand this language,

1807
01:08:21,680 --> 01:08:23,160
not door or metrics alone

1808
01:08:23,160 --> 01:08:25,200
and not satisfaction surveys alone.

1809
01:08:25,200 --> 01:08:27,120
The combination speed and people and adoption

1810
01:08:27,120 --> 01:08:28,560
and cost avoidance together.

1811
01:08:28,560 --> 01:08:30,840
That is how you prove platform ROI.

1812
01:08:30,840 --> 01:08:32,680
Overcoming common adoption barriers.

1813
01:08:32,680 --> 01:08:34,200
Platform initiatives fail more often

1814
01:08:34,200 --> 01:08:35,720
from execution than from concept.

1815
01:08:35,720 --> 01:08:37,160
The problems aren't technical.

1816
01:08:37,160 --> 01:08:39,440
They are structural and they are predictable.

1817
01:08:39,440 --> 01:08:41,440
The first failure mode is over-engineering

1818
01:08:41,440 --> 01:08:43,200
before you know what developers need.

1819
01:08:43,200 --> 01:08:45,120
Platform teams get excited.

1820
01:08:45,120 --> 01:08:47,560
They build full solutions and design intricate governance

1821
01:08:47,560 --> 01:08:48,400
systems.

1822
01:08:48,400 --> 01:08:49,960
They create elaborate permission models

1823
01:08:49,960 --> 01:08:51,720
and build portals with hundreds of features.

1824
01:08:51,720 --> 01:08:53,920
They release the platform and wait for adoption,

1825
01:08:53,920 --> 01:08:54,640
but it doesn't come.

1826
01:08:54,640 --> 01:08:56,160
The platform is too complex.

1827
01:08:56,160 --> 01:08:58,200
Too many features confuse instead of clarify.

1828
01:08:58,200 --> 01:09:00,360
Too many options paralyze instead of enable.

1829
01:09:00,360 --> 01:09:01,840
Developers don't know where to start.

1830
01:09:01,840 --> 01:09:03,480
They go back to doing things manually

1831
01:09:03,480 --> 01:09:06,120
because manual is simpler than understanding the platform.

1832
01:09:06,120 --> 01:09:07,760
This happens because platform teams

1833
01:09:07,760 --> 01:09:09,280
engineer in isolation.

1834
01:09:09,280 --> 01:09:11,160
They don't talk to developers before building.

1835
01:09:11,160 --> 01:09:12,640
They don't watch how developers work.

1836
01:09:12,640 --> 01:09:14,400
They don't iterate based on feedback.

1837
01:09:14,400 --> 01:09:16,400
They design what they think developers need.

1838
01:09:16,400 --> 01:09:18,600
And then they are surprised when developers don't want it.

1839
01:09:18,600 --> 01:09:20,120
The fix is to start small.

1840
01:09:20,120 --> 01:09:21,720
Build the minimum viable platform

1841
01:09:21,720 --> 01:09:24,320
that solves one real problem, one golden path,

1842
01:09:24,320 --> 01:09:26,480
one template, one service.

1843
01:09:26,480 --> 01:09:28,920
Get it in front of developers and watch how they use it.

1844
01:09:28,920 --> 01:09:30,280
Talk to them about friction.

1845
01:09:30,280 --> 01:09:31,920
Does it solve the problem you intended?

1846
01:09:31,920 --> 01:09:33,440
Is it easier than the alternative?

1847
01:09:33,440 --> 01:09:34,560
What would make it better?

1848
01:09:34,560 --> 01:09:35,760
Then iterate.

1849
01:09:35,760 --> 01:09:37,840
Build the second template based on what you learned.

1850
01:09:37,840 --> 01:09:39,560
Keep the scope bounded until you understand

1851
01:09:39,560 --> 01:09:41,680
what developers actually value.

1852
01:09:41,680 --> 01:09:44,040
The second failure mode is treating the platform

1853
01:09:44,040 --> 01:09:46,480
as infrastructure instead of as a product.

1854
01:09:46,480 --> 01:09:49,000
This manifests as platform teams building systems,

1855
01:09:49,000 --> 01:09:50,800
but not caring whether people use them.

1856
01:09:50,800 --> 01:09:53,520
They focus on technical excellence, clean architecture,

1857
01:09:53,520 --> 01:09:55,440
proper separation of concerns.

1858
01:09:55,440 --> 01:09:58,200
The platform is technically elegant, but nobody adopts it.

1859
01:09:58,200 --> 01:10:01,080
The team measures success by whether the infrastructure works

1860
01:10:01,080 --> 01:10:03,160
not by whether developers choose to use it.

1861
01:10:03,160 --> 01:10:05,440
This is engineering focus instead of product focus.

1862
01:10:05,440 --> 01:10:07,440
A product mindset starts with the user.

1863
01:10:07,440 --> 01:10:08,600
What problem are you solving?

1864
01:10:08,600 --> 01:10:09,760
For whom?

1865
01:10:09,760 --> 01:10:11,280
How will you know if you solved it?

1866
01:10:11,280 --> 01:10:13,520
Success is measured by adoption and satisfaction,

1867
01:10:13,520 --> 01:10:15,000
not by technical purity.

1868
01:10:15,000 --> 01:10:16,000
You make trade-offs.

1869
01:10:16,000 --> 01:10:19,040
Sometimes you accept architectural compromise

1870
01:10:19,040 --> 01:10:20,560
to reduce cognitive load.

1871
01:10:20,560 --> 01:10:23,120
You prioritize ease of use over elegant design.

1872
01:10:23,120 --> 01:10:25,320
You measure what matters to your customers, the developers,

1873
01:10:25,320 --> 01:10:27,080
not what is technically interesting.

1874
01:10:27,080 --> 01:10:30,040
The third failure mode is forcing adoption instead of earning it.

1875
01:10:30,040 --> 01:10:32,800
Some organizations mandate that developers use the platform.

1876
01:10:32,800 --> 01:10:34,600
New projects must use the golden paths

1877
01:10:34,600 --> 01:10:36,680
and teams can't deviate without approval.

1878
01:10:36,680 --> 01:10:38,200
This creates resentment.

1879
01:10:38,200 --> 01:10:40,360
The platform becomes something developers resent.

1880
01:10:40,360 --> 01:10:43,280
Instead of something they appreciate, they find workarounds.

1881
01:10:43,280 --> 01:10:44,800
They complain.

1882
01:10:44,800 --> 01:10:47,440
Adoption numbers look high because it is mandated,

1883
01:10:47,440 --> 01:10:49,680
but actual usage is low and grudging.

1884
01:10:49,680 --> 01:10:52,560
Adoption you earn is better than adoption you force.

1885
01:10:52,560 --> 01:10:54,200
When developers choose to use the platform

1886
01:10:54,200 --> 01:10:56,520
because it is genuinely easier than the alternative,

1887
01:10:56,520 --> 01:10:58,680
adoption is voluntary and sustainable.

1888
01:10:58,680 --> 01:11:01,800
This requires that the platform actually deliver value.

1889
01:11:01,800 --> 01:11:03,520
It requires that it solve real problems.

1890
01:11:03,520 --> 01:11:06,160
It requires that using it be easier than working around it.

1891
01:11:06,160 --> 01:11:09,120
If the platform is so good that developers choose it willingly,

1892
01:11:09,120 --> 01:11:10,440
you have a winning product.

1893
01:11:10,440 --> 01:11:12,160
If you need to force it, you have a problem

1894
01:11:12,160 --> 01:11:14,120
that mandates won't solve.

1895
01:11:14,120 --> 01:11:16,720
The fourth failure mode is ignoring developer feedback.

1896
01:11:16,720 --> 01:11:18,040
Platform teams release something

1897
01:11:18,040 --> 01:11:19,960
and don't listen to what developers say.

1898
01:11:19,960 --> 01:11:21,560
The friction points they mention.

1899
01:11:21,560 --> 01:11:24,320
The features they request, the alternatives they prefer.

1900
01:11:24,320 --> 01:11:26,360
Ignoring this feedback means you miss the signals

1901
01:11:26,360 --> 01:11:28,560
that the platform isn't solving the right problems.

1902
01:11:28,560 --> 01:11:30,800
Development teams quietly build alternatives.

1903
01:11:30,800 --> 01:11:32,000
They work around the platform.

1904
01:11:32,000 --> 01:11:35,120
They don't complain because complaining didn't help last time.

1905
01:11:35,120 --> 01:11:37,080
The platform becomes quietly irrelevant.

1906
01:11:37,080 --> 01:11:40,360
The fixes systematic feedback loops, surveys, interviews,

1907
01:11:40,360 --> 01:11:43,120
watching how developers work, building channels for input

1908
01:11:43,120 --> 01:11:45,160
and most importantly, acting on it.

1909
01:11:45,160 --> 01:11:47,600
If developers say something is confusing, fix it.

1910
01:11:47,600 --> 01:11:50,080
If they request a feature, evaluate whether to build it.

1911
01:11:50,080 --> 01:11:52,240
If they are finding workarounds, understand why

1912
01:11:52,240 --> 01:11:53,360
and address the gap.

1913
01:11:53,360 --> 01:11:55,920
Feedback should visibly influence platform direction.

1914
01:11:55,920 --> 01:11:57,720
When developers see that their feedback matters,

1915
01:11:57,720 --> 01:11:59,480
they engage with the platform team.

1916
01:11:59,480 --> 01:12:01,160
They invest in the process.

1917
01:12:01,160 --> 01:12:03,480
The fifth failure mode is ambiguous ownership.

1918
01:12:03,480 --> 01:12:05,360
When everyone is responsible for the platform,

1919
01:12:05,360 --> 01:12:07,160
it means nobody is responsible.

1920
01:12:07,160 --> 01:12:08,800
Decisions don't get made.

1921
01:12:08,800 --> 01:12:10,480
Feedback doesn't get processed.

1922
01:12:10,480 --> 01:12:12,080
Roadmaps don't get published.

1923
01:12:12,080 --> 01:12:13,760
The platform stagnates.

1924
01:12:13,760 --> 01:12:15,680
Clear ownership means a product manager

1925
01:12:15,680 --> 01:12:18,680
or a platform leader takes responsibility for success.

1926
01:12:18,680 --> 01:12:19,840
They own the roadmap.

1927
01:12:19,840 --> 01:12:21,280
They are accountable for adoption.

1928
01:12:21,280 --> 01:12:22,520
They measure outcomes.

1929
01:12:22,520 --> 01:12:23,960
They drive iteration.

1930
01:12:23,960 --> 01:12:25,800
Success requires product discipline

1931
01:12:25,800 --> 01:12:27,440
applied to an internal platform.

1932
01:12:27,440 --> 01:12:29,640
Not engineering discipline, product discipline,

1933
01:12:29,640 --> 01:12:32,640
built for users, measure adoption, listen to feedback,

1934
01:12:32,640 --> 01:12:34,160
iterate based on outcomes.

1935
01:12:34,160 --> 01:12:36,240
This is how platforms actually work at scale.

1936
01:12:36,240 --> 01:12:38,320
The strategic shift in operating model,

1937
01:12:38,320 --> 01:12:40,120
platform engineering isn't a tool change,

1938
01:12:40,120 --> 01:12:42,600
it isn't a debate about bicep versus terraform.

1939
01:12:42,600 --> 01:12:45,680
Or whether you should pick GitHub actions over Azure DevOps.

1940
01:12:45,680 --> 01:12:47,040
Those are tactical choices.

1941
01:12:47,040 --> 01:12:48,320
They come later.

1942
01:12:48,320 --> 01:12:49,760
The real shift is organizational.

1943
01:12:49,760 --> 01:12:52,120
It's about how your company actually makes decisions.

1944
01:12:52,120 --> 01:12:54,240
Who builds the systems, who maintains them,

1945
01:12:54,240 --> 01:12:56,560
who owns the responsibility and one level deeper.

1946
01:12:56,560 --> 01:12:59,960
It's about how you measure success and how careers advance.

1947
01:12:59,960 --> 01:13:02,800
This shift creates roles that simply didn't exist before.

1948
01:13:02,800 --> 01:13:05,320
Platform engineers are not just traditional infrastructure

1949
01:13:05,320 --> 01:13:06,600
engineers with a new title.

1950
01:13:06,600 --> 01:13:08,720
Infrastructure engineers manage systems.

1951
01:13:08,720 --> 01:13:09,600
They keep the lights on.

1952
01:13:09,600 --> 01:13:10,800
They react to failures.

1953
01:13:10,800 --> 01:13:12,680
Platform engineers design products.

1954
01:13:12,680 --> 01:13:14,320
They study how developers work.

1955
01:13:14,320 --> 01:13:15,520
They anticipate what's coming.

1956
01:13:15,520 --> 01:13:17,440
They build solutions and measure adoption.

1957
01:13:17,440 --> 01:13:19,000
It's the difference between operations

1958
01:13:19,000 --> 01:13:20,200
and product development.

1959
01:13:20,200 --> 01:13:22,960
Both are necessary, but the mindset is completely different.

1960
01:13:22,960 --> 01:13:25,640
We're also seeing product managers enter the engineering org

1961
01:13:25,640 --> 01:13:27,280
in a brand new context.

1962
01:13:27,280 --> 01:13:29,240
They aren't managing customer-facing apps.

1963
01:13:29,240 --> 01:13:30,760
They're managing the internal platform.

1964
01:13:30,760 --> 01:13:31,840
They own the roadmap.

1965
01:13:31,840 --> 01:13:34,680
They talk to developers to find out what actually matters.

1966
01:13:34,680 --> 01:13:35,800
And they make the hard trade-offs

1967
01:13:35,800 --> 01:13:37,880
between technical purity and ease of use.

1968
01:13:37,880 --> 01:13:39,360
They're accountable for adoption.

1969
01:13:39,360 --> 01:13:41,160
They're accountable for satisfaction.

1970
01:13:41,160 --> 01:13:43,320
They drive the organization to treat the platform

1971
01:13:43,320 --> 01:13:45,800
as a product, not just a pile of infrastructure.

1972
01:13:45,800 --> 01:13:47,200
Then you have developer advocates.

1973
01:13:47,200 --> 01:13:48,720
Their job is to find the friction.

1974
01:13:48,720 --> 01:13:51,680
They identify the gap between what the platform provides

1975
01:13:51,680 --> 01:13:54,200
and what the developers actually need to get their work done.

1976
01:13:54,200 --> 01:13:56,200
They evangelize, they gather feedback.

1977
01:13:56,200 --> 01:13:58,080
They help teams move to new capabilities.

1978
01:13:58,080 --> 01:13:59,160
They sit right in the middle.

1979
01:13:59,160 --> 01:14:00,480
They speak both languages.

1980
01:14:00,480 --> 01:14:02,640
These roles require different hiring criteria

1981
01:14:02,640 --> 01:14:04,080
and different performance metrics.

1982
01:14:04,080 --> 01:14:06,280
You aren't just looking for engineers who conscript

1983
01:14:06,280 --> 01:14:08,240
that you're looking for product people.

1984
01:14:08,240 --> 01:14:10,400
You're looking for people who care about adoption

1985
01:14:10,400 --> 01:14:11,520
and user happiness.

1986
01:14:11,520 --> 01:14:12,880
And you're building a product organization

1987
01:14:12,880 --> 01:14:14,560
inside your infrastructure function.

1988
01:14:14,560 --> 01:14:16,840
The metrics that matter change fundamentally.

1989
01:14:16,840 --> 01:14:18,960
Traditional infrastructure is about uptime.

1990
01:14:18,960 --> 01:14:19,800
Availability.

1991
01:14:19,800 --> 01:14:21,560
And how fast you respond to an incident.

1992
01:14:21,560 --> 01:14:22,480
Those still matter.

1993
01:14:22,480 --> 01:14:24,160
The platform has to be reliable.

1994
01:14:24,160 --> 01:14:25,840
But reliability is just table stakes.

1995
01:14:25,840 --> 01:14:26,680
It isn't the goal.

1996
01:14:26,680 --> 01:14:27,600
The goal is adoption.

1997
01:14:27,600 --> 01:14:29,200
How many teams are using the platform?

1998
01:14:29,200 --> 01:14:31,600
How many new services are moving through the golden paths?

1999
01:14:31,600 --> 01:14:33,280
How satisfied are your developers?

2000
01:14:33,280 --> 01:14:34,440
Those are product metrics.

2001
01:14:34,440 --> 01:14:36,680
Budget models shift to in the old model.

2002
01:14:36,680 --> 01:14:38,040
You have a fixed-ops budget.

2003
01:14:38,040 --> 01:14:40,280
You hire a set number of people to handle the load.

2004
01:14:40,280 --> 01:14:42,600
And if the load goes up, you hire more people.

2005
01:14:42,600 --> 01:14:45,320
In platform engineering, you invest upfront.

2006
01:14:45,320 --> 01:14:46,960
You spend the money to build golden paths

2007
01:14:46,960 --> 01:14:48,080
and self-service tools.

2008
01:14:48,080 --> 01:14:49,600
That investment is supposed to drive down

2009
01:14:49,600 --> 01:14:51,280
the cost of every future project.

2010
01:14:51,280 --> 01:14:52,600
You measure the ROI.

2011
01:14:52,600 --> 01:14:54,200
Did this work reduce the manual toil?

2012
01:14:54,200 --> 01:14:56,320
Did it free up the ops team to actually innovate?

2013
01:14:56,320 --> 01:14:58,480
The organizational structure flattens out.

2014
01:14:58,480 --> 01:15:00,560
Traditional models are rigid hierarchies,

2015
01:15:00,560 --> 01:15:02,640
with approvers and requesters, policymakers,

2016
01:15:02,640 --> 01:15:04,600
and rule followers in the platform model.

2017
01:15:04,600 --> 01:15:05,640
That distinction collapses.

2018
01:15:05,640 --> 01:15:07,120
Developers don't ask for infrastructure.

2019
01:15:07,120 --> 01:15:08,200
They self-serve.

2020
01:15:08,200 --> 01:15:09,560
Ops doesn't approve or deny.

2021
01:15:09,560 --> 01:15:12,200
They build the system that makes the approval automatic.

2022
01:15:12,200 --> 01:15:14,640
The interaction shifts from vertical to lateral.

2023
01:15:14,640 --> 01:15:16,760
The culture becomes one of continuous learning.

2024
01:15:16,760 --> 01:15:18,520
The platform is never done.

2025
01:15:18,520 --> 01:15:21,360
It needs to iterate based on what developers are actually doing.

2026
01:15:21,360 --> 01:15:24,480
This requires a culture where people experiment, get feedback,

2027
01:15:24,480 --> 01:15:25,440
and improve.

2028
01:15:25,440 --> 01:15:26,680
Failure is just learning.

2029
01:15:26,680 --> 01:15:27,520
You ship something.

2030
01:15:27,520 --> 01:15:28,600
You see what works.

2031
01:15:28,600 --> 01:15:29,760
You listen to what doesn't.

2032
01:15:29,760 --> 01:15:30,840
And then you fix it.

2033
01:15:30,840 --> 01:15:32,800
Career progression changes too.

2034
01:15:32,800 --> 01:15:35,280
In traditional ops, you move up by being the person

2035
01:15:35,280 --> 01:15:36,560
who makes the big decisions.

2036
01:15:36,560 --> 01:15:39,080
In platform engineering, you move up by enabling more work

2037
01:15:39,080 --> 01:15:41,120
by building things that teams choose to use,

2038
01:15:41,120 --> 01:15:42,520
by driving adoption.

2039
01:15:42,520 --> 01:15:45,240
Your value comes from multiplying what everyone else can do,

2040
01:15:45,240 --> 01:15:46,880
not from controlling what they do.

2041
01:15:46,880 --> 01:15:48,480
From bottleneck to enablement,

2042
01:15:48,480 --> 01:15:50,360
the old operating model moved the bottleneck

2043
01:15:50,360 --> 01:15:51,760
without ever actually fixing it.

2044
01:15:51,760 --> 01:15:53,320
You just change to was waiting.

2045
01:15:53,320 --> 01:15:55,360
The structural problem was always the same.

2046
01:15:55,360 --> 01:15:58,600
Infrastructure decisions required a human to say yes.

2047
01:15:58,600 --> 01:16:00,360
And whenever you need a human to say yes,

2048
01:16:00,360 --> 01:16:02,000
queues form, waiting increases.

2049
01:16:02,000 --> 01:16:04,240
Platform engineering eliminates that bottleneck,

2050
01:16:04,240 --> 01:16:06,000
not by hiring more people to say yes,

2051
01:16:06,000 --> 01:16:07,720
but by automating the yes itself,

2052
01:16:07,720 --> 01:16:09,880
by encoding those decisions into templates,

2053
01:16:09,880 --> 01:16:11,800
by making governance a part of the deployment,

2054
01:16:11,800 --> 01:16:13,080
not something you check afterward.

2055
01:16:13,080 --> 01:16:14,920
Golden paths, built with bicep modules,

2056
01:16:14,920 --> 01:16:16,360
make this possible at scale,

2057
01:16:16,360 --> 01:16:19,640
developers follow them because it's easier than doing it themselves.

2058
01:16:19,640 --> 01:16:21,720
They aren't forced, it's just better.

2059
01:16:21,720 --> 01:16:23,920
The shift from tickets to templates is structural.

2060
01:16:23,920 --> 01:16:25,800
You're changing how decisions get made,

2061
01:16:25,800 --> 01:16:28,080
from approval-based to automation-based,

2062
01:16:28,080 --> 01:16:29,400
from days to minutes.

2063
01:16:29,400 --> 01:16:32,160
This matters to executives because it hits the business outcomes

2064
01:16:32,160 --> 01:16:35,960
that count, faster delivery, better attention, lower risk.

2065
01:16:35,960 --> 01:16:37,920
This is how you move from being the bottleneck

2066
01:16:37,920 --> 01:16:38,960
to being the enablement.