The DevOps Tax: Why Your Platform is Failing

1
00:00:00,000 --> 00:00:02,920
It was 2010, a simple idea spread through the tech world.

2
00:00:02,920 --> 00:00:05,080
You build it, you run it, that was the promise.

3
00:00:05,080 --> 00:00:06,480
Eliminate the handoff.

4
00:00:06,480 --> 00:00:09,160
No more tossing code over the wall to operations.

5
00:00:09,160 --> 00:00:10,960
No more waiting weeks for infrastructure.

6
00:00:10,960 --> 00:00:12,480
No more, that's not my job.

7
00:00:12,480 --> 00:00:14,080
Developers and operators would merge.

8
00:00:14,080 --> 00:00:16,440
They'd own the entire life cycle, responsibility,

9
00:00:16,440 --> 00:00:18,720
autonomy, speed.

10
00:00:18,720 --> 00:00:20,200
And for a moment it worked.

11
00:00:20,200 --> 00:00:23,760
But by 2026, something broke, not the idea, the execution.

12
00:00:23,760 --> 00:00:25,480
Today, developers aren't shipping faster.

13
00:00:25,480 --> 00:00:26,280
They're drowning.

14
00:00:26,280 --> 00:00:28,200
They're drowning in Kubernetes configurations.

15
00:00:28,200 --> 00:00:29,480
They don't understand.

16
00:00:29,480 --> 00:00:31,960
In YAML files, that never passed the same way twice.

17
00:00:31,960 --> 00:00:33,840
In permission models, so complex that they've

18
00:00:33,840 --> 00:00:35,040
stopped trying to understand them.

19
00:00:35,040 --> 00:00:36,960
They're buried under compliance checklists

20
00:00:36,960 --> 00:00:39,120
that land on their desks like avalanches.

21
00:00:39,120 --> 00:00:40,840
They're stuck with observability tools

22
00:00:40,840 --> 00:00:43,480
that require doctorates to configure and security scanning

23
00:00:43,480 --> 00:00:46,240
that blocks deployments for reasons nobody can explain.

24
00:00:46,240 --> 00:00:48,880
The DevOps promise didn't fail because the idea was wrong.

25
00:00:48,880 --> 00:00:50,240
It failed because it scaled wrong.

26
00:00:50,240 --> 00:00:52,760
And now, there's a cost nobody wants to measure.

27
00:00:52,760 --> 00:00:54,960
A hidden tax that sits on every engineering budget.

28
00:00:54,960 --> 00:00:55,920
A tax that compounds.

29
00:00:55,920 --> 00:00:57,680
A tax that's invisible on the balance sheet,

30
00:00:57,680 --> 00:00:59,520
but very visible in burnout, in turnover,

31
00:00:59,520 --> 00:01:00,800
and in missed delivery dates.

32
00:01:00,800 --> 00:01:02,600
This is the DevOps tax.

33
00:01:02,600 --> 00:01:04,000
The DevOps tax defined.

34
00:01:04,000 --> 00:01:05,760
The DevOps tax isn't a tool problem.

35
00:01:05,760 --> 00:01:08,480
It's not about Jenkins being slow or Docker being hard.

36
00:01:08,480 --> 00:01:10,880
It's about what happened when organizations took a good idea

37
00:01:10,880 --> 00:01:12,800
and tried to scale it to thousands of engineers

38
00:01:12,800 --> 00:01:15,160
without the infrastructure to support it.

39
00:01:15,160 --> 00:01:16,760
The original intent was clean.

40
00:01:16,760 --> 00:01:19,360
Break down the wall between development and operations.

41
00:01:19,360 --> 00:01:20,520
Stop the blame shifting.

42
00:01:20,520 --> 00:01:21,320
Stop the silos.

43
00:01:21,320 --> 00:01:23,000
Make teams own what they build.

44
00:01:23,000 --> 00:01:24,600
What actually happened was different.

45
00:01:24,600 --> 00:01:27,720
Every developer became a part time infrastructure engineer.

46
00:01:27,720 --> 00:01:29,640
And nobody asked them if they wanted the job.

47
00:01:29,640 --> 00:01:31,880
Think about what a developer needs to understand now.

48
00:01:31,880 --> 00:01:32,880
Not once needs.

49
00:01:32,880 --> 00:01:34,640
They need to understand their cloud provider.

50
00:01:34,640 --> 00:01:37,000
Maybe it's Azure, maybe AWS, maybe both.

51
00:01:37,000 --> 00:01:39,400
They need to understand containers and how to build them.

52
00:01:39,400 --> 00:01:41,760
Kubernetes, if they're not living under a rock.

53
00:01:41,760 --> 00:01:45,720
Networking, RBAC, storage classes, persistent volumes,

54
00:01:45,720 --> 00:01:49,200
ingress controllers, service meshes, CICD pipelines,

55
00:01:49,200 --> 00:01:51,000
Git workflows, terraform or bicep,

56
00:01:51,000 --> 00:01:52,920
depending on what your organization chose,

57
00:01:52,920 --> 00:01:56,160
Prometheus or DATA Dog or New Relic, log aggregation,

58
00:01:56,160 --> 00:01:59,760
distributed tracing, security scanning, compliance frameworks,

59
00:01:59,760 --> 00:02:03,680
network policies, pod security policies, secrets management,

60
00:02:03,680 --> 00:02:07,000
disaster recovery, cost optimization, the list never ends,

61
00:02:07,000 --> 00:02:09,760
and none of that is the product they are supposed to be building.

62
00:02:09,760 --> 00:02:12,560
The metric that should matter, the one nobody measures is this.

63
00:02:12,560 --> 00:02:15,440
How much of your engineering team's capacity is actually spent

64
00:02:15,440 --> 00:02:18,360
on business logic versus undifferentiated heavy lifting?

65
00:02:18,360 --> 00:02:20,160
The answer is brutal.

66
00:02:20,160 --> 00:02:23,800
Research shows 74% of developer capacity is consumed

67
00:02:23,800 --> 00:02:26,200
by shadow operations and infrastructure toil

68
00:02:26,200 --> 00:02:27,760
instead of shipping features.

69
00:02:27,760 --> 00:02:29,680
74%, that's not an anomaly.

70
00:02:29,680 --> 00:02:31,280
That's the baseline, that's the tax.

71
00:02:31,280 --> 00:02:32,720
And it's called a tax for a reason.

72
00:02:32,720 --> 00:02:35,400
Taxes are unavoidable, you can't opt out, they compound.

73
00:02:35,400 --> 00:02:38,160
A 2% tax becomes 4% becomes 8%,

74
00:02:38,160 --> 00:02:39,240
and they're invisible.

75
00:02:39,240 --> 00:02:41,840
The infrastructure cost doesn't show up on the PNL.

76
00:02:41,840 --> 00:02:44,200
It shows up as missed deadlines as junior engineers

77
00:02:44,200 --> 00:02:45,800
who burned out after two years

78
00:02:45,800 --> 00:02:47,720
and as senior architects who stopped mentoring

79
00:02:47,720 --> 00:02:50,560
because they're too busy debugging Kubernetes networking.

80
00:02:50,560 --> 00:02:53,760
The DevOps tax is the gap between what you pay for engineering

81
00:02:53,760 --> 00:02:55,720
and what you actually get in business value.

82
00:02:55,720 --> 00:02:58,760
It's the cost of giving every team the responsibility

83
00:02:58,760 --> 00:03:00,240
to run production infrastructure

84
00:03:00,240 --> 00:03:02,480
without giving them the tools to do it at scale.

85
00:03:02,480 --> 00:03:05,360
It's the cost of tool proliferation without standardization.

86
00:03:05,360 --> 00:03:07,840
It's the cost of pushing decisions down to the team level

87
00:03:07,840 --> 00:03:09,680
without a framework to help them make good ones.

88
00:03:09,680 --> 00:03:11,840
In small organizations, this tax is manageable.

89
00:03:11,840 --> 00:03:15,560
A 5% team can all understand each other's infrastructure choices.

90
00:03:15,560 --> 00:03:17,800
Context is shared, decision making is fast,

91
00:03:17,800 --> 00:03:19,520
the cognitive load is spread across people

92
00:03:19,520 --> 00:03:20,920
who already know the system.

93
00:03:20,920 --> 00:03:22,960
Scale to 50 teams, 100 teams,

94
00:03:22,960 --> 00:03:24,960
suddenly you're not managing infrastructure anymore,

95
00:03:24,960 --> 00:03:27,920
you're managing chaos, and the chaos is extracting a price

96
00:03:27,920 --> 00:03:29,480
you're not accounting for.

97
00:03:29,480 --> 00:03:31,240
How DevOps broke at scale?

98
00:03:31,240 --> 00:03:33,120
The model worked fine when teams were small,

99
00:03:33,120 --> 00:03:34,720
but here's what changed.

100
00:03:34,720 --> 00:03:37,680
Between 2010 and 2015, DevOps wasn't a failure,

101
00:03:37,680 --> 00:03:40,240
it was a massive success story, small teams loved it.

102
00:03:40,240 --> 00:03:43,920
A group of 15 engineers could own their entire stack

103
00:03:43,920 --> 00:03:45,120
without any outside help.

104
00:03:45,120 --> 00:03:47,040
They knew each other, they shared context.

105
00:03:47,040 --> 00:03:49,400
When someone needed to deploy,

106
00:03:49,400 --> 00:03:50,680
the person who built the feature

107
00:03:50,680 --> 00:03:53,200
was the same person running it in production.

108
00:03:53,200 --> 00:03:56,240
Responsibility was direct, feedback was immediate.

109
00:03:56,240 --> 00:03:57,720
If something broke at midnight,

110
00:03:57,720 --> 00:04:00,680
the engineer who actually wrote the code got the page

111
00:04:00,680 --> 00:04:03,240
and fixed it because they owned the outcome.

112
00:04:03,240 --> 00:04:04,200
In those early years,

113
00:04:04,200 --> 00:04:06,960
the infrastructure was simple enough for developers to learn.

114
00:04:06,960 --> 00:04:09,280
You learned Git, you learned a few bash scripts,

115
00:04:09,280 --> 00:04:11,840
you understood a Docker file, the barrier to entry was real,

116
00:04:11,840 --> 00:04:13,680
but it was surmountable for most people.

117
00:04:13,680 --> 00:04:16,880
A competent developer could pick it up in weeks rather than months,

118
00:04:16,880 --> 00:04:19,160
and once they did, they had total clarity,

119
00:04:19,160 --> 00:04:20,640
they knew what they were responsible for,

120
00:04:20,640 --> 00:04:22,680
they knew what could break, they knew how to fix it,

121
00:04:22,680 --> 00:04:24,560
then organizations grew.

122
00:04:24,560 --> 00:04:28,640
Five teams became 10, 10 became 50, 50 became 200,

123
00:04:28,640 --> 00:04:30,800
and somewhere in that progression, the model broke,

124
00:04:30,800 --> 00:04:33,360
not in theory, but in practice.

125
00:04:33,360 --> 00:04:35,280
What actually happened is that the number of tools

126
00:04:35,280 --> 00:04:37,920
didn't grow at a steady pace, it exploded.

127
00:04:37,920 --> 00:04:39,560
Every time a new team joined,

128
00:04:39,560 --> 00:04:41,880
they didn't just add more infrastructure decisions.

129
00:04:41,880 --> 00:04:43,200
They added their own preferences,

130
00:04:43,200 --> 00:04:45,600
their own choices, their own dependencies.

131
00:04:45,600 --> 00:04:47,760
Team H.O.'s Jenkins for their CICD,

132
00:04:47,760 --> 00:04:49,720
Team B thought Jenkins was outdated,

133
00:04:49,720 --> 00:04:51,760
so they built everything on GitLab instead.

134
00:04:51,760 --> 00:04:54,680
Team C found Jenkins too heavy and moved to GitHub actions

135
00:04:54,680 --> 00:04:56,560
while Team D is still using Circle CI

136
00:04:56,560 --> 00:04:58,560
because they never found a reason to switch.

137
00:04:58,560 --> 00:05:00,880
Now you have four different systems running at once,

138
00:05:00,880 --> 00:05:02,320
and nobody can explain why.

139
00:05:02,320 --> 00:05:04,120
The same thing happened with observability,

140
00:05:04,120 --> 00:05:07,120
one team uses Prometheus, another uses DataDog,

141
00:05:07,120 --> 00:05:09,720
a third uses New Relic, a fourth team is still logging

142
00:05:09,720 --> 00:05:11,280
to an Elk stack they've had for years

143
00:05:11,280 --> 00:05:13,320
because nobody wants to deal with the migration.

144
00:05:13,320 --> 00:05:15,360
A fifth just adopted Grafana Cloud.

145
00:05:15,360 --> 00:05:17,800
Each choice was rational for that specific team

146
00:05:17,800 --> 00:05:20,120
at that specific time, but collectively,

147
00:05:20,120 --> 00:05:22,200
they created a mess of incompatibility.

148
00:05:22,200 --> 00:05:23,880
Then you add container orchestration,

149
00:05:23,880 --> 00:05:27,080
most teams use Kubernetes, but some use container instances,

150
00:05:27,080 --> 00:05:29,360
and one team decided they didn't need containers at all

151
00:05:29,360 --> 00:05:30,960
and went back to virtual machines.

152
00:05:30,960 --> 00:05:33,240
Now the platform team has to support all three.

153
00:05:33,240 --> 00:05:35,440
The ops team is constantly switching context.

154
00:05:35,440 --> 00:05:37,880
The documentation is split, the runbook's diverge,

155
00:05:37,880 --> 00:05:39,280
you add Terraform to one team,

156
00:05:39,280 --> 00:05:41,800
bicep to another and cloud formation to a third.

157
00:05:41,800 --> 00:05:44,040
You add PagerDuty, Slack, CustomWebhooks,

158
00:05:44,040 --> 00:05:46,560
and automation scripts that nobody remembers writing.

159
00:05:46,560 --> 00:05:48,600
You add security tools that work in some pipelines

160
00:05:48,600 --> 00:05:49,760
but fail in others.

161
00:05:49,760 --> 00:05:51,400
The result isn't a coherent platform.

162
00:05:51,400 --> 00:05:53,800
It's a collection of semi-connected tools held together

163
00:05:53,800 --> 00:05:55,520
by documentation that's always out of date

164
00:05:55,520 --> 00:05:56,960
and institutional knowledge that lives

165
00:05:56,960 --> 00:05:58,800
in the heads of three senior engineers.

166
00:05:58,800 --> 00:06:01,000
That's where decision paralysis sets in.

167
00:06:01,000 --> 00:06:03,640
When a new team forms, they can't just use the stack

168
00:06:03,640 --> 00:06:05,040
because the stack doesn't exist.

169
00:06:05,040 --> 00:06:06,160
They have too many options.

170
00:06:06,160 --> 00:06:08,600
Do we use Kubernetes or container instances?

171
00:06:08,600 --> 00:06:12,400
Terraform or bicep, Prometheus or DataDog?

172
00:06:12,400 --> 00:06:15,040
Every choice branches into a dozen more sub-decisions

173
00:06:15,040 --> 00:06:16,960
about resource limits, networking models,

174
00:06:16,960 --> 00:06:18,440
and backup strategies.

175
00:06:18,440 --> 00:06:20,400
A team that should be shipping features is spending

176
00:06:20,400 --> 00:06:23,800
entire sprints just deciding how they'll run their infrastructure.

177
00:06:23,800 --> 00:06:25,760
Meanwhile, the coordination tax explodes.

178
00:06:25,760 --> 00:06:27,200
Teams aren't independent anymore.

179
00:06:27,200 --> 00:06:28,480
They're interdependent.

180
00:06:28,480 --> 00:06:32,320
Team A uses a database configuration that team B depends on

181
00:06:32,320 --> 00:06:34,520
and team C's networking model conflicts

182
00:06:34,520 --> 00:06:36,200
with what team D is trying to do.

183
00:06:36,200 --> 00:06:38,840
Everyone attends meetings, everyone writes documentation,

184
00:06:38,840 --> 00:06:41,640
everyone adds cross-team dependencies to their roadmaps

185
00:06:41,640 --> 00:06:44,120
and the senior engineers, the architects.

186
00:06:44,120 --> 00:06:46,200
The people who should be designing systems

187
00:06:46,200 --> 00:06:48,840
are spending half their time debugging

188
00:06:48,840 --> 00:06:52,320
why Kubernetes networking isn't working the way one team expects.

189
00:06:52,320 --> 00:06:54,520
They're in meetings explaining why they can't change

190
00:06:54,520 --> 00:06:57,560
a shared database configuration without three weeks of notice.

191
00:06:57,560 --> 00:06:59,400
They're writing runbooks for corner cases

192
00:06:59,400 --> 00:07:01,320
that nobody should have to understand.

193
00:07:01,320 --> 00:07:02,600
The burnout isn't subtle.

194
00:07:02,600 --> 00:07:03,680
It's structural.

195
00:07:03,680 --> 00:07:05,200
The cognitive load crisis.

196
00:07:05,200 --> 00:07:07,120
This is where it gets personal for your team.

197
00:07:07,120 --> 00:07:09,480
Cognitive load is a theory from psychology

198
00:07:09,480 --> 00:07:11,960
that describes the mental effort required to finish a task.

199
00:07:11,960 --> 00:07:13,280
It has three layers.

200
00:07:13,280 --> 00:07:15,280
The first is intrinsic load.

201
00:07:15,280 --> 00:07:18,240
That's the inherent complexity of the problem you're solving

202
00:07:18,240 --> 00:07:20,800
if you're building a payment system that's complex by nature.

203
00:07:20,800 --> 00:07:24,080
You need to understand transactions, security, and audit trails.

204
00:07:24,080 --> 00:07:25,520
That complexity is unavoidable.

205
00:07:25,520 --> 00:07:26,680
It comes with the job.

206
00:07:26,680 --> 00:07:28,400
The second is extraneous load.

207
00:07:28,400 --> 00:07:30,360
That's the unnecessary complexity caused

208
00:07:30,360 --> 00:07:32,040
by how you're solving the problem.

209
00:07:32,040 --> 00:07:34,680
It's the friction that has nothing to do with the business logic.

210
00:07:34,680 --> 00:07:36,480
It's the mental energy spent on tool choices,

211
00:07:36,480 --> 00:07:38,400
process overhead, and documentation gaps.

212
00:07:38,400 --> 00:07:39,640
Extraneous load is the tax.

213
00:07:39,640 --> 00:07:40,960
The third is germane load.

214
00:07:40,960 --> 00:07:44,040
That's the productive mental effort spent on learning and solving.

215
00:07:44,040 --> 00:07:46,120
It's the thinking you actually want developers to do.

216
00:07:46,120 --> 00:07:47,680
How should we structure this system?

217
00:07:47,680 --> 00:07:49,120
What patents fit this domain?

218
00:07:49,120 --> 00:07:51,560
The DevOps model, when it's scaled without guardrails,

219
00:07:51,560 --> 00:07:54,280
maximise the tax and crushed the productive thinking.

220
00:07:54,280 --> 00:07:56,040
A developer sitting down to build a new service

221
00:07:56,040 --> 00:07:57,960
doesn't start by thinking about the product.

222
00:07:57,960 --> 00:07:59,760
They start by thinking about infrastructure.

223
00:07:59,760 --> 00:08:01,680
Do we use Kubernetes or container instances?

224
00:08:01,680 --> 00:08:04,200
If Kubernetes, what networking model, service mesh, or not,

225
00:08:04,200 --> 00:08:05,240
how do we handle secrets?

226
00:08:05,240 --> 00:08:06,960
What's the disaster recovery strategy?

227
00:08:06,960 --> 00:08:08,600
What resource limits should we set?

228
00:08:08,600 --> 00:08:10,440
15 to 20 distinct concepts.

229
00:08:10,440 --> 00:08:12,120
Every single one of them is necessary.

230
00:08:12,120 --> 00:08:13,440
None of them are optional.

231
00:08:13,440 --> 00:08:16,240
And that's before they write a single line of business logic.

232
00:08:16,240 --> 00:08:18,040
A junior engineer spends weeks just trying

233
00:08:18,040 --> 00:08:19,480
to understand the landscape.

234
00:08:19,480 --> 00:08:21,680
A senior engineer navigates it faster,

235
00:08:21,680 --> 00:08:23,560
but the cognitive tax is still there.

236
00:08:23,560 --> 00:08:24,840
Their brain is constantly switching

237
00:08:24,840 --> 00:08:27,280
between infrastructure concerns and product concerns.

238
00:08:27,280 --> 00:08:28,440
That switch has a cost.

239
00:08:28,440 --> 00:08:30,760
Every context switch drains mental energy.

240
00:08:30,760 --> 00:08:33,760
Every decision that isn't about the product adds fatigue.

241
00:08:33,760 --> 00:08:37,360
The research community calls this concepts to ship or CTS.

242
00:08:37,360 --> 00:08:39,520
It's the count of distinct things a developer must understand

243
00:08:39,520 --> 00:08:41,160
just to get a service into production.

244
00:08:41,160 --> 00:08:43,280
For a manually configured DevOps environment,

245
00:08:43,280 --> 00:08:45,680
CTS usually runs between 15 and 20.

246
00:08:45,680 --> 00:08:46,880
You have Kubernetes networking,

247
00:08:46,880 --> 00:08:48,560
RBAC permissions and storage classes.

248
00:08:48,560 --> 00:08:50,760
You have ingress controllers, config maps, and resource

249
00:08:50,760 --> 00:08:51,280
limits.

250
00:08:51,280 --> 00:08:53,680
You have network policies, observability setup,

251
00:08:53,680 --> 00:08:56,040
and CI/CD pipeline configuration.

252
00:08:56,040 --> 00:08:59,440
Each concept requires study, each requires decisions,

253
00:08:59,440 --> 00:09:00,640
each adds friction.

254
00:09:00,640 --> 00:09:03,280
A mature platform reduces that count to four or five.

255
00:09:03,280 --> 00:09:06,520
Service name, environment, replica count, resource limits.

256
00:09:06,520 --> 00:09:09,040
The difference between four and 20 isn't just mental.

257
00:09:09,040 --> 00:09:11,000
It's organizational.

258
00:09:11,000 --> 00:09:12,920
A developer working in a four-concept system

259
00:09:12,920 --> 00:09:15,600
can focus 80% of their energy on the product.

260
00:09:15,600 --> 00:09:17,560
A developer working in a 20-concept system

261
00:09:17,560 --> 00:09:18,640
has it backwards.

262
00:09:18,640 --> 00:09:20,400
Infrastructure becomes the problem.

263
00:09:20,400 --> 00:09:22,360
The product is just what they do in the gaps.

264
00:09:22,360 --> 00:09:23,960
And organizations don't measure this.

265
00:09:23,960 --> 00:09:25,600
They measure how often they deploy.

266
00:09:25,600 --> 00:09:26,600
They measure uptime.

267
00:09:26,600 --> 00:09:27,680
They measure cost.

268
00:09:27,680 --> 00:09:29,560
But they don't measure cognitive load.

269
00:09:29,560 --> 00:09:31,520
They don't ask how much of your mental capacity

270
00:09:31,520 --> 00:09:33,440
is spent on infrastructure instead of the product.

271
00:09:33,440 --> 00:09:35,720
If they did, they'd see the tax clearly.

272
00:09:35,720 --> 00:09:37,160
They'd see that the brilliant architect

273
00:09:37,160 --> 00:09:39,520
who should be designing the next generation of systems

274
00:09:39,520 --> 00:09:41,720
is instead debugging R-back permissions.

275
00:09:41,720 --> 00:09:43,800
They'd see the team lead who should be mentoring is,

276
00:09:43,800 --> 00:09:46,720
instead explaining why a Kubernetes manifest won't apply.

277
00:09:46,720 --> 00:09:48,440
They'd see the junior engineer who should be learning

278
00:09:48,440 --> 00:09:51,320
clean code is instead copy-pasting YAML from stack overflow

279
00:09:51,320 --> 00:09:53,080
without understanding what it does.

280
00:09:53,080 --> 00:09:55,200
The devil's promise was supposed to eliminate waste.

281
00:09:55,200 --> 00:09:58,080
Instead, it created a new kind of waste, not operational waste,

282
00:09:58,080 --> 00:09:59,440
cognitive waste.

283
00:09:59,440 --> 00:10:01,480
And that waste is compounding.

284
00:10:01,480 --> 00:10:03,720
Why manual configuration doesn't scale?

285
00:10:03,720 --> 00:10:05,360
The model breaks the moment you look at how

286
00:10:05,360 --> 00:10:07,120
infrastructure actually gets built.

287
00:10:07,120 --> 00:10:09,960
In organizations that never moved past manual configuration,

288
00:10:09,960 --> 00:10:11,000
the process is a mess.

289
00:10:11,000 --> 00:10:12,320
A team needs a database.

