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.