July 16, 2026
Platform Engineering - Simply Explained
For years, DevOps promised to break down the barriers between development and operations by giving teams greater ownership over the software they build. While the idea was powerful, reality became far more complicated. Developers suddenly found themselves responsible not only for writing code, but also for Kubernetes, Terraform, CI/CD pipelines, cloud networking, monitoring, security, secret management, and dozens of Azure services. Instead of increasing productivity, many teams became overwhelmed by operational complexity. In this episode of Microsoft Knowledge Nuggets, we explain Platform Engineering in simple terms and show how Internal Developer Platforms (IDPs) help organizations reduce cognitive load, standardize infrastructure, and allow developers to focus on building great software instead of managing cloud infrastructure.
WHY DEVOPS ALONE IS NO LONGER ENOUGH
DevOps successfully removed many organizational barriers, but it also shifted operational responsibilities directly onto development teams. Every project began creating its own deployment pipelines, Kubernetes manifests, monitoring dashboards, and infrastructure templates. The result was duplicated work, inconsistent implementations, rising cloud costs, and increasing developer burnout. Platform Engineering addresses this problem by introducing a dedicated platform team responsible for building reusable infrastructure, automation, security controls, and deployment workflows that every development team can consume through simple self-service interfaces. Instead of forcing every developer to become a cloud infrastructure expert, Platform Engineering provides standardized, secure, and well-supported building blocks that dramatically simplify software delivery.
INTERNAL DEVELOPER PLATFORMS AND GOLDEN PATHS
At the center of Platform Engineering is the Internal Developer Platform (IDP). An IDP combines infrastructure provisioning, CI/CD pipelines, security policies, secret management, monitoring, logging, and deployment automation into one unified platform. Developers no longer need to manually configure Kubernetes clusters, Terraform modules, networking, or observability. Instead, they simply request a new service or environment, and the platform handles the complexity automatically. We also explore one of the most important concepts in Platform Engineering: Golden Paths. These are pre-built, recommended workflows that make the secure and supported way the easiest way. Rather than restricting innovation, Golden Paths provide fast, well-tested defaults while still allowing teams to customize solutions when necessary.
REDUCING COGNITIVE LOAD AND IMPROVING DEVELOPER EXPERIENCE
One of Platform Engineering's primary goals is reducing cognitive load. Developers should focus on solving business problems instead of remembering infrastructure configurations, Kubernetes versions, cloud networking rules, or deployment procedures. Platform teams carefully decide which technical details should be exposed and which should remain hidden behind automation and self-service capabilities. By standardizing infrastructure while maintaining transparency when needed, organizations create better developer experiences, reduce onboarding time, minimize operational mistakes, and significantly increase engineering productivity. Platform Engineering is not about hiding technology—it is about hiding unnecessary complexity while exposing the information developers actually need to be successful.
TREATING THE PLATFORM AS A PRODUCT
A successful platform is never built solely around technology—it is built around its users. This episode explains why Platform Engineering teams should think like product teams instead of infrastructure teams. Developers become internal customers whose feedback directly influences the platform roadmap. Success is measured through metrics such as onboarding time, deployment speed, developer satisfaction, and platform adoption rather than simply counting infrastructure components. Organizations like Spotify have demonstrated that treating Internal Developer Platforms as products leads to significantly higher adoption, faster software delivery, and stronger collaboration between platform engineers and development teams. If developers choose to use the platform voluntarily because it genuinely improves their daily work, the platform is succeeding.
WHY PLATFORM ENGINEERING MATTERS IN THE AGE OF AI
The rapid rise of AI coding assistants like GitHub Copilot has fundamentally changed software development. Developers can now generate significantly more code than ever before, but every application still requires secure infrastructure, automated deployment, monitoring, governance, and operational support. Without Platform Engineering, AI simply accelerates operational chaos. With a mature Internal Developer Platform, however, organizations can safely scale software delivery while maintaining consistency, governance, and security. AI also helps platform teams build reusable infrastructure, generate automation, improve documentation, and optimize developer workflows. Together, Platform Engineering and AI create the foundation for the next generation of high-performing software organizations.
HOW TO GET STARTED WITH PLATFORM ENGINEERING
Building an Internal Developer Platform doesn't begin with a massive architecture project. Instead, organizations should start by identifying one painful developer workflow and creating a single Golden Path that solves it exceptionally well. Measure deployment time, developer adoption, onboarding speed, and manual effort saved. Collect feedback, continuously improve the platform, and expand incrementally rather than attempting to automate everything at once. Whether you're building cloud-native applications on Azure, managing Kubernetes clusters, or modernizing enterprise software delivery, Platform Engineering provides a scalable operating model that enables developers to ship software faster, more securely, and with significantly less operational complexity. After listening to this episode, you'll understand why Platform Engineering has become one of the fastest-growing disciplines in cloud computing and why Internal Developer Platforms are rapidly becoming essential for modern software organizations.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
1
00:00:00,000 --> 00:00:03,620
Welcome to another episode of Microsoft Knowledge Nuggets on M365.
2
00:00:03,620 --> 00:00:05,700
FM, I'm your host, Mirko Peters.
3
00:00:05,700 --> 00:00:07,940
Today's topic is one that nearly everyone has heard of,
4
00:00:07,940 --> 00:00:10,500
but few really understand, platform engineering.
5
00:00:10,500 --> 00:00:11,900
You've probably heard about DevOps,
6
00:00:11,900 --> 00:00:15,400
the idea that developers and operations teams work together seamlessly,
7
00:00:15,400 --> 00:00:17,700
but somewhere along the way that promise got messy.
8
00:00:17,700 --> 00:00:20,100
Developers ended up doing ops work, that system broke.
9
00:00:20,100 --> 00:00:21,940
By the end of this episode, you'll understand
10
00:00:21,940 --> 00:00:23,340
what went wrong with DevOps,
11
00:00:23,340 --> 00:00:25,660
what an internal developer platform actually is,
12
00:00:25,660 --> 00:00:28,300
how golden parts give teams a clear road to follow,
13
00:00:28,300 --> 00:00:31,500
and why the smartest engineering teams are already building one.
14
00:00:31,500 --> 00:00:33,160
The mess DevOps left behind.
15
00:00:33,160 --> 00:00:34,460
Let's go back to where it started.
16
00:00:34,460 --> 00:00:36,700
DevOps was a great idea with a simple goal,
17
00:00:36,700 --> 00:00:38,940
break down the walls between developers and operations,
18
00:00:38,940 --> 00:00:41,600
no more throwing code over the wall and hoping for the best.
19
00:00:41,600 --> 00:00:45,200
Shift left, move testing, security and operations earlier in the process,
20
00:00:45,200 --> 00:00:48,100
faster delivery, fewer hand-offs, more ownership.
21
00:00:48,100 --> 00:00:49,700
On paper, it looked perfect.
22
00:00:49,700 --> 00:00:51,500
In practice, something went wrong.
23
00:00:51,500 --> 00:00:54,100
Shift left didn't just shift responsibilities.
24
00:00:54,100 --> 00:00:55,640
It piled them on.
25
00:00:55,640 --> 00:00:57,800
The developer who used to write code and file a ticket
26
00:00:57,800 --> 00:01:01,520
now owns infrastructure, security, monitoring, Kubernetes,
27
00:01:01,520 --> 00:01:04,000
CI/CD pipelines, secret management,
28
00:01:04,000 --> 00:01:07,200
and about 15 cloud services they'd never heard of before.
29
00:01:07,200 --> 00:01:10,500
One person handles all of that while still building the actual product.
30
00:01:10,500 --> 00:01:12,300
Here's what that looks like in real life.
31
00:01:12,300 --> 00:01:15,100
A team wants to spin up a new environment to test a feature.
32
00:01:15,100 --> 00:01:17,400
Before DevOps, they'd file a ticket and wait.
33
00:01:17,400 --> 00:01:20,600
After DevOps, they own it themselves, which sounds great in theory.
34
00:01:20,600 --> 00:01:22,200
But now they need to write terraform modules,
35
00:01:22,200 --> 00:01:23,800
configure a Kubernetes cluster,
36
00:01:23,800 --> 00:01:24,940
set up networking rules,
37
00:01:24,940 --> 00:01:29,640
wire up monitoring, figure out secrets, management, and make sure security policies are applied.
38
00:01:29,640 --> 00:01:32,140
What used to be a ticket that took someone else an hour
39
00:01:32,140 --> 00:01:34,440
now takes three days of a developer's time.
40
00:01:34,440 --> 00:01:36,540
Three days, they're not writing product code.
41
00:01:36,540 --> 00:01:41,240
They're fighting YAML files and debugging why the load balancer isn't rooting traffic correctly.
42
00:01:41,240 --> 00:01:42,740
The mental load here is enormous.
43
00:01:42,740 --> 00:01:44,740
Every team ends up building their own pipelines,
44
00:01:44,740 --> 00:01:47,040
deployment scripts, and monitoring dashboards.
45
00:01:47,040 --> 00:01:49,440
And because everyone's stretched, then corners get cut.
46
00:01:49,440 --> 00:01:52,040
Security gets skipped because the deadline is Friday.
47
00:01:52,040 --> 00:01:53,740
Cloud builds double without anyone noticing
48
00:01:53,740 --> 00:01:56,140
because nobody remembered to shut down the test environment.
49
00:01:56,140 --> 00:01:58,140
And when something breaks at 2 a.m.,
50
00:01:58,140 --> 00:02:00,640
the developer who built it is the only one who can fix it.
51
00:02:00,640 --> 00:02:01,840
This isn't sustainable.
52
00:02:01,840 --> 00:02:03,840
And here's why it matters more than ever.
53
00:02:03,840 --> 00:02:05,540
Cloud complexity keeps growing.
54
00:02:05,540 --> 00:02:08,740
Every year there are more services, more tools, more decisions to make.
55
00:02:08,740 --> 00:02:12,240
And now AI coding tools let developers ship code faster than ever.
56
00:02:12,240 --> 00:02:15,140
10, 20, even 30 times more code per day.
57
00:02:15,140 --> 00:02:18,440
But all that code still needs infrastructure, security, and monitoring.
58
00:02:18,440 --> 00:02:22,040
More code without a better system just means faster chaos.
59
00:02:22,040 --> 00:02:25,240
If you feel like you're drowning in YAML and Terraform, you're not alone.
60
00:02:25,240 --> 00:02:26,740
This isn't a personal failure.
61
00:02:26,740 --> 00:02:27,740
It's systemic.
62
00:02:27,740 --> 00:02:28,840
The model broke.
63
00:02:28,840 --> 00:02:31,040
What platform engineering actually is.
64
00:02:31,040 --> 00:02:31,840
So what's the fix?
65
00:02:31,840 --> 00:02:33,640
It's called platform engineering.
66
00:02:33,640 --> 00:02:35,640
And here's the simplest way to think about it.
67
00:02:35,640 --> 00:02:37,640
This discipline creates an internal layer
68
00:02:37,640 --> 00:02:39,640
that absorbs complexity for developers.
69
00:02:39,640 --> 00:02:41,640
Imagine walking into a large office building.
70
00:02:41,640 --> 00:02:43,540
You don't need to worry about who has access to,
71
00:02:43,540 --> 00:02:45,640
which floor, which security badge works,
72
00:02:45,640 --> 00:02:47,140
or where the fire exits are.
73
00:02:47,140 --> 00:02:48,840
The reception desk handles all that for you
74
00:02:48,840 --> 00:02:50,240
and you just walk in and get to work.
75
00:02:50,240 --> 00:02:52,940
That's exactly what platform engineering does for your developers.
76
00:02:52,940 --> 00:02:55,840
Instead of every single developer needing to become an expert
77
00:02:55,840 --> 00:02:58,540
in Kubernetes, Terraform, networking, and security,
78
00:02:58,540 --> 00:03:00,340
a central platform team creates a layer
79
00:03:00,340 --> 00:03:02,440
that manages all that complexity.
80
00:03:02,440 --> 00:03:04,140
The developer gets a simple interface.
81
00:03:04,140 --> 00:03:06,640
Click a button, run a command, fill out a form,
82
00:03:06,640 --> 00:03:08,440
and the platform takes care of everything else.
83
00:03:08,440 --> 00:03:09,440
But here's the thing.
84
00:03:09,440 --> 00:03:10,740
This isn't the same as DevOps.
85
00:03:10,740 --> 00:03:13,040
DevOps taught every team to own their own infrastructure,
86
00:03:13,040 --> 00:03:15,640
but platform engineering says that's a recipe for burnout.
87
00:03:15,640 --> 00:03:18,040
Instead, the platform team provides paved roads,
88
00:03:18,040 --> 00:03:21,440
standard, tested, and secure ways to handle common tasks.
89
00:03:21,440 --> 00:03:22,840
They build and maintain the road,
90
00:03:22,840 --> 00:03:24,640
while product teams just drive on it.
91
00:03:24,640 --> 00:03:26,440
The core outcome of platform engineering
92
00:03:26,440 --> 00:03:28,640
is something called an internal developer platform,
93
00:03:28,640 --> 00:03:30,240
or IDP for short.
94
00:03:30,240 --> 00:03:31,840
Think of it as a self-service system
95
00:03:31,840 --> 00:03:34,240
that automates all that repetitive work.
96
00:03:34,240 --> 00:03:37,340
Infrastructure provisioning, CI/CD pipelines,
97
00:03:37,340 --> 00:03:40,840
security checks, monitoring, all built-in and standardized.
98
00:03:40,840 --> 00:03:42,040
Here's a concrete example.
99
00:03:42,040 --> 00:03:44,440
When a developer wants to deploy a new service without a platform,
100
00:03:44,440 --> 00:03:46,240
it's been days setting up infrastructure,
101
00:03:46,240 --> 00:03:49,040
writing pipelines, and configuring monitoring.
102
00:03:49,040 --> 00:03:52,040
With an IDP, they just click "Deploy" in a UI
103
00:03:52,040 --> 00:03:53,440
or run a single command.
104
00:03:53,440 --> 00:03:55,040
And the platform handles everything,
105
00:03:55,040 --> 00:03:57,240
provisioning, tests, monitoring, deployment,
106
00:03:57,240 --> 00:03:58,840
all in minutes instead of days.
107
00:03:58,840 --> 00:03:59,840
So what does this mean for you?
108
00:03:59,840 --> 00:04:01,840
You stop being a jack-of-all infrastructure
109
00:04:01,840 --> 00:04:04,040
and start being a specialist in your actual product.
110
00:04:04,040 --> 00:04:05,840
Your job goes back to building features
111
00:04:05,840 --> 00:04:07,040
that matter to your customers.
112
00:04:07,040 --> 00:04:10,040
Instead of debugging why your Terraform state file is corrupted,
113
00:04:10,040 --> 00:04:11,240
that's the whole point.
114
00:04:11,240 --> 00:04:13,440
The internal developer platform in plain English.
115
00:04:13,440 --> 00:04:15,640
So let's break down what an internal developer platform
116
00:04:15,640 --> 00:04:16,440
actually is.
117
00:04:16,440 --> 00:04:19,040
It's the engine that combines everything into one system.
118
00:04:19,040 --> 00:04:21,440
Your CI/CD pipelines, infrastructure templates,
119
00:04:21,440 --> 00:04:23,840
security policies, monitoring, and logging.
120
00:04:23,840 --> 00:04:26,840
Instead of six separate tools, you have to wire together.
121
00:04:26,840 --> 00:04:27,640
Here's an analogy.
122
00:04:27,640 --> 00:04:30,840
Think of it as "cooking from scratch" versus using a vending machine.
123
00:04:30,840 --> 00:04:32,640
"Cooking from scratch" means buying ingredients,
124
00:04:32,640 --> 00:04:35,640
chopping vegetables, measuring spices, monitoring the stove,
125
00:04:35,640 --> 00:04:38,640
lots of decisions, lots of steps, lots of ways to mess up.
126
00:04:38,640 --> 00:04:41,440
A vending machine gives you a result with one button press.
127
00:04:41,440 --> 00:04:44,240
Fewer decisions, faster outcome, consistent quality,
128
00:04:44,240 --> 00:04:46,040
and IDP is that vending machine.
129
00:04:46,040 --> 00:04:48,840
The developer doesn't need to know how infrastructure is provisioned
130
00:04:48,840 --> 00:04:50,440
or where secrets are stored.
131
00:04:50,440 --> 00:04:51,840
They just press the button.
132
00:04:51,840 --> 00:04:53,440
What's inside that vending machine?
133
00:04:53,440 --> 00:04:55,240
The core components are pretty standard.
134
00:04:55,240 --> 00:04:57,440
CI/CD templates for consistent builds,
135
00:04:57,440 --> 00:05:00,440
infrastructure provisioning for automatic environment spin-up,
136
00:05:00,440 --> 00:05:04,040
secret management, so credentials aren't floating around in config files,
137
00:05:04,040 --> 00:05:06,040
and logging with built-in observability
138
00:05:06,040 --> 00:05:08,240
so you can troubleshoot without scrambling.
139
00:05:08,240 --> 00:05:11,240
All of it pre-configured, tested, and maintained by the platform team.
140
00:05:11,240 --> 00:05:12,640
Here's a concrete example.
141
00:05:12,640 --> 00:05:15,440
A developer types create new service into a command line
142
00:05:15,440 --> 00:05:17,240
or clicks a button in a portal.
143
00:05:17,240 --> 00:05:20,840
Behind the scenes, the IDP spins up a new repository with the right structure,
144
00:05:20,840 --> 00:05:24,040
sets up a build pipeline that runs tests automatically,
145
00:05:24,040 --> 00:05:26,240
deploys the service to a development environment,
146
00:05:26,240 --> 00:05:28,440
and adds health check endpoints with logging.
147
00:05:28,440 --> 00:05:29,840
All of that happens in minutes.
148
00:05:29,840 --> 00:05:32,240
The developer never touched a single terraform file
149
00:05:32,240 --> 00:05:34,240
or configured a Kubernetes manifest.
150
00:05:34,240 --> 00:05:36,040
Just type to command and got a running service.
151
00:05:36,040 --> 00:05:37,040
Why does this matter?
152
00:05:37,040 --> 00:05:39,040
Consistency is the key reason.
153
00:05:39,040 --> 00:05:42,440
When every team builds their own pipelines and writes their own deployment scripts,
154
00:05:42,440 --> 00:05:44,640
you end up with snowflake configurations,
155
00:05:44,640 --> 00:05:47,640
50 different services, 50 different ways of doing things.
156
00:05:47,640 --> 00:05:51,440
When something breaks, nobody can debug it except the person who built it
157
00:05:51,440 --> 00:05:53,640
and if that person left the company, good luck.
158
00:05:53,640 --> 00:05:57,440
An IDP eliminates that by making every service follow the same patterns,
159
00:05:57,440 --> 00:06:01,040
every deployment uses the same pipeline and every team get the same defaults.
160
00:06:01,040 --> 00:06:04,240
When something breaks, the patterns are familiar and the fix is documented.
161
00:06:04,240 --> 00:06:05,640
So here's what this means for you.
162
00:06:05,640 --> 00:06:08,840
If your organization has 50 teams doing deployment 50 different ways,
163
00:06:08,840 --> 00:06:10,240
an IDP is the solution.
164
00:06:10,240 --> 00:06:11,640
It doesn't mean teams lose autonomy.
165
00:06:11,640 --> 00:06:15,240
It means the boring, repetitive, error-prone parts get standardized
166
00:06:15,240 --> 00:06:17,440
so the interesting creative work can vary.
167
00:06:17,440 --> 00:06:19,240
That's a trade-off worth making.
168
00:06:19,240 --> 00:06:21,640
Golden parts, the way, not a cage.
169
00:06:21,640 --> 00:06:23,040
Let's talk about golden parts.
170
00:06:23,040 --> 00:06:25,240
You've probably heard the name, but the idea is simple.
171
00:06:25,240 --> 00:06:28,240
A golden path is a recommended pre-built workflow
172
00:06:28,240 --> 00:06:30,640
that makes the right thing the easiest thing to do.
173
00:06:30,640 --> 00:06:33,840
Your platform team says, "Here's how we suggest you do this."
174
00:06:33,840 --> 00:06:37,240
We've tested it, it works, and we'll back you up if something breaks.
175
00:06:37,240 --> 00:06:39,440
Notice that word recommend.
176
00:06:39,440 --> 00:06:41,440
Golden parts aren't mandatory.
177
00:06:41,440 --> 00:06:43,640
Developers can step off the path if they need to,
178
00:06:43,640 --> 00:06:45,440
but the path is the fast-safety fault.
179
00:06:45,440 --> 00:06:47,640
It's already running, supported and documented.
180
00:06:47,640 --> 00:06:49,640
You don't have to figure everything out from scratch.
181
00:06:49,640 --> 00:06:52,640
Think of it like railway tracks instead of guard rails.
182
00:06:52,640 --> 00:06:54,440
Guard rails catch you when you crash.
183
00:06:54,440 --> 00:06:56,440
They react, they stop you from going off a cliff,
184
00:06:56,440 --> 00:06:58,040
but they don't help you steer.
185
00:06:58,040 --> 00:07:00,040
Railway tracks guide you smoothly along the route
186
00:07:00,040 --> 00:07:02,240
so you don't have to decide where to turn.
187
00:07:02,240 --> 00:07:04,840
Golden parts are the tracks, they move you forward,
188
00:07:04,840 --> 00:07:06,440
not just catch you when you fail.
189
00:07:06,440 --> 00:07:08,240
Here's where a lot of teams get this wrong.
190
00:07:08,240 --> 00:07:10,440
They build golden parts for the platform team,
191
00:07:10,440 --> 00:07:11,440
not for the developers.
192
00:07:11,440 --> 00:07:14,240
They optimize for architectural purity or security compliance
193
00:07:14,240 --> 00:07:17,440
or some internal rule nobody outside the platform team understands.
194
00:07:17,440 --> 00:07:20,440
The result looks great on a whiteboard, but feels terrible to use.
195
00:07:20,440 --> 00:07:23,240
Developers quietly find workarounds, adoption drops,
196
00:07:23,240 --> 00:07:26,240
and the platform team wonders why nobody appreciates all that effort.
197
00:07:26,240 --> 00:07:28,040
The fix is simple, but it's hard to do.
198
00:07:28,040 --> 00:07:29,240
You need escape hatches.
199
00:07:29,240 --> 00:07:32,440
If the path doesn't fit a developer's use case, they need a way out.
200
00:07:32,440 --> 00:07:34,240
A way to override a default,
201
00:07:34,240 --> 00:07:37,240
bring their own pipeline or step outside the platform entirely.
202
00:07:37,240 --> 00:07:38,840
And here's the important part.
203
00:07:38,840 --> 00:07:40,440
When they step off, that's not failure.
204
00:07:40,440 --> 00:07:41,240
It's feedback.
205
00:07:41,240 --> 00:07:44,240
Every time a developer leaves the golden path, it tells you something real.
206
00:07:44,240 --> 00:07:46,640
Either the path is missing a feature it should have,
207
00:07:46,640 --> 00:07:49,040
or the use case genuinely doesn't belong there.
208
00:07:49,040 --> 00:07:50,440
Both signals are valuable.
209
00:07:50,440 --> 00:07:52,840
A good golden path in practice looks like this.
210
00:07:52,840 --> 00:07:55,040
A team wants to deploy a new backend service.
211
00:07:55,040 --> 00:07:56,040
They use the path.
212
00:07:56,040 --> 00:07:59,040
It gives them a template repository with the right structure,
213
00:07:59,040 --> 00:08:01,640
a standard CI/CD pipeline that's already tested.
214
00:08:01,640 --> 00:08:03,040
Built in logging and monitoring,
215
00:08:03,040 --> 00:08:05,240
a one-click rollback if something goes wrong.
216
00:08:05,240 --> 00:08:07,040
The whole thing takes minutes instead of days,
217
00:08:07,040 --> 00:08:10,240
and because the platform team maintains the path when something breaks,
218
00:08:10,240 --> 00:08:11,240
they fix it.
219
00:08:11,240 --> 00:08:14,240
The developer doesn't have to become a pipeline debugging expert.
220
00:08:14,240 --> 00:08:16,240
What this means for you, fewer surprises.
221
00:08:16,240 --> 00:08:18,240
You ship faster because the path is tested.
222
00:08:18,240 --> 00:08:21,240
You ship safer because security and monitoring are built in.
223
00:08:21,240 --> 00:08:23,840
You ship with confidence because rolling back is one-click.
224
00:08:23,840 --> 00:08:27,040
The path exists to help you, not to hold you back.
225
00:08:27,040 --> 00:08:29,240
Use it, cutting cognitive load.
226
00:08:29,240 --> 00:08:31,040
Here's where the real payoff shows up.
227
00:08:31,040 --> 00:08:33,040
When a platform handles the heavy lifting,
228
00:08:33,040 --> 00:08:34,840
developers can actually focus on code.
229
00:08:34,840 --> 00:08:37,440
They don't need to know which Kubernetes version is running.
230
00:08:37,440 --> 00:08:41,640
They don't have to update Terraform modules every time a cloud provider changes in API.
231
00:08:41,640 --> 00:08:42,840
They just write features.
232
00:08:42,840 --> 00:08:44,640
Platform engineers absorb that complexity.
233
00:08:44,640 --> 00:08:47,040
They decide what developers need to see and what should stay hidden.
234
00:08:47,040 --> 00:08:49,240
That's a real design choice, not just a technical one.
235
00:08:49,240 --> 00:08:52,640
It's about figuring out which details matter to the person using the platform
236
00:08:52,640 --> 00:08:54,440
and which ones just add noise.
237
00:08:54,440 --> 00:08:55,640
Here's a concrete example.
238
00:08:55,640 --> 00:08:59,440
A developer deploying a new service doesn't care about cluster node sizes,
239
00:08:59,440 --> 00:09:02,240
instance types, or auto scaling thresholds.
240
00:09:02,240 --> 00:09:04,240
They care about whether their service runs
241
00:09:04,240 --> 00:09:05,840
and how fast it responds.
242
00:09:05,840 --> 00:09:08,440
So the platform pre-configures all that based on the app tier.
243
00:09:08,440 --> 00:09:11,240
Small service, here's the right setup, high traffic service,
244
00:09:11,240 --> 00:09:12,640
here's a different configuration.
245
00:09:12,640 --> 00:09:15,640
The developer doesn't make those choices because they don't need to.
246
00:09:15,640 --> 00:09:16,640
Why does this matter?
247
00:09:16,640 --> 00:09:21,040
Because burnout drops when developers aren't juggling 15 different concerns at once.
248
00:09:21,040 --> 00:09:24,440
Some mature platform teams have cut cognitive load by nearly half.
249
00:09:24,440 --> 00:09:26,840
40 to 50% less mental overhead.
250
00:09:26,840 --> 00:09:28,040
That's a huge shift.
251
00:09:28,040 --> 00:09:30,240
It's the difference between leaving work with energy left
252
00:09:30,240 --> 00:09:33,640
and staring at a terminal at 10pm wondering why your pipeline failed.
253
00:09:33,640 --> 00:09:36,040
But here's the warning, don't create illusions.
254
00:09:36,040 --> 00:09:38,240
Some platform teams fall into a trap.
255
00:09:38,240 --> 00:09:41,240
They hide settings without giving developers any way to understand
256
00:09:41,240 --> 00:09:42,640
what's happening under the hood.
257
00:09:42,640 --> 00:09:44,840
That's not abstraction, that's trickery.
258
00:09:44,840 --> 00:09:46,840
And it backfires the moment something goes wrong,
259
00:09:46,840 --> 00:09:48,840
developers hit a wall they can't see through
260
00:09:48,840 --> 00:09:51,640
and suddenly the platform feels like a black box working against them.
261
00:09:51,640 --> 00:09:53,440
The term for this is a leaky abstraction.
262
00:09:53,440 --> 00:09:56,040
You hide complexity, but eventually that complexity leaks out.
263
00:09:56,040 --> 00:09:58,440
A database gets slow, a deployment fails,
264
00:09:58,440 --> 00:10:00,840
a security policy blocks something unexpected.
265
00:10:00,840 --> 00:10:03,240
And the developer has no mental model of what's happening
266
00:10:03,240 --> 00:10:06,440
because the platform never gave them one, transparency matters.
267
00:10:06,440 --> 00:10:09,040
Show developers what they need to know when they need to know it.
268
00:10:09,040 --> 00:10:11,240
Don't just hide everything and hope for the best.
269
00:10:11,240 --> 00:10:14,440
What this means for you, less context switching and more flow state.
270
00:10:14,440 --> 00:10:17,840
You don't start your morning wondering if the Kubernetes cluster needs an upgrade.
271
00:10:17,840 --> 00:10:20,440
You start your morning working on the feature due next week.
272
00:10:20,440 --> 00:10:23,040
Your job becomes your actual work again.
273
00:10:23,040 --> 00:10:24,840
Treating the platform like a product.
274
00:10:24,840 --> 00:10:26,840
Today we're talking about something that changes
275
00:10:26,840 --> 00:10:28,840
how internal tools actually work.
276
00:10:28,840 --> 00:10:31,640
Most people think a platform team is just an infrastructure team.
277
00:10:31,640 --> 00:10:33,640
It isn't a platform team is a product team.
278
00:10:33,640 --> 00:10:36,040
And the developers using that platform are their customers,
279
00:10:36,040 --> 00:10:37,440
not people filing tickets.
280
00:10:37,440 --> 00:10:38,440
That changes everything.
281
00:10:38,440 --> 00:10:40,440
A product team talks to its customers.
282
00:10:40,440 --> 00:10:42,040
They find out what's actually painful.
283
00:10:42,040 --> 00:10:44,240
They prioritize features based on real need.
284
00:10:44,240 --> 00:10:45,240
They measure adoption.
285
00:10:45,240 --> 00:10:46,840
They don't build something and walk away.
286
00:10:46,840 --> 00:10:48,040
They keep iterating.
287
00:10:48,040 --> 00:10:50,240
So what does a product team look like in practice?
288
00:10:50,240 --> 00:10:52,040
They don't operate like a help desk.
289
00:10:52,040 --> 00:10:53,440
A developer files a ticket.
290
00:10:53,440 --> 00:10:55,640
And the platform team does it manually.
291
00:10:55,640 --> 00:10:57,040
That's not platform engineering.
292
00:10:57,040 --> 00:10:59,240
That's just centralized operations with a new name.
293
00:10:59,240 --> 00:11:00,040
It doesn't scale.
294
00:11:00,040 --> 00:11:01,440
It doesn't reduce cognitive load.
295
00:11:01,440 --> 00:11:03,640
It just moves the bottleneck from one team to another.
296
00:11:03,640 --> 00:11:04,840
Here's what they do instead.
297
00:11:04,840 --> 00:11:06,240
They measure the right things.
298
00:11:06,240 --> 00:11:07,440
Time to first deploy.
299
00:11:07,440 --> 00:11:09,240
Onboarding speed for new team members.
300
00:11:09,240 --> 00:11:11,040
Developer satisfaction scores.
301
00:11:11,040 --> 00:11:12,240
These are the metrics that tell you
302
00:11:12,240 --> 00:11:14,040
whether the platform is actually helping people
303
00:11:14,040 --> 00:11:16,240
or just adding another layer of complexity.
304
00:11:16,240 --> 00:11:17,240
Spotify is a good example.
305
00:11:17,240 --> 00:11:19,640
Their platform team runs like a proper product organization.
306
00:11:19,640 --> 00:11:20,640
They have roadmaps.
307
00:11:20,640 --> 00:11:21,640
They have OKRs.
308
00:11:21,640 --> 00:11:24,440
They talk to developers about what is working and what isn't.
309
00:11:24,440 --> 00:11:26,840
They treat the platform as something that has to earn
310
00:11:26,840 --> 00:11:28,640
its adoption every single day.
311
00:11:28,640 --> 00:11:29,840
And that is the main idea.
312
00:11:29,840 --> 00:11:32,240
A platform nobody uses is just a project.
313
00:11:32,240 --> 00:11:34,040
It's gathering dust in a corner.
314
00:11:34,040 --> 00:11:36,040
Adoption is the ultimate validation.
315
00:11:36,040 --> 00:11:37,640
If developers choose your platform
316
00:11:37,640 --> 00:11:38,840
over building their own tools,
317
00:11:38,840 --> 00:11:40,040
you have done something right.
318
00:11:40,040 --> 00:11:43,440
If they avoided no amount of technical excellence can fix that.
319
00:11:43,440 --> 00:11:44,440
What does this mean for you?
320
00:11:44,440 --> 00:11:46,040
It means if you are building a platform.
321
00:11:46,040 --> 00:11:47,640
Don't start with architecture diagrams.
322
00:11:47,640 --> 00:11:50,240
Don't start with Kubernetes clusters or terraform modules.
323
00:11:50,240 --> 00:11:51,840
Start with user interviews.
324
00:11:51,840 --> 00:11:54,040
Talk to the developers who will use your platform.
325
00:11:54,040 --> 00:11:55,640
Find out what is actually painful.
326
00:11:55,640 --> 00:11:57,640
Build one thing that solves the real problem.
327
00:11:57,640 --> 00:11:58,640
Then iterate.
328
00:11:58,640 --> 00:12:01,640
That is how you build something people actually want to use.
329
00:12:01,640 --> 00:12:02,640
Why right now?
330
00:12:02,640 --> 00:12:03,640
The AI wave.
331
00:12:03,640 --> 00:12:05,440
So why are we talking about this right now?
332
00:12:05,440 --> 00:12:06,240
Why not five years ago?
333
00:12:06,240 --> 00:12:07,240
The answer is AI.
334
00:12:07,240 --> 00:12:09,840
AI coding tools like GitHub co-pilot.
335
00:12:09,840 --> 00:12:13,040
Let developers ship code at a pace we have never seen before.
336
00:12:13,040 --> 00:12:15,840
10 times, 20 times more code per day than what was possible
337
00:12:15,840 --> 00:12:16,840
just a couple of years ago.
338
00:12:16,840 --> 00:12:17,840
But that sounds amazing.
339
00:12:17,840 --> 00:12:18,640
And it is.
340
00:12:18,640 --> 00:12:19,640
But here's the catch.
341
00:12:19,640 --> 00:12:21,440
All that code still needs infrastructure.
342
00:12:21,440 --> 00:12:22,640
It still needs security.
343
00:12:22,640 --> 00:12:25,240
It still needs to be deployed, tested and operated.
344
00:12:25,240 --> 00:12:28,240
More code without a better system does not make you faster.
345
00:12:28,240 --> 00:12:29,840
It just makes the chaos faster.
346
00:12:29,840 --> 00:12:32,640
If your developers are already drowning in YAML and Terraform,
347
00:12:32,640 --> 00:12:34,040
AI does not fix that.
348
00:12:34,040 --> 00:12:36,440
It just means they drown faster while producing more code
349
00:12:36,440 --> 00:12:37,840
that needs to be supported.
350
00:12:37,840 --> 00:12:41,040
Right now about 55% of organizations have already adopted
351
00:12:41,040 --> 00:12:43,240
platform engineering in some form.
352
00:12:43,240 --> 00:12:47,240
Gardner predicts that number will hit 80% by the end of 2026.
353
00:12:47,240 --> 00:12:48,440
That is not a slow trend.
354
00:12:48,440 --> 00:12:50,040
That is a shift happening right now.
355
00:12:50,040 --> 00:12:52,640
Companies are realizing they cannot scale their engineering teams
356
00:12:52,640 --> 00:12:54,040
without a platform layer.
357
00:12:54,040 --> 00:12:56,040
The old approach of every team doing everything themselves
358
00:12:56,040 --> 00:12:58,640
just doesn't work when you are shipping code at AI speed.
359
00:12:58,640 --> 00:13:00,240
Here's what a lot of people miss.
360
00:13:00,240 --> 00:13:02,440
AI does not just create the need for platforms.
361
00:13:02,440 --> 00:13:03,640
It also helps build them.
362
00:13:03,640 --> 00:13:06,440
Platform teams are using AI to generate Terraform modules,
363
00:13:06,440 --> 00:13:09,240
write documentation and debug pipelines.
364
00:13:09,240 --> 00:13:11,840
The same technology creating the urgency is also providing
365
00:13:11,840 --> 00:13:13,240
the tools to solve it.
366
00:13:13,240 --> 00:13:14,440
Now a word of caution.
367
00:13:14,440 --> 00:13:16,840
AI amplifies whatever you already have.
368
00:13:16,840 --> 00:13:18,440
If your fundamentals are solid,
369
00:13:18,440 --> 00:13:20,840
like good architecture and a well-designed platform,
370
00:13:20,840 --> 00:13:23,240
AI makes you two to three times more productive.
371
00:13:23,240 --> 00:13:24,640
But if your foundations are weak,
372
00:13:24,640 --> 00:13:27,240
AI just helps you make bigger mistakes faster.
373
00:13:27,240 --> 00:13:29,640
Bad configuration, security holes, broken infrastructure,
374
00:13:29,640 --> 00:13:31,440
all shipped to production before anyone catches it.
375
00:13:31,440 --> 00:13:33,240
AI doesn't fix bad foundations.
376
00:13:33,240 --> 00:13:34,440
It exposes them.
377
00:13:34,440 --> 00:13:35,840
Here's a real example.
378
00:13:35,840 --> 00:13:38,240
A company with a good internal developer platform
379
00:13:38,240 --> 00:13:40,840
can let a non-engineer safely deploy AI tools.
380
00:13:40,840 --> 00:13:42,240
The platform provides guardrails.
381
00:13:42,240 --> 00:13:43,640
It enforces security policies.
382
00:13:43,640 --> 00:13:45,040
It handles the infrastructure.
383
00:13:45,040 --> 00:13:48,040
So a product manager can spin up an AI-powered prototype
384
00:13:48,040 --> 00:13:51,040
without needing to understand Kubernetes or cloud networking.
385
00:13:51,040 --> 00:13:51,840
That is powerful.
386
00:13:51,840 --> 00:13:54,040
That is the kind of thing that separates teams
387
00:13:54,040 --> 00:13:57,640
ready for the AI era from teams that are going to get left behind.
388
00:13:57,640 --> 00:13:59,040
What does this mean for you?
389
00:13:59,040 --> 00:14:01,040
The window to build a platform is closing,
390
00:14:01,040 --> 00:14:02,840
not because the technology is going away,
391
00:14:02,840 --> 00:14:05,240
but because the gap between teams with platforms
392
00:14:05,240 --> 00:14:07,240
and teams without them is widening fast.
393
00:14:07,240 --> 00:14:08,440
Every month you wait,
394
00:14:08,440 --> 00:14:11,440
the teams that already have platforms are pulling further ahead.
395
00:14:11,440 --> 00:14:13,440
They are shipping faster, burning out less,
396
00:14:13,440 --> 00:14:15,240
and adapting to new tools more quickly.
397
00:14:15,240 --> 00:14:17,840
The teams without platforms are falling further behind,
398
00:14:17,840 --> 00:14:19,240
the choice is yours.
399
00:14:19,240 --> 00:14:20,840
Start with one golden path.
400
00:14:20,840 --> 00:14:22,240
So where do you actually start?
401
00:14:22,240 --> 00:14:25,840
If you're sitting there thinking you need to build a whole internal developer platform
402
00:14:25,840 --> 00:14:27,040
from scratch, stop.
403
00:14:27,040 --> 00:14:29,840
That's the fastest way to kill your project before it even starts.
404
00:14:29,840 --> 00:14:31,440
The biggest mistake teams make?
405
00:14:31,440 --> 00:14:32,840
Trying to build everything at once?
406
00:14:32,840 --> 00:14:35,040
They spend months designing the perfect platform,
407
00:14:35,040 --> 00:14:37,040
packing in every feature they can think of.
408
00:14:37,040 --> 00:14:39,040
Then they launch it, and hear nothing.
409
00:14:39,040 --> 00:14:40,240
Nobody uses it.
410
00:14:40,240 --> 00:14:42,440
Why? Because it solves problems nobody asked about,
411
00:14:42,440 --> 00:14:45,240
and just getting started requires reading a small manual.
412
00:14:45,240 --> 00:14:46,040
Here's the thing.
413
00:14:46,040 --> 00:14:46,840
Don't do that.
414
00:14:46,840 --> 00:14:47,840
Instead start small.
415
00:14:47,840 --> 00:14:49,240
Actually talk to developers,
416
00:14:49,240 --> 00:14:50,840
not the architects, not the managers,
417
00:14:50,840 --> 00:14:54,240
not your own assumptions, find the people writing features every day.
418
00:14:54,240 --> 00:14:55,640
Ask them where it hurts.
419
00:14:55,640 --> 00:14:57,840
Find the one workflow that takes the longest,
420
00:14:57,840 --> 00:14:59,040
frustrates the most people,
421
00:14:59,040 --> 00:15:00,840
or gets skipped more than it should,
422
00:15:00,840 --> 00:15:03,440
then build exactly one golden path all the way through.
423
00:15:03,440 --> 00:15:06,240
Maybe it's create and deploy a new microservice.
424
00:15:06,240 --> 00:15:08,840
Maybe it's set up a development environment from scratch.
425
00:15:08,840 --> 00:15:12,440
Maybe it's ship a hot fix to production without breaking anything.
426
00:15:12,440 --> 00:15:16,240
Pick the one that stings the most and build a path that makes that pain disappear.
427
00:15:16,240 --> 00:15:16,840
Build it.
428
00:15:16,840 --> 00:15:18,040
Test it with real users.
429
00:15:18,040 --> 00:15:18,840
Collect feedback.
430
00:15:18,840 --> 00:15:19,840
Itterate.
431
00:15:19,840 --> 00:15:22,240
Then add another path and another after that.
432
00:15:22,240 --> 00:15:23,640
Don't try to solve every problem at once.
433
00:15:23,640 --> 00:15:26,840
Solve one problem really well and let the momentum carry you forward.
434
00:15:26,840 --> 00:15:28,240
How do you know it's working?
435
00:15:28,240 --> 00:15:29,640
Measure the right things.
436
00:15:29,640 --> 00:15:31,440
Time from idea to first deploy.
437
00:15:31,440 --> 00:15:34,840
Number of manual steps you've eliminated and voluntary adoption rates.
438
00:15:34,840 --> 00:15:37,440
If developers choose your path over building their own,
439
00:15:37,440 --> 00:15:38,240
your winning.
440
00:15:38,240 --> 00:15:39,440
If they're avoiding it,
441
00:15:39,440 --> 00:15:40,840
listen and change direction.
442
00:15:40,840 --> 00:15:42,240
Here's the trap to avoid.
443
00:15:42,240 --> 00:15:44,040
Don't make the platform mandatory.
444
00:15:44,040 --> 00:15:46,640
Force developers onto your path and they'll resent it.
445
00:15:46,640 --> 00:15:47,840
They'll find ways around it.
446
00:15:47,840 --> 00:15:49,840
They'll build their own scripts and hide them from you.
447
00:15:49,840 --> 00:15:51,840
Instead make the path easy.
448
00:15:51,840 --> 00:15:53,640
Make it faster than the alternative.
449
00:15:53,640 --> 00:15:55,040
Make it the obvious choice.
450
00:15:55,040 --> 00:15:56,440
But never the only one.
451
00:15:56,440 --> 00:15:58,240
The first path is always the hardest.
452
00:15:58,240 --> 00:16:00,240
It teaches you everything about product thinking.
453
00:16:00,240 --> 00:16:02,840
You learn how to talk to users, how to prioritize.
454
00:16:02,840 --> 00:16:04,840
And that building something people actually want
455
00:16:04,840 --> 00:16:06,840
is way harder than building something that just works.
456
00:16:06,840 --> 00:16:09,240
But once you've done it once, the second path gets easier
457
00:16:09,240 --> 00:16:10,640
and the third is easier still.
458
00:16:10,640 --> 00:16:12,440
You're not building a platform in one shot.
459
00:16:12,440 --> 00:16:14,440
You're building it one path at a time.
460
00:16:14,440 --> 00:16:15,440
So that's the system.
461
00:16:15,440 --> 00:16:17,640
Platform engineering is about building the paved road.
462
00:16:17,640 --> 00:16:20,840
So developers can focus on driving instead of fixing portals.
463
00:16:20,840 --> 00:16:22,440
If you're tired of fighting infrastructure,
464
00:16:22,440 --> 00:16:25,640
start by finding one golden path on your team, just one.
465
00:16:25,640 --> 00:16:27,440
Share this with someone who needs to hear it
466
00:16:27,440 --> 00:16:30,440
and subscribe for more breakdowns just like this.
00:00:00,000 --> 00:00:03,620
Welcome to another episode of Microsoft Knowledge Nuggets on M365.
2
00:00:03,620 --> 00:00:05,700
FM, I'm your host, Mirko Peters.
3
00:00:05,700 --> 00:00:07,940
Today's topic is one that nearly everyone has heard of,
4
00:00:07,940 --> 00:00:10,500
but few really understand, platform engineering.
5
00:00:10,500 --> 00:00:11,900
You've probably heard about DevOps,
6
00:00:11,900 --> 00:00:15,400
the idea that developers and operations teams work together seamlessly,
7
00:00:15,400 --> 00:00:17,700
but somewhere along the way that promise got messy.
8
00:00:17,700 --> 00:00:20,100
Developers ended up doing ops work, that system broke.
9
00:00:20,100 --> 00:00:21,940
By the end of this episode, you'll understand
10
00:00:21,940 --> 00:00:23,340
what went wrong with DevOps,
11
00:00:23,340 --> 00:00:25,660
what an internal developer platform actually is,
12
00:00:25,660 --> 00:00:28,300
how golden parts give teams a clear road to follow,
13
00:00:28,300 --> 00:00:31,500
and why the smartest engineering teams are already building one.
14
00:00:31,500 --> 00:00:33,160
The mess DevOps left behind.
15
00:00:33,160 --> 00:00:34,460
Let's go back to where it started.
16
00:00:34,460 --> 00:00:36,700
DevOps was a great idea with a simple goal,
17
00:00:36,700 --> 00:00:38,940
break down the walls between developers and operations,
18
00:00:38,940 --> 00:00:41,600
no more throwing code over the wall and hoping for the best.
19
00:00:41,600 --> 00:00:45,200
Shift left, move testing, security and operations earlier in the process,
20
00:00:45,200 --> 00:00:48,100
faster delivery, fewer hand-offs, more ownership.
21
00:00:48,100 --> 00:00:49,700
On paper, it looked perfect.
22
00:00:49,700 --> 00:00:51,500
In practice, something went wrong.
23
00:00:51,500 --> 00:00:54,100
Shift left didn't just shift responsibilities.
24
00:00:54,100 --> 00:00:55,640
It piled them on.
25
00:00:55,640 --> 00:00:57,800
The developer who used to write code and file a ticket
26
00:00:57,800 --> 00:01:01,520
now owns infrastructure, security, monitoring, Kubernetes,
27
00:01:01,520 --> 00:01:04,000
CI/CD pipelines, secret management,
28
00:01:04,000 --> 00:01:07,200
and about 15 cloud services they'd never heard of before.
29
00:01:07,200 --> 00:01:10,500
One person handles all of that while still building the actual product.
30
00:01:10,500 --> 00:01:12,300
Here's what that looks like in real life.
31
00:01:12,300 --> 00:01:15,100
A team wants to spin up a new environment to test a feature.
32
00:01:15,100 --> 00:01:17,400
Before DevOps, they'd file a ticket and wait.
33
00:01:17,400 --> 00:01:20,600
After DevOps, they own it themselves, which sounds great in theory.
34
00:01:20,600 --> 00:01:22,200
But now they need to write terraform modules,
35
00:01:22,200 --> 00:01:23,800
configure a Kubernetes cluster,
36
00:01:23,800 --> 00:01:24,940
set up networking rules,
37
00:01:24,940 --> 00:01:29,640
wire up monitoring, figure out secrets, management, and make sure security policies are applied.
38
00:01:29,640 --> 00:01:32,140
What used to be a ticket that took someone else an hour
39
00:01:32,140 --> 00:01:34,440
now takes three days of a developer's time.
40
00:01:34,440 --> 00:01:36,540
Three days, they're not writing product code.
41
00:01:36,540 --> 00:01:41,240
They're fighting YAML files and debugging why the load balancer isn't rooting traffic correctly.
42
00:01:41,240 --> 00:01:42,740
The mental load here is enormous.
43
00:01:42,740 --> 00:01:44,740
Every team ends up building their own pipelines,
44
00:01:44,740 --> 00:01:47,040
deployment scripts, and monitoring dashboards.
45
00:01:47,040 --> 00:01:49,440
And because everyone's stretched, then corners get cut.
46
00:01:49,440 --> 00:01:52,040
Security gets skipped because the deadline is Friday.
47
00:01:52,040 --> 00:01:53,740
Cloud builds double without anyone noticing
48
00:01:53,740 --> 00:01:56,140
because nobody remembered to shut down the test environment.
49
00:01:56,140 --> 00:01:58,140
And when something breaks at 2 a.m.,
50
00:01:58,140 --> 00:02:00,640
the developer who built it is the only one who can fix it.
51
00:02:00,640 --> 00:02:01,840
This isn't sustainable.
52
00:02:01,840 --> 00:02:03,840
And here's why it matters more than ever.
53
00:02:03,840 --> 00:02:05,540
Cloud complexity keeps growing.
54
00:02:05,540 --> 00:02:08,740
Every year there are more services, more tools, more decisions to make.
55
00:02:08,740 --> 00:02:12,240
And now AI coding tools let developers ship code faster than ever.
56
00:02:12,240 --> 00:02:15,140
10, 20, even 30 times more code per day.
57
00:02:15,140 --> 00:02:18,440
But all that code still needs infrastructure, security, and monitoring.
58
00:02:18,440 --> 00:02:22,040
More code without a better system just means faster chaos.
59
00:02:22,040 --> 00:02:25,240
If you feel like you're drowning in YAML and Terraform, you're not alone.
60
00:02:25,240 --> 00:02:26,740
This isn't a personal failure.
61
00:02:26,740 --> 00:02:27,740
It's systemic.
62
00:02:27,740 --> 00:02:28,840
The model broke.
63
00:02:28,840 --> 00:02:31,040
What platform engineering actually is.
64
00:02:31,040 --> 00:02:31,840
So what's the fix?
65
00:02:31,840 --> 00:02:33,640
It's called platform engineering.
66
00:02:33,640 --> 00:02:35,640
And here's the simplest way to think about it.
67
00:02:35,640 --> 00:02:37,640
This discipline creates an internal layer
68
00:02:37,640 --> 00:02:39,640
that absorbs complexity for developers.
69
00:02:39,640 --> 00:02:41,640
Imagine walking into a large office building.
70
00:02:41,640 --> 00:02:43,540
You don't need to worry about who has access to,
71
00:02:43,540 --> 00:02:45,640
which floor, which security badge works,
72
00:02:45,640 --> 00:02:47,140
or where the fire exits are.
73
00:02:47,140 --> 00:02:48,840
The reception desk handles all that for you
74
00:02:48,840 --> 00:02:50,240
and you just walk in and get to work.
75
00:02:50,240 --> 00:02:52,940
That's exactly what platform engineering does for your developers.
76
00:02:52,940 --> 00:02:55,840
Instead of every single developer needing to become an expert
77
00:02:55,840 --> 00:02:58,540
in Kubernetes, Terraform, networking, and security,
78
00:02:58,540 --> 00:03:00,340
a central platform team creates a layer
79
00:03:00,340 --> 00:03:02,440
that manages all that complexity.
80
00:03:02,440 --> 00:03:04,140
The developer gets a simple interface.
81
00:03:04,140 --> 00:03:06,640
Click a button, run a command, fill out a form,
82
00:03:06,640 --> 00:03:08,440
and the platform takes care of everything else.
83
00:03:08,440 --> 00:03:09,440
But here's the thing.
84
00:03:09,440 --> 00:03:10,740
This isn't the same as DevOps.
85
00:03:10,740 --> 00:03:13,040
DevOps taught every team to own their own infrastructure,
86
00:03:13,040 --> 00:03:15,640
but platform engineering says that's a recipe for burnout.
87
00:03:15,640 --> 00:03:18,040
Instead, the platform team provides paved roads,
88
00:03:18,040 --> 00:03:21,440
standard, tested, and secure ways to handle common tasks.
89
00:03:21,440 --> 00:03:22,840
They build and maintain the road,
90
00:03:22,840 --> 00:03:24,640
while product teams just drive on it.
91
00:03:24,640 --> 00:03:26,440
The core outcome of platform engineering
92
00:03:26,440 --> 00:03:28,640
is something called an internal developer platform,
93
00:03:28,640 --> 00:03:30,240
or IDP for short.
94
00:03:30,240 --> 00:03:31,840
Think of it as a self-service system
95
00:03:31,840 --> 00:03:34,240
that automates all that repetitive work.
96
00:03:34,240 --> 00:03:37,340
Infrastructure provisioning, CI/CD pipelines,
97
00:03:37,340 --> 00:03:40,840
security checks, monitoring, all built-in and standardized.
98
00:03:40,840 --> 00:03:42,040
Here's a concrete example.
99
00:03:42,040 --> 00:03:44,440
When a developer wants to deploy a new service without a platform,
100
00:03:44,440 --> 00:03:46,240
it's been days setting up infrastructure,
101
00:03:46,240 --> 00:03:49,040
writing pipelines, and configuring monitoring.
102
00:03:49,040 --> 00:03:52,040
With an IDP, they just click "Deploy" in a UI
103
00:03:52,040 --> 00:03:53,440
or run a single command.
104
00:03:53,440 --> 00:03:55,040
And the platform handles everything,
105
00:03:55,040 --> 00:03:57,240
provisioning, tests, monitoring, deployment,
106
00:03:57,240 --> 00:03:58,840
all in minutes instead of days.
107
00:03:58,840 --> 00:03:59,840
So what does this mean for you?
108
00:03:59,840 --> 00:04:01,840
You stop being a jack-of-all infrastructure
109
00:04:01,840 --> 00:04:04,040
and start being a specialist in your actual product.
110
00:04:04,040 --> 00:04:05,840
Your job goes back to building features
111
00:04:05,840 --> 00:04:07,040
that matter to your customers.
112
00:04:07,040 --> 00:04:10,040
Instead of debugging why your Terraform state file is corrupted,
113
00:04:10,040 --> 00:04:11,240
that's the whole point.
114
00:04:11,240 --> 00:04:13,440
The internal developer platform in plain English.
115
00:04:13,440 --> 00:04:15,640
So let's break down what an internal developer platform
116
00:04:15,640 --> 00:04:16,440
actually is.
117
00:04:16,440 --> 00:04:19,040
It's the engine that combines everything into one system.
118
00:04:19,040 --> 00:04:21,440
Your CI/CD pipelines, infrastructure templates,
119
00:04:21,440 --> 00:04:23,840
security policies, monitoring, and logging.
120
00:04:23,840 --> 00:04:26,840
Instead of six separate tools, you have to wire together.
121
00:04:26,840 --> 00:04:27,640
Here's an analogy.
122
00:04:27,640 --> 00:04:30,840
Think of it as "cooking from scratch" versus using a vending machine.
123
00:04:30,840 --> 00:04:32,640
"Cooking from scratch" means buying ingredients,
124
00:04:32,640 --> 00:04:35,640
chopping vegetables, measuring spices, monitoring the stove,
125
00:04:35,640 --> 00:04:38,640
lots of decisions, lots of steps, lots of ways to mess up.
126
00:04:38,640 --> 00:04:41,440
A vending machine gives you a result with one button press.
127
00:04:41,440 --> 00:04:44,240
Fewer decisions, faster outcome, consistent quality,
128
00:04:44,240 --> 00:04:46,040
and IDP is that vending machine.
129
00:04:46,040 --> 00:04:48,840
The developer doesn't need to know how infrastructure is provisioned
130
00:04:48,840 --> 00:04:50,440
or where secrets are stored.
131
00:04:50,440 --> 00:04:51,840
They just press the button.
132
00:04:51,840 --> 00:04:53,440
What's inside that vending machine?
133
00:04:53,440 --> 00:04:55,240
The core components are pretty standard.
134
00:04:55,240 --> 00:04:57,440
CI/CD templates for consistent builds,
135
00:04:57,440 --> 00:05:00,440
infrastructure provisioning for automatic environment spin-up,
136
00:05:00,440 --> 00:05:04,040
secret management, so credentials aren't floating around in config files,
137
00:05:04,040 --> 00:05:06,040
and logging with built-in observability
138
00:05:06,040 --> 00:05:08,240
so you can troubleshoot without scrambling.
139
00:05:08,240 --> 00:05:11,240
All of it pre-configured, tested, and maintained by the platform team.
140
00:05:11,240 --> 00:05:12,640
Here's a concrete example.
141
00:05:12,640 --> 00:05:15,440
A developer types create new service into a command line
142
00:05:15,440 --> 00:05:17,240
or clicks a button in a portal.
143
00:05:17,240 --> 00:05:20,840
Behind the scenes, the IDP spins up a new repository with the right structure,
144
00:05:20,840 --> 00:05:24,040
sets up a build pipeline that runs tests automatically,
145
00:05:24,040 --> 00:05:26,240
deploys the service to a development environment,
146
00:05:26,240 --> 00:05:28,440
and adds health check endpoints with logging.
147
00:05:28,440 --> 00:05:29,840
All of that happens in minutes.
148
00:05:29,840 --> 00:05:32,240
The developer never touched a single terraform file
149
00:05:32,240 --> 00:05:34,240
or configured a Kubernetes manifest.
150
00:05:34,240 --> 00:05:36,040
Just type to command and got a running service.
151
00:05:36,040 --> 00:05:37,040
Why does this matter?
152
00:05:37,040 --> 00:05:39,040
Consistency is the key reason.
153
00:05:39,040 --> 00:05:42,440
When every team builds their own pipelines and writes their own deployment scripts,
154
00:05:42,440 --> 00:05:44,640
you end up with snowflake configurations,
155
00:05:44,640 --> 00:05:47,640
50 different services, 50 different ways of doing things.
156
00:05:47,640 --> 00:05:51,440
When something breaks, nobody can debug it except the person who built it
157
00:05:51,440 --> 00:05:53,640
and if that person left the company, good luck.
158
00:05:53,640 --> 00:05:57,440
An IDP eliminates that by making every service follow the same patterns,
159
00:05:57,440 --> 00:06:01,040
every deployment uses the same pipeline and every team get the same defaults.
160
00:06:01,040 --> 00:06:04,240
When something breaks, the patterns are familiar and the fix is documented.
161
00:06:04,240 --> 00:06:05,640
So here's what this means for you.
162
00:06:05,640 --> 00:06:08,840
If your organization has 50 teams doing deployment 50 different ways,
163
00:06:08,840 --> 00:06:10,240
an IDP is the solution.
164
00:06:10,240 --> 00:06:11,640
It doesn't mean teams lose autonomy.
165
00:06:11,640 --> 00:06:15,240
It means the boring, repetitive, error-prone parts get standardized
166
00:06:15,240 --> 00:06:17,440
so the interesting creative work can vary.
167
00:06:17,440 --> 00:06:19,240
That's a trade-off worth making.
168
00:06:19,240 --> 00:06:21,640
Golden parts, the way, not a cage.
169
00:06:21,640 --> 00:06:23,040
Let's talk about golden parts.
170
00:06:23,040 --> 00:06:25,240
You've probably heard the name, but the idea is simple.
171
00:06:25,240 --> 00:06:28,240
A golden path is a recommended pre-built workflow
172
00:06:28,240 --> 00:06:30,640
that makes the right thing the easiest thing to do.
173
00:06:30,640 --> 00:06:33,840
Your platform team says, "Here's how we suggest you do this."
174
00:06:33,840 --> 00:06:37,240
We've tested it, it works, and we'll back you up if something breaks.
175
00:06:37,240 --> 00:06:39,440
Notice that word recommend.
176
00:06:39,440 --> 00:06:41,440
Golden parts aren't mandatory.
177
00:06:41,440 --> 00:06:43,640
Developers can step off the path if they need to,
178
00:06:43,640 --> 00:06:45,440
but the path is the fast-safety fault.
179
00:06:45,440 --> 00:06:47,640
It's already running, supported and documented.
180
00:06:47,640 --> 00:06:49,640
You don't have to figure everything out from scratch.
181
00:06:49,640 --> 00:06:52,640
Think of it like railway tracks instead of guard rails.
182
00:06:52,640 --> 00:06:54,440
Guard rails catch you when you crash.
183
00:06:54,440 --> 00:06:56,440
They react, they stop you from going off a cliff,
184
00:06:56,440 --> 00:06:58,040
but they don't help you steer.
185
00:06:58,040 --> 00:07:00,040
Railway tracks guide you smoothly along the route
186
00:07:00,040 --> 00:07:02,240
so you don't have to decide where to turn.
187
00:07:02,240 --> 00:07:04,840
Golden parts are the tracks, they move you forward,
188
00:07:04,840 --> 00:07:06,440
not just catch you when you fail.
189
00:07:06,440 --> 00:07:08,240
Here's where a lot of teams get this wrong.
190
00:07:08,240 --> 00:07:10,440
They build golden parts for the platform team,
191
00:07:10,440 --> 00:07:11,440
not for the developers.
192
00:07:11,440 --> 00:07:14,240
They optimize for architectural purity or security compliance
193
00:07:14,240 --> 00:07:17,440
or some internal rule nobody outside the platform team understands.
194
00:07:17,440 --> 00:07:20,440
The result looks great on a whiteboard, but feels terrible to use.
195
00:07:20,440 --> 00:07:23,240
Developers quietly find workarounds, adoption drops,
196
00:07:23,240 --> 00:07:26,240
and the platform team wonders why nobody appreciates all that effort.
197
00:07:26,240 --> 00:07:28,040
The fix is simple, but it's hard to do.
198
00:07:28,040 --> 00:07:29,240
You need escape hatches.
199
00:07:29,240 --> 00:07:32,440
If the path doesn't fit a developer's use case, they need a way out.
200
00:07:32,440 --> 00:07:34,240
A way to override a default,
201
00:07:34,240 --> 00:07:37,240
bring their own pipeline or step outside the platform entirely.
202
00:07:37,240 --> 00:07:38,840
And here's the important part.
203
00:07:38,840 --> 00:07:40,440
When they step off, that's not failure.
204
00:07:40,440 --> 00:07:41,240
It's feedback.
205
00:07:41,240 --> 00:07:44,240
Every time a developer leaves the golden path, it tells you something real.
206
00:07:44,240 --> 00:07:46,640
Either the path is missing a feature it should have,
207
00:07:46,640 --> 00:07:49,040
or the use case genuinely doesn't belong there.
208
00:07:49,040 --> 00:07:50,440
Both signals are valuable.
209
00:07:50,440 --> 00:07:52,840
A good golden path in practice looks like this.
210
00:07:52,840 --> 00:07:55,040
A team wants to deploy a new backend service.
211
00:07:55,040 --> 00:07:56,040
They use the path.
212
00:07:56,040 --> 00:07:59,040
It gives them a template repository with the right structure,
213
00:07:59,040 --> 00:08:01,640
a standard CI/CD pipeline that's already tested.
214
00:08:01,640 --> 00:08:03,040
Built in logging and monitoring,
215
00:08:03,040 --> 00:08:05,240
a one-click rollback if something goes wrong.
216
00:08:05,240 --> 00:08:07,040
The whole thing takes minutes instead of days,
217
00:08:07,040 --> 00:08:10,240
and because the platform team maintains the path when something breaks,
218
00:08:10,240 --> 00:08:11,240
they fix it.
219
00:08:11,240 --> 00:08:14,240
The developer doesn't have to become a pipeline debugging expert.
220
00:08:14,240 --> 00:08:16,240
What this means for you, fewer surprises.
221
00:08:16,240 --> 00:08:18,240
You ship faster because the path is tested.
222
00:08:18,240 --> 00:08:21,240
You ship safer because security and monitoring are built in.
223
00:08:21,240 --> 00:08:23,840
You ship with confidence because rolling back is one-click.
224
00:08:23,840 --> 00:08:27,040
The path exists to help you, not to hold you back.
225
00:08:27,040 --> 00:08:29,240
Use it, cutting cognitive load.
226
00:08:29,240 --> 00:08:31,040
Here's where the real payoff shows up.
227
00:08:31,040 --> 00:08:33,040
When a platform handles the heavy lifting,
228
00:08:33,040 --> 00:08:34,840
developers can actually focus on code.
229
00:08:34,840 --> 00:08:37,440
They don't need to know which Kubernetes version is running.
230
00:08:37,440 --> 00:08:41,640
They don't have to update Terraform modules every time a cloud provider changes in API.
231
00:08:41,640 --> 00:08:42,840
They just write features.
232
00:08:42,840 --> 00:08:44,640
Platform engineers absorb that complexity.
233
00:08:44,640 --> 00:08:47,040
They decide what developers need to see and what should stay hidden.
234
00:08:47,040 --> 00:08:49,240
That's a real design choice, not just a technical one.
235
00:08:49,240 --> 00:08:52,640
It's about figuring out which details matter to the person using the platform
236
00:08:52,640 --> 00:08:54,440
and which ones just add noise.
237
00:08:54,440 --> 00:08:55,640
Here's a concrete example.
238
00:08:55,640 --> 00:08:59,440
A developer deploying a new service doesn't care about cluster node sizes,
239
00:08:59,440 --> 00:09:02,240
instance types, or auto scaling thresholds.
240
00:09:02,240 --> 00:09:04,240
They care about whether their service runs
241
00:09:04,240 --> 00:09:05,840
and how fast it responds.
242
00:09:05,840 --> 00:09:08,440
So the platform pre-configures all that based on the app tier.
243
00:09:08,440 --> 00:09:11,240
Small service, here's the right setup, high traffic service,
244
00:09:11,240 --> 00:09:12,640
here's a different configuration.
245
00:09:12,640 --> 00:09:15,640
The developer doesn't make those choices because they don't need to.
246
00:09:15,640 --> 00:09:16,640
Why does this matter?
247
00:09:16,640 --> 00:09:21,040
Because burnout drops when developers aren't juggling 15 different concerns at once.
248
00:09:21,040 --> 00:09:24,440
Some mature platform teams have cut cognitive load by nearly half.
249
00:09:24,440 --> 00:09:26,840
40 to 50% less mental overhead.
250
00:09:26,840 --> 00:09:28,040
That's a huge shift.
251
00:09:28,040 --> 00:09:30,240
It's the difference between leaving work with energy left
252
00:09:30,240 --> 00:09:33,640
and staring at a terminal at 10pm wondering why your pipeline failed.
253
00:09:33,640 --> 00:09:36,040
But here's the warning, don't create illusions.
254
00:09:36,040 --> 00:09:38,240
Some platform teams fall into a trap.
255
00:09:38,240 --> 00:09:41,240
They hide settings without giving developers any way to understand
256
00:09:41,240 --> 00:09:42,640
what's happening under the hood.
257
00:09:42,640 --> 00:09:44,840
That's not abstraction, that's trickery.
258
00:09:44,840 --> 00:09:46,840
And it backfires the moment something goes wrong,
259
00:09:46,840 --> 00:09:48,840
developers hit a wall they can't see through
260
00:09:48,840 --> 00:09:51,640
and suddenly the platform feels like a black box working against them.
261
00:09:51,640 --> 00:09:53,440
The term for this is a leaky abstraction.
262
00:09:53,440 --> 00:09:56,040
You hide complexity, but eventually that complexity leaks out.
263
00:09:56,040 --> 00:09:58,440
A database gets slow, a deployment fails,
264
00:09:58,440 --> 00:10:00,840
a security policy blocks something unexpected.
265
00:10:00,840 --> 00:10:03,240
And the developer has no mental model of what's happening
266
00:10:03,240 --> 00:10:06,440
because the platform never gave them one, transparency matters.
267
00:10:06,440 --> 00:10:09,040
Show developers what they need to know when they need to know it.
268
00:10:09,040 --> 00:10:11,240
Don't just hide everything and hope for the best.
269
00:10:11,240 --> 00:10:14,440
What this means for you, less context switching and more flow state.
270
00:10:14,440 --> 00:10:17,840
You don't start your morning wondering if the Kubernetes cluster needs an upgrade.
271
00:10:17,840 --> 00:10:20,440
You start your morning working on the feature due next week.
272
00:10:20,440 --> 00:10:23,040
Your job becomes your actual work again.
273
00:10:23,040 --> 00:10:24,840
Treating the platform like a product.
274
00:10:24,840 --> 00:10:26,840
Today we're talking about something that changes
275
00:10:26,840 --> 00:10:28,840
how internal tools actually work.
276
00:10:28,840 --> 00:10:31,640
Most people think a platform team is just an infrastructure team.
277
00:10:31,640 --> 00:10:33,640
It isn't a platform team is a product team.
278
00:10:33,640 --> 00:10:36,040
And the developers using that platform are their customers,
279
00:10:36,040 --> 00:10:37,440
not people filing tickets.
280
00:10:37,440 --> 00:10:38,440
That changes everything.
281
00:10:38,440 --> 00:10:40,440
A product team talks to its customers.
282
00:10:40,440 --> 00:10:42,040
They find out what's actually painful.
283
00:10:42,040 --> 00:10:44,240
They prioritize features based on real need.
284
00:10:44,240 --> 00:10:45,240
They measure adoption.
285
00:10:45,240 --> 00:10:46,840
They don't build something and walk away.
286
00:10:46,840 --> 00:10:48,040
They keep iterating.
287
00:10:48,040 --> 00:10:50,240
So what does a product team look like in practice?
288
00:10:50,240 --> 00:10:52,040
They don't operate like a help desk.
289
00:10:52,040 --> 00:10:53,440
A developer files a ticket.
290
00:10:53,440 --> 00:10:55,640
And the platform team does it manually.
291
00:10:55,640 --> 00:10:57,040
That's not platform engineering.
292
00:10:57,040 --> 00:10:59,240
That's just centralized operations with a new name.
293
00:10:59,240 --> 00:11:00,040
It doesn't scale.
294
00:11:00,040 --> 00:11:01,440
It doesn't reduce cognitive load.
295
00:11:01,440 --> 00:11:03,640
It just moves the bottleneck from one team to another.
296
00:11:03,640 --> 00:11:04,840
Here's what they do instead.
297
00:11:04,840 --> 00:11:06,240
They measure the right things.
298
00:11:06,240 --> 00:11:07,440
Time to first deploy.
299
00:11:07,440 --> 00:11:09,240
Onboarding speed for new team members.
300
00:11:09,240 --> 00:11:11,040
Developer satisfaction scores.
301
00:11:11,040 --> 00:11:12,240
These are the metrics that tell you
302
00:11:12,240 --> 00:11:14,040
whether the platform is actually helping people
303
00:11:14,040 --> 00:11:16,240
or just adding another layer of complexity.
304
00:11:16,240 --> 00:11:17,240
Spotify is a good example.
305
00:11:17,240 --> 00:11:19,640
Their platform team runs like a proper product organization.
306
00:11:19,640 --> 00:11:20,640
They have roadmaps.
307
00:11:20,640 --> 00:11:21,640
They have OKRs.
308
00:11:21,640 --> 00:11:24,440
They talk to developers about what is working and what isn't.
309
00:11:24,440 --> 00:11:26,840
They treat the platform as something that has to earn
310
00:11:26,840 --> 00:11:28,640
its adoption every single day.
311
00:11:28,640 --> 00:11:29,840
And that is the main idea.
312
00:11:29,840 --> 00:11:32,240
A platform nobody uses is just a project.
313
00:11:32,240 --> 00:11:34,040
It's gathering dust in a corner.
314
00:11:34,040 --> 00:11:36,040
Adoption is the ultimate validation.
315
00:11:36,040 --> 00:11:37,640
If developers choose your platform
316
00:11:37,640 --> 00:11:38,840
over building their own tools,
317
00:11:38,840 --> 00:11:40,040
you have done something right.
318
00:11:40,040 --> 00:11:43,440
If they avoided no amount of technical excellence can fix that.
319
00:11:43,440 --> 00:11:44,440
What does this mean for you?
320
00:11:44,440 --> 00:11:46,040
It means if you are building a platform.
321
00:11:46,040 --> 00:11:47,640
Don't start with architecture diagrams.
322
00:11:47,640 --> 00:11:50,240
Don't start with Kubernetes clusters or terraform modules.
323
00:11:50,240 --> 00:11:51,840
Start with user interviews.
324
00:11:51,840 --> 00:11:54,040
Talk to the developers who will use your platform.
325
00:11:54,040 --> 00:11:55,640
Find out what is actually painful.
326
00:11:55,640 --> 00:11:57,640
Build one thing that solves the real problem.
327
00:11:57,640 --> 00:11:58,640
Then iterate.
328
00:11:58,640 --> 00:12:01,640
That is how you build something people actually want to use.
329
00:12:01,640 --> 00:12:02,640
Why right now?
330
00:12:02,640 --> 00:12:03,640
The AI wave.
331
00:12:03,640 --> 00:12:05,440
So why are we talking about this right now?
332
00:12:05,440 --> 00:12:06,240
Why not five years ago?
333
00:12:06,240 --> 00:12:07,240
The answer is AI.
334
00:12:07,240 --> 00:12:09,840
AI coding tools like GitHub co-pilot.
335
00:12:09,840 --> 00:12:13,040
Let developers ship code at a pace we have never seen before.
336
00:12:13,040 --> 00:12:15,840
10 times, 20 times more code per day than what was possible
337
00:12:15,840 --> 00:12:16,840
just a couple of years ago.
338
00:12:16,840 --> 00:12:17,840
But that sounds amazing.
339
00:12:17,840 --> 00:12:18,640
And it is.
340
00:12:18,640 --> 00:12:19,640
But here's the catch.
341
00:12:19,640 --> 00:12:21,440
All that code still needs infrastructure.
342
00:12:21,440 --> 00:12:22,640
It still needs security.
343
00:12:22,640 --> 00:12:25,240
It still needs to be deployed, tested and operated.
344
00:12:25,240 --> 00:12:28,240
More code without a better system does not make you faster.
345
00:12:28,240 --> 00:12:29,840
It just makes the chaos faster.
346
00:12:29,840 --> 00:12:32,640
If your developers are already drowning in YAML and Terraform,
347
00:12:32,640 --> 00:12:34,040
AI does not fix that.
348
00:12:34,040 --> 00:12:36,440
It just means they drown faster while producing more code
349
00:12:36,440 --> 00:12:37,840
that needs to be supported.
350
00:12:37,840 --> 00:12:41,040
Right now about 55% of organizations have already adopted
351
00:12:41,040 --> 00:12:43,240
platform engineering in some form.
352
00:12:43,240 --> 00:12:47,240
Gardner predicts that number will hit 80% by the end of 2026.
353
00:12:47,240 --> 00:12:48,440
That is not a slow trend.
354
00:12:48,440 --> 00:12:50,040
That is a shift happening right now.
355
00:12:50,040 --> 00:12:52,640
Companies are realizing they cannot scale their engineering teams
356
00:12:52,640 --> 00:12:54,040
without a platform layer.
357
00:12:54,040 --> 00:12:56,040
The old approach of every team doing everything themselves
358
00:12:56,040 --> 00:12:58,640
just doesn't work when you are shipping code at AI speed.
359
00:12:58,640 --> 00:13:00,240
Here's what a lot of people miss.
360
00:13:00,240 --> 00:13:02,440
AI does not just create the need for platforms.
361
00:13:02,440 --> 00:13:03,640
It also helps build them.
362
00:13:03,640 --> 00:13:06,440
Platform teams are using AI to generate Terraform modules,
363
00:13:06,440 --> 00:13:09,240
write documentation and debug pipelines.
364
00:13:09,240 --> 00:13:11,840
The same technology creating the urgency is also providing
365
00:13:11,840 --> 00:13:13,240
the tools to solve it.
366
00:13:13,240 --> 00:13:14,440
Now a word of caution.
367
00:13:14,440 --> 00:13:16,840
AI amplifies whatever you already have.
368
00:13:16,840 --> 00:13:18,440
If your fundamentals are solid,
369
00:13:18,440 --> 00:13:20,840
like good architecture and a well-designed platform,
370
00:13:20,840 --> 00:13:23,240
AI makes you two to three times more productive.
371
00:13:23,240 --> 00:13:24,640
But if your foundations are weak,
372
00:13:24,640 --> 00:13:27,240
AI just helps you make bigger mistakes faster.
373
00:13:27,240 --> 00:13:29,640
Bad configuration, security holes, broken infrastructure,
374
00:13:29,640 --> 00:13:31,440
all shipped to production before anyone catches it.
375
00:13:31,440 --> 00:13:33,240
AI doesn't fix bad foundations.
376
00:13:33,240 --> 00:13:34,440
It exposes them.
377
00:13:34,440 --> 00:13:35,840
Here's a real example.
378
00:13:35,840 --> 00:13:38,240
A company with a good internal developer platform
379
00:13:38,240 --> 00:13:40,840
can let a non-engineer safely deploy AI tools.
380
00:13:40,840 --> 00:13:42,240
The platform provides guardrails.
381
00:13:42,240 --> 00:13:43,640
It enforces security policies.
382
00:13:43,640 --> 00:13:45,040
It handles the infrastructure.
383
00:13:45,040 --> 00:13:48,040
So a product manager can spin up an AI-powered prototype
384
00:13:48,040 --> 00:13:51,040
without needing to understand Kubernetes or cloud networking.
385
00:13:51,040 --> 00:13:51,840
That is powerful.
386
00:13:51,840 --> 00:13:54,040
That is the kind of thing that separates teams
387
00:13:54,040 --> 00:13:57,640
ready for the AI era from teams that are going to get left behind.
388
00:13:57,640 --> 00:13:59,040
What does this mean for you?
389
00:13:59,040 --> 00:14:01,040
The window to build a platform is closing,
390
00:14:01,040 --> 00:14:02,840
not because the technology is going away,
391
00:14:02,840 --> 00:14:05,240
but because the gap between teams with platforms
392
00:14:05,240 --> 00:14:07,240
and teams without them is widening fast.
393
00:14:07,240 --> 00:14:08,440
Every month you wait,
394
00:14:08,440 --> 00:14:11,440
the teams that already have platforms are pulling further ahead.
395
00:14:11,440 --> 00:14:13,440
They are shipping faster, burning out less,
396
00:14:13,440 --> 00:14:15,240
and adapting to new tools more quickly.
397
00:14:15,240 --> 00:14:17,840
The teams without platforms are falling further behind,
398
00:14:17,840 --> 00:14:19,240
the choice is yours.
399
00:14:19,240 --> 00:14:20,840
Start with one golden path.
400
00:14:20,840 --> 00:14:22,240
So where do you actually start?
401
00:14:22,240 --> 00:14:25,840
If you're sitting there thinking you need to build a whole internal developer platform
402
00:14:25,840 --> 00:14:27,040
from scratch, stop.
403
00:14:27,040 --> 00:14:29,840
That's the fastest way to kill your project before it even starts.
404
00:14:29,840 --> 00:14:31,440
The biggest mistake teams make?
405
00:14:31,440 --> 00:14:32,840
Trying to build everything at once?
406
00:14:32,840 --> 00:14:35,040
They spend months designing the perfect platform,
407
00:14:35,040 --> 00:14:37,040
packing in every feature they can think of.
408
00:14:37,040 --> 00:14:39,040
Then they launch it, and hear nothing.
409
00:14:39,040 --> 00:14:40,240
Nobody uses it.
410
00:14:40,240 --> 00:14:42,440
Why? Because it solves problems nobody asked about,
411
00:14:42,440 --> 00:14:45,240
and just getting started requires reading a small manual.
412
00:14:45,240 --> 00:14:46,040
Here's the thing.
413
00:14:46,040 --> 00:14:46,840
Don't do that.
414
00:14:46,840 --> 00:14:47,840
Instead start small.
415
00:14:47,840 --> 00:14:49,240
Actually talk to developers,
416
00:14:49,240 --> 00:14:50,840
not the architects, not the managers,
417
00:14:50,840 --> 00:14:54,240
not your own assumptions, find the people writing features every day.
418
00:14:54,240 --> 00:14:55,640
Ask them where it hurts.
419
00:14:55,640 --> 00:14:57,840
Find the one workflow that takes the longest,
420
00:14:57,840 --> 00:14:59,040
frustrates the most people,
421
00:14:59,040 --> 00:15:00,840
or gets skipped more than it should,
422
00:15:00,840 --> 00:15:03,440
then build exactly one golden path all the way through.
423
00:15:03,440 --> 00:15:06,240
Maybe it's create and deploy a new microservice.
424
00:15:06,240 --> 00:15:08,840
Maybe it's set up a development environment from scratch.
425
00:15:08,840 --> 00:15:12,440
Maybe it's ship a hot fix to production without breaking anything.
426
00:15:12,440 --> 00:15:16,240
Pick the one that stings the most and build a path that makes that pain disappear.
427
00:15:16,240 --> 00:15:16,840
Build it.
428
00:15:16,840 --> 00:15:18,040
Test it with real users.
429
00:15:18,040 --> 00:15:18,840
Collect feedback.
430
00:15:18,840 --> 00:15:19,840
Itterate.
431
00:15:19,840 --> 00:15:22,240
Then add another path and another after that.
432
00:15:22,240 --> 00:15:23,640
Don't try to solve every problem at once.
433
00:15:23,640 --> 00:15:26,840
Solve one problem really well and let the momentum carry you forward.
434
00:15:26,840 --> 00:15:28,240
How do you know it's working?
435
00:15:28,240 --> 00:15:29,640
Measure the right things.
436
00:15:29,640 --> 00:15:31,440
Time from idea to first deploy.
437
00:15:31,440 --> 00:15:34,840
Number of manual steps you've eliminated and voluntary adoption rates.
438
00:15:34,840 --> 00:15:37,440
If developers choose your path over building their own,
439
00:15:37,440 --> 00:15:38,240
your winning.
440
00:15:38,240 --> 00:15:39,440
If they're avoiding it,
441
00:15:39,440 --> 00:15:40,840
listen and change direction.
442
00:15:40,840 --> 00:15:42,240
Here's the trap to avoid.
443
00:15:42,240 --> 00:15:44,040
Don't make the platform mandatory.
444
00:15:44,040 --> 00:15:46,640
Force developers onto your path and they'll resent it.
445
00:15:46,640 --> 00:15:47,840
They'll find ways around it.
446
00:15:47,840 --> 00:15:49,840
They'll build their own scripts and hide them from you.
447
00:15:49,840 --> 00:15:51,840
Instead make the path easy.
448
00:15:51,840 --> 00:15:53,640
Make it faster than the alternative.
449
00:15:53,640 --> 00:15:55,040
Make it the obvious choice.
450
00:15:55,040 --> 00:15:56,440
But never the only one.
451
00:15:56,440 --> 00:15:58,240
The first path is always the hardest.
452
00:15:58,240 --> 00:16:00,240
It teaches you everything about product thinking.
453
00:16:00,240 --> 00:16:02,840
You learn how to talk to users, how to prioritize.
454
00:16:02,840 --> 00:16:04,840
And that building something people actually want
455
00:16:04,840 --> 00:16:06,840
is way harder than building something that just works.
456
00:16:06,840 --> 00:16:09,240
But once you've done it once, the second path gets easier
457
00:16:09,240 --> 00:16:10,640
and the third is easier still.
458
00:16:10,640 --> 00:16:12,440
You're not building a platform in one shot.
459
00:16:12,440 --> 00:16:14,440
You're building it one path at a time.
460
00:16:14,440 --> 00:16:15,440
So that's the system.
461
00:16:15,440 --> 00:16:17,640
Platform engineering is about building the paved road.
462
00:16:17,640 --> 00:16:20,840
So developers can focus on driving instead of fixing portals.
463
00:16:20,840 --> 00:16:22,440
If you're tired of fighting infrastructure,
464
00:16:22,440 --> 00:16:25,640
start by finding one golden path on your team, just one.
465
00:16:25,640 --> 00:16:27,440
Share this with someone who needs to hear it
466
00:16:27,440 --> 00:16:30,440
and subscribe for more breakdowns just like this.