290
00:10:12,320 --> 00:10:13,760
They open the Azure portal.

291
00:10:13,760 --> 00:10:15,080
They write a random script.

292
00:10:15,080 --> 00:10:16,960
Or they follow a runbook written three years ago

293
00:10:16,960 --> 00:10:18,440
that's probably missing half the steps.

294
00:10:18,440 --> 00:10:20,920
They provision the instance, set some parameters,

295
00:10:20,920 --> 00:10:23,560
add firewall rules, and create credentials.

296
00:10:23,560 --> 00:10:24,880
The database exists.

297
00:10:24,880 --> 00:10:25,640
It works.

298
00:10:25,640 --> 00:10:26,760
It's in production.

299
00:10:26,760 --> 00:10:27,960
But here's the problem.

300
00:10:27,960 --> 00:10:29,680
This team's database looks nothing

301
00:10:29,680 --> 00:10:31,240
like any other team's database.

302
00:10:31,240 --> 00:10:32,560
Team A uses one SKU.

303
00:10:32,560 --> 00:10:33,960
Team B uses another.

304
00:10:33,960 --> 00:10:35,320
The backup policies are different.

305
00:10:35,320 --> 00:10:36,680
The networking models are different.

306
00:10:36,680 --> 00:10:40,040
One team uses a public endpoint with IP restrictions,

307
00:10:40,040 --> 00:10:41,720
while another uses private endpoints.

308
00:10:41,720 --> 00:10:43,200
And a third uses service endpoints.

309
00:10:43,200 --> 00:10:44,280
Technically, they all work.

310
00:10:44,280 --> 00:10:45,360
They all store data.

311
00:10:45,360 --> 00:10:48,040
But they aren't consistent.

312
00:10:48,040 --> 00:10:52,160
Consistency sounds like a nice to have feature.

313
00:10:52,160 --> 00:10:54,760
In reality, it's the only way an organization can scale.

314
00:10:54,760 --> 00:10:57,440
When you have five teams, inconsistencies, just friction.

315
00:10:57,440 --> 00:10:59,480
You document the right way to do it.

316
00:10:59,480 --> 00:11:00,880
Most teams follow it.

317
00:11:00,880 --> 00:11:01,480
Some don't.

318
00:11:01,480 --> 00:11:03,320
Some want grumbles in a meeting about why they aren't

319
00:11:03,320 --> 00:11:04,280
any mandates.

320
00:11:04,280 --> 00:11:05,600
And then everyone moves on.

321
00:11:05,600 --> 00:11:08,640
But when you have 50 teams, inconsistency becomes chaos.

322
00:11:08,640 --> 00:11:10,240
Your runbooks break because they assume

323
00:11:10,240 --> 00:11:12,000
a specific setup that doesn't exist.

324
00:11:12,000 --> 00:11:13,760
Your monitoring breaks because every team

325
00:11:13,760 --> 00:11:15,400
use different alert thresholds.

326
00:11:15,400 --> 00:11:17,840
Your backups are a gamble because retention policies vary

327
00:11:17,840 --> 00:11:19,080
from person to person.

328
00:11:19,080 --> 00:11:21,160
Your disaster recovery tests fail

329
00:11:21,160 --> 00:11:23,520
because the replication settings weren't standardized.

330
00:11:23,520 --> 00:11:25,480
The knowledge of how things should actually work lives

331
00:11:25,480 --> 00:11:28,240
entirely in the heads of individual engineers.

332
00:11:28,240 --> 00:11:30,800
And that leads to the next problem, knowledge hoarding.

333
00:11:31,800 --> 00:11:33,880
Senior engineers become the only people

334
00:11:33,880 --> 00:11:36,000
who understand the right way to build.

335
00:11:36,000 --> 00:11:37,000
They've seen the patterns.

336
00:11:37,000 --> 00:11:37,920
They know the gotchas.

337
00:11:37,920 --> 00:11:40,480
They know why a specific parameter has to be set

338
00:11:40,480 --> 00:11:41,840
to a specific value.

339
00:11:41,840 --> 00:11:43,320
And they become the bottleneck.

340
00:11:43,320 --> 00:11:45,240
A junior engineer can't provision infrastructure

341
00:11:45,240 --> 00:11:46,560
with any confidence.

342
00:11:46,560 --> 00:11:47,480
They have to ask.

343
00:11:47,480 --> 00:11:49,440
They have to wait for the one person who knows.

344
00:11:49,440 --> 00:11:50,800
But that person is busy.

345
00:11:50,800 --> 00:11:51,760
They're always busy.

346
00:11:51,760 --> 00:11:54,280
So the junior engineer either waits, or they guess,

347
00:11:54,280 --> 00:11:57,040
or they copy what another team did, even if it's wrong.

348
00:11:57,040 --> 00:11:59,280
The senior engineer ends up reviewing every single move.

349
00:11:59,280 --> 00:12:00,360
They become a gatekeeper.

350
00:12:00,360 --> 00:12:02,680
Their calendar fills up with approvals and reviews.

351
00:12:02,680 --> 00:12:05,440
They have less time to solve actual architectural problems.

352
00:12:05,440 --> 00:12:07,760
And more time managing a consistency crisis

353
00:12:07,760 --> 00:12:10,160
they created by never writing down the rules.

354
00:12:10,160 --> 00:12:12,000
Governance becomes theoretical.

355
00:12:12,000 --> 00:12:14,360
Your security team writes down policies.

356
00:12:14,360 --> 00:12:16,600
All databases must have encryption.

357
00:12:16,600 --> 00:12:18,480
All databases must have backups.

358
00:12:18,480 --> 00:12:20,840
All databases must be in private subnets.

359
00:12:20,840 --> 00:12:21,960
These are official.

360
00:12:21,960 --> 00:12:23,640
They're also meaningless.

361
00:12:23,640 --> 00:12:25,560
Because there is no way to enforce them.

362
00:12:25,560 --> 00:12:27,640
Instead, enforcement happens through code review.

363
00:12:27,640 --> 00:12:29,080
Someone opens a pull request.

364
00:12:29,080 --> 00:12:30,080
Someone else reviews it.

365
00:12:30,080 --> 00:12:33,040
If they remember the policies, they might catch a mistake.

366
00:12:33,040 --> 00:12:35,280
If they're busy, they'll miss it.

367
00:12:35,280 --> 00:12:38,160
The engineer might argue they have a good reason to break the rules.

368
00:12:38,160 --> 00:12:40,280
The reviewer might believe them, or they might not.

369
00:12:40,280 --> 00:12:42,640
The result isn't a system that prevents errors.

370
00:12:42,640 --> 00:12:44,640
It's two people spending an hour arguing

371
00:12:44,640 --> 00:12:46,160
about whether an error is acceptable.

372
00:12:46,160 --> 00:12:47,120
That's not governance.

373
00:12:47,120 --> 00:12:48,480
That's theatre.

374
00:12:48,480 --> 00:12:51,000
Audits become post-mortems instead of actual validation

375
00:12:51,000 --> 00:12:52,000
once a year.

376
00:12:52,000 --> 00:12:53,040
Auditors show up.

377
00:12:53,040 --> 00:12:54,920
They ask for the disaster recovery plan.

378
00:12:54,920 --> 00:12:56,880
You scramble to test it only to find out

379
00:12:56,880 --> 00:12:58,880
your backups haven't worked for six months.

380
00:12:58,880 --> 00:12:59,880
You fix it.

381
00:12:59,880 --> 00:13:01,280
And then you do the same thing next year.

382
00:13:01,280 --> 00:13:02,760
And this is where things change.

383
00:13:02,760 --> 00:13:04,440
Because now we're adding AI to the mix.

384
00:13:04,440 --> 00:13:06,400
M365Copilot is powerful.

385
00:13:06,400 --> 00:13:09,640
It can summarize documents, write code, and automate workflows.

386
00:13:09,640 --> 00:13:11,840
It can also interact with your infrastructure.

387
00:13:11,840 --> 00:13:13,440
It can read your configurations.

388
00:13:13,440 --> 00:13:14,520
And here's the shift.

389
00:13:14,520 --> 00:13:17,600
When copilot interacts with manually configured infrastructure,

390
00:13:17,600 --> 00:13:21,840
it inherits every inconsistency and every shortcut you ever took.

391
00:13:21,840 --> 00:13:24,760
If you tell copilot to provision a database,

392
00:13:24,760 --> 00:13:26,600
and it doesn't have a golden path to follow,

393
00:13:26,600 --> 00:13:28,600
it makes decisions based on what it sees.

394
00:13:28,600 --> 00:13:30,160
And what it sees is chaos.

395
00:13:30,160 --> 00:13:32,840
Some databases are encrypted, some aren't, some have backups.

396
00:13:32,840 --> 00:13:33,840
Some don't.

397
00:13:33,840 --> 00:13:35,960
Copilot might copy a patent from a legacy system

398
00:13:35,960 --> 00:13:38,440
that was built wrong ten years ago and never fixed.

399
00:13:38,440 --> 00:13:40,400
Now you don't just have inconsistent infrastructure

400
00:13:40,400 --> 00:13:41,560
managed by humans.

401
00:13:41,560 --> 00:13:43,840
You have inconsistent infrastructure managed by humans

402
00:13:43,840 --> 00:13:46,520
and amplified by AI, making decisions at a scale

403
00:13:46,520 --> 00:13:48,400
you can't easily reverse.

404
00:13:48,400 --> 00:13:50,880
Manual configuration stops working the moment you add intelligence

405
00:13:50,880 --> 00:13:53,200
to the system.

406
00:13:53,200 --> 00:13:54,720
The real cost of shadow it.

407
00:13:54,720 --> 00:13:55,920
Here's what happens next.

408
00:13:55,920 --> 00:13:57,240
And this is inevitable.

409
00:13:57,240 --> 00:13:58,640
The official path is too slow.

410
00:13:58,640 --> 00:13:59,720
It requires approvals.

411
00:13:59,720 --> 00:14:01,000
It requires documentation.

412
00:14:01,000 --> 00:14:04,000
It requires following a process that doesn't make sense.

413
00:14:04,000 --> 00:14:05,080
So teams don't follow it.

414
00:14:05,080 --> 00:14:06,400
Instead, they build their own.

415
00:14:06,400 --> 00:14:08,240
They provision infrastructure using scripts

416
00:14:08,240 --> 00:14:09,880
in a random repo nobody knows about.

417
00:14:09,880 --> 00:14:12,680
They automate workflows using cloud accounts only they can access.

418
00:14:12,680 --> 00:14:14,680
They build platforms inside your platforms.

419
00:14:14,680 --> 00:14:16,200
They create notification systems

420
00:14:16,200 --> 00:14:17,960
that don't talk to the official ones.

421
00:14:17,960 --> 00:14:20,440
They stand up databases in unapproved regions

422
00:14:20,440 --> 00:14:22,400
because the approved ones were too slow.

423
00:14:22,400 --> 00:14:25,160
They bypass your CICD because it's easier to just deploy

424
00:14:25,160 --> 00:14:25,760
directly.

425
00:14:25,760 --> 00:14:28,440
This is shadow ET and it's not rogue behavior.

426
00:14:28,440 --> 00:14:29,680
It's not in subordination.

427
00:14:29,680 --> 00:14:31,920
It's a rational response to a broken system.

428
00:14:31,920 --> 00:14:33,640
When the official path has high friction,

429
00:14:33,640 --> 00:14:34,880
teams don't sit around waiting.

430
00:14:34,880 --> 00:14:37,400
If a database takes two weeks and three approvals,

431
00:14:37,400 --> 00:14:39,200
they'll find a way to do it in 10 minutes.

432
00:14:39,200 --> 00:14:40,840
They solve the problem themselves.

433
00:14:40,840 --> 00:14:42,280
From their perspective, this makes sense.

434
00:14:42,280 --> 00:14:43,360
They ship faster.

435
00:14:43,360 --> 00:14:44,400
They get their work done.

436
00:14:44,400 --> 00:14:46,160
But from an organizational perspective,

437
00:14:46,160 --> 00:14:47,360
you've just lost control.

438
00:14:47,360 --> 00:14:50,120
The hidden costs pile up in places you can't even measure.

439
00:14:50,120 --> 00:14:51,560
First, duplicated effort.

440
00:14:51,560 --> 00:14:53,840
You have a platform team building standard patterns.

441
00:14:53,840 --> 00:14:56,480
But you also have 15 other teams building their own versions

442
00:14:56,480 --> 00:14:57,360
of those same patterns.

443
00:14:57,360 --> 00:14:58,240
That's not two versions.

444
00:14:58,240 --> 00:14:59,120
It's 20.

445
00:14:59,120 --> 00:15:00,800
Every team reinvented the wheel.

446
00:15:00,800 --> 00:15:02,960
Every team spent engineering hours building something

447
00:15:02,960 --> 00:15:04,480
that already existed.

448
00:15:04,480 --> 00:15:07,680
But they didn't know it because the official option was too slow.

449
00:15:07,680 --> 00:15:09,320
Second, security gaps.

450
00:15:09,320 --> 00:15:11,920
Your security policies are supposed to apply to everything.

451
00:15:11,920 --> 00:15:14,200
But when infrastructure is built outside your framework,

452
00:15:14,200 --> 00:15:15,640
the policies don't exist.

453
00:15:15,640 --> 00:15:17,920
An engineer spins up a database with public access

454
00:15:17,920 --> 00:15:19,640
because they didn't know any better.

455
00:15:19,640 --> 00:15:22,600
A team configures storage with world readable permissions

456
00:15:22,600 --> 00:15:25,040
because it was easier than figuring out your R-back model.

457
00:15:25,040 --> 00:15:26,520
A service runs without encryption

458
00:15:26,520 --> 00:15:28,960
because the engineer didn't realize it was mandatory.

459
00:15:28,960 --> 00:15:30,280
These aren't malicious acts.

460
00:15:30,280 --> 00:15:33,160
Their gaps created by a lack of guardrails.

461
00:15:33,160 --> 00:15:35,480
Third, compliance violations.

462
00:15:35,480 --> 00:15:38,360
Auditors want to see every piece of infrastructure in production.

463
00:15:38,360 --> 00:15:40,440
You can show them the official systems.

464
00:15:40,440 --> 00:15:41,640
But you can't show them the rest

465
00:15:41,640 --> 00:15:43,360
because you don't know the rest exists.

466
00:15:43,360 --> 00:15:45,160
An engineer deployed something two years ago

467
00:15:45,160 --> 00:15:46,120
and left the company.

468
00:15:46,120 --> 00:15:47,520
The service is still running.

469
00:15:47,520 --> 00:15:48,560
Nobody knows who owns it.

470
00:15:48,560 --> 00:15:49,800
Nobody knows if it's compliant.

471
00:15:49,800 --> 00:15:50,960
You have massive risk.

472
00:15:50,960 --> 00:15:52,960
And you don't even know where it is.

473
00:15:52,960 --> 00:15:55,080
Fourth, knowledge silos.

474
00:15:55,080 --> 00:15:56,600
The person who built the shadow system

475
00:15:56,600 --> 00:15:59,160
is the only one who understands it when they leave.

476
00:15:59,160 --> 00:16:00,880
That knowledge is gone a year later.

477
00:16:00,880 --> 00:16:01,720
The system breaks.

478
00:16:01,720 --> 00:16:04,040
Nobody can fix it because nobody knows how it works.

479
00:16:04,040 --> 00:16:05,640
You're paying to maintain infrastructure.

480
00:16:05,640 --> 00:16:06,960
You didn't even know you had.

481
00:16:06,960 --> 00:16:09,520
The metric that captures this is the escape rate.

482
00:16:09,520 --> 00:16:12,720
How often do teams bypass the official platform entirely?

483
00:16:12,720 --> 00:16:15,600
Research shows that if your escape rate is above 20%,

484
00:16:15,600 --> 00:16:16,520
it's a warning sign.

485
00:16:16,520 --> 00:16:18,600
If it's above 30%, you've lost control.

486
00:16:18,600 --> 00:16:20,920
If it's above 50%, you don't have a platform.

487
00:16:20,920 --> 00:16:22,160
You have a suggestion.

488
00:16:22,160 --> 00:16:23,720
Most organizations don't measure this

489
00:16:23,720 --> 00:16:25,640
because they're afraid of the answer.

490
00:16:25,640 --> 00:16:27,600
When they finally do, they often find

491
00:16:27,600 --> 00:16:29,920
that 40% of their infrastructure is running

492
00:16:29,920 --> 00:16:31,480
outside the official framework.

493
00:16:31,480 --> 00:16:32,400
40%.

494
00:16:32,400 --> 00:16:33,880
That's not a technical issue.

495
00:16:33,880 --> 00:16:35,160
It's a governance failure.

496
00:16:35,160 --> 00:16:36,640
The risk just keeps compounding.

497
00:16:36,640 --> 00:16:38,400
You lose visibility into production.

498
00:16:38,400 --> 00:16:41,240
You can't forecast costs because you don't know what's out there.

499
00:16:41,240 --> 00:16:43,040
You can't manage security because you aren't

500
00:16:43,040 --> 00:16:44,080
seeing the whole picture.

501
00:16:44,080 --> 00:16:45,080
You're flying blind.

502
00:16:45,080 --> 00:16:46,880
And the security risk is immediate.

503
00:16:46,880 --> 00:16:49,120
Shadow infrastructure is almost never monitored.

504
00:16:49,120 --> 00:16:50,240
Backups don't run.

505
00:16:50,240 --> 00:16:52,680
Disaster recovery isn't tested when something breaks.

506
00:16:52,680 --> 00:16:54,960
There's no documentation when someone attacks it.

507
00:16:54,960 --> 00:16:56,120
Nobody notices for months.

508
00:16:56,120 --> 00:16:57,800
This is the real cost of a platform

509
00:16:57,800 --> 00:16:59,960
that isn't good enough to actually use.

510
00:16:59,960 --> 00:17:02,400
DevOps versus platform engineering, the shift.

511
00:17:02,400 --> 00:17:03,880
The failure is obvious now.

512
00:17:03,880 --> 00:17:05,000
The model breaks.

513
00:17:05,000 --> 00:17:06,920
Teams can't navigate the complexity

514
00:17:06,920 --> 00:17:08,400
so they create their own solutions.

515
00:17:08,400 --> 00:17:09,720
The platform doesn't contain them.

516
00:17:09,720 --> 00:17:10,720
It fragments them.

517
00:17:10,720 --> 00:17:12,200
So what changes?

518
00:17:12,200 --> 00:17:13,440
This is the critical move.

519
00:17:13,440 --> 00:17:14,720
It isn't a technology shift.

520
00:17:14,720 --> 00:17:16,200
It's a philosophical one.

521
00:17:16,200 --> 00:17:19,280
DevOps said, distribute responsibility to the edges.

522
00:17:19,280 --> 00:17:21,560
Make teams own their own infrastructure.

523
00:17:21,560 --> 00:17:25,160
The logic was sound, eliminate handoffs, eliminate silos,

524
00:17:25,160 --> 00:17:27,360
make people accountable for what they build.

525
00:17:27,360 --> 00:17:29,400
Platform engineering says something different.

526
00:17:29,400 --> 00:17:31,680
Centralize capability at the foundation.

527
00:17:31,680 --> 00:17:34,320
Make teams own their products, not their infrastructure.

528
00:17:34,320 --> 00:17:35,200
This sounds subtle.

529
00:17:35,200 --> 00:17:36,480
It's not.

530
00:17:36,480 --> 00:17:37,960
DevOps distributes the burden.

531
00:17:37,960 --> 00:17:39,920
Everyone gets the power to configure everything.

532
00:17:39,920 --> 00:17:42,480
And everyone gets the responsibility to understand it.

533
00:17:42,480 --> 00:17:43,360
That's the deal.

534
00:17:43,360 --> 00:17:46,120
You want autonomy, you get complexity, you want ownership,

535
00:17:46,120 --> 00:17:47,000
you own all of it.

536
00:17:47,000 --> 00:17:48,880
Platform engineering inverts the trade off.

537
00:17:48,880 --> 00:17:52,120
It says, you get autonomy over what matters, your product,

538
00:17:52,120 --> 00:17:53,760
and the platform owns what doesn't.

539
00:17:53,760 --> 00:17:55,960
You own your features, you own your business logic,

540
00:17:55,960 --> 00:17:57,280
you own your user experience.

541
00:17:57,280 --> 00:17:59,200
The platform owns how your code gets deployed,

542
00:17:59,200 --> 00:18:01,360
the platform owns how your service gets monitored,

543
00:18:01,360 --> 00:18:03,520
the platform owns how your access is managed,

544
00:18:03,520 --> 00:18:06,240
the platform owns how your infrastructure gets secured.

545
00:18:06,240 --> 00:18:07,560
The difference isn't theoretical.

546
00:18:07,560 --> 00:18:09,080
It's structural.

547
00:18:09,080 --> 00:18:11,480
In a DevOps organization, a team that needs a database

548
00:18:11,480 --> 00:18:13,040
has to understand databases.

549
00:18:13,040 --> 00:18:14,800
They have to understand backup strategies,

550
00:18:14,800 --> 00:18:17,800
replication, scaling, failover, and disaster recovery.

551
00:18:17,800 --> 00:18:20,120
Because they have to make decisions about all of it,

552
00:18:20,120 --> 00:18:22,680
they own the consequences when things go wrong.

553
00:18:22,680 --> 00:18:24,400
In a platform engineering organization,

554
00:18:24,400 --> 00:18:27,040
a team that needs a database, submits a request.

555
00:18:27,040 --> 00:18:28,440
The platform provisions it.

556
00:18:28,440 --> 00:18:30,920
It's pre-configured with industry standard backup strategies,

557
00:18:30,920 --> 00:18:33,480
replication, scaling rules, and failover logic.

558
00:18:33,480 --> 00:18:35,400
The team doesn't need to understand any of it.

559
00:18:35,400 --> 00:18:36,080
They just use it.

560
00:18:36,080 --> 00:18:37,760
The DevOps team is responsible for learning.

561
00:18:37,760 --> 00:18:40,520
The platform engineering team is responsible for deciding.

562
00:18:40,520 --> 00:18:42,200
This shift changes what teams look like.

563
00:18:42,200 --> 00:18:44,400
In DevOps, you have a large central ops team

564
00:18:44,400 --> 00:18:46,000
managing shared infrastructure

565
00:18:46,000 --> 00:18:48,880
and large distributed teams managing their own infrastructure.

566
00:18:48,880 --> 00:18:52,320
In platform engineering, you have a small dedicated platform team,

567
00:18:52,320 --> 00:18:55,240
your infrastructure as product and product teams that consume it.

568
00:18:55,240 --> 00:18:57,240
The platform team doesn't manage infrastructure.

569
00:18:57,240 --> 00:18:58,160
They don't run servers.

570
00:18:58,160 --> 00:18:59,160
They don't fight fires.

571
00:18:59,160 --> 00:19:02,040
They build systems that let other teams run their own infrastructure

572
00:19:02,040 --> 00:19:03,720
without having to understand all of it.

573
00:19:03,720 --> 00:19:04,920
This is the key inside.

574
00:19:04,920 --> 00:19:06,400
Infrastructure as a product.

575
00:19:06,400 --> 00:19:07,920
A product has a user experience.

576
00:19:07,920 --> 00:19:08,960
It has documentation.

577
00:19:08,960 --> 00:19:09,880
It has an API.

578
00:19:09,880 --> 00:19:10,600
It has support.

579
00:19:10,600 --> 00:19:11,400
It has a roadmap.

580
00:19:11,400 --> 00:19:14,400
It has a team that cares whether people actually use it.

581
00:19:14,400 --> 00:19:16,680
When someone doesn't understand how to use the product,

582
00:19:16,680 --> 00:19:18,600
the product team doesn't blame the user.

583
00:19:18,600 --> 00:19:19,920
They blame themselves.

584
00:19:19,920 --> 00:19:21,120
The product wasn't clear.

585
00:19:21,120 --> 00:19:22,840
The documentation wasn't helpful.

586
00:19:22,840 --> 00:19:24,440
The feature didn't match the use case.

587
00:19:24,440 --> 00:19:26,400
Platform teams operate the same way.

588
00:19:26,400 --> 00:19:28,160
If teams aren't using the platform,

589
00:19:28,160 --> 00:19:29,720
it's not because the teams are incompetent.

590
00:19:29,720 --> 00:19:31,920
It's because the platform isn't solving their problem.

591
00:19:31,920 --> 00:19:33,840
The interaction model is completely different.

592
00:19:33,840 --> 00:19:36,040
In DevOps, the interaction is collaboration.

593
00:19:36,040 --> 00:19:36,880
Teams coordinate.

594
00:19:36,880 --> 00:19:37,480
They align.

595
00:19:37,480 --> 00:19:38,160
They negotiate.

596
00:19:38,160 --> 00:19:39,360
They submit tickets.

597
00:19:39,360 --> 00:19:40,520
They wait for approvals.

598
00:19:40,520 --> 00:19:41,920
There's constant back and forth

599
00:19:41,920 --> 00:19:44,640
because the boundary between responsibility isn't clear.

600
00:19:44,640 --> 00:19:47,320
In platform engineering, the interaction is X as a service.

601
00:19:47,320 --> 00:19:49,320
X as a service means here's a service.

602
00:19:49,320 --> 00:19:50,280
Here's how you use it.

603
00:19:50,280 --> 00:19:51,280
Here's what it does.

604
00:19:51,280 --> 00:19:52,960
You don't need to talk to us.

605
00:19:52,960 --> 00:19:54,240
You don't need our permission.

606
00:19:54,240 --> 00:19:55,480
You don't need to coordinate.

607
00:19:55,480 --> 00:19:56,600
You request a resource.

608
00:19:56,600 --> 00:19:57,720
The system provisions it.

609
00:19:57,720 --> 00:19:58,800
It's available in minutes.

610
00:19:58,800 --> 00:19:59,560
It's documented.

611
00:19:59,560 --> 00:20:00,280
It works.

612
00:20:00,280 --> 00:20:01,960
This enables the outcome that matters.

613
00:20:01,960 --> 00:20:03,360
In a DevOps organization,

614
00:20:03,360 --> 00:20:06,120
developers spend 20% of their time on business logic

615
00:20:06,120 --> 00:20:07,960
and 80% on infrastructure.

616
00:20:07,960 --> 00:20:08,640
They're drowning.

617
00:20:08,640 --> 00:20:09,840
They're context switching.

618
00:20:09,840 --> 00:20:11,240
They're making infrastructure decisions

619
00:20:11,240 --> 00:20:13,040
that have nothing to do with the product.

620
00:20:13,040 --> 00:20:14,760
In a platform engineering organization,

621
00:20:14,760 --> 00:20:16,440
developers flip that ratio.

622
00:20:16,440 --> 00:20:19,120
They spend 80% of their time on business logic

623
00:20:19,120 --> 00:20:21,000
and 20% on infrastructure.

624
00:20:21,000 --> 00:20:23,840
The platform handles the undifferentiated heavy lifting.

625
00:20:23,840 --> 00:20:26,440
Developers focus on what differentiates their product.

626
00:20:26,440 --> 00:20:28,400
That's not just a productivity improvement.

627
00:20:28,400 --> 00:20:30,600
That's a structural change in what becomes possible.

628
00:20:30,600 --> 00:20:33,040
An engineer who spends 80% of her time on the product

629
00:20:33,040 --> 00:20:34,760
can think clearly about architecture.

630
00:20:34,760 --> 00:20:36,280
She can mentor junior engineers.

631
00:20:36,280 --> 00:20:37,680
She can design for scale.

632
00:20:37,680 --> 00:20:39,240
She can reason about trade-offs.

633
00:20:39,240 --> 00:20:42,440
An engineer who spends 80% of her time managing infrastructure

634
00:20:42,440 --> 00:20:43,560
is in triage mode.

635
00:20:43,560 --> 00:20:44,240
She's reactive.

636
00:20:44,240 --> 00:20:45,240
She's solving firefights.

637
00:20:45,240 --> 00:20:46,880
She's not building.

638
00:20:46,880 --> 00:20:48,920
The shift from DevOps to platform engineering

639
00:20:48,920 --> 00:20:50,760
is the shift from distributed burden

640
00:20:50,760 --> 00:20:52,680
to centralized responsibility.

641
00:20:52,680 --> 00:20:55,200
It's the shift from everyone learns infrastructure

642
00:20:55,200 --> 00:20:57,720
to everyone uses infrastructure well.

643
00:20:57,720 --> 00:20:59,720
It's the shift from infrastructure

644
00:20:59,720 --> 00:21:02,160
as a cost to infrastructure as a product.

645
00:21:02,160 --> 00:21:03,760
And that shift has to start somewhere.

646
00:21:03,760 --> 00:21:05,800
What golden paths actually are?

647
00:21:05,800 --> 00:21:06,960
The philosophy is clean.

648
00:21:06,960 --> 00:21:08,520
The execution is the hard part.

649
00:21:08,520 --> 00:21:11,280
How do you actually move from the old model to this new one?

650
00:21:11,280 --> 00:21:14,280
You start by building what the platform team calls a golden path.

651
00:21:14,280 --> 00:21:15,600
This term gets thrown around a lot.

652
00:21:15,600 --> 00:21:17,400
So let's be precise about what it means.

653
00:21:17,400 --> 00:21:20,440
A golden path is an opinionated pre-built workflow

654
00:21:20,440 --> 00:21:23,760
that handles the 80% of use cases that are actually common,

655
00:21:23,760 --> 00:21:26,600
not all use cases, not every possible variation.

656
00:21:26,600 --> 00:21:29,680
The 80% that show up repeatedly across your organization.

657
00:21:29,680 --> 00:21:31,160
What does it include?

658
00:21:31,160 --> 00:21:32,680
Infrastructure templates.

659
00:21:32,680 --> 00:21:33,720
You have a service.

660
00:21:33,720 --> 00:21:35,200
It needs to run somewhere.

661
00:21:35,200 --> 00:21:38,040
The golden path says, here's how we run services.

662
00:21:38,040 --> 00:21:39,920
Here's the standard compute configuration.

663
00:21:39,920 --> 00:21:41,120
Here's the network setup.

664
00:21:41,120 --> 00:21:42,200
Here's the storage.

665
00:21:42,200 --> 00:21:43,840
Here's the secrets management.

666
00:21:43,840 --> 00:21:46,400
Here are the security baselines that are already configured.

667
00:21:46,400 --> 00:21:47,280
You don't choose them.

668
00:21:47,280 --> 00:21:48,200
They're the default.

669
00:21:48,200 --> 00:21:50,520
It includes CI/CD pipelines.

670
00:21:50,520 --> 00:21:52,680
Not blank slate pipelines where teams decide

671
00:21:52,680 --> 00:21:53,840
how to build and deploy.

672
00:21:53,840 --> 00:21:54,960
Standard pipelines.

673
00:21:54,960 --> 00:21:56,240
Your code gets built this way.

674
00:21:56,240 --> 00:21:57,840
Your tests run with these tools.

675
00:21:57,840 --> 00:21:59,720
Your deployment follows this process.

676
00:21:59,720 --> 00:22:01,080
Security scanning happens here.

677
00:22:01,080 --> 00:22:02,560
Compliance checks happen there.

678
00:22:02,560 --> 00:22:03,440
It's all automated.

679
00:22:03,440 --> 00:22:04,480
It's all consistent.

680
00:22:04,480 --> 00:22:07,240
It includes observability, setup, logging, metrics,

681
00:22:07,240 --> 00:22:09,520
tracing, alerts, already wired, already pointing

682
00:22:09,520 --> 00:22:10,680
to the right systems.

683
00:22:10,680 --> 00:22:13,240
A service that follows the golden path is automatically

684
00:22:13,240 --> 00:22:13,840
observable.

685
00:22:13,840 --> 00:22:15,600
You don't have to remember to add instrumentation.

686
00:22:15,600 --> 00:22:17,640
You don't have to figure out which monitoring tool

687
00:22:17,640 --> 00:22:18,800
the org standardized on.

688
00:22:18,800 --> 00:22:19,840
It's already there.

689
00:22:19,840 --> 00:22:21,360
It includes compliance checks.

690
00:22:21,360 --> 00:22:23,000
Your service is automatically validated

691
00:22:23,000 --> 00:22:24,600
against policy when it deploys.

692
00:22:24,600 --> 00:22:26,520
No compliance team reviewing it later.

693
00:22:26,520 --> 00:22:28,600
No security team doing a post-deploy audit.

694
00:22:28,600 --> 00:22:30,320
The policy is embedded in the path.

695
00:22:30,320 --> 00:22:32,200
Your deployment either meets the requirements

696
00:22:32,200 --> 00:22:33,440
or it doesn't deploy.

697
00:22:33,440 --> 00:22:35,080
But the golden path does not include

698
00:22:35,080 --> 00:22:36,360
is escape hatches.

699
00:22:36,360 --> 00:22:38,240
It doesn't say here's the standard way,

700
00:22:38,240 --> 00:22:39,720
but if you need something different,

701
00:22:39,720 --> 00:22:41,520
follow these 30 other procedures.

702
00:22:41,520 --> 00:22:42,720
That's not a golden path.

703
00:22:42,720 --> 00:22:44,280
That's a maze with a recommended route.

704
00:22:44,280 --> 00:22:45,560
The golden path is the route.

705
00:22:45,560 --> 00:22:46,800
If you're on it, you're good.

706
00:22:46,800 --> 00:22:48,320
If you're not, you need to talk to someone.

707
00:22:48,320 --> 00:22:50,240
This is intentional.

708
00:22:50,240 --> 00:22:52,560
The escape hatches are collaboration moments.

709
00:22:52,560 --> 00:22:54,240
The golden path handles 80%.

710
00:22:54,240 --> 00:22:57,000
The other 20% requires actual conversation

711
00:22:57,000 --> 00:22:58,080
with the platform team.

712
00:22:58,080 --> 00:22:59,960
Maybe you have a legitimate edge case.

713
00:22:59,960 --> 00:23:02,360
Maybe your domain requires a different architecture.

714
00:23:02,360 --> 00:23:03,040
That's fine.

715
00:23:03,040 --> 00:23:04,240
But you can't do it quietly.

716
00:23:04,240 --> 00:23:06,880
You can't do it by following some hidden alternative procedure.

717
00:23:06,880 --> 00:23:08,320
You have to have a conversation.

718
00:23:08,320 --> 00:23:09,920
The platform team needs to understand

719
00:23:09,920 --> 00:23:11,680
why the golden path doesn't work for you.

720
00:23:11,680 --> 00:23:12,560
They might refine it.

721
00:23:12,560 --> 00:23:13,880
They might approve an exception.

722
00:23:13,880 --> 00:23:15,240
But they'll know about it.

723
00:23:15,240 --> 00:23:17,720
The design principle underlying all of this is simple.

724
00:23:17,720 --> 00:23:20,200
Make the default choice the best choice for most teams.

725
00:23:20,200 --> 00:23:23,640
In a manual environment, the default is figure it out yourself.

726
00:23:23,640 --> 00:23:26,160
The best choice is whatever works, but you have to discover it.

727
00:23:26,160 --> 00:23:27,040
There's no default.

728
00:23:27,040 --> 00:23:29,040
There's no best practice embedded in the system.

729
00:23:29,040 --> 00:23:31,680
You explore, you experiment, you find something that works,

730
00:23:31,680 --> 00:23:33,360
or you copy what another team did.

731
00:23:33,360 --> 00:23:35,800
In a golden path environment, the default is the best choice.

732
00:23:35,800 --> 00:23:38,040
You don't explore because exploration is expensive.

733
00:23:38,040 --> 00:23:40,160
You don't experiment because experimentation

734
00:23:40,160 --> 00:23:41,440
creates variance.

735
00:23:41,440 --> 00:23:43,840
You don't copy because there's nothing else to copy.

736
00:23:43,840 --> 00:23:44,960
You follow the path.

737
00:23:44,960 --> 00:23:46,680
And the path is designed to work.

738
00:23:46,680 --> 00:23:49,480
What does using a golden path look like from a user perspective?

739
00:23:49,480 --> 00:23:50,160
It looks simple.

740
00:23:50,160 --> 00:23:53,520
You fill out a form or you run a CLI command or you use a portal.

741
00:23:53,520 --> 00:23:56,040
The form says, what's your service name, what environment,

742
00:23:56,040 --> 00:23:57,200
how many replicas do you need?

743
00:23:57,200 --> 00:23:58,760
Maybe how much memory and CPU?

744
00:23:58,760 --> 00:23:59,440
That's it.

745
00:23:59,440 --> 00:24:01,800
Five fields instead of 50, you submit.

746
00:24:01,800 --> 00:24:03,480
A few minutes later, your service exists.

747
00:24:03,480 --> 00:24:04,920
It has a CI/CD pipeline.

748
00:24:04,920 --> 00:24:05,680
It has monitoring.

749
00:24:05,680 --> 00:24:06,720
It has security scanning.

750
00:24:06,720 --> 00:24:07,760
It has compliance checks.

751
00:24:07,760 --> 00:24:08,560
It has alerts.

752
00:24:08,560 --> 00:24:09,560
It has everything.

753
00:24:09,560 --> 00:24:11,360
You don't read documentation.

754
00:24:11,360 --> 00:24:12,880
You don't make 30 decisions.

755
00:24:12,880 --> 00:24:14,800
You don't learn 15 new concepts.

756
00:24:14,800 --> 00:24:16,960
You just describe what you want and the system builds it.

757
00:24:16,960 --> 00:24:20,240
This is how you reduce CTS, not by teaching people more concepts,

758
00:24:20,240 --> 00:24:21,720
by making the concepts irrelevant.

759
00:24:21,720 --> 00:24:22,800
The platform handles them.

760
00:24:22,800 --> 00:24:24,200
You don't need to understand them.

761
00:24:24,200 --> 00:24:25,680
The measurement that matters is adoption.

762
00:24:25,680 --> 00:24:28,000
What percentage of new services use the golden path?

763
00:24:28,000 --> 00:24:29,720
And how fast do services go live?

764
00:24:29,720 --> 00:24:31,440
If adoption is below 70%,

765
00:24:31,440 --> 00:24:33,040
your golden path isn't good enough.

766
00:24:33,040 --> 00:24:36,240
If time to first deploy is still measured in weeks instead of hours,

767
00:24:36,240 --> 00:24:37,760
you haven't actually solved the problem.

768
00:24:37,760 --> 00:24:41,000
The metrics tell you whether the path is actually working.

769
00:24:41,000 --> 00:24:43,320
Infrastructure as code as the foundation,

770
00:24:43,320 --> 00:24:44,800
you can define a golden path.

771
00:24:44,800 --> 00:24:46,560
You can build beautiful documentation.

772
00:24:46,560 --> 00:24:48,360
You can even create the best form in the world

773
00:24:48,360 --> 00:24:50,560
for teams to request infrastructure.

774
00:24:50,560 --> 00:24:52,400
But none of it matters if you can't actually deliver

775
00:24:52,400 --> 00:24:53,800
what you promised at scale.

776
00:24:53,800 --> 00:24:56,440
And you can't deliver at scale without infrastructure as code.

777
00:24:56,440 --> 00:24:58,120
ISE is straightforward in concept.

778
00:24:58,120 --> 00:25:01,600
It means expressing your infrastructure as version controlled code.

779
00:25:01,600 --> 00:25:03,720
Instead of clicking buttons in the Cloud Console,

780
00:25:03,720 --> 00:25:08,760
you write files, bicep files, terraform files, or CloudFormation templates.

781
00:25:08,760 --> 00:25:11,240
These files describe exactly what you want to exist.

782
00:25:11,240 --> 00:25:12,440
You commit them to Git.

783
00:25:12,440 --> 00:25:14,520
You review them like you review application code.

784
00:25:14,520 --> 00:25:15,960
You deploy them through pipelines.

785
00:25:15,960 --> 00:25:20,320
They are auditable, reproducible, and trackable.

786
00:25:20,320 --> 00:25:22,840
The word reproducible is doing a lot of work here.

787
00:25:22,840 --> 00:25:24,960
It means if someone asks if you can stand up

788
00:25:24,960 --> 00:25:27,320
an identical copy of a service in another region,

789
00:25:27,320 --> 00:25:28,240
the answer is yes.

790
00:25:28,240 --> 00:25:30,480
You don't rely on someone's memory of which buttons

791
00:25:30,480 --> 00:25:32,520
to click or what settings to choose.

792
00:25:32,520 --> 00:25:33,640
You run the same code.

793
00:25:33,640 --> 00:25:35,880
You get the same result every single time.

794
00:25:35,880 --> 00:25:39,120
Auditability means you can see exactly what changed when it changed

795
00:25:39,120 --> 00:25:40,200
and who made the change.

796
00:25:40,200 --> 00:25:41,360
It is all in Git.

797
00:25:41,360 --> 00:25:44,080
If a security team needs to know what firewall rules were added

798
00:25:44,080 --> 00:25:45,840
three months ago, they look at the Git history.

799
00:25:45,840 --> 00:25:48,800
They see the PR, they see the approval, they see the deployment.

800
00:25:48,800 --> 00:25:49,640
There is no mystery.

801
00:25:49,640 --> 00:25:53,240
There is no, I think we added something, but nobody documented it.

802
00:25:53,240 --> 00:25:55,640
The infrastructure is documented by its own code.

803
00:25:55,640 --> 00:25:57,280
But the real power is enforcement.

804
00:25:57,280 --> 00:26:00,160
When infrastructure is manual, governance is a suggestion.

805
00:26:00,160 --> 00:26:01,080
You write a policy.

806
00:26:01,080 --> 00:26:02,160
You hope people follow it.

807
00:26:02,160 --> 00:26:04,720
When infrastructure is code, governance is a barrier.

808
00:26:04,720 --> 00:26:06,960
Policies become automated checks.

809
00:26:06,960 --> 00:26:08,400
They run on every deployment.

810
00:26:08,400 --> 00:26:10,200
If your infrastructure violates a policy,

811
00:26:10,200 --> 00:26:11,480
the deployment doesn't proceed.

812
00:26:11,480 --> 00:26:12,840
You didn't have to think about compliance

813
00:26:12,840 --> 00:26:14,320
because the system enforced it for you.

814
00:26:14,320 --> 00:26:16,240
You can't deploy an unencrypted database

815
00:26:16,240 --> 00:26:17,840
because the policy won't let you.

816
00:26:17,840 --> 00:26:19,320
You can't create a public IP address

817
00:26:19,320 --> 00:26:20,600
because the policy blocks it.

818
00:26:20,600 --> 00:26:22,880
You can't open a firewall rule to all traffic

819
00:26:22,880 --> 00:26:24,480
because the system won't allow it.

820
00:26:24,480 --> 00:26:25,720
This is the governance layer.

821
00:26:25,720 --> 00:26:27,680
It isn't a gate that blocks after the fact.

822
00:26:27,680 --> 00:26:30,600
It is a guardrail that prevents the wrong action in the first place.

823
00:26:30,600 --> 00:26:33,040
So the question becomes, which tool do you use?

824
00:26:33,040 --> 00:26:35,040
Bicep and Terraform are the two serious choices

825
00:26:35,040 --> 00:26:36,280
for Azure organizations.

826
00:26:36,280 --> 00:26:38,120
Bicep is Microsoft's language.

827
00:26:38,120 --> 00:26:39,720
It compiles to arm templates.

828
00:26:39,720 --> 00:26:41,040
It is native to Azure.

829
00:26:41,040 --> 00:26:43,040
When Microsoft releases a new Azure service,

830
00:26:43,040 --> 00:26:44,560
bicep supports it immediately.

831
00:26:44,560 --> 00:26:46,600
There is no wait, no provider lag,

832
00:26:46,600 --> 00:26:49,440
and no waiting for a third party provider to catch up.

833
00:26:49,440 --> 00:26:51,880
bicep integrates tightly with Azure policy.

834
00:26:51,880 --> 00:26:54,080
You can express governance rules in the same language

835
00:26:54,080 --> 00:26:55,360
as your infrastructure.

836
00:26:55,360 --> 00:26:58,480
Everything feels connected because it is all built on the same platform.

837
00:26:58,480 --> 00:26:59,800
Terraform is agnostic.

838
00:26:59,800 --> 00:27:03,240
It works on Azure, AWS, GCP and dozens of other platforms.

839
00:27:03,240 --> 00:27:05,320
This is powerful if you are multi-cloud.

840
00:27:05,320 --> 00:27:07,600
One language, one workflow.

841
00:27:07,600 --> 00:27:10,600
Consistent across your entire infrastructure portfolio.

842
00:27:10,600 --> 00:27:13,160
But the trade-off is that Terraform relies on provider plugins.

843
00:27:13,160 --> 00:27:15,720
Those plugins are maintained by the community.

844
00:27:15,720 --> 00:27:17,440
When Azure releases a new service,

845
00:27:17,440 --> 00:27:20,560
someone has to build support for it in the Terraform provider.

846
00:27:20,560 --> 00:27:21,320
That takes time.

847
00:27:21,320 --> 00:27:23,080
Sometimes weeks, sometimes months.

848
00:27:23,080 --> 00:27:24,560
You are always slightly behind.

849
00:27:24,560 --> 00:27:28,120
For a pure Azure organization, bicep wins on native integration.

850
00:27:28,120 --> 00:27:31,520
For a multi-cloud organization, Terraform wins on consistency.

851
00:27:31,520 --> 00:27:33,040
The choice depends on your strategy.

852
00:27:33,040 --> 00:27:35,520
But either way, you need the ISE life cycle.

853
00:27:35,520 --> 00:27:39,000
You author the code, you push it to a branch, appear, reviews it.

854
00:27:39,000 --> 00:27:40,480
They make sure it follows your patterns.

855
00:27:40,480 --> 00:27:42,200
They verify the policy implications.

856
00:27:42,200 --> 00:27:43,800
They approve or suggest changes.

857
00:27:43,800 --> 00:27:46,000
The code is deployed to a non-production environment.

858
00:27:46,000 --> 00:27:47,400
It runs there. You verify it works.

859
00:27:47,400 --> 00:27:50,120
It goes to production, but first in audit mode, the policy runs.

860
00:27:50,120 --> 00:27:51,440
It logs what it would enforce.

861
00:27:51,440 --> 00:27:53,040
You verify nothing breaks.

862
00:27:53,040 --> 00:27:55,320
Now the policy actually blocks violations.

863
00:27:55,320 --> 00:27:57,800
It is live. It is protecting your infrastructure.

864
00:27:57,800 --> 00:28:01,920
This life cycle takes infrastructure from a reactive problem to a proactive system.

865
00:28:01,920 --> 00:28:03,680
Violations aren't discovered in audits.

866
00:28:03,680 --> 00:28:05,720
They are prevented at deployment time.

867
00:28:05,720 --> 00:28:06,760
And here is what matters.

868
00:28:06,760 --> 00:28:08,640
Infrastructure changes become as traceable,

869
00:28:08,640 --> 00:28:11,200
reviewable, and roll backable as application code.

870
00:28:11,200 --> 00:28:13,640
If something goes wrong, you don't just know about it.

871
00:28:13,640 --> 00:28:14,960
You know exactly what changed.

872
00:28:14,960 --> 00:28:15,800
You can revert.

873
00:28:15,800 --> 00:28:17,720
You can see who made the change and why.

874
00:28:17,720 --> 00:28:19,240
You have a complete audit trail.

875
00:28:19,240 --> 00:28:22,320
This is what makes large-scale infrastructure governance possible.

876
00:28:22,320 --> 00:28:26,720
Not policies written in documents, not reviews done manually.

877
00:28:26,720 --> 00:28:28,800
Code that enforces itself.

878
00:28:28,800 --> 00:28:30,240
Policy as code.

879
00:28:30,240 --> 00:28:31,600
Embedding governance.

880
00:28:31,600 --> 00:28:33,760
Infrastructure as code is the foundation.

881
00:28:33,760 --> 00:28:35,080
But code alone isn't enough.

882
00:28:35,080 --> 00:28:37,040
Code is just text. It describes what you want.

883
00:28:37,040 --> 00:28:38,320
It doesn't prevent what you don't want.

884
00:28:38,320 --> 00:28:39,800
That's where policy as code comes in.

885
00:28:39,800 --> 00:28:42,960
Policy as code is the practice of expressing your governance rules

886
00:28:42,960 --> 00:28:45,600
as code that runs automatically during deployment.

887
00:28:45,600 --> 00:28:49,520
Security requirements, compliance rules, cost controls, architectural standards.

888
00:28:49,520 --> 00:28:51,720
It isn't a checklist that someone reviews manually.

889
00:28:51,720 --> 00:28:54,160
It isn't a policy document that people are supposed to read.

890
00:28:54,160 --> 00:28:57,640
It is code that runs, evaluates your infrastructure, and makes a decision.

891
00:28:57,640 --> 00:28:59,200
This is allowed, or this is not.

892
00:28:59,200 --> 00:29:03,080
The distinction matters because everything changes when governance becomes automatic.

893
00:29:03,080 --> 00:29:06,920
When your security policy says, all databases must be encrypted.

894
00:29:06,920 --> 00:29:08,120
That is a policy.

895
00:29:08,120 --> 00:29:12,280
When you express it as code that blocks the deployment of any unencrypted database

896
00:29:12,280 --> 00:29:14,880
that is policy as code, one is advisory.

897
00:29:14,880 --> 00:29:16,040
The other is a guardrail.

898
00:29:16,040 --> 00:29:17,880
Azure policy is the native tool for this.

899
00:29:17,880 --> 00:29:19,120
You define a policy.

900
00:29:19,120 --> 00:29:22,240
It is a set of rules that evaluate resource configurations.

901
00:29:22,240 --> 00:29:24,240
Does this database have encryption enabled?

902
00:29:24,240 --> 00:29:26,880
Is this storage account using secure transfer only?

903
00:29:26,880 --> 00:29:30,240
Is this network security group exposing this port to the internet?

904
00:29:30,240 --> 00:29:31,680
The policy is the question.

905
00:29:31,680 --> 00:29:33,120
The enforcement is the answer.

906
00:29:33,120 --> 00:29:35,360
Then you assign that policy to a scope,

907
00:29:35,360 --> 00:29:37,720
usually a management group or a subscription.

908
00:29:37,720 --> 00:29:40,720
Once assigned, every resource created within that scope

909
00:29:40,720 --> 00:29:42,800
is evaluated against the policy.

910
00:29:42,800 --> 00:29:45,040
Automatically, without human review,

911
00:29:45,040 --> 00:29:46,520
the enforcement model is crucial.

912
00:29:46,520 --> 00:29:48,080
You can run a policy in audit mode.

913
00:29:48,080 --> 00:29:50,720
It evaluates your infrastructure and logs violations,

914
00:29:50,720 --> 00:29:52,160
but it doesn't block anything.

915
00:29:52,160 --> 00:29:53,080
This is how you test.

916
00:29:53,080 --> 00:29:54,240
You see what would break.

917
00:29:54,240 --> 00:29:55,680
You give teams time to adjust.

918
00:29:55,680 --> 00:29:56,920
Then you flip it to deny mode.

919
00:29:56,920 --> 00:29:59,680
Now, the policy actually blocks deployments that violate it.

920
00:29:59,680 --> 00:30:01,600
This is the inverse of the manual approach.

921
00:30:01,600 --> 00:30:04,320
In manual governance, you hope people follow the rules.

922
00:30:04,320 --> 00:30:07,960
In policy-driven governance, the rules are enforced by the system.

923
00:30:07,960 --> 00:30:09,600
Here is what changes for a developer.

924
00:30:09,600 --> 00:30:11,440
They don't need to know the security policy.

925
00:30:11,440 --> 00:30:13,720
They don't need to understand compliance requirements.

926
00:30:13,720 --> 00:30:15,000
They follow the golden path.

927
00:30:15,000 --> 00:30:18,000
The golden path is pre-configured with all the policy guardrails

928
00:30:18,000 --> 00:30:20,640
already baked in when they deploy the policy's run.

929
00:30:20,640 --> 00:30:23,120
They are already compliant because the path ensures it.

930
00:30:23,120 --> 00:30:24,880
The developer experience is simple.

931
00:30:24,880 --> 00:30:26,880
They provision a database through the platform.

932
00:30:26,880 --> 00:30:28,240
The system provisions it.

933
00:30:28,240 --> 00:30:29,080
It is encrypted.

934
00:30:29,080 --> 00:30:30,000
It has backups.

935
00:30:30,000 --> 00:30:31,680
It has the right access controls.

936
00:30:31,680 --> 00:30:33,120
It meets every policy.

937
00:30:33,120 --> 00:30:35,160
Not because the developer made those decisions,

938
00:30:35,160 --> 00:30:36,520
but because the system made them

939
00:30:36,520 --> 00:30:38,280
and the policy validated them.

940
00:30:38,280 --> 00:30:39,960
This is where governance stops being a burden

941
00:30:39,960 --> 00:30:41,720
and becomes a platform capability.

942
00:30:41,720 --> 00:30:43,160
Measurement shifts, too.

943
00:30:43,160 --> 00:30:45,480
Instead of asking if you are compliant after an audit,

944
00:30:45,480 --> 00:30:47,560
you ask for your real-time compliance score.

945
00:30:47,560 --> 00:30:50,520
This is the percentage of resources that meet policy.

946
00:30:50,520 --> 00:30:52,400
If it is 95%, you are in good shape.

947
00:30:52,400 --> 00:30:55,520
If it is 70%, you have violations that need attention.

948
00:30:55,520 --> 00:30:58,960
And you know exactly which resources violate which policies

949
00:30:58,960 --> 00:31:00,480
because it is all tracked.

950
00:31:00,480 --> 00:31:02,440
Time to compliance becomes a metric.

951
00:31:02,440 --> 00:31:05,480
When a violation is discovered, how long until it is fixed?

952
00:31:05,480 --> 00:31:07,640
In a manual system, this could be weeks.

953
00:31:07,640 --> 00:31:09,520
Someone notices the violation.

954
00:31:09,520 --> 00:31:10,840
Someone files a ticket.

955
00:31:10,840 --> 00:31:12,040
Someone reviews it.

956
00:31:12,040 --> 00:31:13,320
Someone fixes it.

957
00:31:13,320 --> 00:31:14,760
The cycle is slow.

958
00:31:14,760 --> 00:31:16,080
In a policy-driven system,

959
00:31:16,080 --> 00:31:17,760
the owner gets notified immediately.

960
00:31:17,760 --> 00:31:19,520
The violation is logged.

961
00:31:19,520 --> 00:31:21,200
The owner fixes it.

962
00:31:21,200 --> 00:31:23,840
The metric is days, not weeks.

963
00:31:23,840 --> 00:31:26,000
The real outcome is a shift in responsibility.

964
00:31:26,000 --> 00:31:27,480
Compliance stops being something

965
00:31:27,480 --> 00:31:29,560
the security team enforces on everyone else.

966
00:31:29,560 --> 00:31:32,080
It becomes something the platform enforces for everyone.

967
00:31:32,080 --> 00:31:34,640
Security teams move from gatekeepers to architects.

968
00:31:34,640 --> 00:31:36,920
They design policies that are sensible and enforceable.

969
00:31:36,920 --> 00:31:38,840
They test them, they roll them out.

970
00:31:38,840 --> 00:31:40,040
Then the system does the work.

971
00:31:40,040 --> 00:31:42,800
No manual review, no compliance theater,

972
00:31:42,800 --> 00:31:45,160
just automatic continuous validation.

973
00:31:45,160 --> 00:31:46,840
This is how you scale governance,

974
00:31:46,840 --> 00:31:48,840
not by hiring more security reviewers,

975
00:31:48,840 --> 00:31:50,680
by making security automatic,

976
00:31:50,680 --> 00:31:52,440
not by writing stricter policies,

977
00:31:52,440 --> 00:31:54,600
by embedding policies into the systems

978
00:31:54,600 --> 00:31:56,400
where violations are impossible.

979
00:31:56,400 --> 00:31:58,440
When a developer can't create something insecure

980
00:31:58,440 --> 00:32:00,000
because the policy won't allow it,

981
00:32:00,000 --> 00:32:01,680
compliance isn't a negotiation.

982
00:32:01,680 --> 00:32:02,680
It is a fact.

983
00:32:02,680 --> 00:32:05,400
Team topologies, organizing for platform success.

984
00:32:05,400 --> 00:32:06,800
Structure is everything.

985
00:32:06,800 --> 00:32:08,880
You can build the best golden path in the world

986
00:32:08,880 --> 00:32:11,640
and you can have perfect IAC and policy automation,

987
00:32:11,640 --> 00:32:14,360
but none of it works if your organization is structured wrong.

988
00:32:14,360 --> 00:32:16,760
And most organizations are structured wrong for this model.

989
00:32:16,760 --> 00:32:19,480
The framework that fixes this is called team topologies.

990
00:32:19,480 --> 00:32:21,920
It's a way of thinking about how teams should be organized,

991
00:32:21,920 --> 00:32:23,360
not based on technical function,

992
00:32:23,360 --> 00:32:26,280
but based on how cognitive load flows through the organization.

993
00:32:26,280 --> 00:32:28,800
Team topologies defines four team types.

994
00:32:28,800 --> 00:32:31,520
You've probably heard of streamlined teams and platform teams.

995
00:32:31,520 --> 00:32:32,480
Those are the core.

996
00:32:32,480 --> 00:32:34,280
But the full picture requires all four.

997
00:32:34,280 --> 00:32:36,120
Stream aligned teams are product teams.

998
00:32:36,120 --> 00:32:38,240
They own a complete value stream from end to end.

999
00:32:38,240 --> 00:32:40,160
They own the features, they own the deployment,

1000
00:32:40,160 --> 00:32:42,320
they own the monitoring, they own the decisions,

1001
00:32:42,320 --> 00:32:44,960
they're not waiting on another team to move infrastructure

1002
00:32:44,960 --> 00:32:47,560
or approve deployments or explain how something works.

1003
00:32:47,560 --> 00:32:48,200
They own it.

1004
00:32:48,200 --> 00:32:49,640
This is the DevOps principle,

1005
00:32:49,640 --> 00:32:52,040
but applied to products, not to infrastructure.

1006
00:32:52,040 --> 00:32:53,440
Platform teams are the inverse.

1007
00:32:53,440 --> 00:32:54,760
They don't own products.

1008
00:32:54,760 --> 00:32:57,000
They own the capabilities that products consume.

1009
00:32:57,000 --> 00:32:58,200
They own the golden path.

1010
00:32:58,200 --> 00:32:59,920
They own the infrastructure automation.

1011
00:32:59,920 --> 00:33:01,200
They own the policy enforcement.

1012
00:33:01,200 --> 00:33:02,920
They own the CI/CD system.

1013
00:33:02,920 --> 00:33:04,680
They own the observability platform.

1014
00:33:04,680 --> 00:33:06,440
They're the infrastructure as product.

1015
00:33:06,440 --> 00:33:08,480
Every stream aligned team is their customer.

1016
00:33:08,480 --> 00:33:09,760
Then there are enabling teams.

1017
00:33:09,760 --> 00:33:11,280
These are temporary expert teams.

1018
00:33:11,280 --> 00:33:12,400
A cloud enablement team.

1019
00:33:12,400 --> 00:33:15,680
A security team that helps other teams adopt security practices.

1020
00:33:15,680 --> 00:33:17,960
An SRE team that coaches on observability.

1021
00:33:17,960 --> 00:33:19,720
These teams don't own anything permanently.

1022
00:33:19,720 --> 00:33:21,200
They own capability transfer.

1023
00:33:21,200 --> 00:33:23,920
They come in, help a stream aligned team learn a new practice,

1024
00:33:23,920 --> 00:33:26,200
embed that practice into the platform teams offerings,

1025
00:33:26,200 --> 00:33:27,040
and move on.

1026
00:33:27,040 --> 00:33:29,560
The fourth type is complicated subsystem teams.

1027
00:33:29,560 --> 00:33:31,360
These are teams that own a piece of infrastructure

1028
00:33:31,360 --> 00:33:34,360
that's so technically complex that it needs dedicated experts.

1029
00:33:34,360 --> 00:33:35,880
Maybe it's your Kubernetes cluster.

1030
00:33:35,880 --> 00:33:37,720
Maybe it's your database replication layer.

1031
00:33:37,720 --> 00:33:39,320
Maybe it's your distributed cache.

1032
00:33:39,320 --> 00:33:41,880
These teams exist to handle complexity that's better managed

1033
00:33:41,880 --> 00:33:44,560
by specialists than spread across the product teams.

1034
00:33:44,560 --> 00:33:45,800
Now, the interaction modes.

1035
00:33:45,800 --> 00:33:47,320
This is where it gets practical.

1036
00:33:47,320 --> 00:33:49,920
Collaboration is when two teams work closely together.

1037
00:33:49,920 --> 00:33:51,800
Lots of back and forth, shared goals,

1038
00:33:51,800 --> 00:33:53,280
figuring things out together.

1039
00:33:53,280 --> 00:33:55,320
This is appropriate during discovery.

1040
00:33:55,320 --> 00:33:57,200
When the platform team and a stream aligned team

1041
00:33:57,200 --> 00:34:00,080
are designing a new capability together, they collaborate.

1042
00:34:00,080 --> 00:34:02,200
When an enabling team is coaching a product team,

1043
00:34:02,200 --> 00:34:03,200
they collaborate.

1044
00:34:03,200 --> 00:34:04,400
But collaboration is exhausting.

1045
00:34:04,400 --> 00:34:06,000
It requires constant synchronization.

1046
00:34:06,000 --> 00:34:07,480
It doesn't scale.

1047
00:34:07,480 --> 00:34:09,400
X as a service is the steady state.

1048
00:34:09,400 --> 00:34:10,800
One team provides something.

1049
00:34:10,800 --> 00:34:12,160
Other teams consume it.

1050
00:34:12,160 --> 00:34:15,040
The interaction is through an interface, not through conversation.

1051
00:34:15,040 --> 00:34:17,080
The platform team provides a database service.

1052
00:34:17,080 --> 00:34:18,240
Stream aligned teams use it.

1053
00:34:18,240 --> 00:34:19,040
No collaboration.

1054
00:34:19,040 --> 00:34:19,560
No meetings.

1055
00:34:19,560 --> 00:34:20,560
You request a database.

1056
00:34:20,560 --> 00:34:21,840
The platform provisions it.

1057
00:34:21,840 --> 00:34:24,160
Done facilitation is the enabling team mode.

1058
00:34:24,160 --> 00:34:26,920
It's coaching, not management, temporary pairing.

1059
00:34:26,920 --> 00:34:29,240
Teaching, not doing.

1060
00:34:29,240 --> 00:34:32,080
An enabling team helps a product team adopt a new practice.

1061
00:34:32,080 --> 00:34:34,440
Once the practice is embedded in the platform,

1062
00:34:34,440 --> 00:34:36,800
once it becomes part of the golden path,

1063
00:34:36,800 --> 00:34:38,240
the enabling work is done.

1064
00:34:38,240 --> 00:34:40,280
The practice is now X as a service.

1065
00:34:40,280 --> 00:34:42,520
The cognitive load principle underlying all of this

1066
00:34:42,520 --> 00:34:43,200
is crucial.

1067
00:34:43,200 --> 00:34:45,800
Team boundaries aren't drawn to maximize technical elegance.

1068
00:34:45,800 --> 00:34:48,400
They're drawn to minimize the mental burden on every team.

1069
00:34:48,400 --> 00:34:50,600
A stream aligned team shouldn't have to understand

1070
00:34:50,600 --> 00:34:53,720
distributed systems, cloud cost optimization,

1071
00:34:53,720 --> 00:34:55,760
policy design, and compliance requirements.

1072
00:34:55,760 --> 00:34:57,480
That's too much cognitive load.

1073
00:34:57,480 --> 00:34:59,520
The platform takes those concerns off the table.

1074
00:34:59,520 --> 00:35:02,320
Now, the stream aligned team can focus on features.

1075
00:35:02,320 --> 00:35:04,160
A platform team shouldn't be forced into supporting

1076
00:35:04,160 --> 00:35:06,000
50 different infrastructure variations.

1077
00:35:06,000 --> 00:35:07,800
That's cognitive overload for them too,

1078
00:35:07,800 --> 00:35:08,600
but they standardize.

1079
00:35:08,600 --> 00:35:10,200
They build for the 80% case,

1080
00:35:10,200 --> 00:35:12,280
the rare exceptions go through collaboration mode,

1081
00:35:12,280 --> 00:35:14,640
but those are genuine exceptions, not the default.

1082
00:35:14,640 --> 00:35:16,560
An enabling team shouldn't be permanent.

1083
00:35:16,560 --> 00:35:18,000
They don't scale that way.

1084
00:35:18,000 --> 00:35:21,080
The moment an enabling team has to support everything permanently,

1085
00:35:21,080 --> 00:35:22,320
they become a bottleneck.

1086
00:35:22,320 --> 00:35:25,440
They're supposed to transfer capability, then shift focus.

1087
00:35:25,440 --> 00:35:28,360
This organizational model is what makes everything else work.

1088
00:35:28,360 --> 00:35:30,840
ISE and policy and golden paths are tools.

1089
00:35:30,840 --> 00:35:32,800
Team topologies is the structure that determines

1090
00:35:32,800 --> 00:35:34,840
how those tools actually function at scale.

1091
00:35:34,840 --> 00:35:37,000
Without this structure, you have platform chaos.

1092
00:35:37,000 --> 00:35:38,480
With it, you have clarity.

1093
00:35:38,480 --> 00:35:40,080
Stream aligned teams move fast.

1094
00:35:40,080 --> 00:35:41,800
Platform teams maintain standards,

1095
00:35:41,800 --> 00:35:43,640
enabling team spread capability.

1096
00:35:43,640 --> 00:35:45,280
And everyone has clear boundaries around

1097
00:35:45,280 --> 00:35:47,120
what they're responsible for understanding

1098
00:35:47,120 --> 00:35:49,120
that clarity is worth more than any tool.

1099
00:35:49,120 --> 00:35:51,640
The platform product mindset.

1100
00:35:51,640 --> 00:35:53,240
Here's where the real shift happens.

1101
00:35:53,240 --> 00:35:55,040
Because organizational structure alone

1102
00:35:55,040 --> 00:35:56,520
doesn't guarantee success.

1103
00:35:56,520 --> 00:35:58,160
You can have the right teams in place

1104
00:35:58,160 --> 00:36:00,360
and still build a platform nobody uses.

1105
00:36:00,360 --> 00:36:02,280
The difference between a platform that thrives

1106
00:36:02,280 --> 00:36:04,640
and the platform that becomes overhead is mindset.

1107
00:36:04,640 --> 00:36:07,040
Traditional infrastructure thinking treats the platform

1108
00:36:07,040 --> 00:36:08,760
as invisible infrastructure.

1109
00:36:08,760 --> 00:36:09,960
It should exist.

1110
00:36:09,960 --> 00:36:10,800
It should work.

1111
00:36:10,800 --> 00:36:12,280
It shouldn't demand attention.

1112
00:36:12,280 --> 00:36:14,240
You measure it on uptime and cost.

1113
00:36:14,240 --> 00:36:16,760
If it's running and it's affordable, success.

1114
00:36:16,760 --> 00:36:17,960
Product thinking is different.

1115
00:36:17,960 --> 00:36:19,680
The platform isn't infrastructure.

1116
00:36:19,680 --> 00:36:20,520
It's a product.

1117
00:36:20,520 --> 00:36:22,760
It has customers, in this case, developers.

1118
00:36:22,760 --> 00:36:24,360
And like any product, it's success.

1119
00:36:24,360 --> 00:36:26,640
Depends on whether those customers actually want to use it.

1120
00:36:26,640 --> 00:36:27,840
This distinction sounds academic.

1121
00:36:27,840 --> 00:36:28,440
It's not.

1122
00:36:28,440 --> 00:36:30,560
It changes everything about how you operate.

1123
00:36:30,560 --> 00:36:32,120
A product has a road map.

1124
00:36:32,120 --> 00:36:33,480
Not a backlog of technical debt

1125
00:36:33,480 --> 00:36:35,720
that accumulates until you're forced to address it.

1126
00:36:35,720 --> 00:36:38,160
A road map, a direction, planned improvements,

1127
00:36:38,160 --> 00:36:39,960
things you're removing, things you're adding,

1128
00:36:39,960 --> 00:36:42,400
and the road map is driven by what your customers need,

1129
00:36:42,400 --> 00:36:44,600
not by what your engineers think is cool.

1130
00:36:44,600 --> 00:36:46,080
A product has user research.

1131
00:36:46,080 --> 00:36:47,920
You don't guess what developers want.

1132
00:36:47,920 --> 00:36:48,760
You ask them.

1133
00:36:48,760 --> 00:36:50,520
You watch how they use the platform.

1134
00:36:50,520 --> 00:36:52,200
You pay attention to where they get stuck.

1135
00:36:52,200 --> 00:36:54,600
You notice the patterns in the requests they make.

1136
00:36:54,600 --> 00:36:56,680
You run surveys, you conduct interviews,

1137
00:36:56,680 --> 00:36:58,400
you understand the friction points,

1138
00:36:58,400 --> 00:36:59,880
a product has feedback loops.

1139
00:36:59,880 --> 00:37:01,880
When a developer struggles with the platform,

1140
00:37:01,880 --> 00:37:03,280
that's not a personal failure.

1141
00:37:03,280 --> 00:37:04,600
That's a product failure.

1142
00:37:04,600 --> 00:37:06,200
The platform didn't meet their needs.

1143
00:37:06,200 --> 00:37:07,760
The documentation wasn't clear enough.

1144
00:37:07,760 --> 00:37:09,320
The workflow was too complicated.

1145
00:37:09,320 --> 00:37:10,760
The feature didn't do what they expected.

1146
00:37:10,760 --> 00:37:13,120
You treat feedback as a gift, not as criticism.

1147
00:37:13,120 --> 00:37:14,760
A product has deprecation policies.

1148
00:37:14,760 --> 00:37:15,680
Nothing is forever.

1149
00:37:15,680 --> 00:37:17,920
Sometimes a feature was the right answer when you built it,

1150
00:37:17,920 --> 00:37:19,360
but circumstances change.

1151
00:37:19,360 --> 00:37:21,600
You don't leave it in place forever just because it exists.

1152
00:37:21,600 --> 00:37:23,000
You announce when something is ending.

1153
00:37:23,000 --> 00:37:24,560
You give teams time to migrate.

1154
00:37:24,560 --> 00:37:27,240
You provide clear guidance on what replaces it.

1155
00:37:27,240 --> 00:37:28,840
You do this in the same structured way

1156
00:37:28,840 --> 00:37:30,560
that a commercial product would.

1157
00:37:30,560 --> 00:37:31,920
A product has SLAs.

1158
00:37:31,920 --> 00:37:33,080
You commit to availability.

1159
00:37:33,080 --> 00:37:34,480
You commit to response times.

1160
00:37:34,480 --> 00:37:35,480
You commit to performance.

1161
00:37:35,480 --> 00:37:38,280
If you fail to deliver, you know about it and you fix it.

1162
00:37:38,280 --> 00:37:40,600
This matters because your customers depend on you.

1163
00:37:40,600 --> 00:37:42,200
If your CI/CD platform is down,

1164
00:37:42,200 --> 00:37:43,480
every developer is blocked.

1165
00:37:43,480 --> 00:37:44,520
That's not an inconvenience.

1166
00:37:44,520 --> 00:37:45,720
That's a business impact.

1167
00:37:45,720 --> 00:37:47,200
Now here's the crucial insight.

1168
00:37:47,200 --> 00:37:49,880
Adoption is the only metric that actually matters.

1169
00:37:49,880 --> 00:37:51,480
If teams aren't using your platform,

1170
00:37:51,480 --> 00:37:53,240
it's not because they're incompetent.

1171
00:37:53,240 --> 00:37:55,280
It's not because they're lazy or stubborn.

1172
00:37:55,280 --> 00:37:58,120
It's because the platform isn't solving their problem well enough.

1173
00:37:58,120 --> 00:38:00,000
Maybe it's slower than their work around.

1174
00:38:00,000 --> 00:38:01,920
Maybe the documentation is confusing.

1175
00:38:01,920 --> 00:38:03,840
Maybe the feature they need isn't there.

1176
00:38:03,840 --> 00:38:04,800
Maybe they tried it once.

1177
00:38:04,800 --> 00:38:05,960
It didn't work and they gave up.

1178
00:38:05,960 --> 00:38:07,080
The reason doesn't matter.

1179
00:38:07,080 --> 00:38:09,200
The fact is they chose something else.

1180
00:38:09,200 --> 00:38:10,160
When you measure adoption,

1181
00:38:10,160 --> 00:38:11,360
you get immediate feedback

1182
00:38:11,360 --> 00:38:13,320
on whether your product is actually working.

1183
00:38:13,320 --> 00:38:14,600
Adoption isn't aspirational.

1184
00:38:14,600 --> 00:38:15,520
It's the ground truth.

1185
00:38:15,520 --> 00:38:17,080
Either teams use it or they don't.

1186
00:38:17,080 --> 00:38:19,040
This drives the metrics that matter.

1187
00:38:19,040 --> 00:38:20,800
Net promoter score for the platform.

1188
00:38:20,800 --> 00:38:22,880
Would developers recommend it to their peers?

1189
00:38:22,880 --> 00:38:24,560
How many teams are using the golden parts

1190
00:38:24,560 --> 00:38:25,840
versus rolling their own?

1191
00:38:25,840 --> 00:38:27,480
How fast can a new service go live?

1192
00:38:27,480 --> 00:38:29,040
What percentage of infrastructure requests

1193
00:38:29,040 --> 00:38:30,760
are self-service versus tickets?

1194
00:38:30,760 --> 00:38:32,760
These numbers tell you whether the product is good.

1195
00:38:32,760 --> 00:38:33,880
When adoption is high,

1196
00:38:33,880 --> 00:38:35,880
your platform is solving a real problem.

1197
00:38:35,880 --> 00:38:38,040
When adoption is low, your platform has work to do.

1198
00:38:38,040 --> 00:38:40,000
No excuse is no blame, just data.

1199
00:38:40,000 --> 00:38:41,560
And data drives the roadmap.

1200
00:38:41,560 --> 00:38:43,480
This is how platforms stop being overhead

1201
00:38:43,480 --> 00:38:44,600
and become enablement.

1202
00:38:44,600 --> 00:38:47,360
When you design for users instead of for technical perfection,

1203
00:38:47,360 --> 00:38:48,400
adoption follows.

1204
00:38:48,400 --> 00:38:50,960
When you measure adoption and make it the success metric,

1205
00:38:50,960 --> 00:38:52,160
everything else aligns.

1206
00:38:52,160 --> 00:38:54,440
Every decision gets evaluated through one lens.

1207
00:38:54,440 --> 00:38:56,680
Does this help developers move faster?

1208
00:38:56,680 --> 00:38:58,280
That lens changes the organization.

1209
00:38:58,280 --> 00:38:59,880
Self-service as the default.

1210
00:38:59,880 --> 00:39:02,440
The product mindset changes how your platform operates,

1211
00:39:02,440 --> 00:39:05,320
but it only works if there is actual infrastructure behind it,

1212
00:39:05,320 --> 00:39:07,000
shifting from thinking like a product

1213
00:39:07,000 --> 00:39:09,120
to actually being one means removing friction.

1214
00:39:09,120 --> 00:39:12,040
You have to stop developers from reaching for something else.

1215
00:39:12,040 --> 00:39:13,600
Self-service is the mechanism.

1216
00:39:13,600 --> 00:39:16,280
It is the difference between a platform that enables

1217
00:39:16,280 --> 00:39:18,360
and one that constrains true self-service

1218
00:39:18,360 --> 00:39:21,040
means developers do what they need without asking for permission.

1219
00:39:21,040 --> 00:39:23,360
They provision an environment, they create a database,

1220
00:39:23,360 --> 00:39:26,720
they set up a CI/CD pipeline, they configure monitoring.

1221
00:39:26,720 --> 00:39:29,520
All without filing a ticket, all without waiting for approval,

1222
00:39:29,520 --> 00:39:32,080
all without having a conversation with the platform team.

1223
00:39:32,080 --> 00:39:33,080
This sounds dangerous.

1224
00:39:33,080 --> 00:39:35,440
You might think this leads to chaos or security gaps,

1225
00:39:35,440 --> 00:39:36,440
but the answer is no.

1226
00:39:36,440 --> 00:39:38,200
It only works if you design it correctly.

1227
00:39:38,200 --> 00:39:40,120
The friction points are usually very specific.

1228
00:39:40,120 --> 00:39:41,920
You see forms that demand 30 fields

1229
00:39:41,920 --> 00:39:43,600
when the developer only needs five.

1230
00:39:43,600 --> 00:39:45,560
You find documentation that contradicts itself

1231
00:39:45,560 --> 00:39:47,320
or assumes knowledge they don't have.

1232
00:39:47,320 --> 00:39:48,680
Then there are the approval workflows.

1233
00:39:48,680 --> 00:39:50,680
You submit a request and wait three days

1234
00:39:50,680 --> 00:39:53,280
for someone to decide if you are allowed to do something obvious.

1235
00:39:53,280 --> 00:39:54,760
The design principle is simple.

1236
00:39:54,760 --> 00:39:57,320
If a developer has to ask for help to use the platform,

1237
00:39:57,320 --> 00:39:59,680
you have failed. I am not talking about edge cases.

1238
00:39:59,680 --> 00:40:01,280
I am talking about the normal path.

1239
00:40:01,280 --> 00:40:03,280
If the standard thing a developer wants to do

1240
00:40:03,280 --> 00:40:06,400
requires human intervention, your platform is a bottleneck.

1241
00:40:06,400 --> 00:40:08,120
The actual mechanics are straightforward,

1242
00:40:08,120 --> 00:40:11,520
a developer opens a form, service name, environment,

1243
00:40:11,520 --> 00:40:12,720
resource limits.

1244
00:40:12,720 --> 00:40:13,480
That is it.

1245
00:40:13,480 --> 00:40:15,760
No cloud credentials, no role definitions,

1246
00:40:15,760 --> 00:40:19,040
no network configuration, no infrastructure decisions.

1247
00:40:19,040 --> 00:40:20,880
All of that is handled by the platform.

1248
00:40:20,880 --> 00:40:24,320
They submit a pipeline runs, the infrastructure is created.

1249
00:40:24,320 --> 00:40:26,120
10 minutes later, it is ready.

1250
00:40:27,120 --> 00:40:30,320
This works because the platform has already made the hard decisions.

1251
00:40:30,320 --> 00:40:32,920
The form does not ask which SKU they want for the database

1252
00:40:32,920 --> 00:40:34,800
because the platform already decided.

1253
00:40:34,800 --> 00:40:37,720
It provides the right size for 90% of use cases

1254
00:40:37,720 --> 00:40:39,000
if they need something different.

1255
00:40:39,000 --> 00:40:39,920
That is a conversation.

1256
00:40:39,920 --> 00:40:41,040
It is not the default path.

1257
00:40:41,040 --> 00:40:42,320
The guardrails are the key.

1258
00:40:42,320 --> 00:40:44,280
Self-service does not mean uncontrolled.

1259
00:40:44,280 --> 00:40:46,760
It means controlled by policy and not by process.

1260
00:40:46,760 --> 00:40:49,040
A policy is code.

1261
00:40:49,040 --> 00:40:50,160
It runs automatically.

1262
00:40:50,160 --> 00:40:52,240
It blocks the wrong action before it happens.

1263
00:40:52,240 --> 00:40:54,120
A developer can provision anything,

1264
00:40:54,120 --> 00:40:56,000
but they cannot provision something in secure

1265
00:40:56,000 --> 00:40:57,880
because the policy will not allow it.

1266
00:40:57,880 --> 00:41:00,720
They can create a database, but not one without encryption.

1267
00:41:00,720 --> 00:41:03,960
They can create a network, but not one that exposes the internet.

1268
00:41:03,960 --> 00:41:06,000
This is controlled without permission asking.

1269
00:41:06,000 --> 00:41:07,800
The developer does not feel controlled

1270
00:41:07,800 --> 00:41:09,160
because they are not waiting.

1271
00:41:09,160 --> 00:41:10,720
They are not jumping through hoops.

1272
00:41:10,720 --> 00:41:12,040
They provision what they need.

1273
00:41:12,040 --> 00:41:13,720
It works and it is compliant.

1274
00:41:13,720 --> 00:41:15,680
The policy runs silently in the background.

1275
00:41:15,680 --> 00:41:17,800
The metrics that prove this is working are simple.

1276
00:41:17,800 --> 00:41:19,920
The self-service ratio is the percentage of actions

1277
00:41:19,920 --> 00:41:21,280
completed without tickets.

1278
00:41:21,280 --> 00:41:23,840
If you are above 85%, you are winning.

1279
00:41:23,840 --> 00:41:26,200
If you are below 50%, your platform has friction

1280
00:41:26,200 --> 00:41:29,200
that is driving people away, then there is time to provision.

1281
00:41:29,200 --> 00:41:31,000
This is the time from I need a database

1282
00:41:31,000 --> 00:41:33,200
to my database is ready.

1283
00:41:33,200 --> 00:41:35,840
For a mature platform, this is measured in minutes.

1284
00:41:35,840 --> 00:41:38,160
For a broken platform, this is measured in days.

1285
00:41:38,160 --> 00:41:40,000
The metric exposes the truth immediately.

1286
00:41:40,000 --> 00:41:41,680
The outcome is a platform that disappears.

1287
00:41:41,680 --> 00:41:43,680
Developers use it without thinking about it.

1288
00:41:43,680 --> 00:41:44,920
They get what they need.

1289
00:41:44,920 --> 00:41:45,760
It is secure.

1290
00:41:45,760 --> 00:41:46,880
It is there.

1291
00:41:46,880 --> 00:41:47,680
They move on.

1292
00:41:47,680 --> 00:41:49,160
They are not building shadow systems

1293
00:41:49,160 --> 00:41:51,400
because the official platform actually works.

1294
00:41:51,400 --> 00:41:54,200
This is where safety and speed become the same thing.

1295
00:41:54,200 --> 00:41:56,080
They are no longer opposing forces.

1296
00:41:56,080 --> 00:41:59,080
A policy-driven platform is faster because there is no wait time.

1297
00:41:59,080 --> 00:42:02,120
It is safer because policies are consistent and automated.

1298
00:42:02,120 --> 00:42:04,080
You do not sacrifice one for the other.

1299
00:42:04,080 --> 00:42:05,400
The platform gives you both.

1300
00:42:05,400 --> 00:42:07,600
The measurement problem.

1301
00:42:07,600 --> 00:42:09,560
You cannot improve what you do not measure.

1302
00:42:09,560 --> 00:42:11,640
This is true for everything in engineering

1303
00:42:11,640 --> 00:42:13,680
and it is especially true for platforms.

1304
00:42:13,680 --> 00:42:16,280
Where the value is invisible, if you do not look for it.

1305
00:42:16,280 --> 00:42:17,480
Here is the baseline.

1306
00:42:17,480 --> 00:42:20,360
Most organizations measure platform success on two metrics.

1307
00:42:20,360 --> 00:42:21,800
Uptime, cost.

1308
00:42:21,800 --> 00:42:22,560
Is it running?

1309
00:42:22,560 --> 00:42:23,640
Is it affordable?

1310
00:42:23,640 --> 00:42:24,960
If the answer is yes.

1311
00:42:24,960 --> 00:42:26,040
They consider it a win.

1312
00:42:26,040 --> 00:42:27,160
This is lazy measurement.

1313
00:42:27,160 --> 00:42:29,200
It tells you if the infrastructure exists.

1314
00:42:29,200 --> 00:42:32,680
It tells you nothing about whether the platform is actually helping.

1315
00:42:32,680 --> 00:42:34,760
The standard for delivery performance is Dora.

1316
00:42:34,760 --> 00:42:37,120
Deployment frequency, lead time for changes,

1317
00:42:37,120 --> 00:42:39,560
change failure rate, time to restore.

1318
00:42:39,560 --> 00:42:42,480
These four metrics correlate with how an organization performs.

1319
00:42:42,480 --> 00:42:44,480
Teams that deploy frequently with low failure rates

1320
00:42:44,480 --> 00:42:45,800
are the high performers.

1321
00:42:45,800 --> 00:42:47,520
This is well researched and documented,

1322
00:42:47,520 --> 00:42:50,560
but Dora alone does not tell you if your platform is working.

1323
00:42:50,560 --> 00:42:52,480
Dora tells you if you are shipping fast.

1324
00:42:52,480 --> 00:42:54,600
It does not tell you if developers are happy.

1325
00:42:54,600 --> 00:42:58,000
It does not tell you if the platform reduced cognitive load.

1326
00:42:58,000 --> 00:43:01,240
It does not tell you if teams are using it or bypassing it.

1327
00:43:01,240 --> 00:43:03,360
This is why platform teams need to measure more.

1328
00:43:03,360 --> 00:43:05,280
Developer satisfaction is the starting point.

1329
00:43:05,280 --> 00:43:07,360
You need a net promoter score for the platform.

1330
00:43:07,360 --> 00:43:08,880
You ask one simple question.

1331
00:43:08,880 --> 00:43:10,800
Would you recommend this to a colleague?

1332
00:43:10,800 --> 00:43:12,920
The answer tells you immediately if you are winning.

1333
00:43:12,920 --> 00:43:14,360
Then look at the adoption rate.

1334
00:43:14,360 --> 00:43:16,600
What percentage of teams are using the golden parts

1335
00:43:16,600 --> 00:43:17,880
versus rolling their own?

1336
00:43:17,880 --> 00:43:20,040
If adoption is low, your product has work to do.

1337
00:43:20,040 --> 00:43:21,880
Look at time to first deploy.

1338
00:43:21,880 --> 00:43:24,160
This is the time from when a developer joins the company

1339
00:43:24,160 --> 00:43:26,040
to when they ship their first change.

1340
00:43:26,040 --> 00:43:27,720
This is a proxy for cognitive load.

1341
00:43:27,720 --> 00:43:29,880
A long time to first deploy means high friction.

1342
00:43:29,880 --> 00:43:31,320
Then there is the self-service ratio.

1343
00:43:31,320 --> 00:43:33,880
What percentage of requests are completed without tickets?

1344
00:43:33,880 --> 00:43:37,200
Low self-service means your automation is not good enough.

1345
00:43:37,200 --> 00:43:39,040
There is also cognitive load itself.

1346
00:43:39,040 --> 00:43:40,920
Remember the concepts to ship metric.

1347
00:43:40,920 --> 00:43:42,400
This is the number of distinct things

1348
00:43:42,400 --> 00:43:44,760
a developer must understand just to deploy.

1349
00:43:44,760 --> 00:43:47,200
But your platforms drive this down to four or five.

1350
00:43:47,200 --> 00:43:50,200
Manual DevOps environments require 15 to 20.

1351
00:43:50,200 --> 00:43:52,960
Measuring this tells you if you are reducing the burden.

1352
00:43:52,960 --> 00:43:53,960
Or just moving it around.

1353
00:43:53,960 --> 00:43:55,200
Here's the paradox.

1354
00:43:55,200 --> 00:43:57,840
30% of platform teams measure nothing at all.

1355
00:43:57,840 --> 00:43:58,640
Zero metrics.

1356
00:43:58,640 --> 00:43:59,800
They build a platform.

1357
00:43:59,800 --> 00:44:01,480
But they have no idea if it is working.

1358
00:44:01,480 --> 00:44:04,680
Another 40% cannot show ROI within 12 months of launch.

1359
00:44:04,680 --> 00:44:05,520
Think about that.

1360
00:44:05,520 --> 00:44:07,680
You invest six months building a platform.

1361
00:44:07,680 --> 00:44:08,720
You launch it.

1362
00:44:08,720 --> 00:44:11,520
And after a year, you still cannot prove it created value.

1363
00:44:11,520 --> 00:44:13,240
That is not a platform problem.

1364
00:44:13,240 --> 00:44:14,480
That is a measurement problem.

1365
00:44:14,480 --> 00:44:16,240
The organizations that do measure are the ones

1366
00:44:16,240 --> 00:44:17,600
that can tell a story.

1367
00:44:17,600 --> 00:44:20,840
A year ago, our average time to first deploy was three weeks.

1368
00:44:20,840 --> 00:44:22,360
Today it is four hours.

1369
00:44:22,360 --> 00:44:26,120
A year ago, developers spend 70% of their time on toil.

1370
00:44:26,120 --> 00:44:27,360
Today it is 20%.

1371
00:44:27,360 --> 00:44:30,240
Our adoption rate went from 40% to 85%.

1372
00:44:30,240 --> 00:44:31,920
Our deployment frequency doubled.

1373
00:44:31,920 --> 00:44:35,280
Our change failure rate dropped from 15% to 5%.

1374
00:44:35,280 --> 00:44:36,200
That is evidence.

1375
00:44:36,200 --> 00:44:37,320
That is proof.

1376
00:44:37,320 --> 00:44:40,680
The ROI calculation is where this becomes business critical.

1377
00:44:40,680 --> 00:44:45,600
A mature platform reports 200 to 800% ROI within 18 to 24 months.

1378
00:44:45,600 --> 00:44:48,600
If you invest $1 million, you are recovering 2 to 8 million

1379
00:44:48,600 --> 00:44:49,960
in value over two years.

1380
00:44:49,960 --> 00:44:52,240
But you only see this number if you measure it.

1381
00:44:52,240 --> 00:44:54,240
Without measurement, there is no ROI story.

1382
00:44:54,240 --> 00:44:57,160
There is just an expense that you are not sure justified itself.

1383
00:44:57,160 --> 00:44:59,800
Measurement also changes how the platform evolves.

1384
00:44:59,800 --> 00:45:02,040
Instead of guessing what teams need, you see where they are

1385
00:45:02,040 --> 00:45:04,520
struggling, you see where they get stuck, you see which

1386
00:45:04,520 --> 00:45:05,760
features are unused.

1387
00:45:05,760 --> 00:45:08,320
Measurement data becomes the roadmap, not politics, not

1388
00:45:08,320 --> 00:45:09,800
the loudest voice data.

1389
00:45:09,800 --> 00:45:12,520
The organizations that win treat the platform like a product

1390
00:45:12,520 --> 00:45:14,640
and measurement like science, they baseline everything

1391
00:45:14,640 --> 00:45:16,720
before they start, then they track relentlessly.

1392
00:45:16,720 --> 00:45:18,080
They are just based on data.

1393
00:45:18,080 --> 00:45:19,520
They prove value continuously.

1394
00:45:19,520 --> 00:45:22,880
And they use that proof to justify the next step.

1395
00:45:22,880 --> 00:45:24,480
Why most platforms fail?

1396
00:45:24,480 --> 00:45:27,800
Most platforms fail, not all of them, but most.

1397
00:45:27,800 --> 00:45:30,160
And the interesting thing is that these failures almost never

1398
00:45:30,160 --> 00:45:31,520
happen for technical reasons.

1399
00:45:31,520 --> 00:45:33,080
The technology is usually fine.

1400
00:45:33,080 --> 00:45:36,200
Your infrastructure as code works, your policy automation works,

1401
00:45:36,200 --> 00:45:37,520
the tooling itself is solid.

1402
00:45:37,520 --> 00:45:39,880
The platform fails because of organizational decisions

1403
00:45:39,880 --> 00:45:41,440
and operational choices.

1404
00:45:41,440 --> 00:45:43,920
Understanding these failure modes is actually more valuable

1405
00:45:43,920 --> 00:45:46,200
than understanding the theory, because you can design

1406
00:45:46,200 --> 00:45:48,080
the perfect architecture and still build something

1407
00:45:48,080 --> 00:45:49,400
that nobody ever uses.

1408
00:45:49,400 --> 00:45:51,120
The first failure mode is label theater.

1409
00:45:51,120 --> 00:45:53,160
This is where an organization renames a team

1410
00:45:53,160 --> 00:45:55,640
without changing a single thing about how it operates.

1411
00:45:55,640 --> 00:45:58,680
The DevOps team becomes the platform team on paper,

1412
00:45:58,680 --> 00:46:00,880
but everything else stays exactly the same.

1413
00:46:00,880 --> 00:46:02,360
They still function as a ticket shop.

1414
00:46:02,360 --> 00:46:03,880
Teams still file requests.

1415
00:46:03,880 --> 00:46:05,680
They still wait for manual approvals.

1416
00:46:05,680 --> 00:46:07,760
They still depend on two or three senior engineers

1417
00:46:07,760 --> 00:46:09,840
who are the only ones who understand the right way

1418
00:46:09,840 --> 00:46:10,680
to do things.

1419
00:46:10,680 --> 00:46:13,800
The platform team still exists to serve others, not to empower them.

1420
00:46:13,800 --> 00:46:15,400
It looks different on the org chart,

1421
00:46:15,400 --> 00:46:17,200
but the friction is identical.

1422
00:46:17,200 --> 00:46:19,120
So naturally, teams just bypass it.

1423
00:46:19,120 --> 00:46:21,720
The escape rate stays high while adoption stays low,

1424
00:46:21,720 --> 00:46:23,520
and the leadership wonders why the platform

1425
00:46:23,520 --> 00:46:26,120
is just a rebranding of the same old broken model.

1426
00:46:26,120 --> 00:46:28,000
The name matters less than the interaction.

1427
00:46:28,000 --> 00:46:31,040
If you didn't shift from approval workflows to self-service,

1428
00:46:31,040 --> 00:46:32,480
you didn't build a platform.

1429
00:46:32,480 --> 00:46:33,840
You just bought new business cards.

1430
00:46:33,840 --> 00:46:35,800
The second failure mode is over ambition.

1431
00:46:35,800 --> 00:46:37,240
A team decides they're going to build

1432
00:46:37,240 --> 00:46:40,440
the comprehensive platform that covers every possible base.

1433
00:46:40,440 --> 00:46:43,800
Kubernetes databases, networking security, CI/CD,

1434
00:46:43,800 --> 00:46:46,400
and cost management are all bundled together from day one.

1435
00:46:46,400 --> 00:46:47,440
The scope is massive.

1436
00:46:47,440 --> 00:46:48,640
The build takes a year.

1437
00:46:48,640 --> 00:46:50,200
By the time it finally launches,

1438
00:46:50,200 --> 00:46:52,880
the platform is so complex that the learning curve

1439
00:46:52,880 --> 00:46:54,600
is a vertical wall.

1440
00:46:54,600 --> 00:46:57,480
The documentation is thick, the features are endless,

1441
00:46:57,480 --> 00:46:59,640
and the teams using it have to understand

1442
00:46:59,640 --> 00:47:02,200
a mountain of new concepts just to get started

1443
00:47:02,200 --> 00:47:03,960
because there is so much service area,

1444
00:47:03,960 --> 00:47:05,680
there is also more that can break.

1445
00:47:05,680 --> 00:47:08,320
Teams don't trust it for their critical services,

1446
00:47:08,320 --> 00:47:10,640
so they build their own custom stacks for what matters

1447
00:47:10,640 --> 00:47:13,360
and use your platform for the stuff they don't care about.

1448
00:47:13,360 --> 00:47:15,160
The comprehensive platform becomes the default

1449
00:47:15,160 --> 00:47:16,360
for everything except the things

1450
00:47:16,360 --> 00:47:17,800
that actually drive the business,

1451
00:47:17,800 --> 00:47:19,560
which is the exact opposite of what you wanted.

1452
00:47:19,560 --> 00:47:21,840
The third failure is a lack of product thinking.

1453
00:47:21,840 --> 00:47:24,000
A platform team builds what they think is cool

1454
00:47:24,000 --> 00:47:25,680
instead of what developers actually need

1455
00:47:25,680 --> 00:47:26,640
to get their jobs done.

1456
00:47:26,640 --> 00:47:28,360
They optimize for technical elegance

1457
00:47:28,360 --> 00:47:31,560
and create the most architecturally pure solution imaginable.

1458
00:47:31,560 --> 00:47:33,920
They design for edge cases that almost nobody ever hits.

1459
00:47:33,920 --> 00:47:35,560
They build features that sound amazing

1460
00:47:35,560 --> 00:47:37,040
in a PowerPoint presentation.

1461
00:47:37,040 --> 00:47:38,680
And then developers use none of it.

1462
00:47:38,680 --> 00:47:40,600
It doesn't solve their actual problems,

1463
00:47:40,600 --> 00:47:43,800
the team confused technical perfection with user value,

1464
00:47:43,800 --> 00:47:46,120
but users don't care about how pure the code is.

1465
00:47:46,120 --> 00:47:47,880
They care about whether it solves their problem

1466
00:47:47,880 --> 00:47:49,280
faster than the alternative.

1467
00:47:49,280 --> 00:47:51,120
If it doesn't, they leave.

1468
00:47:51,120 --> 00:47:53,600
The fourth failure is a poor adoption strategy.

1469
00:47:53,600 --> 00:47:56,360
An organization decides to make the platform mandatory.

1470
00:47:56,360 --> 00:47:57,800
They tell everyone they have to use it

1471
00:47:57,800 --> 00:48:00,160
and announce they are killing off the old system.

1472
00:48:00,160 --> 00:48:03,240
But forced adoption without trust is just a recipe for resistance.

1473
00:48:03,240 --> 00:48:05,960
Teams use the platform because they are forced to,

1474
00:48:05,960 --> 00:48:07,000
not because it helps them.

1475
00:48:07,000 --> 00:48:08,600
They resent it, they complain about it.

1476
00:48:08,600 --> 00:48:11,240
They spend their time looking for ways to work around the rules.

1477
00:48:11,240 --> 00:48:14,360
Morale drops and the moment there is any slack in that mandate,

1478
00:48:14,360 --> 00:48:16,480
teams abandon the platform entirely.

1479
00:48:16,480 --> 00:48:19,120
Mandatory adoption is how you get the worst possible feedback.

1480
00:48:19,120 --> 00:48:21,080
People tell you what they think you want to hear

1481
00:48:21,080 --> 00:48:22,880
instead of telling you what's actually broken.

1482
00:48:22,880 --> 00:48:24,040
You miss the real pain points

1483
00:48:24,040 --> 00:48:26,360
because they're hidden under a layer of resentment.

1484
00:48:26,360 --> 00:48:28,040
The fifth failure is the measurement gap.

1485
00:48:28,040 --> 00:48:30,760
A platform launches and nobody tracks a single metric.

1486
00:48:30,760 --> 00:48:33,160
No adoption rates, no time to first deploy

1487
00:48:33,160 --> 00:48:36,480
and no data on developer satisfaction or ROI.

1488
00:48:36,480 --> 00:48:38,560
A year later, the team can't justify

1489
00:48:38,560 --> 00:48:40,160
why the platform even exists.

1490
00:48:40,160 --> 00:48:40,920
Was it faster?

1491
00:48:40,920 --> 00:48:41,440
Nobody knows.

1492
00:48:41,440 --> 00:48:43,280
Did it reduce the mental load on developers?

1493
00:48:43,280 --> 00:48:44,280
There's no data.

1494
00:48:44,280 --> 00:48:45,440
Did it save the company money?

1495
00:48:45,440 --> 00:48:47,080
You can't tell.

1496
00:48:47,080 --> 00:48:49,360
Without measurement, platforms have no story to tell.

1497
00:48:49,360 --> 00:48:51,760
They just exist and consume resources

1498
00:48:51,760 --> 00:48:53,960
until a new executive eventually asks

1499
00:48:53,960 --> 00:48:55,800
what the platform is costing the company.

1500
00:48:55,800 --> 00:48:57,240
When nobody can answer that question,

1501
00:48:57,240 --> 00:48:58,240
the project gets killed.

1502
00:48:58,240 --> 00:49:00,360
The sixth failure is a governance mismatch.

1503
00:49:00,360 --> 00:49:01,600
Sometimes policies are so strict

1504
00:49:01,600 --> 00:49:03,560
that they kill innovation before it starts.

1505
00:49:03,560 --> 00:49:05,760
Teams can't do anything without a signature

1506
00:49:05,760 --> 00:49:08,600
and governance becomes just another bottleneck in the system.

1507
00:49:08,600 --> 00:49:10,440
Developers give up and build shadow systems

1508
00:49:10,440 --> 00:49:12,320
because the official path is more locked down

1509
00:49:12,320 --> 00:49:13,440
than it is useful.

1510
00:49:13,440 --> 00:49:14,960
Or the governance is so loose

1511
00:49:14,960 --> 00:49:17,360
that it doesn't actually constrain anything at all.

1512
00:49:17,360 --> 00:49:18,960
Policies exist on a wiki somewhere,

1513
00:49:18,960 --> 00:49:20,960
but aren't enforced, security gaps emerge

1514
00:49:20,960 --> 00:49:22,800
and compliance becomes theater again.

1515
00:49:22,800 --> 00:49:24,480
The governance has to fit the organization

1516
00:49:24,480 --> 00:49:26,120
and its actual risk appetite.

1517
00:49:26,120 --> 00:49:28,040
Too tight and it strangles the platform,

1518
00:49:28,040 --> 00:49:29,760
too loose and it fails to govern anything.

1519
00:49:29,760 --> 00:49:31,480
These aren't technical failures.

1520
00:49:31,480 --> 00:49:33,520
They are organizational failures

1521
00:49:33,520 --> 00:49:34,960
and they are preventable.

1522
00:49:34,960 --> 00:49:36,760
The thinnest viable platform.

1523
00:49:36,760 --> 00:49:38,520
So how do you avoid those traps?

1524
00:49:38,520 --> 00:49:40,760
How do you build something that actually works

1525
00:49:40,760 --> 00:49:42,680
instead of something that just sits in the middle

1526
00:49:42,680 --> 00:49:43,800
helping nobody?

1527
00:49:43,800 --> 00:49:45,280
You start with constraint.

1528
00:49:45,280 --> 00:49:47,800
The thinnest viable platform is not just a buzzword.

1529
00:49:47,800 --> 00:49:49,080
It's a survival strategy.

1530
00:49:49,080 --> 00:49:51,560
It is the realization that your first version

1531
00:49:51,560 --> 00:49:53,720
doesn't need to cover every single use case.

1532
00:49:53,720 --> 00:49:55,520
It only needs to cover the ones that matter most.

1533
00:49:55,520 --> 00:49:56,960
The ones that show up every day.

1534
00:49:56,960 --> 00:49:58,800
The ones where the friction is the highest.

1535
00:49:58,800 --> 00:49:59,880
The principle is simple.

1536
00:49:59,880 --> 00:50:01,760
Start small, measure the impact

1537
00:50:01,760 --> 00:50:04,120
and expand only when there is actual demand.

1538
00:50:04,120 --> 00:50:05,640
Not because a feature sounds interesting,

1539
00:50:05,640 --> 00:50:07,760
but because you have evidence that people need it.

1540
00:50:07,760 --> 00:50:09,120
Most platform failures happen

1541
00:50:09,120 --> 00:50:11,560
because teams build too much, too fast

1542
00:50:11,560 --> 00:50:13,440
for problems that don't even exist yet.

1543
00:50:13,440 --> 00:50:15,240
They theorize about what teams might need

1544
00:50:15,240 --> 00:50:17,520
and design for scenarios that haven't happened.

1545
00:50:17,520 --> 00:50:20,480
They add features just because the architecture can support them

1546
00:50:20,480 --> 00:50:22,840
and then the platform launches to teams

1547
00:50:22,840 --> 00:50:25,480
that don't even recognize their own workflows in the tool.

1548
00:50:25,480 --> 00:50:27,400
A thinnest viable platform does the opposite.

1549
00:50:27,400 --> 00:50:29,920
It launches small, deliberately small.

1550
00:50:29,920 --> 00:50:31,600
You only ship the capabilities

1551
00:50:31,600 --> 00:50:34,680
that solve the most obvious high-friction problems right now.

1552
00:50:34,680 --> 00:50:35,920
Everything else waits.

1553
00:50:35,920 --> 00:50:37,800
Everything else can be built later.

1554
00:50:37,800 --> 00:50:39,920
Once you actually know what matters to your users.

1555
00:50:39,920 --> 00:50:41,440
So what does that first wave look like?

1556
00:50:41,440 --> 00:50:43,680
First, you have CICD pipelines.

1557
00:50:43,680 --> 00:50:46,000
This is universal because every team needs to build

1558
00:50:46,000 --> 00:50:47,320
and deploy code.

1559
00:50:47,320 --> 00:50:49,520
You create a standard pipeline that handles the build,

1560
00:50:49,520 --> 00:50:51,440
the tests and the security scanning.

1561
00:50:51,440 --> 00:50:53,480
You don't build every possible variation.

1562
00:50:53,480 --> 00:50:56,120
You build the one that works for 80% of your services.

1563
00:50:56,120 --> 00:50:57,680
Next is environment provisioning.

1564
00:50:57,680 --> 00:50:59,560
Developers need a place to test their work

1565
00:50:59,560 --> 00:51:01,280
and getting a dev or test environment

1566
00:51:01,280 --> 00:51:02,760
should be a self-service experience.

1567
00:51:02,760 --> 00:51:04,000
They should be able to push a button

1568
00:51:04,000 --> 00:51:05,480
and get an environment in minutes

1569
00:51:05,480 --> 00:51:08,160
rather than waiting days for a ticket to be processed.

1570
00:51:08,160 --> 00:51:09,600
Then you add basic observability.

1571
00:51:09,600 --> 00:51:11,440
This means logging, metrics and alerts.

1572
00:51:11,440 --> 00:51:13,840
It isn't a comprehensive, all-encompassing monitoring suite.

1573
00:51:13,840 --> 00:51:14,720
It's just the basics.

1574
00:51:14,720 --> 00:51:17,560
It's enough for a developer to see if something is broken.

1575
00:51:17,560 --> 00:51:19,320
Finally, you include security scanning.

1576
00:51:19,320 --> 00:51:21,520
Every deployment should run through automated checks

1577
00:51:21,520 --> 00:51:24,840
for vulnerable dependencies or secrets exposed in the code.

1578
00:51:24,840 --> 00:51:26,680
These vulnerabilities should be code automatically

1579
00:51:26,680 --> 00:51:28,680
and denied before they ever reach production.

1580
00:51:28,680 --> 00:51:30,080
That is the first wave.

1581
00:51:30,080 --> 00:51:34,320
Four capabilities, not 20, not 10, just four.

1582
00:51:34,320 --> 00:51:36,400
And they solve the most immediate problem.

1583
00:51:36,400 --> 00:51:39,200
How do we ship code safely and consistently?

1584
00:51:39,200 --> 00:51:41,040
Once this is live, you measure everything.

1585
00:51:41,040 --> 00:51:43,240
You look at how many teams are using the golden path

1586
00:51:43,240 --> 00:51:44,960
for their pipelines and how many are actually

1587
00:51:44,960 --> 00:51:46,840
using the self-service provisioning.

1588
00:51:46,840 --> 00:51:48,400
You track the time to first deploy

1589
00:51:48,400 --> 00:51:49,840
and the overall adoption rate.

1590
00:51:49,840 --> 00:51:52,600
If your adoption is below 70%, something isn't working.

1591
00:51:52,600 --> 00:51:54,040
It's not because the teams are lazy.

1592
00:51:54,040 --> 00:51:56,920
It's because the platform isn't solving their problem well enough.

1593
00:51:56,920 --> 00:51:59,720
You have to fix that before you even think about expanding.

1594
00:51:59,720 --> 00:52:02,280
You only add the second wave, once the first wave is solid

1595
00:52:02,280 --> 00:52:03,440
and widely adopted.

1596
00:52:03,440 --> 00:52:04,680
The second wave comes much later.

1597
00:52:04,680 --> 00:52:06,200
This is where you add cost governance

1598
00:52:06,200 --> 00:52:09,280
like tagging and budget alerts, or the automatic shutdown

1599
00:52:09,280 --> 00:52:10,480
of unused resources.

1600
00:52:10,480 --> 00:52:13,320
You might add advanced networking, multi-region connectivity,

1601
00:52:13,320 --> 00:52:14,920
or disaster recovery patterns.

1602
00:52:14,920 --> 00:52:17,160
These are important, but they aren't the first problem

1603
00:52:17,160 --> 00:52:18,120
teams face.

1604
00:52:18,120 --> 00:52:20,560
Developers can survive the first few months without them.

1605
00:52:20,560 --> 00:52:22,320
Once the platform is stable and trusted

1606
00:52:22,320 --> 00:52:24,480
and once teams are actually using it every day,

1607
00:52:24,480 --> 00:52:26,520
then you layer in those next capabilities.

1608
00:52:26,520 --> 00:52:28,720
The third wave is for specialized needs.

1609
00:52:28,720 --> 00:52:31,440
This includes data platforms, machine learning infrastructure,

1610
00:52:31,440 --> 00:52:33,800
or compliance patterns for regulated workloads.

1611
00:52:33,800 --> 00:52:36,560
You might add message cues or distributed caching here.

1612
00:52:36,560 --> 00:52:38,440
These are things that specific teams need,

1613
00:52:38,440 --> 00:52:40,680
but they aren't universal requirements.

1614
00:52:40,680 --> 00:52:43,480
By this point, your platform team understands the model.

1615
00:52:43,480 --> 00:52:45,480
They know how to build things that teams actually use

1616
00:52:45,480 --> 00:52:48,400
because they've already proven their value and earned that trust.

1617
00:52:48,400 --> 00:52:51,040
Now they have the permission to expand into specialization.

1618
00:52:51,040 --> 00:52:52,240
Here is why this works.

1619
00:52:52,240 --> 00:52:54,560
First, it keeps the platform team focused.

1620
00:52:54,560 --> 00:52:56,600
They aren't trying to build everything at once.

1621
00:52:56,600 --> 00:52:58,920
They are building one thing exceptionally well.

1622
00:52:58,920 --> 00:53:01,280
The learning curve for your user stays flat.

1623
00:53:01,280 --> 00:53:03,520
They only have to learn four things instead of 40,

1624
00:53:03,520 --> 00:53:04,800
so adoption follows naturally

1625
00:53:04,800 --> 00:53:06,280
because the platform solves a problem

1626
00:53:06,280 --> 00:53:08,160
without overwhelming them.

1627
00:53:08,160 --> 00:53:09,800
Second, measurement tells you immediately

1628
00:53:09,800 --> 00:53:10,840
if you're on the right track.

1629
00:53:10,840 --> 00:53:12,560
If adoption is low on that first wave,

1630
00:53:12,560 --> 00:53:13,680
you have actionable feedback.

1631
00:53:13,680 --> 00:53:16,120
You don't just hear that the platform is too complex.

1632
00:53:16,120 --> 00:53:18,520
You see that CICD adoption is at 45%,

1633
00:53:18,520 --> 00:53:20,440
which means teams don't trust the pipeline yet.

1634
00:53:20,440 --> 00:53:23,240
That is a specific problem with a specific fix.

1635
00:53:23,240 --> 00:53:26,280
Third, you prove the value before you place a massive bet.

1636
00:53:26,280 --> 00:53:28,440
If the first wave creates a 20% improvement

1637
00:53:28,440 --> 00:53:29,920
in how often you can deploy,

1638
00:53:29,920 --> 00:53:31,400
you have your proof of concept.

1639
00:53:31,400 --> 00:53:34,080
That success justifies the next wave of investment.

1640
00:53:34,080 --> 00:53:36,080
If adoption is high and teams are happy,

1641
00:53:36,080 --> 00:53:37,560
you have earned the right to grow.

1642
00:53:37,560 --> 00:53:39,160
You aren't gambling on what might work.

1643
00:53:39,160 --> 00:53:41,320
You are building on evidence of what already does.

1644
00:53:41,320 --> 00:53:43,200
The organizations that win with platforms

1645
00:53:43,200 --> 00:53:45,680
are the ones that resist the urge to do everything at once.

1646
00:53:45,680 --> 00:53:47,480
They start small, they measure the results,

1647
00:53:47,480 --> 00:53:49,080
and they expand methodically.

1648
00:53:49,080 --> 00:53:51,240
They watch those adoption rates like a hawk

1649
00:53:51,240 --> 00:53:54,080
because adoption is the only metric that actually matters.

1650
00:53:54,080 --> 00:53:57,800
Developer experience as a leading indicator,

1651
00:53:57,800 --> 00:53:59,800
we've spent a lot of time talking about measurement,

1652
00:53:59,800 --> 00:54:01,360
we've looked at adoption rates,

1653
00:54:01,360 --> 00:54:04,480
DORA, metrics, and cognitive load.

1654
00:54:04,480 --> 00:54:07,800
But there is one specific metric that sits above everything else.

1655
00:54:07,800 --> 00:54:09,320
It's the one number that actually predicts

1656
00:54:09,320 --> 00:54:11,000
whether your platform will succeed or fail.

1657
00:54:11,000 --> 00:54:12,680
And yet, most organizations

1658
00:54:12,680 --> 00:54:13,720
completely ignore it.

1659
00:54:13,720 --> 00:54:16,320
That metric is developer experience or DX.

1660
00:54:16,320 --> 00:54:19,040
But here is the thing, DX is not just a feeling.

1661
00:54:19,040 --> 00:54:21,480
It isn't something you measure in a yearly satisfaction survey

1662
00:54:21,480 --> 00:54:24,840
and then file away in a drawer, it is a quantifiable, measurable.

1663
00:54:24,840 --> 00:54:27,440
Predictor of whether your platform is actually doing its job.

1664
00:54:27,440 --> 00:54:29,120
And the reason that matters so much is that

1665
00:54:29,120 --> 00:54:32,240
high DX correlates with every single outcome you care about.

1666
00:54:32,240 --> 00:54:35,360
High adoption, low cognitive load, fast delivery,

1667
00:54:35,360 --> 00:54:36,600
and low burnout.

1668
00:54:36,600 --> 00:54:39,280
All of those things flow directly from the developer experience.

1669
00:54:39,280 --> 00:54:41,720
This isn't just theory, it's visible in how people act.

1670
00:54:41,720 --> 00:54:44,360
When a developer has a good experience with the platform,

1671
00:54:44,360 --> 00:54:45,200
they use it.

1672
00:54:45,200 --> 00:54:48,000
When the experience is frustrating, they build a workaround.

1673
00:54:48,000 --> 00:54:51,720
That isn't an opinion, it's a behavior, and behavior doesn't lie.

1674
00:54:51,720 --> 00:54:54,320
So what does DX actually look like in practice?

1675
00:54:54,320 --> 00:54:57,800
It's simple, how easy is it for a developer to do their job using your tools?

1676
00:54:57,800 --> 00:55:00,560
So I'm not asking how technically elegant the platform is.

1677
00:55:00,560 --> 00:55:03,800
Or how pure the architecture looks on a whiteboard, I'm asking.

1678
00:55:03,800 --> 00:55:04,920
Is it satisfying to use?

1679
00:55:04,920 --> 00:55:07,400
Can a developer get what they need without hitting a wall?

1680
00:55:07,400 --> 00:55:09,440
Or do they spend four hours a day fighting the system

1681
00:55:09,440 --> 00:55:11,120
just to get a single service running,

1682
00:55:11,120 --> 00:55:12,800
measuring this is straightforward?

1683
00:55:12,800 --> 00:55:14,480
You start with a net promoter score.

1684
00:55:14,480 --> 00:55:18,120
Asking one question, would you recommend this platform to a colleague?

1685
00:55:18,120 --> 00:55:20,720
You use a seven point scale, you get a number,

1686
00:55:20,720 --> 00:55:23,200
and that number tells you immediately if you're winning or losing,

1687
00:55:23,200 --> 00:55:24,200
but you don't stop there.

1688
00:55:24,200 --> 00:55:26,840
You pair that survey data with workflow telemetry

1689
00:55:26,840 --> 00:55:29,280
to see how much time people are actually spending in each tool.

1690
00:55:29,280 --> 00:55:31,560
If the data shows a developer is fighting the platform

1691
00:55:31,560 --> 00:55:34,160
for two hours to finish a task that should take 20 minutes,

1692
00:55:34,160 --> 00:55:36,680
the telemetry will flag it, then you add friction logs

1693
00:55:36,680 --> 00:55:38,280
looking for where people get stuck.

1694
00:55:38,280 --> 00:55:40,080
What questions keep popping up in Slack?

1695
00:55:40,080 --> 00:55:41,880
And which errors are flooding the logs?

1696
00:55:41,880 --> 00:55:44,880
When you combine the surveys, the telemetry and the friction logs,

1697
00:55:44,880 --> 00:55:47,440
you finally get a complete picture of the user experience.

1698
00:55:47,440 --> 00:55:49,240
Now, connect that back to Dora.

1699
00:55:49,240 --> 00:55:50,440
This is the real insight.

1700
00:55:50,440 --> 00:55:52,920
Teams with high DX scores report more frequent deployments

1701
00:55:52,920 --> 00:55:54,080
and shorter lead times.

1702
00:55:54,080 --> 00:55:57,720
Teams with low DX scores report more incidents and slower recovery.

1703
00:55:57,720 --> 00:55:59,720
That isn't a coincidence, it's causation.

1704
00:55:59,720 --> 00:56:02,640
When the platform is easy to use, developers use it more often.

1705
00:56:02,640 --> 00:56:05,480
When they use it more often, they deploy more frequently.

1706
00:56:05,480 --> 00:56:08,240
And because they are deploying all the time, they get better at it.

1707
00:56:08,240 --> 00:56:10,320
So they recover faster when things break,

1708
00:56:10,320 --> 00:56:12,080
the platform becomes invisible.

1709
00:56:12,080 --> 00:56:13,160
It just works.

1710
00:56:13,160 --> 00:56:14,760
So they ship faster.

1711
00:56:14,760 --> 00:56:16,240
But look at the opposite side.

1712
00:56:16,240 --> 00:56:18,600
Teams with low DX avoid the platform entirely.

1713
00:56:18,600 --> 00:56:21,760
They deploy less often because the platform feels like a bottleneck.

1714
00:56:21,760 --> 00:56:24,920
When they finally do ship code, they often use a manual workaround

1715
00:56:24,920 --> 00:56:26,680
that bypasses the official guardrails.

1716
00:56:26,680 --> 00:56:29,400
So when a failure happens, they aren't practiced at recovery.

1717
00:56:29,400 --> 00:56:30,800
They don't have the right observability

1718
00:56:30,800 --> 00:56:32,600
because they weren't using the standard stack.

1719
00:56:32,600 --> 00:56:35,720
It takes them longer to find the problem and even longer to fix it.

1720
00:56:35,720 --> 00:56:37,640
This is why DX is a leading indicator.

1721
00:56:37,640 --> 00:56:40,560
It predicts your door or metrics before they even happen.

1722
00:56:40,560 --> 00:56:43,400
If you measure DX today, you already know if your door or metrics

1723
00:56:43,400 --> 00:56:45,400
will improve or crash six months from now.

1724
00:56:45,400 --> 00:56:48,240
You don't have to wait half a year to see if adoption is working.

1725
00:56:48,240 --> 00:56:50,800
The DX score tells you right now if you're on the right path.

1726
00:56:50,800 --> 00:56:53,520
But here is what most leaders miss, the actual business impact.

1727
00:56:53,520 --> 00:56:57,320
Developers who report a good experience are 50% more likely to say

1728
00:56:57,320 --> 00:56:59,960
they are satisfied with their job, 50%.

1729
00:56:59,960 --> 00:57:01,120
That isn't a small detail.

1730
00:57:01,120 --> 00:57:02,760
It's a massive business advantage.

1731
00:57:02,760 --> 00:57:04,560
Satisfied developers stay at the company.

1732
00:57:04,560 --> 00:57:06,440
They don't leave for the next recruiter who calls.

1733
00:57:06,440 --> 00:57:08,280
They mentor the junior engineers.

1734
00:57:08,280 --> 00:57:10,000
They tackle the hardest problems.

1735
00:57:10,000 --> 00:57:12,680
And they actually care about the quality of the code they ship.

1736
00:57:12,680 --> 00:57:16,120
On the other hand, developers with low DX are burning out.

1737
00:57:16,120 --> 00:57:19,400
They spend their entire day fighting tools that are broken.

1738
00:57:19,400 --> 00:57:21,640
They waste their mental energy on frustration

1739
00:57:21,640 --> 00:57:23,440
instead of solving business problems.

1740
00:57:23,440 --> 00:57:25,600
Eventually, they start looking for the exit.

1741
00:57:25,600 --> 00:57:30,480
Replacing a senior engineer costs anywhere from 200,000 to $500,000.

1742
00:57:30,480 --> 00:57:33,120
If a bad developer experience causes just two engineers

1743
00:57:33,120 --> 00:57:36,120
to leave a team of 20, you are looking at a million dollars

1744
00:57:36,120 --> 00:57:38,240
in replacement costs every single year.

1745
00:57:38,240 --> 00:57:39,240
And that's just the cash.

1746
00:57:39,240 --> 00:57:42,400
It doesn't count the loss productivity while the seat is empty.

1747
00:57:42,400 --> 00:57:44,440
The time it takes to train someone new.

1748
00:57:44,440 --> 00:57:47,120
Or the institutional knowledge that just walked out the door.

1749
00:57:47,120 --> 00:57:49,040
Now, scale that across the whole company.

1750
00:57:49,040 --> 00:57:51,960
If you have 500 developers struggling with a bad platform,

1751
00:57:51,960 --> 00:57:53,920
and each one is 5% more likely to quit,

1752
00:57:53,920 --> 00:57:55,640
you are losing millions of dollars,

1753
00:57:55,640 --> 00:57:57,080
in a voidable turnover.

1754
00:57:57,080 --> 00:57:59,360
That is why DX is no longer a nice to have.

1755
00:57:59,360 --> 00:58:00,960
It is a hard business metric.

1756
00:58:00,960 --> 00:58:03,040
It affects your retention, your productivity,

1757
00:58:03,040 --> 00:58:04,400
and your ability to compete.

1758
00:58:04,400 --> 00:58:07,880
A company where the platform works is a company where engineers stay.

1759
00:58:07,880 --> 00:58:11,040
And engineers who stay are the ones who ship better code faster.

1760
00:58:11,040 --> 00:58:13,360
Cognitive load reduction is the North Star.

1761
00:58:13,360 --> 00:58:15,640
Everything we've talked about so far, the golden parts,

1762
00:58:15,640 --> 00:58:17,400
the automation, the product mindset,

1763
00:58:17,400 --> 00:58:19,440
it all exists for one reason.

1764
00:58:19,440 --> 00:58:22,400
And if you lose sight of this one goal, the whole thing falls apart.

1765
00:58:22,400 --> 00:58:24,040
That goal is cognitive load reduction,

1766
00:58:24,040 --> 00:58:25,640
not simplification for the sake of it,

1767
00:58:25,640 --> 00:58:28,240
not technical purity, cognitive load reduction.

1768
00:58:28,240 --> 00:58:30,880
The ability to let a developer focus on the business problem

1769
00:58:30,880 --> 00:58:32,680
instead of the infrastructure around it.

1770
00:58:32,680 --> 00:58:34,960
Think about what this looks like in the real world.

1771
00:58:34,960 --> 00:58:38,000
Cognitive load is just the mental effort it takes to do a task.

1772
00:58:38,000 --> 00:58:39,520
When you're building a new feature,

1773
00:58:39,520 --> 00:58:42,400
your brain is already juggling a dozen things, the business logic,

1774
00:58:42,400 --> 00:58:45,400
the design patterns, the edge cases, the security concerns.

1775
00:58:45,400 --> 00:58:48,600
That is the intrinsic load, it's the work, it's necessary.

1776
00:58:48,600 --> 00:58:50,920
But then, we pile on the toil.

1777
00:58:50,920 --> 00:58:54,320
Cloud configurations, networking setup, storage provisioning,

1778
00:58:54,320 --> 00:58:56,800
observability wiring, and compliance checks.

1779
00:58:56,800 --> 00:58:58,520
All of that takes mental effort too,

1780
00:58:58,520 --> 00:59:00,280
but it has nothing to do with the business problem.

1781
00:59:00,280 --> 00:59:01,480
It doesn't make the feature better.

1782
00:59:01,480 --> 00:59:03,920
It just consumes the mental capacity that should have gone

1783
00:59:03,920 --> 00:59:05,320
toward the actual product.

1784
00:59:05,320 --> 00:59:07,000
This is where the measurement gets real.

1785
00:59:07,000 --> 00:59:08,640
We look at concepts to ship.

1786
00:59:08,640 --> 00:59:11,320
How many different things does a developer have to understand

1787
00:59:11,320 --> 00:59:13,160
just to get code into production?

1788
00:59:13,160 --> 00:59:15,440
In a manual environment, the answer is exhausting.

1789
00:59:15,440 --> 00:59:18,040
You have to understand Kubernetes networking primitives,

1790
00:59:18,040 --> 00:59:20,280
RBACCY, and persistent volumes.

1791
00:59:20,280 --> 00:59:23,120
You're worrying about ingress controllers, storage classes,

1792
00:59:23,120 --> 00:59:25,080
log aggregation, and image signing.

1793
00:59:25,080 --> 00:59:26,800
That is 15 or 20 different concepts

1794
00:59:26,800 --> 00:59:29,400
a developer has to hold in their head at the same time.

1795
00:59:29,400 --> 00:59:32,800
A mature platform reduces that down to four or five concepts.

1796
00:59:32,800 --> 00:59:36,440
Service name, environment, number of replicas, and resource limits.

1797
00:59:36,440 --> 00:59:37,160
That's it.

1798
00:59:37,160 --> 00:59:38,400
Everything else is hidden.

1799
00:59:38,400 --> 00:59:40,040
The platform handles the complexity.

1800
00:59:40,040 --> 00:59:41,000
This isn't abstract.

1801
00:59:41,000 --> 00:59:42,360
It's measurable.

1802
00:59:42,360 --> 00:59:44,800
If you give a developer a form with five fields,

1803
00:59:44,800 --> 00:59:46,440
they can fill it out in five minutes.

1804
00:59:46,440 --> 00:59:48,960
If you give them a spreadsheet with 15 complex options,

1805
00:59:48,960 --> 00:59:51,040
they will either get it wrong or spend two hours

1806
00:59:51,040 --> 00:59:52,480
researching the right answer.

1807
00:59:52,480 --> 00:59:53,920
That gap is the cognitive load,

1808
00:59:53,920 --> 00:59:56,720
and the difference in how fast they ship is something you can track.

1809
00:59:56,720 --> 00:59:59,560
But here is why cognitive load reduction is the North Star.

1810
00:59:59,560 --> 01:00:00,600
It isn't just about speed.

1811
01:00:00,600 --> 01:00:02,240
It's about everything else.

1812
01:00:02,240 --> 01:00:04,400
Lower cognitive load means faster onboarding

1813
01:00:04,400 --> 01:00:05,520
when a new engineer joins.

1814
01:00:05,520 --> 01:00:07,600
They don't have to spend three weeks learning infrastructure

1815
01:00:07,600 --> 01:00:08,720
before they can deploy.

1816
01:00:08,720 --> 01:00:10,360
They learn the platform in three days.

1817
01:00:10,360 --> 01:00:12,400
And they ship code in a week instead of a month.

1818
01:00:12,400 --> 01:00:15,200
That speed compounds across the entire organization.

1819
01:00:15,200 --> 01:00:17,360
Lower cognitive load also means fewer bugs

1820
01:00:17,360 --> 01:00:18,560
when a developer is exhausted

1821
01:00:18,560 --> 01:00:20,320
from making infrastructure decisions.

1822
01:00:20,320 --> 01:00:22,520
They get distracted, they're tired, they miss things,

1823
01:00:22,520 --> 01:00:23,560
and they rush through testing

1824
01:00:23,560 --> 01:00:24,920
because they just want to be done.

1825
01:00:24,920 --> 01:00:26,720
A platform that removes those decisions

1826
01:00:26,720 --> 01:00:28,760
lets that mental energy go back into the code.

1827
01:00:28,760 --> 01:00:30,640
Fewer bugs follow naturally.

1828
01:00:30,640 --> 01:00:32,560
It also leads to better architecture.

1829
01:00:32,560 --> 01:00:34,840
Senior engineers stop spending their time explaining

1830
01:00:34,840 --> 01:00:36,360
the right way to set up a database

1831
01:00:36,360 --> 01:00:38,040
and start focusing on system design.

1832
01:00:38,040 --> 01:00:38,880
They mentor differently.

1833
01:00:38,880 --> 01:00:41,240
They coach people on architecture instead of operations.

1834
01:00:41,240 --> 01:00:42,400
So the code base gets cleaner

1835
01:00:42,400 --> 01:00:44,400
and the systems become easier to maintain.

1836
01:00:44,400 --> 01:00:46,200
And finally, lower cognitive load

1837
01:00:46,200 --> 01:00:47,640
leads to higher job satisfaction.

1838
01:00:47,640 --> 01:00:49,520
This is the through line.

1839
01:00:49,520 --> 01:00:51,560
Developers who aren't drained by infrastructure

1840
01:00:51,560 --> 01:00:53,120
toil actually enjoy their work.

1841
01:00:53,120 --> 01:00:55,080
They aren't frustrated, they aren't burning out

1842
01:00:55,080 --> 01:00:56,480
and they stay at the company.

1843
01:00:56,480 --> 01:00:58,520
This is why cognitive load is the North Star.

1844
01:00:58,520 --> 01:01:00,080
It isn't a metric that stands alone.

1845
01:01:00,080 --> 01:01:02,000
It's the lever that moves everything else.

1846
01:01:02,000 --> 01:01:05,040
Dora metrics improve because developers aren't fighting the system.

1847
01:01:05,040 --> 01:01:07,760
Adoption climbs because the platform is actually usable.

1848
01:01:07,760 --> 01:01:10,200
Retention improves because people aren't exhausted.

1849
01:01:10,200 --> 01:01:12,440
The organization ships better code faster.

1850
01:01:12,440 --> 01:01:14,480
With engineers who are actually happy to be there,

1851
01:01:14,480 --> 01:01:17,880
everything you are building is in service of this one outcome.

1852
01:01:17,880 --> 01:01:19,840
If your platform doesn't reduce cognitive load,

1853
01:01:19,840 --> 01:01:21,760
you might have built something sophisticated,

1854
01:01:21,760 --> 01:01:24,280
but you haven't actually solved the problem.

1855
01:01:24,280 --> 01:01:27,240
The AI governance layer, you've built a solid platform.

1856
01:01:27,240 --> 01:01:29,240
Golden paths, infrastructure as code,

1857
01:01:29,240 --> 01:01:30,960
policies that enforce themselves,

1858
01:01:30,960 --> 01:01:32,960
developers are shipping fast because governance

1859
01:01:32,960 --> 01:01:34,520
is embedded into the workflow.

1860
01:01:34,520 --> 01:01:35,480
Everything is auditable.

1861
01:01:35,480 --> 01:01:36,480
It's a clean system.

1862
01:01:36,480 --> 01:01:38,600
And then M365 co-pilot enters the picture.

1863
01:01:38,600 --> 01:01:39,960
This is where the model breaks.

1864
01:01:39,960 --> 01:01:42,240
Because an AI agent isn't like a developer.

1865
01:01:42,240 --> 01:01:43,920
A developer reads the documentation.

1866
01:01:43,920 --> 01:01:45,840
They understand the constraints of the system.

1867
01:01:45,840 --> 01:01:48,080
They make deliberate human choices.

1868
01:01:48,080 --> 01:01:49,480
An AI agent doesn't do that.

1869
01:01:49,480 --> 01:01:52,960
An AI agent simply looks at what it has access to and uses it.

1870
01:01:52,960 --> 01:01:54,880
If your infrastructure is inconsistent,

1871
01:01:54,880 --> 01:01:56,760
the agent operates inconsistently.

1872
01:01:56,760 --> 01:01:59,560
If there are security gaps, the agent inherits them.

1873
01:01:59,560 --> 01:02:01,920
If your governance is manual, the agent can't follow it.

1874
01:02:01,920 --> 01:02:04,360
The floor is inheritance.

1875
01:02:04,360 --> 01:02:06,320
When your infrastructure is manually configured,

1876
01:02:06,320 --> 01:02:08,360
inconsistencies are scattered everywhere.

1877
01:02:08,360 --> 01:02:10,560
One team sets up a database with encryption

1878
01:02:10,560 --> 01:02:12,480
while another team leaves theirs dark.

1879
01:02:12,480 --> 01:02:15,000
Networking rules vary from one department to the next.

1880
01:02:15,000 --> 01:02:16,800
Access controls are ad hoc.

1881
01:02:16,800 --> 01:02:18,360
A developer navigating this mess

1882
01:02:18,360 --> 01:02:21,080
makes a conscious choice about which pattern to follow.

1883
01:02:21,080 --> 01:02:21,880
They bring context.

1884
01:02:21,880 --> 01:02:22,920
They bring judgment.

1885
01:02:22,920 --> 01:02:24,600
An AI agent doesn't.

1886
01:02:24,600 --> 01:02:27,360
The agent encounters the infrastructure exactly as it exists.

1887
01:02:27,360 --> 01:02:29,280
If it can access a resource, it will.

1888
01:02:29,280 --> 01:02:31,800
If it is permitted to create something, it creates it.

1889
01:02:31,800 --> 01:02:34,040
The agent doesn't know that one team's database

1890
01:02:34,040 --> 01:02:36,120
is misconfigured and should be avoided.

1891
01:02:36,120 --> 01:02:37,960
It doesn't know that creating a public IP

1892
01:02:37,960 --> 01:02:40,800
violates your security posture, even if the system technically

1893
01:02:40,800 --> 01:02:42,120
allowed the API call.

1894
01:02:42,120 --> 01:02:44,400
The agency's a landscape of APIs and permissions.

1895
01:02:44,400 --> 01:02:46,800
It doesn't see the intent behind the configuration.

1896
01:02:46,800 --> 01:02:49,960
So when you deploy AI agents into an inconsistent environment,

1897
01:02:49,960 --> 01:02:51,320
they amplify the mess.

1898
01:02:51,320 --> 01:02:52,200
They find the gaps.

1899
01:02:52,200 --> 01:02:53,360
They exploit them.

1900
01:02:53,360 --> 01:02:56,800
Not because they're malicious, but just because they can.

1901
01:02:56,800 --> 01:02:58,440
A copilot agent trained on your code base

1902
01:02:58,440 --> 01:03:00,240
will use whatever patterns it finds.

1903
01:03:00,240 --> 01:03:02,000
If your services are misconfigured,

1904
01:03:02,000 --> 01:03:04,520
the agent will generate code that matches those broken

1905
01:03:04,520 --> 01:03:05,120
patterns.

1906
01:03:05,120 --> 01:03:06,320
It propagates the problem.

1907
01:03:06,320 --> 01:03:08,680
This is the governance challenge at the agent layer.

1908
01:03:08,680 --> 01:03:11,160
You can't rely on agents to understand what they shouldn't do.

1909
01:03:11,160 --> 01:03:13,160
You have to make it impossible for them to do it.

1910
01:03:13,160 --> 01:03:15,400
The solution is to embed governance at the API level.

1911
01:03:15,400 --> 01:03:18,520
When an AI agent calls an API to create a resource,

1912
01:03:18,520 --> 01:03:21,480
that call must hit a policy check before anything happens.

1913
01:03:21,480 --> 01:03:23,600
The policy verifies the permissions, the encryption,

1914
01:03:23,600 --> 01:03:26,200
the security posture, and the data residency rules.

1915
01:03:26,200 --> 01:03:28,360
If any check fails, the call is denied.

1916
01:03:28,360 --> 01:03:29,800
The agent doesn't get an error message.

1917
01:03:29,800 --> 01:03:31,040
It might misinterpret.

1918
01:03:31,040 --> 01:03:32,400
The action simply doesn't happen.

1919
01:03:32,400 --> 01:03:34,880
This requires the infrastructure you've already built.

1920
01:03:34,880 --> 01:03:36,960
The policy as code prevents the wrong actions,

1921
01:03:36,960 --> 01:03:40,200
while RBAC ensures agents only touch what they should.

1922
01:03:40,200 --> 01:03:42,840
Audit trails log every move so you know exactly what happened

1923
01:03:42,840 --> 01:03:43,800
and when.

1924
01:03:43,800 --> 01:03:45,120
But you need a new layer on top.

1925
01:03:45,120 --> 01:03:47,600
Agent identity every AI agent is a principle.

1926
01:03:47,600 --> 01:03:48,520
It has credentials.

1927
01:03:48,520 --> 01:03:49,360
It has permissions.

1928
01:03:49,360 --> 01:03:51,360
It has accountability.

1929
01:03:51,360 --> 01:03:53,640
When co-pilot interacts with your infrastructure,

1930
01:03:53,640 --> 01:03:56,400
it does so with a specific identity.

1931
01:03:56,400 --> 01:03:59,520
Every action is logged to that identity, meaning you can trace

1932
01:03:59,520 --> 01:04:02,960
every infrastructure change back to the specific agent that made it.

1933
01:04:02,960 --> 01:04:06,240
Measurement shifts to compliance score becomes the percentage

1934
01:04:06,240 --> 01:04:08,480
of AI actions that actually meet your policy.

1935
01:04:08,480 --> 01:04:11,680
If an agent tries to violate a rule, that counts as a failure.

1936
01:04:11,680 --> 01:04:14,640
You see immediately if an agent is behaving outside the guard rails.

1937
01:04:14,640 --> 01:04:16,320
The outcome is safety at scale.

1938
01:04:16,320 --> 01:04:19,120
You can enable AI agents to interact with your systems

1939
01:04:19,120 --> 01:04:20,760
without creating new risks.

1940
01:04:20,760 --> 01:04:22,600
They operate within the boundaries you've defined.

1941
01:04:22,600 --> 01:04:25,920
They can't create something insecure because the policy prevents it.

1942
01:04:25,920 --> 01:04:26,960
They can't access data.

1943
01:04:26,960 --> 01:04:28,840
They shouldn't because RBAC blocks it.

1944
01:04:28,840 --> 01:04:31,840
They can't operate in the dark because every action is audited.

1945
01:04:31,840 --> 01:04:34,600
This is where automation and AI safety converge.

1946
01:04:34,600 --> 01:04:36,320
You've simplified the decision so much

1947
01:04:36,320 --> 01:04:38,560
that agents can navigate the system safely.

1948
01:04:38,560 --> 01:04:41,880
Your policy automation is so full that agents inherit compliance

1949
01:04:41,880 --> 01:04:43,200
instead of chaos.

1950
01:04:43,200 --> 01:04:44,360
Migration path.

1951
01:04:44,360 --> 01:04:46,120
From manual to platform driven.

1952
01:04:46,120 --> 01:04:47,960
So you've decided to build a platform.

1953
01:04:47,960 --> 01:04:49,080
You understand the tax.

1954
01:04:49,080 --> 01:04:50,040
You understand the cost.

1955
01:04:50,040 --> 01:04:51,720
You understand what success looks like.

1956
01:04:51,720 --> 01:04:53,760
Now the question is, how do you actually get there?

1957
01:04:53,760 --> 01:04:56,760
How do you move from teams scattered across a fragmented landscape

1958
01:04:56,760 --> 01:04:58,280
to a unified platform?

1959
01:04:58,280 --> 01:04:59,440
The path is six phases.

1960
01:04:59,440 --> 01:05:03,400
It takes 18 to 24 months to reach a functioning adopted platform.

1961
01:05:03,400 --> 01:05:06,560
It's not fast, but it's faster than continuing to pay the tax.

1962
01:05:06,560 --> 01:05:08,480
Phase one is baseline and discovery.

1963
01:05:08,480 --> 01:05:09,760
This takes about three months.

1964
01:05:09,760 --> 01:05:11,080
You don't start building it.

1965
01:05:11,080 --> 01:05:11,800
You start measuring.

1966
01:05:11,800 --> 01:05:14,480
You look at your door on metrics to see how often deployments break

1967
01:05:14,480 --> 01:05:15,760
and how long recovery takes.

1968
01:05:15,760 --> 01:05:17,760
You run a survey to measure cognitive load.

1969
01:05:17,760 --> 01:05:19,800
How many concepts does a developer need to understand

1970
01:05:19,800 --> 01:05:21,120
just to get code live?

1971
01:05:21,120 --> 01:05:23,720
You identify the pain points by talking to the teams.

1972
01:05:23,720 --> 01:05:24,880
Ask them where they get blocked

1973
01:05:24,880 --> 01:05:26,800
and when they give up and build a workaround.

1974
01:05:26,800 --> 01:05:29,040
Usually the answer is environment provisioning

1975
01:05:29,040 --> 01:05:30,480
or deployment pipelines.

1976
01:05:30,480 --> 01:05:31,520
Friction is high there.

1977
01:05:31,520 --> 01:05:33,320
The return on solving it is immediate.

1978
01:05:33,320 --> 01:05:35,760
Phase two is building the thinnest viable platform.

1979
01:05:35,760 --> 01:05:37,680
This happens between months, four and six.

1980
01:05:37,680 --> 01:05:39,360
You focus on the 80% case.

1981
01:05:39,360 --> 01:05:41,240
Don't try to solve every edge case.

1982
01:05:41,240 --> 01:05:42,520
Solve what most teams need.

1983
01:05:42,520 --> 01:05:44,800
Start with a standard CIS/CD pipeline

1984
01:05:44,800 --> 01:05:47,760
that handles the basics like testing and security scanning.

1985
01:05:47,760 --> 01:05:50,240
Then move to environment provisioning.

1986
01:05:50,240 --> 01:05:52,040
Developers need to be able to push a button

1987
01:05:52,040 --> 01:05:53,960
and get a test environment in minutes.

1988
01:05:53,960 --> 01:05:55,920
Add the fundamentals of observability,

1989
01:05:55,920 --> 01:05:57,240
like logging and alerts,

1990
01:05:57,240 --> 01:05:59,520
and build security scanning into the pipeline.

1991
01:05:59,520 --> 01:06:02,560
These four capabilities solve the most obvious problems.

1992
01:06:02,560 --> 01:06:04,680
Phase three is piloting with early adopters.

1993
01:06:04,680 --> 01:06:06,440
This covers months 7 through 9.

1994
01:06:06,440 --> 01:06:07,800
You don't launch to the whole company.

1995
01:06:07,800 --> 01:06:09,120
You launch to two or three teams

1996
01:06:09,120 --> 01:06:10,480
who actually want to make it work.

1997
01:06:10,480 --> 01:06:11,640
You work closely with them

1998
01:06:11,640 --> 01:06:13,400
and watch how they use the platform.

1999
01:06:13,400 --> 01:06:15,600
You see what breaks and what feels unclear.

2000
01:06:15,600 --> 01:06:17,480
You gather feedback relentlessly

2001
01:06:17,480 --> 01:06:21,080
and refine the system based on real usage, not theory.

2002
01:06:21,080 --> 01:06:22,680
These pilot teams become your advocates

2003
01:06:22,680 --> 01:06:24,680
because they see the benefit every day.

2004
01:06:24,680 --> 01:06:26,520
Phase four is expanding adoption.

2005
01:06:26,520 --> 01:06:28,560
This takes you through the end of the first year.

2006
01:06:28,560 --> 01:06:30,280
You roll out to more teams gradually.

2007
01:06:30,280 --> 01:06:33,920
You use enabling teams like Cloud Coaches and SRE Guides

2008
01:06:33,920 --> 01:06:35,960
to help people adopt the new way of working.

2009
01:06:35,960 --> 01:06:38,560
Their job isn't to force adoption, it's to support it.

2010
01:06:38,560 --> 01:06:39,600
You watch the metrics.

2011
01:06:39,600 --> 01:06:41,560
If adoption is stalling, you ask why?

2012
01:06:41,560 --> 01:06:43,080
Is the platform not solving the problem?

2013
01:06:43,080 --> 01:06:44,520
Is the documentation confusing?

2014
01:06:44,520 --> 01:06:46,280
You fix the platform, not the teams.

2015
01:06:46,280 --> 01:06:48,080
Phase five is measure and optimize.

2016
01:06:48,080 --> 01:06:50,280
This happens between months 13 and 18.

2017
01:06:50,280 --> 01:06:52,680
You track adoption rates and developer satisfaction.

2018
01:06:52,680 --> 01:06:54,680
You check if the concepts to ship numbers

2019
01:06:54,680 --> 01:06:55,960
are actually going down.

2020
01:06:55,960 --> 01:06:58,680
You look at the door metrics for the teams using the platform.

2021
01:06:58,680 --> 01:07:00,560
If adoption is stuck at 50%,

2022
01:07:00,560 --> 01:07:03,600
you investigate the friction before you try to expand the scope.

2023
01:07:03,600 --> 01:07:05,400
Phase six is expanding scope.

2024
01:07:05,400 --> 01:07:09,040
This is the final stretch from month 19 to 24.

2025
01:07:09,040 --> 01:07:11,320
Only now do you add specialized capabilities

2026
01:07:11,320 --> 01:07:14,120
like cost governance or advanced networking.

2027
01:07:14,120 --> 01:07:16,800
You add these because teams have proven they trust the platform.

2028
01:07:16,800 --> 01:07:18,400
You've earned the right to expand.

2029
01:07:18,400 --> 01:07:21,000
The entire timeline is 18 to 24 months.

2030
01:07:21,000 --> 01:07:24,360
It sounds long, but compare it to the cost of doing things manually

2031
01:07:24,360 --> 01:07:25,640
for another five years.

2032
01:07:25,640 --> 01:07:28,560
18 months to transform how your organization operates is fast.

2033
01:07:28,560 --> 01:07:29,880
The key is discipline.

2034
01:07:29,880 --> 01:07:31,120
Don't skip phases.

2035
01:07:31,120 --> 01:07:33,320
Don't try to build everything in phase two.

2036
01:07:33,320 --> 01:07:36,000
Don't launch to everyone before you've refined the system

2037
01:07:36,000 --> 01:07:36,960
with your pilots.

2038
01:07:36,960 --> 01:07:39,240
The phases exist because they work.

2039
01:07:39,240 --> 01:07:40,640
The ROI story.

2040
01:07:40,640 --> 01:07:43,240
None of this matters if you can't justify the investment.

2041
01:07:43,240 --> 01:07:44,480
So let's look at the business case.

2042
01:07:44,480 --> 01:07:47,720
Most organizations spend 20 to 30% of their engineering capacity

2043
01:07:47,720 --> 01:07:50,480
on infrastructure, toil, not on architecture, not on design,

2044
01:07:50,480 --> 01:07:51,600
just toil.

2045
01:07:51,600 --> 01:07:53,840
This is the repetitive, non-differentiating work

2046
01:07:53,840 --> 01:07:57,240
that eats up time without creating any value for your customers.

2047
01:07:57,240 --> 01:07:59,160
If you have 100 person engineering team,

2048
01:07:59,160 --> 01:08:02,160
that means 20 to 30 people are essentially stuck.

2049
01:08:02,160 --> 01:08:04,120
Their job description says engineer.

2050
01:08:04,120 --> 01:08:05,760
But their daily reality is just keeping

2051
01:08:05,760 --> 01:08:07,560
the infrastructure from falling apart.

2052
01:08:07,560 --> 01:08:08,640
They aren't shipping features.

2053
01:08:08,640 --> 01:08:10,560
They aren't solving customer problems.

2054
01:08:10,560 --> 01:08:12,920
They are running runbooks, answering the same questions

2055
01:08:12,920 --> 01:08:15,240
about deployments and debugging networking issues

2056
01:08:15,240 --> 01:08:16,200
over and over again.

2057
01:08:16,200 --> 01:08:18,480
They spend their days reviewing infrastructure changes

2058
01:08:18,480 --> 01:08:20,320
or sitting on call for outages.

2059
01:08:20,320 --> 01:08:22,760
None of that work ever shows up on a product roadmap.

2060
01:08:22,760 --> 01:08:23,960
It doesn't generate revenue.

2061
01:08:23,960 --> 01:08:24,720
It's a tax.

2062
01:08:24,720 --> 01:08:26,840
Now, let's put a dollar amount on that tax.

2063
01:08:26,840 --> 01:08:30,400
The fully loaded cost for an engineer is roughly $150,000

2064
01:08:30,400 --> 01:08:34,320
per year once you factor in salary, benefits, and overhead.

2065
01:08:34,320 --> 01:08:38,200
30 engineers at $150,000 each adds up to $4.5 million

2066
01:08:38,200 --> 01:08:39,040
every single year.

2067
01:08:39,040 --> 01:08:42,000
That is $4.5 million spent on infrastructure toil

2068
01:08:42,000 --> 01:08:44,400
that could have been spent building things people actually pay for.

2069
01:08:44,400 --> 01:08:45,360
This is your baseline.

2070
01:08:45,360 --> 01:08:47,160
This is what you are paying right now.

2071
01:08:47,160 --> 01:08:49,640
You don't see it as a problem because it's baked into your planning.

2072
01:08:49,640 --> 01:08:50,800
The money leaves your budget,

2073
01:08:50,800 --> 01:08:53,840
but it doesn't show up as a line item called infrastructure tax.

2074
01:08:53,840 --> 01:08:56,200
It's just buried in engineering capacity.

2075
01:08:56,200 --> 01:08:58,560
You assume you need these people, you budget for them,

2076
01:08:58,560 --> 01:08:59,400
and you move on.

2077
01:08:59,400 --> 01:09:02,280
But you never stop to ask what if we didn't need to work this way?

2078
01:09:02,280 --> 01:09:03,800
Now look at the platform investment.

2079
01:09:03,800 --> 01:09:07,840
A mature platform team usually costs between $1.2 million per year.

2080
01:09:07,840 --> 01:09:10,520
That covers the salaries for platform engineers, architects,

2081
01:09:10,520 --> 01:09:13,400
and product managers plus the cloud costs in tooling.

2082
01:09:13,400 --> 01:09:16,320
Compare that $2 million investment to the $4.5 million

2083
01:09:16,320 --> 01:09:18,000
you are currently losing to toil.

2084
01:09:18,000 --> 01:09:19,240
Here is the payoff.

2085
01:09:19,240 --> 01:09:21,760
If the platform cuts that toil by just 50%,

2086
01:09:21,760 --> 01:09:24,680
you recover over $2 million in developer capacity.

2087
01:09:24,680 --> 01:09:27,120
You are spending $2 million to get $2.4 million back.

2088
01:09:27,120 --> 01:09:28,680
That's a net gain in year one.

2089
01:09:28,680 --> 01:09:30,560
But the math gets even better in year two.

2090
01:09:30,560 --> 01:09:34,000
Your platform costs stay steady at $1.2 million,

2091
01:09:34,000 --> 01:09:35,960
but adoption is now much higher.

2092
01:09:35,960 --> 01:09:37,920
More teams are using the golden paths.

2093
01:09:37,920 --> 01:09:39,040
Cognitive load is dropping.

2094
01:09:39,040 --> 01:09:40,960
Time to first deploy is faster.

2095
01:09:40,960 --> 01:09:43,040
The toil doesn't come back, so your payoff stays high

2096
01:09:43,040 --> 01:09:45,400
while your delivery metrics start to multiply.

2097
01:09:45,400 --> 01:09:48,320
By the second year, you have recovered the entire investment

2098
01:09:48,320 --> 01:09:49,680
and you're seeing net savings.

2099
01:09:49,680 --> 01:09:51,320
By year three, those savings compound.

2100
01:09:51,320 --> 01:09:52,640
You built the platform once,

2101
01:09:52,640 --> 01:09:55,360
and now it operates at scale without the team leading to grow.

2102
01:09:55,360 --> 01:09:57,800
The money that used to flow into the void of toil

2103
01:09:57,800 --> 01:10:00,000
is now flowing directly into features.

2104
01:10:00,000 --> 01:10:02,040
That's how you build a competitive advantage.

2105
01:10:02,040 --> 01:10:05,120
Mature platforms report between 208% ROI

2106
01:10:05,120 --> 01:10:06,680
within 18 to 24 months.

2107
01:10:06,680 --> 01:10:07,520
That isn't a theory.

2108
01:10:07,520 --> 01:10:10,120
That is what's being reported from actual implementations.

2109
01:10:10,120 --> 01:10:13,600
200% means you get $2 back for every dollar you put in.

2110
01:10:13,600 --> 01:10:15,320
The range is wide because it depends

2111
01:10:15,320 --> 01:10:17,120
on how much you're struggling right now.

2112
01:10:17,120 --> 01:10:19,320
If you are drowning in toil, your return will be closer

2113
01:10:19,320 --> 01:10:21,040
to that 800% mark.

2114
01:10:21,040 --> 01:10:22,600
The timeline is the only catch.

2115
01:10:22,600 --> 01:10:26,480
18 to 24 months is longer than a single quarterly budget cycle.

2116
01:10:26,480 --> 01:10:27,520
It requires patience.

2117
01:10:27,520 --> 01:10:30,320
It requires leadership that looks past the next three months.

2118
01:10:30,320 --> 01:10:31,600
But here's the alternative.

2119
01:10:31,600 --> 01:10:33,360
You can keep paying the tax forever.

2120
01:10:33,360 --> 01:10:36,360
You can keep losing $4.5 million a year indefinitely.

2121
01:10:36,360 --> 01:10:39,240
The choice isn't actually between investing and not investing.

2122
01:10:39,240 --> 01:10:40,720
You are already spending the money.

2123
01:10:40,720 --> 01:10:42,800
The only question is whether you're spending it

2124
01:10:42,800 --> 01:10:45,160
on building features or spending it on the overhead

2125
01:10:45,160 --> 01:10:48,320
that prevents those features from being built.

2126
01:10:48,320 --> 01:10:50,200
Common objections on how to answer them.

2127
01:10:50,200 --> 01:10:51,440
You're going to hear pushback.

2128
01:10:51,440 --> 01:10:53,720
It will come from engineering leaders, product managers,

2129
01:10:53,720 --> 01:10:55,160
and definitely the CFO.

2130
01:10:55,160 --> 01:10:58,040
The objections are predictable. They sound reasonable.

2131
01:10:58,040 --> 01:10:59,800
Until you look at what they're actually saying,

2132
01:10:59,800 --> 01:11:01,480
the first one is the most common.

2133
01:11:01,480 --> 01:11:03,520
We don't have time to build a platform.

2134
01:11:03,520 --> 01:11:04,760
We need to ship features.

2135
01:11:04,760 --> 01:11:06,320
This one is tough because it's true.

2136
01:11:06,320 --> 01:11:07,440
You do need to ship.

2137
01:11:07,440 --> 01:11:09,560
The market doesn't care about your internal tools.

2138
01:11:09,560 --> 01:11:11,160
So why spend months building something

2139
01:11:11,160 --> 01:11:12,600
the customer never sees?

2140
01:11:12,600 --> 01:11:14,960
The answer requires a shift in how you look at time.

2141
01:11:14,960 --> 01:11:17,520
You aren't choosing between a platform and features.

2142
01:11:17,520 --> 01:11:19,360
You're choosing where the toil goes.

2143
01:11:19,360 --> 01:11:21,880
Right now, your teams are trying to ship features

2144
01:11:21,880 --> 01:11:24,200
while they manage infrastructure at the same time.

2145
01:11:24,200 --> 01:11:26,520
They are doing both and they are doing both badly.

2146
01:11:26,520 --> 01:11:28,560
Context switching is a productivity killer.

2147
01:11:28,560 --> 01:11:31,160
So the real question is, can you afford not to build this?

2148
01:11:31,160 --> 01:11:32,480
The time is already being spent.

2149
01:11:32,480 --> 01:11:34,840
It's just being spent inefficiently by everyone at once.

2150
01:11:34,840 --> 01:11:36,680
A platform consolidates that work.

2151
01:11:36,680 --> 01:11:39,640
It moves the infrastructure burden to one dedicated team

2152
01:11:39,640 --> 01:11:41,840
and frees everyone else to focus on the product.

2153
01:11:41,840 --> 01:11:42,800
You aren't losing time.

2154
01:11:42,800 --> 01:11:44,000
You're relocating it.

2155
01:11:44,000 --> 01:11:46,000
And that relocation is exactly what makes

2156
01:11:46,000 --> 01:11:47,920
you ship faster in the long run.

2157
01:11:47,920 --> 01:11:50,320
The second objection is about variety.

2158
01:11:50,320 --> 01:11:51,640
Our teams are two different.

2159
01:11:51,640 --> 01:11:52,960
We can't have golden paths.

2160
01:11:52,960 --> 01:11:55,320
Every organization thinks they are a special case.

2161
01:11:55,320 --> 01:11:57,360
They think their architecture is too complex

2162
01:11:57,360 --> 01:11:59,000
or their constraints are unique.

2163
01:11:59,000 --> 01:12:00,400
Maybe some of that is true.

2164
01:12:00,400 --> 01:12:04,640
But in reality, 80% of what your teams do is exactly the same.

2165
01:12:04,640 --> 01:12:05,920
They create a service.

2166
01:12:05,920 --> 01:12:06,600
They deploy it.

2167
01:12:06,600 --> 01:12:07,840
They monitor it.

2168
01:12:07,840 --> 01:12:11,120
The 20% that is actually different is handled by escape hatches.

2169
01:12:11,120 --> 01:12:13,080
The golden path covers the bulk of the work.

2170
01:12:13,080 --> 01:12:15,040
If a team has a legitimate edge case,

2171
01:12:15,040 --> 01:12:17,800
they work with the platform team to build a solution.

2172
01:12:17,800 --> 01:12:18,800
But that is the exception.

2173
01:12:18,800 --> 01:12:19,640
It isn't the rule.

2174
01:12:19,640 --> 01:12:21,520
The mistake is assuming the exceptions happen

2175
01:12:21,520 --> 01:12:23,520
more often than they actually do.

2176
01:12:23,520 --> 01:12:26,280
The third objection comes from past trauma.

2177
01:12:26,280 --> 01:12:28,280
We tried a platform before and it failed.

2178
01:12:28,280 --> 01:12:29,720
This is just a scar tissue.

2179
01:12:29,720 --> 01:12:31,400
Maybe a previous initiative didn't work

2180
01:12:31,400 --> 01:12:32,680
or teams refused to use it.

2181
01:12:32,680 --> 01:12:33,920
It's a fair concern.

2182
01:12:33,920 --> 01:12:36,160
But the failure wasn't because the concept of a platform

2183
01:12:36,160 --> 01:12:36,960
is flawed.

2184
01:12:36,960 --> 01:12:38,840
The failure was organizational.

2185
01:12:38,840 --> 01:12:41,120
Either it was built without talking to the developers

2186
01:12:41,120 --> 01:12:43,520
or it was never measured or it was a top-down mandate

2187
01:12:43,520 --> 01:12:45,200
that made everyone's life harder.

2188
01:12:45,200 --> 01:12:46,400
This time is different because you

2189
01:12:46,400 --> 01:12:48,000
are treating the platform as a product.

2190
01:12:48,000 --> 01:12:49,240
You are measuring adoption.

2191
01:12:49,240 --> 01:12:51,320
You are focusing on the developer experience.

2192
01:12:51,320 --> 01:12:53,480
You are starting small and expanding

2193
01:12:53,480 --> 01:12:55,360
based on what the evidence tells you.

2194
01:12:55,360 --> 01:12:57,320
The fourth objection is about speed.

2195
01:12:57,320 --> 01:12:59,120
Governance will slow us down.

2196
01:12:59,120 --> 01:13:01,360
People hear governance and they think of manual reviews

2197
01:13:01,360 --> 01:13:02,520
and approval workflows.

2198
01:13:02,520 --> 01:13:03,680
Those are bottlenecks.

2199
01:13:03,680 --> 01:13:05,760
But policy is code isn't a bottleneck.

2200
01:13:05,760 --> 01:13:07,520
It's automation.

2201
01:13:07,520 --> 01:13:09,360
A policy check runs in milliseconds.

2202
01:13:09,360 --> 01:13:11,760
It approves or denies based on clear rules.

2203
01:13:11,760 --> 01:13:13,080
There is no human in the loop

2204
01:13:13,080 --> 01:13:15,000
and no waiting around for a meeting.

2205
01:13:15,000 --> 01:13:17,280
This makes governance faster than the alternative.

2206
01:13:17,280 --> 01:13:19,680
It's much better than a developer spending three days

2207
01:13:19,680 --> 01:13:21,960
working on something only to find out it violates

2208
01:13:21,960 --> 01:13:23,360
a security policy later.

2209
01:13:23,360 --> 01:13:25,560
The last objection is the most practical.

2210
01:13:25,560 --> 01:13:27,000
We can't afford to build this.

2211
01:13:27,000 --> 01:13:28,000
It's a fair question.

2212
01:13:28,000 --> 01:13:29,320
Where does the money come from?

2213
01:13:29,320 --> 01:13:31,840
The budget answer is that you're already spending it.

2214
01:13:31,840 --> 01:13:33,200
The platform costs two million

2215
01:13:33,200 --> 01:13:35,480
but you're losing four and a half million to toil.

2216
01:13:35,480 --> 01:13:38,000
Right now, you are just redirecting the spend.

2217
01:13:38,000 --> 01:13:40,160
But the deeper truth is that you can't afford to wait.

2218
01:13:40,160 --> 01:13:42,720
The cost of doing nothing compounds every single year.

2219
01:13:42,720 --> 01:13:44,240
Every year you delay is another year

2220
01:13:44,240 --> 01:13:46,680
you pay that four and a half million dollar tax.

2221
01:13:46,680 --> 01:13:48,760
The ROI of the platform only gets clearer

2222
01:13:48,760 --> 01:13:50,120
the longer you wait to start.

2223
01:13:50,120 --> 01:13:52,520
These objections aren't really about the technology.

2224
01:13:52,520 --> 01:13:53,680
They are about a fear of change

2225
01:13:53,680 --> 01:13:54,840
and the memory of past failures.

2226
01:13:54,840 --> 01:13:56,480
Those feelings are legitimate.

2227
01:13:56,480 --> 01:13:58,600
But they aren't arguments against building.

2228
01:13:58,600 --> 01:14:00,400
They are arguments for building thoughtfully.

2229
01:14:00,400 --> 01:14:03,640
Start small, measure everything and grow

2230
01:14:03,640 --> 01:14:05,640
based on what actually works.

2231
01:14:05,640 --> 01:14:07,880
The future state, what success looks like.

2232
01:14:07,880 --> 01:14:10,360
Imagine it six months after you launched the platform.

2233
01:14:10,360 --> 01:14:12,640
A new developer joins the team on a Monday morning.

2234
01:14:12,640 --> 01:14:15,600
By Tuesday afternoon, she has already shipped her first change

2235
01:14:15,600 --> 01:14:17,800
to production, not a staging environment,

2236
01:14:17,800 --> 01:14:20,000
not a local branch, production.

2237
01:14:20,000 --> 01:14:21,800
She provisioned the environment herself.

2238
01:14:21,800 --> 01:14:24,200
She deployed the code, she saw the results live.

2239
01:14:24,200 --> 01:14:26,240
And the entire process took about four hours

2240
01:14:26,240 --> 01:14:28,000
compared that to 18 months ago

2241
01:14:28,000 --> 01:14:30,560
when that same developer would have spent three weeks

2242
01:14:30,560 --> 01:14:32,160
just learning infrastructure concepts

2243
01:14:32,160 --> 01:14:33,800
before shipping a single line.

2244
01:14:33,800 --> 01:14:36,840
The real difference here isn't just speed, it's psychology.

2245
01:14:36,840 --> 01:14:38,400
She isn't intimidated by the system.

2246
01:14:38,400 --> 01:14:39,560
She isn't drowning in tickets.

2247
01:14:39,560 --> 01:14:40,920
She is productive on day one

2248
01:14:40,920 --> 01:14:44,280
because the platform made the right way, the easy way.

2249
01:14:44,280 --> 01:14:46,080
If you walk through the code base now,

2250
01:14:46,080 --> 01:14:49,240
you'll see that 80% of services follow the same golden path.

2251
01:14:49,240 --> 01:14:50,520
They use the same deployment steps,

2252
01:14:50,520 --> 01:14:53,000
the same security posture and the same patterns.

2253
01:14:53,000 --> 01:14:55,320
This isn't about restriction, it's about clarity.

2254
01:14:55,320 --> 01:14:59,000
Teams use the standard approach because they know it works.

2255
01:14:59,000 --> 01:15:00,040
They know it's been tested

2256
01:15:00,040 --> 01:15:02,120
and they know support is actually there if they need it

2257
01:15:02,120 --> 01:15:04,240
for the 20% that need something unique.

2258
01:15:04,240 --> 01:15:05,800
They have escape hatches, they collaborate

2259
01:15:05,800 --> 01:15:08,160
with the platform team to build what they need.

2260
01:15:08,160 --> 01:15:09,600
But the standard remains the default

2261
01:15:09,600 --> 01:15:11,760
when you ask a developer where her time goes.

2262
01:15:11,760 --> 01:15:13,920
She'll tell you 80% is spent on features.

2263
01:15:13,920 --> 01:15:15,160
She's designing systems.

2264
01:15:15,160 --> 01:15:16,120
She's writing code.

2265
01:15:16,120 --> 01:15:17,840
She's thinking about customer value.

2266
01:15:17,840 --> 01:15:20,600
Only 20% of her time goes to infrastructure tasks

2267
01:15:20,600 --> 01:15:23,280
like provisioning or debugging compliance checks

2268
01:15:23,280 --> 01:15:24,280
before the platform.

2269
01:15:24,280 --> 01:15:26,520
That ratio was completely inverted.

2270
01:15:26,520 --> 01:15:28,200
The cognitive energy that used to be scattered

2271
01:15:28,200 --> 01:15:31,800
across tool decisions is now consolidated into one place.

2272
01:15:31,800 --> 01:15:34,560
Her mind is finally free for the work that actually matters.

2273
01:15:34,560 --> 01:15:37,040
The concept to ship metric is holding steady at four.

2274
01:15:37,040 --> 01:15:40,840
Service name, environment, replica account, resource limits.

2275
01:15:40,840 --> 01:15:42,520
Everything else is abstracted away.

2276
01:15:42,520 --> 01:15:44,000
A new engineer doesn't need to understand

2277
01:15:44,000 --> 01:15:46,840
Kubernetes networking or reason about ingress controllers

2278
01:15:46,840 --> 01:15:48,520
because those things are invisible.

2279
01:15:48,520 --> 01:15:50,680
She talks to the platform in her own language.

2280
01:15:50,680 --> 01:15:52,400
Not the language of the infrastructure.

2281
01:15:52,400 --> 01:15:53,800
Look at the adoption numbers.

2282
01:15:53,800 --> 01:15:57,240
85% of teams use the platform for their standard needs.

2283
01:15:57,240 --> 01:15:59,080
Not because of a mandate, but because it works.

2284
01:15:59,080 --> 01:16:01,200
They use it because it's faster than the alternative.

2285
01:16:01,200 --> 01:16:03,280
They use it because the documentation is clear.

2286
01:16:03,280 --> 01:16:05,120
They use it because when something breaks,

2287
01:16:05,120 --> 01:16:06,600
support is immediate.

2288
01:16:06,600 --> 01:16:08,920
Voluntary adoption is the only proof point that matters.

2289
01:16:08,920 --> 01:16:12,000
If teams are using it willingly, you solve the right problem.

2290
01:16:12,000 --> 01:16:13,840
Governance no longer feels like friction.

2291
01:16:13,840 --> 01:16:15,160
It's invisible.

2292
01:16:15,160 --> 01:16:17,720
When a deployment runs, policy checks happen in milliseconds.

2293
01:16:17,720 --> 01:16:20,680
The code either moves forward or fails based on automated rules.

2294
01:16:20,680 --> 01:16:24,280
There is no approval workflow, no bottleneck, no waiting.

2295
01:16:24,280 --> 01:16:25,920
Security teams finally sleep at night

2296
01:16:25,920 --> 01:16:28,400
because policies are enforced at the point of action.

2297
01:16:28,400 --> 01:16:30,320
Not weeks later, during a manual audit,

2298
01:16:30,320 --> 01:16:32,760
measurement is now continuous.

2299
01:16:32,760 --> 01:16:35,760
You can open a dashboard and see adoption metrics in real time.

2300
01:16:35,760 --> 01:16:38,680
You see that time the first deploy is down to four hours

2301
01:16:38,680 --> 01:16:41,320
and the change failure rate has dropped by 60%.

2302
01:16:41,320 --> 01:16:43,040
Deployment frequency has tripled.

2303
01:16:43,040 --> 01:16:45,360
Lead times have been cut by 70%.

2304
01:16:45,360 --> 01:16:46,960
The metrics are green because the platform

2305
01:16:46,960 --> 01:16:48,880
is doing exactly what it was designed to do.

2306
01:16:48,880 --> 01:16:51,040
Even AI agents can operate safely now

2307
01:16:51,040 --> 01:16:52,560
because governance is embedded.

2308
01:16:52,560 --> 01:16:55,720
When a tool like co-pilot tries to create a resource,

2309
01:16:55,720 --> 01:16:58,960
the policy engine evaluates that request before it happens.

2310
01:16:58,960 --> 01:17:01,440
The agent can't accidentally create something insecure

2311
01:17:01,440 --> 01:17:03,520
because the platform simply won't allow it.

2312
01:17:03,520 --> 01:17:06,120
The audit trails show exactly what happened and when.

2313
01:17:06,120 --> 01:17:08,840
Governance is tighter than ever, but it's invisible.

2314
01:17:08,840 --> 01:17:10,920
The agent just works within the guardrails.

2315
01:17:10,920 --> 01:17:13,040
The choice, the DevOps Tax is real.

2316
01:17:13,040 --> 01:17:15,520
It is costing your organization millions of dollars

2317
01:17:15,520 --> 01:17:16,440
every single year.

2318
01:17:16,440 --> 01:17:18,520
It's an invisible cost, built into salaries,

2319
01:17:18,520 --> 01:17:20,040
and burned into engineering capacity

2320
01:17:20,040 --> 01:17:21,360
that should be going toward building.

2321
01:17:21,360 --> 01:17:23,280
Platform engineering is the correction.

2322
01:17:23,280 --> 01:17:25,920
It isn't just a new philosophy or DevOps 2.0.

2323
01:17:25,920 --> 01:17:27,760
It is a structural shift in how we work.

2324
01:17:27,760 --> 01:17:30,880
It's the move from treating infrastructure as a shared burden

2325
01:17:30,880 --> 01:17:32,280
to treating it as a product.

2326
01:17:32,280 --> 01:17:34,080
The path forward requires four elements,

2327
01:17:34,080 --> 01:17:36,880
golden paths that make the best choice the easiest one,

2328
01:17:36,880 --> 01:17:40,120
infrastructure as code that makes every setup reproducible.

2329
01:17:40,120 --> 01:17:43,120
Policy as code that replaces manual processes with automation

2330
01:17:43,120 --> 01:17:45,760
and team topologies that organize people around flow.

2331
01:17:45,760 --> 01:17:48,760
Instead of function, but none of this works without measurement.

2332
01:17:48,760 --> 01:17:51,640
Cognitive load, developer experience, adoption rates,

2333
01:17:51,640 --> 01:17:53,040
these aren't optional metrics.

2334
01:17:53,040 --> 01:17:55,640
They are the only way you know if you're actually winning.

2335
01:17:55,640 --> 01:17:57,440
The outcome of this shift is liberation.

2336
01:17:57,440 --> 01:18:00,760
It means developers who ship faster and safer with less burnout.

2337
01:18:00,760 --> 01:18:02,440
It means large organizations that can move

2338
01:18:02,440 --> 01:18:04,240
like companies a tenth of their size.

2339
01:18:04,240 --> 01:18:06,920
It creates a competitive advantage that compounds over time.

2340
01:18:06,920 --> 01:18:08,400
The invitation is simple.

2341
01:18:08,400 --> 01:18:09,280
Start small.

2342
01:18:09,280 --> 01:18:10,440
Measure the impact.

2343
01:18:10,440 --> 01:18:12,000
Expand incrementally.

2344
01:18:12,000 --> 01:18:13,800
Don't try to build everything at once.

2345
01:18:13,800 --> 01:18:14,720
Build what matters.

2346
01:18:14,720 --> 01:18:15,640
Prove that it works.

2347
01:18:15,640 --> 01:18:16,440
And then grow.

2348
01:18:16,440 --> 01:18:17,400
The tax is real.

2349
01:18:17,400 --> 01:18:19,240
But it doesn't have to be inevitable.