1 00:00:00,000 --> 00:00:02,580 Everybody thinks that tools is the problem, but it isn't. 2 00:00:02,700 --> 00:00:06,240 I talked to around 390 platform engineering leaders this year. 3 00:00:06,360 --> 00:00:08,610 One person said that tooling was their problem. 4 00:00:08,730 --> 00:00:11,652 Today's guest is Sam Barlien, Community Organizer for the 5 00:00:11,652 --> 00:00:13,500 world's largest platform engineering community. 6 00:00:13,590 --> 00:00:16,158 Sam interviews engineering leaders to understand platform 7 00:00:16,158 --> 00:00:18,375 engineering challenges and has uncovered surprising patterns 8 00:00:18,375 --> 00:00:20,365 about why most organizations fail at it. 9 00:00:20,550 --> 00:00:22,740 The problems will often be culture. 10 00:00:22,860 --> 00:00:24,540 It'll be organizational challenges. 11 00:00:24,630 --> 00:00:27,430 It's never, oh, did we use the right CI/CD tooling? 12 00:00:27,590 --> 00:00:30,320 It's the culture around our CI/CD. 13 00:00:30,470 --> 00:00:32,750 How would you describe platform engineering essentially? 14 00:00:32,870 --> 00:00:35,990 Platform engineering as the discipline of treating internal 15 00:00:35,990 --> 00:00:39,054 service like a product. Are you thinking about those 16 00:00:39,054 --> 00:00:42,014 things like you are a product manager and the developers are 17 00:00:42,014 --> 00:00:44,180 your customer? Are you doing user research? 18 00:00:44,360 --> 00:00:47,774 That's the big differentiator. Why is it such a craze these 19 00:00:47,774 --> 00:00:49,990 days that people want to adopt platform engineering? 20 00:00:50,060 --> 00:00:53,510 If you are a developer 15 years ago, 9 out of 10 times, it was 21 00:00:53,510 --> 00:00:55,935 just writing code. There probably wasn't that much 22 00:00:55,935 --> 00:00:58,205 tooling. Now, zoom into today, the 23 00:00:58,205 --> 00:01:02,420 average new tooling a developer had to onboard to was 12. 12 new 24 00:01:02,420 --> 00:01:03,470 tools. This is insane! 25 00:01:03,560 --> 00:01:06,994 Take every single problem I've just mentioned, add AI onto it. 26 00:01:07,125 --> 00:01:09,830 And you see it's a 10x bigger problem now. 27 00:01:09,890 --> 00:01:13,190 AI makes every single one of these issues 10x worse. 28 00:01:13,190 --> 00:01:17,465 I was just at AWS re:Invent. And you can see for every talk 29 00:01:17,465 --> 00:01:20,978 that has AI as the headline, it's platform engineering as the 30 00:01:20,978 --> 00:01:24,800 core content within there. It's the thing that lets you do 31 00:01:24,800 --> 00:01:26,720 AI safely, AI effectively, move fast. 32 00:01:43,336 --> 00:01:45,782 Hey, quick pause. My goal with Tech Lead Journal 33 00:01:45,782 --> 00:01:48,366 is simple. Learn from the best in tech so 34 00:01:48,366 --> 00:01:51,736 we can all grow together. If this resonates with you, hit 35 00:01:51,736 --> 00:01:55,030 subscribe to follow the channel. It's the biggest way for you to 36 00:01:55,030 --> 00:01:57,601 support the show and help us keep bringing great guests and 37 00:01:57,601 --> 00:02:00,088 insights to you. Thanks for being here, and let's 38 00:02:00,088 --> 00:02:02,560 get back to it. Hello everyone. 39 00:02:02,560 --> 00:02:05,206 Welcome back to another new episode of the Tech Journal 40 00:02:05,206 --> 00:02:07,305 podcast. Today I have with me Sam 41 00:02:07,305 --> 00:02:09,965 Barlien. He's the community organizer for 42 00:02:09,965 --> 00:02:11,830 the Platform Engineering community. 43 00:02:12,250 --> 00:02:15,490 So I think platform engineering has always been kind of like a 44 00:02:15,490 --> 00:02:18,518 big topics these days. A little bit, you know, 45 00:02:18,518 --> 00:02:22,087 overwhelmed by AI these days. But hopefully we can switch a 46 00:02:22,087 --> 00:02:25,448 gear a little bit to platform engineering and what's so cool 47 00:02:25,448 --> 00:02:27,848 about the latest and greatest in platform engineering. 48 00:02:28,058 --> 00:02:30,638 Because Sam is really deep into platform engineering. 49 00:02:30,638 --> 00:02:33,398 He's been running the community, running conference. 50 00:02:33,698 --> 00:02:37,508 And I hope today we are going to learn a lot of things cool about 51 00:02:37,508 --> 00:02:39,998 platform engineering lately. So Sam, welcome to the show. 52 00:02:40,575 --> 00:02:42,885 Yeah, thank you very much. It is a, it's a big honor. 53 00:02:42,945 --> 00:02:46,288 I've watched quite a few so it's quite cool being here and now 54 00:02:46,288 --> 00:02:49,530 and getting to see myself up there with some pretty nice 55 00:02:49,530 --> 00:02:50,845 ranks. So thank you so much, Henry. 56 00:02:50,845 --> 00:02:54,962 I'm glad to be here and I think platform engineering, you know, 57 00:02:54,962 --> 00:02:59,939 really is one of, in my view, the hottest but also equally 58 00:02:59,939 --> 00:03:02,711 most forgotten enterprise trends at the moment. 59 00:03:02,711 --> 00:03:05,001 You know, AI obviously takes over everything. 60 00:03:05,445 --> 00:03:08,451 But I think I'll be able to make a pretty compelling argument as 61 00:03:08,451 --> 00:03:11,415 we go through this, why platform engineering is absolutely not 62 00:03:11,415 --> 00:03:13,455 something we should be sleeping on. 63 00:03:13,725 --> 00:03:15,711 So super looking forward to talking to you about about it. 64 00:03:16,758 --> 00:03:19,325 Yeah. So when you say AI is taking 65 00:03:19,325 --> 00:03:23,467 over, it is indeed has been taking over, you know, maybe in 66 00:03:23,467 --> 00:03:25,608 the news, in the topics, discussions, wherever. 67 00:03:25,753 --> 00:03:29,683 We talk about always AI. AI engineering, AI-assisted 68 00:03:29,683 --> 00:03:31,927 development. So yeah, hopefully today we can 69 00:03:31,927 --> 00:03:33,043 learn something about platform engineering. 70 00:03:33,133 --> 00:03:36,176 But before we go deep into that, I always love to invite my 71 00:03:36,176 --> 00:03:39,002 guests to share a little bit more about yourself by maybe 72 00:03:39,002 --> 00:03:41,606 telling us career turning points that you think we all can learn 73 00:03:41,606 --> 00:03:43,168 from you. Sure. 74 00:03:43,168 --> 00:03:47,053 I mean, I'll start with a quick intro, kind of even, of who I am 75 00:03:47,053 --> 00:03:51,018 and the community at large. So we are really the world's 76 00:03:51,018 --> 00:03:53,008 largest platform engineering focused community. 77 00:03:53,038 --> 00:03:57,102 So we've got like 270,000 people who read our content, 78 00:03:57,102 --> 00:03:59,338 newsletters, blogs, courses, yada yada yada. 79 00:03:59,668 --> 00:04:02,948 And those are DevOps engineers, SREs, platform engineers, 80 00:04:02,948 --> 00:04:05,818 FinOps. And I do a lot of our research. 81 00:04:06,058 --> 00:04:09,058 I do some of our kind of conversations with enterprise 82 00:04:09,058 --> 00:04:11,493 leaders. I mean, I talk to like 400 83 00:04:11,493 --> 00:04:13,018 engineering leaders a year basically. 84 00:04:13,662 --> 00:04:16,992 You know, I have these meetings every week to just delve into 85 00:04:16,992 --> 00:04:20,836 their problems and I grill them. If some of them are listening 86 00:04:20,836 --> 00:04:22,842 they know. I really, I harass them. 87 00:04:22,842 --> 00:04:25,017 I grill them. It's like the inquisition and 88 00:04:25,017 --> 00:04:27,132 then turns into a bit of therapy. 89 00:04:27,692 --> 00:04:32,982 And I think the turning point for me is this kind of 90 00:04:32,982 --> 00:04:36,540 interesting conversation I have with everybody in my life before 91 00:04:36,540 --> 00:04:38,122 platform engineering. Cause they're like, huh? 92 00:04:38,812 --> 00:04:40,182 You work in platform engineering? 93 00:04:40,202 --> 00:04:43,466 Like, what? You know, I have a technical 94 00:04:43,466 --> 00:04:46,262 marketing background. I worked, I mean 10 years ago, I 95 00:04:46,262 --> 00:04:49,692 worked as an actor but since then I've really been this kind 96 00:04:49,692 --> 00:04:54,072 of technical marketing focus. So it's like how can someone who 97 00:04:54,072 --> 00:04:57,680 worked in kind of marketing, community, even a bit of sales, 98 00:04:57,680 --> 00:05:00,342 like how can you have any relevance in platform 99 00:05:00,342 --> 00:05:03,842 engineering which is like a very deep technical domain? 100 00:05:04,682 --> 00:05:08,219 And it's really because of the big differentiator platform 101 00:05:08,219 --> 00:05:11,172 engineering has around a lot of other engineering — and I think 102 00:05:11,172 --> 00:05:15,722 we're gonna get into that a lot — where platform engineering 103 00:05:15,722 --> 00:05:19,052 requires a lot of cultural stuff. 104 00:05:19,142 --> 00:05:21,932 Way more cultural stuff than people expect. 105 00:05:22,082 --> 00:05:24,452 We're gonna touch on that a lot, I'm sure. 106 00:05:24,902 --> 00:05:28,442 And that often requires a different kind of voice. 107 00:05:28,847 --> 00:05:31,037 We need the architects, we need the engineers. 108 00:05:31,367 --> 00:05:34,133 I obviously have enough of an engineering background to know 109 00:05:34,133 --> 00:05:36,107 what I'm talking about. You gotta have it. 110 00:05:36,497 --> 00:05:40,119 But the challenge for most organizations is never, oh, you 111 00:05:40,119 --> 00:05:43,157 know, we're trying to figure out the code we need to write. 112 00:05:43,817 --> 00:05:47,228 Absolutely not. The challenge is how do I get 113 00:05:47,228 --> 00:05:50,104 this user research? How do I convince a developer to 114 00:05:50,104 --> 00:05:53,645 tell me their problems? You know, how do I get people to 115 00:05:53,645 --> 00:05:56,417 onboard onto my platform or to use our internal tooling? 116 00:05:57,377 --> 00:05:59,987 That's very rarely a technological challenge. 117 00:06:00,567 --> 00:06:03,353 It's, you know, marketing is a dirty word so I try not to use 118 00:06:03,353 --> 00:06:05,477 marketing too much. It's a marketing challenge. 119 00:06:05,537 --> 00:06:09,767 How do you internally market a tool to get your, you know, your 120 00:06:09,767 --> 00:06:12,659 developers to onboard onto it? So that has really been the 121 00:06:12,659 --> 00:06:15,077 turning point for me where I started to have these 122 00:06:15,077 --> 00:06:17,037 conversations about platform engineering. 123 00:06:17,037 --> 00:06:20,137 I started to really work on the product management side. 124 00:06:20,717 --> 00:06:22,307 And I would get invited to speak. 125 00:06:22,307 --> 00:06:25,587 I would get asked, hey, could you give me advice on how to 126 00:06:25,587 --> 00:06:30,391 market my internal platform? And turns out I have a lot to 127 00:06:30,391 --> 00:06:34,405 add on that topic. right? Thank you for sharing such an 128 00:06:34,405 --> 00:06:36,424 interesting thing. So I guess indeed it's, I mean 129 00:06:36,424 --> 00:06:39,451 there's a bit of fun fact when I research you on Google, right? 130 00:06:39,451 --> 00:06:42,391 When I type in your name, the first thing that it pops out is 131 00:06:42,391 --> 00:06:44,339 actually actors. So it is actually true that you 132 00:06:44,339 --> 00:06:47,535 were an actor before. So maybe a little bit of 133 00:06:47,535 --> 00:06:51,048 curiosity, what brings you to, you know, a more deep technical 134 00:06:51,048 --> 00:06:53,603 profession now compared to the previous one? 135 00:06:53,923 --> 00:06:57,673 So what led you turning from an actor into this, doing this now? 136 00:06:58,635 --> 00:07:02,785 Well, the irony is like all the things that I loved about 137 00:07:02,785 --> 00:07:06,465 acting, which was storytelling, telling stories, meeting new 138 00:07:06,465 --> 00:07:11,446 people, you know, trying to translate some kind of message 139 00:07:11,446 --> 00:07:15,859 in an interesting way, you know, that storytelling element of 140 00:07:15,859 --> 00:07:17,823 acting. Like that was the thing that I 141 00:07:17,823 --> 00:07:20,350 loved. And that's the thing that 142 00:07:20,350 --> 00:07:21,895 engineering struggles with the most. 143 00:07:22,285 --> 00:07:25,365 You know, it's the thing that makes platform engineering so 144 00:07:25,365 --> 00:07:27,720 hard for people. You know, that storytelling 145 00:07:27,720 --> 00:07:31,516 element of like, well how do I, and I'm gonna keep harping onto 146 00:07:31,516 --> 00:07:34,036 this idea. Anyone who's ever tried to 147 00:07:34,036 --> 00:07:37,656 launch an internal tool or an internal product and probably 148 00:07:37,656 --> 00:07:41,516 got zero adoption. Oftentimes it's not a technical 149 00:07:41,516 --> 00:07:42,726 problem. Sometimes it is. 150 00:07:42,816 --> 00:07:44,436 You know, we all know sometimes it is. 151 00:07:44,706 --> 00:07:47,746 But often it's they're totally missing the storytelling 152 00:07:47,746 --> 00:07:49,806 element. You know, why should I use this 153 00:07:49,806 --> 00:07:51,898 tool? Where does this tool fit into my 154 00:07:51,898 --> 00:07:54,233 universe? And it just... 155 00:07:54,233 --> 00:07:58,876 It seemed like such an odd shift but it's been such a naturally 156 00:07:58,876 --> 00:08:02,558 perfect thing to be able to tell some of these stories. 157 00:08:02,868 --> 00:08:06,794 To speak to a platform leader, understand their problem, and 158 00:08:06,794 --> 00:08:09,618 then translate it to an engineer or vice versa. 159 00:08:09,978 --> 00:08:13,300 Speak to a developer, understand their pain, and then translate 160 00:08:13,300 --> 00:08:17,667 it to a product person or to a leader who are thinking in 161 00:08:17,667 --> 00:08:19,148 completely different terminology, completely 162 00:08:19,148 --> 00:08:21,982 different language. It's really the that 163 00:08:21,982 --> 00:08:25,738 storytelling side that, you know, blew my mind how valuable 164 00:08:25,738 --> 00:08:27,348 it could be and how useful it would be. 165 00:08:27,788 --> 00:08:29,438 That's really where the shift happened for me. 166 00:08:30,394 --> 00:08:32,394 Yeah, so it sounds like you are the perfect guest today. 167 00:08:32,394 --> 00:08:35,594 So a little bit of acting background for storytelling. 168 00:08:36,344 --> 00:08:37,794 You need to be careful. I'll talk too much. 169 00:08:37,854 --> 00:08:41,635 Yeah. Someone who is also deep in the 170 00:08:41,635 --> 00:08:44,150 platform engineering community, talking to a lot of leaders 171 00:08:44,150 --> 00:08:48,540 every day, every week, right? And also someone who is, who has 172 00:08:48,540 --> 00:08:50,694 the technical background, technical capability to actually 173 00:08:50,694 --> 00:08:53,123 know the stuff required for platform engineering. 174 00:08:53,603 --> 00:08:56,326 But before we dive deep into strategy, you know, how to 175 00:08:56,326 --> 00:08:59,765 adopt, how to sell platform engineering, we know that the 176 00:08:59,765 --> 00:09:02,483 term platform itself is a bit convoluted, right? 177 00:09:02,693 --> 00:09:06,053 Many different people associate platform with many different 178 00:09:06,053 --> 00:09:08,699 things. Not to mention also vendors try 179 00:09:08,699 --> 00:09:11,813 to sell their platform. So whatever platform it is. 180 00:09:11,963 --> 00:09:15,542 So maybe by definition first, how would you describe a 181 00:09:15,542 --> 00:09:18,173 platform and what is platform engineering essentially? 182 00:09:18,940 --> 00:09:21,463 Sure. So I think the simpler way to 183 00:09:21,463 --> 00:09:25,104 look at it. There's specific definitions for 184 00:09:25,104 --> 00:09:27,970 platform engineering. But really platform engineering 185 00:09:27,970 --> 00:09:31,730 is just the treatment of an internal platform. 186 00:09:31,940 --> 00:09:35,450 And platform could be a catch-all term for service, 187 00:09:35,450 --> 00:09:38,976 collection of tooling. It's to treat that tooling like 188 00:09:38,976 --> 00:09:41,510 a product. That's really the simplest way 189 00:09:41,510 --> 00:09:44,660 to think about it and I will go into more detail on that. 190 00:09:45,470 --> 00:09:47,850 Now platform is a really confusing term. 191 00:09:48,570 --> 00:09:51,458 You know, Meta has a platform, Facebook is a platform, 192 00:09:51,458 --> 00:09:55,102 Salesforce is a platform. I understand that's totally 193 00:09:55,102 --> 00:09:57,680 confusing. So we tend to use the term 194 00:09:57,680 --> 00:10:01,419 internal developer platform, so like IDP for short because it's 195 00:10:01,419 --> 00:10:06,456 that internal platform which is the conglomeration of all the 196 00:10:06,456 --> 00:10:10,573 tech, the tools, the services, combined together with an 197 00:10:10,573 --> 00:10:13,300 abstraction layer on top to serve developers. 198 00:10:13,940 --> 00:10:17,948 Now in the last, you know, few months and years, it's grown 199 00:10:17,948 --> 00:10:21,124 beyond developers to include, you know, SREs and data 200 00:10:21,124 --> 00:10:24,020 engineers and especially with AI, now with agents. 201 00:10:24,410 --> 00:10:28,186 But really you should just think about platform engineering as 202 00:10:28,186 --> 00:10:32,062 the discipline of treating an internal, like an internal 203 00:10:32,062 --> 00:10:36,202 service like a product. And when I say like a product 204 00:10:36,202 --> 00:10:39,345 think about like a SaaS product, any SaaS product that you've 205 00:10:39,345 --> 00:10:42,605 ever used. It probably has a name, it 206 00:10:42,605 --> 00:10:46,181 probably has documentation, it has customer success, it has 207 00:10:46,181 --> 00:10:49,145 product managers. And that's what really 208 00:10:49,145 --> 00:10:51,935 differentiates platform engineering from say DevOps or 209 00:10:51,935 --> 00:10:54,635 SRE. People will talk about the goal 210 00:10:54,635 --> 00:10:57,389 of platform engineering and you'll have someone who's, you 211 00:10:57,389 --> 00:11:00,555 know, very familiar with the philosophy of DevOps be like 212 00:11:00,555 --> 00:11:04,913 well, I already do automation. You know, I already think about 213 00:11:04,913 --> 00:11:06,305 self-service workflows for developers. 214 00:11:07,655 --> 00:11:10,247 Sure. But are you thinking about those 215 00:11:10,247 --> 00:11:14,325 things like you are a product manager and the developers are 216 00:11:14,325 --> 00:11:16,685 your customer? Are you doing user research? 217 00:11:16,745 --> 00:11:19,475 Are you interviewing your developers on the workflows? 218 00:11:19,865 --> 00:11:22,913 That's the big differentiator between what is platform 219 00:11:22,913 --> 00:11:25,025 engineering and what is not platform engineering. 220 00:11:25,345 --> 00:11:28,667 And I can really say, you know, I'll have conversations with 221 00:11:28,667 --> 00:11:31,070 people at conferences and I'll be like, hey, what do you do? 222 00:11:31,160 --> 00:11:33,710 Oh I'm a platform engineer. I'm like, awesome. 223 00:11:33,800 --> 00:11:36,957 You know how do you decide what features tp add to your 224 00:11:36,957 --> 00:11:38,474 platform? I'm like, oh, well, you're doing 225 00:11:38,474 --> 00:11:39,770 platform as a product? No. 226 00:11:40,370 --> 00:11:42,325 Okay. How do you decide what features 227 00:11:42,325 --> 00:11:44,688 to add to the platform? Oh we just have some beers and 228 00:11:44,688 --> 00:11:47,046 we decide. Okay, so you're not a platform 229 00:11:47,046 --> 00:11:49,780 engineer. You know, you're probably just 230 00:11:49,780 --> 00:11:53,320 an operations team who has now renamed themselves platform 231 00:11:53,320 --> 00:11:55,850 engineering. And that's really the key 232 00:11:55,850 --> 00:11:58,769 differentiator that I think anyone here listening needs to 233 00:11:58,769 --> 00:12:01,099 think about. If you are treating your 234 00:12:01,099 --> 00:12:03,905 internal service like a product then you're probably doing 235 00:12:03,905 --> 00:12:07,145 platform engineering. If you're not, then you aren't 236 00:12:07,145 --> 00:12:11,016 doing platform engineering yet. Yeah, I like the angle that you 237 00:12:11,016 --> 00:12:13,042 mentioned, you know, treating platform as a product, right? 238 00:12:13,042 --> 00:12:16,419 Because I'm sure many people try to adopt so-called platform or 239 00:12:16,419 --> 00:12:18,372 platform engineering within their organizations, but not 240 00:12:18,372 --> 00:12:20,512 many actually treat them as a product, right? 241 00:12:20,512 --> 00:12:22,132 It could be just a top-down approach. 242 00:12:22,432 --> 00:12:24,932 Maybe this is the latest cool trend, people just wanna 243 00:12:24,932 --> 00:12:27,206 implement that. And yeah, not treating it as a 244 00:12:27,206 --> 00:12:29,667 product. But I think before we go into 245 00:12:29,667 --> 00:12:32,977 that, right, why is it such a craze these days that people 246 00:12:32,977 --> 00:12:34,402 want to adopt platform engineering? 247 00:12:34,402 --> 00:12:37,476 Because in the past, maybe I don't know, 10 years ago, people 248 00:12:37,476 --> 00:12:39,352 do not actually talk about platform. 249 00:12:39,442 --> 00:12:41,873 They maybe talk more about cloud, you know, maybe 250 00:12:41,873 --> 00:12:44,309 integrating SaaS product. And I feel actually cloud is 251 00:12:44,309 --> 00:12:47,725 kind of like one of the biggest success stories of a platform or 252 00:12:47,725 --> 00:12:49,374 platform engineering, right? Oh yeah. 253 00:12:49,374 --> 00:12:52,961 So why all the craze these days about, you know, every 254 00:12:52,961 --> 00:12:54,817 organizations want to adopt platform engineering? 255 00:12:55,734 --> 00:12:59,124 Well I think, you know, there's a fantastic graphic that you can 256 00:12:59,124 --> 00:13:02,630 find somewhere but I will verbalize the graphic for the 257 00:13:02,630 --> 00:13:05,049 audience. And it's when you think about if 258 00:13:05,049 --> 00:13:08,155 you are a developer, what you had to do 10 years ago. 259 00:13:08,755 --> 00:13:11,935 Or we're in 2025 now, so I'll say 15 years ago. 260 00:13:13,255 --> 00:13:16,969 Time's moving too fast, Henry. So 15 years ago, you think about 261 00:13:16,969 --> 00:13:21,489 what was in the remit of a developer. 9 out of 10 times it 262 00:13:21,489 --> 00:13:24,365 was just writing code. There probably wasn't that much 263 00:13:24,365 --> 00:13:27,325 tooling, maybe one or two tools they had to use. 264 00:13:27,685 --> 00:13:29,845 Your organization was not containerized. 265 00:13:29,875 --> 00:13:32,425 Certainly not. There was no 266 00:13:32,425 --> 00:13:34,939 infrastructure-as-code. If you were using the cloud you 267 00:13:34,939 --> 00:13:37,645 were probably a very fast mover, you almost certainly weren't. 268 00:13:37,915 --> 00:13:41,905 So the expectations for you as a developer were very minimal. 269 00:13:42,355 --> 00:13:46,172 Now that also came with a kind of throw it over the fence 270 00:13:46,172 --> 00:13:48,200 mentality. DevOps hadn't really caught on 271 00:13:48,200 --> 00:13:53,030 yet in most organizations. So, you know, you had a much 272 00:13:53,030 --> 00:13:57,215 simpler remit as a developer. What that meant was a 273 00:13:57,215 --> 00:13:59,275 considerable less amount of cognitive load. 274 00:13:59,665 --> 00:14:02,035 There was less challenge when onboarding. 275 00:14:02,035 --> 00:14:04,015 It's like, okay, if you're, you just need to learn some 276 00:14:04,015 --> 00:14:05,905 languages, maybe one or two tools. 277 00:14:06,355 --> 00:14:09,205 Onboarding a person to that or finding people you can onboard 278 00:14:09,205 --> 00:14:13,710 quickly is not too challenging. Now zoom into today, or 279 00:14:13,710 --> 00:14:17,022 certainly two or three years ago before platform engineering 280 00:14:17,022 --> 00:14:20,785 really took off, what does a developer have to learn? 281 00:14:20,875 --> 00:14:24,775 You know, a new hire at Netflix. How much, how many tools do they 282 00:14:24,775 --> 00:14:28,253 need to learn? I mean we did a survey in 2022 283 00:14:28,253 --> 00:14:31,595 and the average new tooling a developer had to onboard to was 284 00:14:31,595 --> 00:14:35,850 12. 12 new tools. And, you know, these are not, 285 00:14:35,850 --> 00:14:38,567 oh, great, here we go I can just one click button. 286 00:14:38,567 --> 00:14:40,577 It's not like a ChatGPT interface. 287 00:14:40,847 --> 00:14:43,367 You know, it's 12 very complicated tools. 288 00:14:43,367 --> 00:14:45,747 Probably a significant amount of ClickOps. 289 00:14:45,767 --> 00:14:49,449 You're probably not able to just, you know, code base CLI 290 00:14:49,449 --> 00:14:51,587 for everything. You're probably having to 291 00:14:51,587 --> 00:14:53,147 navigate through a bunch of tools. 292 00:14:53,147 --> 00:14:56,027 Maybe you're having to learn bits of Argo, bits of Terraform 293 00:14:56,587 --> 00:15:00,767 because, oh, this little item. Ah, it's easier, you know, we 294 00:15:00,767 --> 00:15:03,183 shift left. Let's just have the developer do 295 00:15:03,183 --> 00:15:04,967 it themselves. Oh, they want an S3 bucket? 296 00:15:04,967 --> 00:15:08,623 Well, let's, you know they can go into the AWS cloud console 297 00:15:08,623 --> 00:15:10,327 themselves. This is insane. 298 00:15:11,257 --> 00:15:15,884 You know, it's totally insane. And we all know I don't need to 299 00:15:15,884 --> 00:15:20,080 talk about how great DevOps is. I think anybody listening knows 300 00:15:20,080 --> 00:15:23,532 that DevOps was fantastic. At the time, it made perfect 301 00:15:23,532 --> 00:15:27,408 sense, but you get a very muddled sense of what DevOps is 302 00:15:27,408 --> 00:15:32,004 supposed to be in 2023 when the average developer now has to 303 00:15:32,004 --> 00:15:37,052 deal with 10 tools, possibly even multi-cloud consoles. 304 00:15:37,262 --> 00:15:39,156 They're having to deal themselves with bits of 305 00:15:39,156 --> 00:15:40,472 Terraform. This is insane! 306 00:15:41,222 --> 00:15:45,564 Makes onboarding impossible. It also makes the cognitive load 307 00:15:45,564 --> 00:15:48,312 that's on that one developer impossible. 308 00:15:48,752 --> 00:15:52,326 It also creates a huge overreliance on senior 309 00:15:52,326 --> 00:15:55,709 developers. Because if you think, I'm a 310 00:15:55,709 --> 00:15:59,217 junior dev, I don't really know Terraform, yeah, I need to do 311 00:15:59,217 --> 00:16:01,121 this thing. Well, I'm gonna Slack message or 312 00:16:01,121 --> 00:16:03,137 I'm gonna Teams message someone who can help me. 313 00:16:03,727 --> 00:16:07,037 And so now you've got your highest paid developer make 314 00:16:07,037 --> 00:16:10,996 real, the people making the big bucks, having to spend two, 315 00:16:10,996 --> 00:16:14,387 three hours a day doing these shadow ops work. 316 00:16:15,197 --> 00:16:17,987 It's not tenable. So that's really where the 317 00:16:17,987 --> 00:16:19,547 platform engineering story came from. 318 00:16:19,547 --> 00:16:22,347 And there have been people doing platform engineering for 10 319 00:16:22,347 --> 00:16:24,457 years, just not calling it platform engineering. 320 00:16:25,027 --> 00:16:29,597 But it wasn't something that was like absolutely necessary. 321 00:16:29,777 --> 00:16:33,055 It was kind of an accelerator for fast movers or like a good 322 00:16:33,055 --> 00:16:36,846 idea to improve things. But we get to the territory now, 323 00:16:36,846 --> 00:16:40,247 you know, kind of 2021 and beyond where it's mandatory. 324 00:16:40,827 --> 00:16:44,387 You can't have devs dealing with this current system anymore. 325 00:16:44,387 --> 00:16:47,177 It just, the system is imploding in and itself. 326 00:16:47,447 --> 00:16:50,123 And so having something like an internal developer platform 327 00:16:50,123 --> 00:16:55,172 where you take those 10 tools, integrate them into one IDP, put 328 00:16:55,172 --> 00:16:59,213 a single interface over it, and now your developers just dealing 329 00:16:59,213 --> 00:17:02,049 with one interface. That can be a code-based 330 00:17:02,049 --> 00:17:04,368 interface. It could even be a neural 331 00:17:04,368 --> 00:17:06,794 language interface or natural language interface that could 332 00:17:06,794 --> 00:17:08,227 just be using Claude or something. 333 00:17:08,767 --> 00:17:12,791 And now you're able to have the developer onboard faster, less 334 00:17:12,791 --> 00:17:15,916 cognitive load, less likelihood of mistakes. 335 00:17:15,977 --> 00:17:18,883 I mean, think about, you know, I'm using Terraform as a big 336 00:17:18,883 --> 00:17:21,885 example here cause I was just working with a team who's having 337 00:17:21,885 --> 00:17:25,211 lots of Terraform problems. Think about how many 338 00:17:25,211 --> 00:17:28,693 unstandardized Terraform files your organization might have if 339 00:17:28,693 --> 00:17:31,805 every developer is having to make some of their own Terraform 340 00:17:31,805 --> 00:17:34,076 files. Platform engineering would 341 00:17:34,076 --> 00:17:36,627 standardize all of those. It would give you templates 342 00:17:36,627 --> 00:17:38,747 within the platform that they would have to use. 343 00:17:39,047 --> 00:17:42,611 So you can see immediately the security benefits, the 344 00:17:42,611 --> 00:17:45,377 governance benefits, the observability benefits. 345 00:17:46,127 --> 00:17:49,801 And then when I answer your next question why is things 346 00:17:49,801 --> 00:17:53,557 accelerating so much now? Take every single problem I've 347 00:17:53,557 --> 00:17:58,557 just mentioned, add AI onto it, and you see it's a 10x bigger 348 00:17:58,557 --> 00:18:02,295 problem now. AI makes every single one of 349 00:18:02,295 --> 00:18:07,395 these issues 10x worse. 10 times more bad Terraform files, a 100x 350 00:18:07,395 --> 00:18:10,697 more clunky code, 10 times more security problems. 351 00:18:11,087 --> 00:18:13,857 And that's where platform engineering has really shined 352 00:18:13,857 --> 00:18:18,483 over the last six months. You know, I was just at AWS 353 00:18:18,483 --> 00:18:23,203 Reinvent and you can see for every booth, every talk that has 354 00:18:23,203 --> 00:18:27,428 AI as the headline, it's platform engineering as the core 355 00:18:27,428 --> 00:18:31,001 content within there. Cause it's the thing that lets 356 00:18:31,001 --> 00:18:33,827 you do AI safely, AI effectively, move fast. 357 00:18:34,097 --> 00:18:37,067 So there we go. The big answer to your short 358 00:18:37,067 --> 00:18:40,324 question but that's a question that's really on my mind and I 359 00:18:40,324 --> 00:18:41,927 think is important for people to understand. 360 00:18:43,116 --> 00:18:45,456 Yeah, I find it's such a great overview, right? 361 00:18:45,456 --> 00:18:48,382 So you mentioned, kind of like all the pain, the problems that 362 00:18:48,382 --> 00:18:50,392 engineers these days are experiencing. 363 00:18:50,542 --> 00:18:52,552 So for example, cognitive load, right? 364 00:18:53,092 --> 00:18:56,392 So we are always kind of like thankful for all the modern 365 00:18:56,392 --> 00:18:57,952 technologies and toolings available. 366 00:18:57,952 --> 00:19:01,296 But also with the amount of options that we have now, the 367 00:19:01,296 --> 00:19:04,528 pace of change, the advancement, not to mention with the addition 368 00:19:04,528 --> 00:19:06,742 of AI. So we need to learn more, we 369 00:19:06,742 --> 00:19:08,949 need to do more. In fact, to deliver a single 370 00:19:08,949 --> 00:19:12,099 piece of software or even a single line of code, it's not as 371 00:19:12,099 --> 00:19:15,911 easy as, you know, just deploy one command or you push a button 372 00:19:15,911 --> 00:19:18,789 and it gets deployed, right? And I would say the expectations 373 00:19:18,789 --> 00:19:22,289 also changed a lot since maybe, I don't know, 15, 20 years ago. 374 00:19:22,289 --> 00:19:25,453 We don't really software as frequent as now, but we now have 375 00:19:25,453 --> 00:19:28,328 the DORA metrics saying that you have to deploy, you know, 376 00:19:28,328 --> 00:19:31,357 multiple times a day. So that kind of like creates an 377 00:19:31,357 --> 00:19:34,353 expectation for you to easily deploy software or make some 378 00:19:34,353 --> 00:19:36,614 changes into your, you know, ecosystem, right? 379 00:19:36,944 --> 00:19:39,629 So I think the challenge of platform engineering definitely 380 00:19:39,629 --> 00:19:41,940 is huge. And a lot of developers, 381 00:19:41,940 --> 00:19:44,862 especially in big organizations, you mentioned about security, 382 00:19:44,862 --> 00:19:48,420 standardization, guardrails, and now with AI governance and all 383 00:19:48,420 --> 00:19:50,782 that, I think it's very compelling to have platform 384 00:19:50,782 --> 00:19:52,948 engineering. So we talk about the role. 385 00:19:52,948 --> 00:19:56,303 You mentioned about SRE, DevOps, and now we have platform 386 00:19:56,303 --> 00:19:58,876 engineer. Are there any differences in 387 00:19:58,876 --> 00:20:01,198 terms of, you know, skillset, capabilities? 388 00:20:01,198 --> 00:20:02,548 How would you differentiate all this? 389 00:20:02,548 --> 00:20:04,378 Because, again, it's a convoluted term. 390 00:20:04,708 --> 00:20:09,368 People call DevOps engineer, some companies called SRE, and 391 00:20:09,388 --> 00:20:12,298 some called platform engineers. It's such a confusing place now. 392 00:20:12,880 --> 00:20:16,017 Yeah and I think, you know, organizations are always 393 00:20:16,017 --> 00:20:17,985 terrible with this terminology stuff. 394 00:20:18,015 --> 00:20:21,081 I mean you can still, you can go on LinkedIn right now and you 395 00:20:21,081 --> 00:20:24,641 can search for DevOps engineer and you can find a job that's 396 00:20:24,641 --> 00:20:28,320 actually an SRE or is actually just an ops person or is 397 00:20:28,320 --> 00:20:30,885 actually a platform engineer but it's called DevOps engineer. 398 00:20:30,915 --> 00:20:33,805 And it's the same for SRE, it's the same for platform engineer. 399 00:20:34,085 --> 00:20:37,125 So it's very hard for new joiners for sure. 400 00:20:37,923 --> 00:20:41,103 But if I lay the three out next to each other, like I said kind 401 00:20:41,103 --> 00:20:44,019 of at the beginning, the key differentiator for platform 402 00:20:44,019 --> 00:20:46,833 engineer is the product mindset element. 403 00:20:47,049 --> 00:20:49,152 It's the product management stuff. 404 00:20:49,212 --> 00:20:53,018 So if you are someone who is, you know, working in ops, you 405 00:20:53,018 --> 00:20:56,738 have the DevOps philosophy, you really believe in it, platform 406 00:20:56,738 --> 00:21:00,012 engineering is just adding product management to that. 407 00:21:00,312 --> 00:21:04,179 Now you don't have to become a genius product manager yourself, 408 00:21:04,179 --> 00:21:08,031 but you do need to understand some of these core components of 409 00:21:08,031 --> 00:21:10,512 product management. That's the big differentiator. 410 00:21:10,882 --> 00:21:14,182 When you look at what are the the coding languages, what are 411 00:21:14,182 --> 00:21:18,570 the tools, you know, what are the concept familiarity, it's 412 00:21:18,570 --> 00:21:22,277 95% the same between SRE, platform engineering, and 413 00:21:22,277 --> 00:21:24,726 DevOps. The core difference is that 414 00:21:24,726 --> 00:21:27,087 platform engineering has the product management side. 415 00:21:27,507 --> 00:21:29,737 And I think it's a very, very, very key difference. 416 00:21:30,367 --> 00:21:34,257 You know, it solves a lot of the challenges that organizations 417 00:21:34,257 --> 00:21:38,059 have had with DevOps. You know, it's, failing is a 418 00:21:38,059 --> 00:21:41,835 strong word but the majority of organizations are failing at 419 00:21:41,835 --> 00:21:44,231 DevOps. The majority of organizations 420 00:21:44,231 --> 00:21:47,678 are failing at SRE. You know, I talk to teams all 421 00:21:47,678 --> 00:21:50,385 the time and they're like ah, you know, we're trying to do 422 00:21:50,385 --> 00:21:52,552 SRE, it's not working. I'm like well where do you get 423 00:21:52,552 --> 00:21:56,022 your best practices? From the SRE book, of course. 424 00:21:56,172 --> 00:21:59,502 And I'm like you're not Google. You are not Google. 425 00:21:59,652 --> 00:22:03,102 You don't have Google resources. You don't have Google money, and 426 00:22:03,102 --> 00:22:06,675 you don't have Google culture. So why are you trying to do 427 00:22:06,675 --> 00:22:08,622 Google SRE without any of those things? 428 00:22:08,652 --> 00:22:12,072 Of course, it's failing and it's the exact same thing for DevOps. 429 00:22:12,072 --> 00:22:15,507 I talk to teams every single day who are like DevOps has been a 430 00:22:15,507 --> 00:22:18,071 disaster for us. And I'm I go through and it's 431 00:22:18,071 --> 00:22:20,382 like well, they're not really doing very good DevOps. 432 00:22:20,652 --> 00:22:24,072 So it's you can't blame DevOps for it to an extent. 433 00:22:24,492 --> 00:22:29,252 But that I see is such a problem so often with DevOps and with 434 00:22:29,252 --> 00:22:31,108 SRE. And platform engineering really 435 00:22:31,108 --> 00:22:33,942 aims to solve that. That's where the product 436 00:22:33,942 --> 00:22:37,209 management side comes into it. Yeah, again, I like your 437 00:22:37,209 --> 00:22:39,099 emphasis of adding the product mindset, right? 438 00:22:39,099 --> 00:22:41,589 So think of it just like the, in the beginning you mentioned 439 00:22:41,589 --> 00:22:44,611 about adding features, right? Do you decide it over a beer or 440 00:22:44,611 --> 00:22:47,049 just a chat, casual chat within between colleagues? 441 00:22:47,259 --> 00:22:50,991 Or do you actually put like user mindset, user research, user 442 00:22:50,991 --> 00:22:53,139 pain problems, you know, you're trying to solve? 443 00:22:53,349 --> 00:22:54,699 I think that's a key mindset thing. 444 00:22:55,089 --> 00:22:59,101 And, and you mentioned about, you know, people adopting SRE by 445 00:22:59,101 --> 00:23:02,119 following, you know, I dunno, Google or maybe other big 446 00:23:02,119 --> 00:23:03,549 companies, Amazon, whatever that is. 447 00:23:03,549 --> 00:23:05,139 I think that's also true in the market, right? 448 00:23:05,139 --> 00:23:08,658 We always love to find Silver Bullet and especially also 449 00:23:08,658 --> 00:23:11,785 vendors, consultants, trying to sell, you know, the best way of 450 00:23:11,785 --> 00:23:14,973 doing something. And I think you mentioned before 451 00:23:14,973 --> 00:23:19,065 we chat that actually all these tools, frameworks, and all that 452 00:23:19,065 --> 00:23:21,789 actually don't really matter. And in fact, you validate that 453 00:23:21,789 --> 00:23:24,399 by talking to, you know, hundreds of engineering leaders 454 00:23:24,399 --> 00:23:25,396 out there. Oh yeah. 455 00:23:25,419 --> 00:23:28,531 So tell us, this, I think these insights because people still 456 00:23:28,531 --> 00:23:32,675 think we need to find a silver bullet, we need to find a tools, 457 00:23:32,675 --> 00:23:35,757 framework, platforms out there that we can just plug and play 458 00:23:35,757 --> 00:23:37,599 into our organization that then it'll work. 459 00:23:37,629 --> 00:23:40,179 So maybe tell us why this is such, such a trap. 460 00:23:40,701 --> 00:23:44,520 When you say everybody thinks that tools is the problem, I 461 00:23:44,520 --> 00:23:46,821 will say everybody thinks that tools is the problem. 462 00:23:47,601 --> 00:23:50,639 But it isn't. You know, every person who isn't 463 00:23:50,639 --> 00:23:54,363 a leader or isn't leading a platform team or isn't an 464 00:23:54,363 --> 00:23:57,381 experienced platform engineer thinks, oh, tech and tools. 465 00:23:57,501 --> 00:24:00,298 I get asked by junior people about tech and tools all the 466 00:24:00,298 --> 00:24:03,096 time. But I talked to around it's like 467 00:24:03,096 --> 00:24:05,541 390 or something. I round it up to 400. 468 00:24:05,601 --> 00:24:09,322 So spoilers for anyone, you know, for everyone listening 469 00:24:09,322 --> 00:24:11,613 it's around 390. While the year's not over yet 470 00:24:11,613 --> 00:24:14,403 maybe we'll get to 400. But around 390 platform 471 00:24:14,403 --> 00:24:17,339 engineering leaders and engineering leaders this year, 472 00:24:17,339 --> 00:24:22,214 one person said that tooling, a technological problem was their 473 00:24:22,214 --> 00:24:23,969 problem. They couldn't find enough people 474 00:24:23,969 --> 00:24:26,161 who are experienced with Kubernetes in their hiring. 475 00:24:26,851 --> 00:24:29,121 That was their one one technological problem. 476 00:24:29,481 --> 00:24:32,961 But overwhelmingly, the problems aren't tools. 477 00:24:34,131 --> 00:24:36,921 The problems will often be culture. 478 00:24:37,131 --> 00:24:39,921 Overwhelmingly, it will be organizational challenges. 479 00:24:40,191 --> 00:24:43,721 It will be training, it will be documentation, it'll be product 480 00:24:43,721 --> 00:24:47,019 management issues. And there are tooling 481 00:24:47,019 --> 00:24:50,013 challenges, of course. If you think about some of the 482 00:24:50,013 --> 00:24:51,411 AI tooling challenges teams are having. 483 00:24:51,861 --> 00:24:56,127 You know, procurement is not designed for how fast new tools 484 00:24:56,127 --> 00:24:59,961 are coming, how fast tools are improving, and how fast tools 485 00:24:59,961 --> 00:25:03,417 are being replaced. If you think about an enterprise 486 00:25:03,417 --> 00:25:06,776 procurement lifecycle, you know, it it could take like six 487 00:25:06,776 --> 00:25:09,177 months. And the idea is that they wanna 488 00:25:09,177 --> 00:25:11,571 lock in a tool for two to three years. 489 00:25:12,411 --> 00:25:16,011 That doesn't work when an AI tool I pick now could be 490 00:25:16,011 --> 00:25:19,605 replaced in a month. You know, that sounds like a 491 00:25:19,605 --> 00:25:21,701 tooling problem. And someone might be like, oh 492 00:25:21,701 --> 00:25:23,816 well that's the tool problem. Tools are getting better or 493 00:25:23,816 --> 00:25:26,121 worse. No, it's a culture problem. 494 00:25:26,451 --> 00:25:31,154 Your culture hasn't adapted to an environment of being able to 495 00:25:31,154 --> 00:25:33,861 experiment with new tooling in a safe way. 496 00:25:34,311 --> 00:25:37,881 So that you can be like, okay, this is the best in class tool 497 00:25:37,881 --> 00:25:40,359 right now. Let's play around with it and 498 00:25:40,359 --> 00:25:44,024 then find out in a month. Okay, it wasn't the tool that we 499 00:25:44,024 --> 00:25:45,561 wanted. We need to experiment with 500 00:25:45,561 --> 00:25:47,501 something else. That's a culture problem. 501 00:25:48,121 --> 00:25:49,881 That's not a problem with the tools. 502 00:25:50,181 --> 00:25:53,733 That's that our cultures are not able to keep up with how fast 503 00:25:53,733 --> 00:25:57,045 things are moving now. And that's really, you know, I 504 00:25:57,045 --> 00:25:59,481 keep harping back to this product idea. 505 00:26:00,051 --> 00:26:03,172 When you think about a product, a product doesn't have a 506 00:26:03,172 --> 00:26:06,756 deadline on it. It doesn't, you know, Facebook 507 00:26:06,756 --> 00:26:10,581 doesn't end on January 1st. You don't get, you know, it's 508 00:26:10,581 --> 00:26:11,691 constant. It's living. 509 00:26:12,051 --> 00:26:14,391 It keeps getting updated. It keeps changing. 510 00:26:14,631 --> 00:26:17,601 You have to keep thinking about is this the best it can be. 511 00:26:17,901 --> 00:26:20,137 Is this some. Are there modules that should be 512 00:26:20,137 --> 00:26:21,676 swapped out? Are there things that should 513 00:26:21,676 --> 00:26:23,586 change? And your organization can be 514 00:26:23,586 --> 00:26:26,521 thought about this as well. And it's always the cultural 515 00:26:26,521 --> 00:26:28,551 things that are the big challenge there. 516 00:26:29,001 --> 00:26:32,871 So when I talk to a lot of these engineering leaders what are the 517 00:26:32,871 --> 00:26:34,491 types of problems that they're having. 518 00:26:34,671 --> 00:26:37,401 Well, shared language is a really big one. 519 00:26:37,611 --> 00:26:40,491 That's something that we have touched on extensively here. 520 00:26:40,971 --> 00:26:45,111 The head of platform or the VP engineering might be like, okay 521 00:26:45,231 --> 00:26:47,271 platform engineering I really get it. 522 00:26:47,481 --> 00:26:50,168 You know, I know platform is a product, I understand all of 523 00:26:50,168 --> 00:26:52,251 this. But then their whole team is, 524 00:26:52,251 --> 00:26:55,056 you know, thinking DevOps, thinking SRE, doesn't understand 525 00:26:55,056 --> 00:26:56,961 it. That's a big problem. 526 00:26:57,201 --> 00:27:00,801 Or even worse when we get into like granularity of details. 527 00:27:01,041 --> 00:27:02,691 They're thinking, oh, we have a platform. 528 00:27:02,691 --> 00:27:04,941 You know, we use AWS cloud console. 529 00:27:05,001 --> 00:27:08,361 Or, you know, Kubernetes is a platform, isn't it, technically? 530 00:27:08,361 --> 00:27:10,711 So we have Kubernetes. That's our platform. 531 00:27:11,291 --> 00:27:14,815 It's like, this is where you need to think about these shared 532 00:27:14,815 --> 00:27:18,459 language ideas. And then, of course, it's things 533 00:27:18,459 --> 00:27:22,096 like getting buy-in. Getting buy-in is always going 534 00:27:22,096 --> 00:27:25,970 to be the number one problem. Now that can be, if you're, you 535 00:27:25,970 --> 00:27:29,286 know, someone like you and I and you want to get the CTO, you 536 00:27:29,286 --> 00:27:32,286 wanna get the money for your organization, getting the buy-in 537 00:27:32,286 --> 00:27:35,524 from your executives or from your leadership, that is where a 538 00:27:35,524 --> 00:27:39,228 lot of people struggle. But a lot of the time when I 539 00:27:39,228 --> 00:27:41,466 talk to these engineering leaders their boss gets it. 540 00:27:41,466 --> 00:27:43,746 They're like awesome. You know, this is fantastic. 541 00:27:43,866 --> 00:27:46,920 It's getting buy-in from from more junior people getting 542 00:27:46,920 --> 00:27:50,008 adoption of the platform. It's like we've built this 543 00:27:50,008 --> 00:27:51,306 amazing platform. It's fantastic. 544 00:27:51,306 --> 00:27:54,636 We gave it a cool name. No one's using it. 545 00:27:54,636 --> 00:27:57,570 What's the problem? You know, it's those types of 546 00:27:57,570 --> 00:28:00,834 cultural challenges which are the things that really, really, 547 00:28:00,834 --> 00:28:04,806 really challenge teams. It's never the tool that they're 548 00:28:04,806 --> 00:28:07,461 using. It's never, oh, did we use the 549 00:28:07,461 --> 00:28:11,243 right, you know, CI/CD tooling? It's is the culture around our 550 00:28:11,243 --> 00:28:14,186 CI/CD able to get the most out of it. 551 00:28:14,576 --> 00:28:18,526 So really that's the key thing. Key takeaway I think from any 552 00:28:18,526 --> 00:28:20,811 talk I've ever done, that's what people should get from it. 553 00:28:22,854 --> 00:28:24,354 Yeah, again, it's to emphasize, right? 554 00:28:24,354 --> 00:28:26,874 It's not about tooling, it's not about the tech stack that you 555 00:28:26,874 --> 00:28:29,409 have within the organization. It's not about Kubernetes at 556 00:28:29,409 --> 00:28:31,218 all. So, right, it's more about like, 557 00:28:31,218 --> 00:28:33,972 you know, your mindset, your culture, your adoption, your 558 00:28:33,972 --> 00:28:37,344 product thinking, right? So I think, if you're still 559 00:28:37,344 --> 00:28:40,338 thinking platform is something that you can just buy, procure, 560 00:28:40,338 --> 00:28:43,194 and implement in your organization, I think that's 561 00:28:43,194 --> 00:28:44,964 probably one of the biggest trap. 562 00:28:45,624 --> 00:28:48,774 And that's why probably your, your so-called project, platform 563 00:28:48,774 --> 00:28:50,754 engineering does not succeed, right? 564 00:28:50,994 --> 00:28:53,270 And you talk about, you know, many many organizations are 565 00:28:53,270 --> 00:28:56,446 failing and I think, probably the first one I would assume 566 00:28:56,446 --> 00:28:59,112 that, you know, thinking, building a platform as a 567 00:28:59,112 --> 00:29:01,746 project, right? So it's like, okay, we have a 568 00:29:01,746 --> 00:29:05,274 goal of, I don't know, implement something within a year. 569 00:29:06,084 --> 00:29:10,512 So tell us, how should the leaders actually pitch, pitch it 570 00:29:10,512 --> 00:29:13,569 differently, because I'm sure when people want to, you know, 571 00:29:13,569 --> 00:29:18,026 so called, put a budget upfront about we, hey, we wanna build a 572 00:29:18,026 --> 00:29:19,314 platform within our organization. 573 00:29:19,554 --> 00:29:21,474 They'll think, okay, this is a timeline, right? 574 00:29:22,134 --> 00:29:24,624 But actually you mentioned if we treat it as a product, it's 575 00:29:24,624 --> 00:29:27,843 actually a continuous evolution and it'll always evolve over the 576 00:29:27,843 --> 00:29:29,526 time. So I think this is the first 577 00:29:29,526 --> 00:29:31,356 thing. Maybe if you can enlighten us, 578 00:29:31,356 --> 00:29:34,576 how do we actually pitch it differently as a product instead 579 00:29:34,576 --> 00:29:39,371 of a project? Well, I think the two things I 580 00:29:39,371 --> 00:29:41,641 would say there is the immediate answer. 581 00:29:42,036 --> 00:29:46,226 The first one is that you probably have some form of 582 00:29:46,226 --> 00:29:48,381 platform already. You're just not treating one 583 00:29:48,381 --> 00:29:50,991 like it's a product and you're not thinking about it in that 584 00:29:50,991 --> 00:29:52,674 way. You know, I always talk about 585 00:29:52,674 --> 00:29:55,536 how if you don't build your platform, it'll build itself. 586 00:29:55,896 --> 00:30:01,206 And so you probably have your it kind of disjointed CI/CD. 587 00:30:01,206 --> 00:30:04,416 There's probably some kind of DevOps philosophy workflows. 588 00:30:04,416 --> 00:30:06,915 There's probably some observability stuff that's maybe 589 00:30:06,915 --> 00:30:09,306 a bit disconnected or maybe it is connected. 590 00:30:09,426 --> 00:30:13,044 It's just not being thought of in that kind of platform way 591 00:30:13,044 --> 00:30:16,344 with that product mindset. So one of the first things I 592 00:30:16,344 --> 00:30:17,796 would do is identify those things. 593 00:30:18,562 --> 00:30:22,135 And then the second part is really thinking about starting 594 00:30:22,135 --> 00:30:24,502 small. Really start small. 595 00:30:24,502 --> 00:30:27,964 So we talk a lot about this concept of a minimum viable 596 00:30:27,964 --> 00:30:31,237 platform. When you're talking about 597 00:30:31,237 --> 00:30:34,513 platform engineering and these big cultural changes, it sounds 598 00:30:34,513 --> 00:30:37,873 very scary. And it also clearly seems like 599 00:30:37,873 --> 00:30:40,327 you could incorporate so much into it. 600 00:30:40,747 --> 00:30:43,747 You're like oh my God, we could take the entire CI/CD. 601 00:30:43,747 --> 00:30:45,277 We could put all of that in there. 602 00:30:45,277 --> 00:30:48,200 We can put the AI stuff. We can put all the security 603 00:30:48,200 --> 00:30:49,747 stuff. Well, we can have the data 604 00:30:49,747 --> 00:30:52,051 platform built into it. And then suddenly you're like 605 00:30:52,051 --> 00:30:54,307 wow, wow, okay. This is now three year timeline. 606 00:30:54,307 --> 00:30:58,417 It's a huge org transformation. I need 10 million to do this. 607 00:30:59,347 --> 00:31:01,857 Everything's gonna implode immediately. 608 00:31:02,437 --> 00:31:06,645 Really think small. Think about, okay, what is a 609 00:31:06,645 --> 00:31:08,917 sample app? What is a pioneer team? 610 00:31:08,977 --> 00:31:12,247 What's the first way to really think about this in a small way? 611 00:31:12,577 --> 00:31:15,772 Give yourself like, okay, we're gonna spend four weeks 612 00:31:15,772 --> 00:31:19,336 onboarding a sample app, getting that on demonstrating how this 613 00:31:19,336 --> 00:31:22,087 abstracted layer within the platform improves whatever 614 00:31:22,087 --> 00:31:27,003 target thing you're looking at. The target thing is gonna be key 615 00:31:27,003 --> 00:31:29,764 to your organization. It will be different in your org 616 00:31:29,764 --> 00:31:32,116 versus in mine. I think testing is a great 617 00:31:32,116 --> 00:31:34,677 landscape to look at. Onboarding is a good landscape 618 00:31:34,677 --> 00:31:37,696 to look at. You know, if there's kind of 619 00:31:37,696 --> 00:31:40,612 ticket ops, there's issues with your ticket flow and your CI/CD, 620 00:31:40,612 --> 00:31:44,038 that's a good thing to look at, but it could be completely 621 00:31:44,038 --> 00:31:47,938 different for you. And then identify that kind of 622 00:31:47,938 --> 00:31:52,150 one easy thing on a sample app that's architecture looks the 623 00:31:52,150 --> 00:31:55,812 same as 90% of the rest of the organization or your org. 624 00:31:56,392 --> 00:31:59,872 And then absolutely nail that. Do that. 625 00:32:00,082 --> 00:32:03,881 Do it very well. Get all the data you need to 626 00:32:03,881 --> 00:32:06,760 improve. Figure out how this cultural 627 00:32:06,760 --> 00:32:09,892 process works, how thinking about it as a product works. 628 00:32:10,537 --> 00:32:13,679 You know, get these developer interviews, build that muscle 629 00:32:13,679 --> 00:32:16,187 for yourself. And then expand from there. 630 00:32:16,807 --> 00:32:21,712 I can tell you you will go 10 times faster than if you try and 631 00:32:21,712 --> 00:32:25,067 get the entire state of your organization on board 632 00:32:25,067 --> 00:32:29,113 immediately. Everyone I know who starts like 633 00:32:29,113 --> 00:32:33,495 outrageously small, and then scales up in an MVP manner, ends 634 00:32:33,495 --> 00:32:36,817 up being significantly further ahead than the people who try 635 00:32:36,817 --> 00:32:40,487 and do everything at once. It also makes it way easier to 636 00:32:40,487 --> 00:32:43,237 get buy-in. If you're coming and saying 637 00:32:43,237 --> 00:32:46,777 like, hey I need half a million for two months. 638 00:32:46,957 --> 00:32:49,937 This is what we're gonna do, that's a lot easier than being 639 00:32:49,957 --> 00:32:53,973 like, yeah, we probably need like 5 million a year for three 640 00:32:53,973 --> 00:32:55,977 years. And then after three years, 641 00:32:55,977 --> 00:32:59,696 we'll see what happens. Really think small and then grow 642 00:32:59,696 --> 00:33:02,307 big from there is always my advice. 643 00:33:04,080 --> 00:33:07,578 So I think the thinking small, right, building the MVP relates 644 00:33:07,578 --> 00:33:10,470 back to how you think of a platform as a product, right? 645 00:33:10,470 --> 00:33:13,020 Because we always talk about building minimum viable product. 646 00:33:13,530 --> 00:33:17,430 Start small, iterate, learn from the users, learn from the 647 00:33:17,430 --> 00:33:19,230 experience. I think that's always kind of 648 00:33:19,230 --> 00:33:21,240 like the biggest product mindset that people can adopt. 649 00:33:21,360 --> 00:33:24,660 And I like what you mentioned about, you know, somehow either 650 00:33:24,660 --> 00:33:28,142 we realize or not realize we do have something already running 651 00:33:28,142 --> 00:33:31,068 in the organization, right? It could be some tooling that we 652 00:33:31,068 --> 00:33:32,940 use, could, could be some process we used. 653 00:33:33,000 --> 00:33:35,412 And in fact, if I'm not mistaken, I learned from Team 654 00:33:35,412 --> 00:33:37,308 Topologies that the term platform itself doesn't always 655 00:33:37,308 --> 00:33:39,910 mean, you know, you have to implement something or use a 656 00:33:39,910 --> 00:33:41,750 product. It could be just a simple wiki 657 00:33:41,750 --> 00:33:44,990 that you mentioned as a kind of like processes, how we do stuff. 658 00:33:45,320 --> 00:33:48,090 That could be a start of the platform, right? 659 00:33:48,090 --> 00:33:51,230 So I think don't try to overcomplicate things by, you 660 00:33:51,230 --> 00:33:54,180 know, building a roadmap like three years, five years. 661 00:33:54,480 --> 00:33:59,136 So yeah, always think small and try to measure, how the, the 662 00:33:59,136 --> 00:34:01,410 platform has benefited the organization, right? 663 00:34:01,650 --> 00:34:04,644 Which is my next question because sometimes it's very 664 00:34:04,644 --> 00:34:07,712 difficult, first, to put forth the project, the budget, right, 665 00:34:07,712 --> 00:34:10,080 to get, you know, in the first place. 666 00:34:10,260 --> 00:34:13,282 And how to measure the success of this platform engineering, 667 00:34:13,282 --> 00:34:16,715 you know, the ROI. So what are the typical 668 00:34:16,715 --> 00:34:19,820 measurements that you think will be useful for organizations to, 669 00:34:19,820 --> 00:34:24,480 you know, think about or try to aspire towards, right, so that 670 00:34:24,480 --> 00:34:27,449 they know that their platform engineering effort actually is 671 00:34:27,449 --> 00:34:30,346 successful. Well, the very obvious 672 00:34:30,346 --> 00:34:33,802 non-answer at the beginning is that you need to measure at all. 673 00:34:35,782 --> 00:34:39,797 You know, when I, we did our state of platform engineering 674 00:34:39,797 --> 00:34:42,646 report. It's coming out next week and we 675 00:34:42,646 --> 00:34:48,489 did one last year as well. And last year, 44% of those who 676 00:34:48,489 --> 00:34:50,572 responded didn't measure anything. 677 00:34:51,456 --> 00:34:52,777 They didn't measure a single thing. 678 00:34:52,777 --> 00:34:55,897 That's almost half of platform teams weren't measuring. 679 00:34:56,556 --> 00:35:01,897 So it's no surprise that when we ask them about ROI, improvement, 680 00:35:02,107 --> 00:35:05,254 developer productivity, success of their platforms, they're like 681 00:35:05,254 --> 00:35:07,087 either they're like, oh, I have no idea. 682 00:35:07,357 --> 00:35:11,545 Or it wasn't going well. And of course, if you're not 683 00:35:11,545 --> 00:35:13,597 measuring, how can you improve anything? 684 00:35:13,987 --> 00:35:17,669 Now there's lots of frameworks for measuring which are really 685 00:35:17,669 --> 00:35:19,545 great. You know, DORA, of course, it's 686 00:35:19,545 --> 00:35:22,959 a bit of a leading indicator, but really looking at the DORA 687 00:35:22,959 --> 00:35:26,437 metrics are is good. SPACE framework is great as 688 00:35:26,437 --> 00:35:29,002 well. But I'll kind of break it down 689 00:35:29,002 --> 00:35:32,152 rather than just the framework of measuring, more how you 690 00:35:32,152 --> 00:35:34,327 should think about measuring in general. 691 00:35:34,477 --> 00:35:38,257 Because it's such a wide topic. It's super confusing. 692 00:35:38,257 --> 00:35:41,617 It's also not often a head space that engineers work in. 693 00:35:42,427 --> 00:35:45,618 You know, it's why the platform product manager role having 694 00:35:45,618 --> 00:35:49,537 someone who really gets that world is quite crucial to your 695 00:35:49,537 --> 00:35:52,717 platform team. And when you think about 696 00:35:52,717 --> 00:35:55,987 measuring, use that MVP idea that we thought about. 697 00:35:56,197 --> 00:35:58,477 What is the thing that you are focusing on? 698 00:35:58,867 --> 00:36:02,227 If you're focusing on 50 different things, obviously, 699 00:36:02,227 --> 00:36:03,937 you're not gonna be able to measure. 700 00:36:04,207 --> 00:36:06,607 Because you've got 50 different things that you're looking at. 701 00:36:06,907 --> 00:36:10,519 So you will have no idea the impact of the platform on any of 702 00:36:10,519 --> 00:36:12,067 those. It'll be too overwhelming. 703 00:36:12,337 --> 00:36:14,317 Trying to get a baseline will be impossible. 704 00:36:14,617 --> 00:36:18,067 But if we just take a simple thing like onboarding. 705 00:36:18,847 --> 00:36:21,547 Onboarding is somewhere where I see lots of success. 706 00:36:21,817 --> 00:36:25,027 So I talked to an organization about a month ago. 707 00:36:25,357 --> 00:36:29,489 It took about four and a half weeks for a new developer to 708 00:36:29,489 --> 00:36:33,169 push a single commit. They were quite, you know, four 709 00:36:33,169 --> 00:36:37,207 and a half weeks is not too long but it's not particularly short. 710 00:36:37,687 --> 00:36:39,577 And they wanted it to be way shorter. 711 00:36:39,817 --> 00:36:44,082 So the platform team focused, okay, this is the next area of 712 00:36:44,082 --> 00:36:45,847 feature set that we're gonna focus on. 713 00:36:46,177 --> 00:36:49,683 So they thought about what are all the things that make it 714 00:36:49,683 --> 00:36:53,077 difficult for a developer to do that first commit. 715 00:36:53,197 --> 00:36:56,167 And they found most of it was compliance stuff. 716 00:36:56,497 --> 00:36:58,995 It was because they would ha, they would write the code, the 717 00:36:58,995 --> 00:37:01,667 code would then need to get checked by someone but then that 718 00:37:01,667 --> 00:37:03,277 check would go into a ticketing flow. 719 00:37:03,277 --> 00:37:05,917 The ticketing flow would go to someone that would go on their 720 00:37:05,917 --> 00:37:07,813 list. Once it was on that person's 721 00:37:07,813 --> 00:37:10,902 list, it would take a long time for them to get to it, because 722 00:37:10,902 --> 00:37:13,825 it wasn't a low prio. It wasn't being marked in a 723 00:37:13,825 --> 00:37:15,187 particularly high priority or not. 724 00:37:15,577 --> 00:37:19,769 So when you think about measurement, they had a really 725 00:37:19,769 --> 00:37:23,352 clear target. We know that it takes four and a 726 00:37:23,352 --> 00:37:26,077 half weeks for a developer to push that first commit. 727 00:37:26,077 --> 00:37:29,527 They wanted to get it down to sub-seven days. 728 00:37:30,172 --> 00:37:33,202 Okay, so now they have their measuring baseline. 729 00:37:34,072 --> 00:37:37,222 That isn't necessarily DORA, that's not SPACE. 730 00:37:37,222 --> 00:37:41,820 That's not, but it's a really simple way to think about 731 00:37:41,820 --> 00:37:46,632 improvement and ROI. Now the ROI question becomes, 732 00:37:46,632 --> 00:37:51,252 okay, this is probably something that your product manager role. 733 00:37:51,622 --> 00:37:55,492 But when you think about what is the value that a developer adds? 734 00:37:56,242 --> 00:37:59,112 How much does a developer cost per month is often an easy way 735 00:37:59,112 --> 00:38:02,398 to go about it. You can do the cost element and 736 00:38:02,398 --> 00:38:05,872 you're like, okay, we hire a hundred developers per month. 737 00:38:05,962 --> 00:38:07,732 Their average cost per month is this. 738 00:38:07,792 --> 00:38:10,582 That lost month of coding time costs this. 739 00:38:10,972 --> 00:38:11,962 Bam. There you go. 740 00:38:12,202 --> 00:38:14,612 There's a number you can give to an executive. 741 00:38:15,202 --> 00:38:17,452 Usually, that's the less sexy number. 742 00:38:17,542 --> 00:38:21,220 The sexier number would be, you know, how much value is added 743 00:38:21,220 --> 00:38:23,082 per month. And you can quantify those 744 00:38:23,082 --> 00:38:27,383 things. You can see how I've taken a 745 00:38:27,383 --> 00:38:31,729 wide universe of possibility and just broken it down really 746 00:38:31,729 --> 00:38:35,200 simply into one metric. And it's like for this feature, 747 00:38:35,200 --> 00:38:38,572 you know, for this problem, the measurement for that problem is 748 00:38:38,572 --> 00:38:42,502 we wanna reduce from four and a half weeks to whatever that 749 00:38:42,502 --> 00:38:45,706 reduction time is. And when you think about going 750 00:38:45,706 --> 00:38:48,952 into a conversation about budget for your platform to secure 751 00:38:48,952 --> 00:38:52,658 budget, to show improvement, and you're like, well, I can just 752 00:38:52,658 --> 00:38:55,994 show on a slide with bright colors and a nice arrow pointing 753 00:38:55,994 --> 00:38:57,917 in. Executives love stuff like that. 754 00:38:58,702 --> 00:39:00,592 You can show it was four and a half weeks. 755 00:39:00,802 --> 00:39:04,052 Now it's seven days. Developer time costs this. 756 00:39:04,572 --> 00:39:08,062 This is the estimated increase in in benefit from that. 757 00:39:08,407 --> 00:39:09,547 Bam. There you go. 758 00:39:09,757 --> 00:39:12,287 What an incredibly valuable feature that you've done. 759 00:39:12,997 --> 00:39:15,817 Now you can use DORA, you can use SPACE to help you think 760 00:39:15,817 --> 00:39:18,217 about how you think you structure those types of 761 00:39:18,217 --> 00:39:20,395 measurements. But that's really the way that I 762 00:39:20,395 --> 00:39:24,028 would approach it. And it also forces you to think 763 00:39:24,028 --> 00:39:27,565 small and think specific. Cause if you've got 25 things 764 00:39:27,565 --> 00:39:31,302 you wanna focus on, you're never gonna be able to do any of what 765 00:39:31,302 --> 00:39:33,792 I just suggested. So it's probably a pretty good 766 00:39:33,792 --> 00:39:36,827 sign you're thinking about too much stuff if you are not able 767 00:39:36,827 --> 00:39:39,007 to do that one example that I've just given there. 768 00:39:41,330 --> 00:39:43,360 Yeah, so focus is the key, right? 769 00:39:43,360 --> 00:39:46,576 So if you build, especially if you come from nothing, right, or 770 00:39:46,576 --> 00:39:49,390 if you come from a non organized platform, right? 771 00:39:49,390 --> 00:39:51,670 So always thinking in terms of focus. 772 00:39:51,970 --> 00:39:54,534 What is the biggest user pain point that you're solving, 773 00:39:54,534 --> 00:39:55,960 right? And try to focus on that. 774 00:39:56,680 --> 00:39:58,060 And when you mentioned about all these, right? 775 00:39:58,060 --> 00:40:01,285 I remember my conversation also with, you know, the DX team, the 776 00:40:01,285 --> 00:40:04,510 developer experience team. Sometimes you don't even need to 777 00:40:04,510 --> 00:40:07,030 come up with like a measurement number, metrics, right? 778 00:40:07,030 --> 00:40:09,430 It could be a perception from developers, you know, thinking 779 00:40:09,430 --> 00:40:12,649 about how you do onboarding, how you deploy software, how painful 780 00:40:12,649 --> 00:40:13,990 it is, right? Yeah. 781 00:40:14,200 --> 00:40:17,770 So that could also be a metric. And I think I wanna also 782 00:40:17,770 --> 00:40:20,170 mention, since you've mentioned about storytelling, right? 783 00:40:20,235 --> 00:40:23,791 I, I, we can, we can see just now when you mentioned about how 784 00:40:23,791 --> 00:40:26,860 you actually put forth the, the kind of like the story for you 785 00:40:26,860 --> 00:40:28,010 to start this platform engineering. 786 00:40:28,030 --> 00:40:29,410 I think that's also very important. 787 00:40:29,590 --> 00:40:32,130 How do you sell the story such that, you know, people 788 00:40:32,130 --> 00:40:34,300 understand the benefits of this platform engineering? 789 00:40:34,540 --> 00:40:37,210 So I think we can see all these, in, in play, right? 790 00:40:37,210 --> 00:40:40,870 So the, the product thinking, the storytelling, and the 791 00:40:40,870 --> 00:40:44,913 developer experience aspect. So speaking about, you know, 792 00:40:44,913 --> 00:40:48,214 building a platform, right? I know that you mentioned it is 793 00:40:48,214 --> 00:40:51,575 never ending, but people these days mention this term called 794 00:40:51,575 --> 00:40:53,847 Golden Path. You know, this is like, also 795 00:40:53,847 --> 00:40:55,725 another buzzword in the platform engineering thing. 796 00:40:56,145 --> 00:40:59,139 What is Golden Path in your view, and is it something that 797 00:40:59,139 --> 00:41:02,621 is kind of like the only way of doing something within the 798 00:41:02,621 --> 00:41:05,555 organization, meaning that in an organization you should not have 799 00:41:05,555 --> 00:41:07,515 different options of, you know, doing stuff? 800 00:41:07,815 --> 00:41:09,525 So tell us, what is this golden path? 801 00:41:10,332 --> 00:41:12,607 You can see I felt so strongly about that that I started 802 00:41:12,607 --> 00:41:17,468 shaking my head preemptively. So a simple way to think about a 803 00:41:17,468 --> 00:41:22,017 golden path is really to break it down is like, it's the either 804 00:41:22,017 --> 00:41:25,717 it's the best route one could take to do something. 805 00:41:26,137 --> 00:41:31,597 So if you have two options for pushing out code, one option is 806 00:41:31,597 --> 00:41:35,509 you just do your own kind of disconnected IDE, maybe 807 00:41:35,509 --> 00:41:38,043 you're... Or actually, I'm gonna give a 808 00:41:38,043 --> 00:41:40,867 very, a very clear example, which any engineering leader 809 00:41:40,867 --> 00:41:44,207 listening to is right now. And we'll talk about AI tooling. 810 00:41:44,847 --> 00:41:50,066 So AI tooling, probably your enterprise forces you to use 811 00:41:50,066 --> 00:41:53,185 Copilot. Most enterprises force people to 812 00:41:53,185 --> 00:41:56,694 use Copilot. Copilot is not the best of the 813 00:41:56,694 --> 00:42:00,325 AI tools, you know, it's great but comparatively it's not the 814 00:42:00,325 --> 00:42:03,781 best. So when you start to go and 815 00:42:03,781 --> 00:42:07,812 track AI usage in relation to people emailing themselves stuff 816 00:42:07,812 --> 00:42:11,542 from ChatGPT or from Cursor, you see it's huge. 817 00:42:11,962 --> 00:42:15,322 The number of developers emailing themselves code that 818 00:42:15,322 --> 00:42:20,088 they have generated with Cursor or with with ChatGPT and then 819 00:42:20,088 --> 00:42:25,372 they copy it from their email into their ID at work. 820 00:42:26,212 --> 00:42:28,822 That is absolutely, you know, that's what we would consider 821 00:42:28,822 --> 00:42:31,274 like an anti-pattern. That's a very negative thing to 822 00:42:31,274 --> 00:42:35,062 happen. So you can see we are ripe for a 823 00:42:35,062 --> 00:42:39,566 golden path there. Now you can see that is a really 824 00:42:39,566 --> 00:42:43,242 problematic route. Using Copilot is too strict. 825 00:42:43,272 --> 00:42:46,784 If forcing the usage of Copilot, that's too strict and it's 826 00:42:46,784 --> 00:42:49,642 causing people to go off path in a negative way. 827 00:42:50,362 --> 00:42:56,307 Well, a golden path there might be, okay, let's identify why do 828 00:42:56,307 --> 00:42:59,952 we have to use Copilot. Because we're able to enforce 829 00:42:59,952 --> 00:43:02,332 all of our governance, all of our guardrails. 830 00:43:02,572 --> 00:43:05,839 It prevents people from, you know, blowing up the 831 00:43:05,839 --> 00:43:07,592 organization or doing anything too crazy. 832 00:43:08,232 --> 00:43:12,749 Well, how about use a cloud development environment to allow 833 00:43:12,749 --> 00:43:16,372 people to experiment with other tools within the CDE. 834 00:43:17,302 --> 00:43:20,107 And now you have all the governance, you have all the 835 00:43:20,107 --> 00:43:22,181 guardrails. And people are allowed to use 836 00:43:22,181 --> 00:43:25,265 the tools that they want without the risk to the rest of the 837 00:43:25,265 --> 00:43:27,462 enterprise. That would be a golden path. 838 00:43:27,862 --> 00:43:31,462 People are able to use Copilot, if they would like. 839 00:43:31,912 --> 00:43:34,372 They could use the Copilot directly in the enterprise. 840 00:43:34,732 --> 00:43:38,471 Or they can use the AI tooling that's provided within the cloud 841 00:43:38,471 --> 00:43:41,015 development environment that lets them do everything that 842 00:43:41,015 --> 00:43:44,930 they wanted to do, but with all of the enforcement, all the 843 00:43:44,930 --> 00:43:47,662 safety, it's a disconnected box from the system. 844 00:43:48,472 --> 00:43:52,932 Now this doesn't stop people from emailing themselves code 845 00:43:52,932 --> 00:43:55,042 from ChatGPT. But why would they? 846 00:43:55,462 --> 00:43:58,872 They don't need to, because they can just use the ChatGPT 847 00:43:58,872 --> 00:44:01,816 directly within the CDE. They get all the benefit that 848 00:44:01,816 --> 00:44:04,606 they wanted. And so you've removed an 849 00:44:04,606 --> 00:44:07,222 anti-pattern. You've removed a risk vector by 850 00:44:07,222 --> 00:44:11,349 giving people a better option. That's the concept of golden 851 00:44:11,349 --> 00:44:14,859 path. It's like, you know, how do you 852 00:44:14,859 --> 00:44:16,762 enforce ima, container image scanning. 853 00:44:17,152 --> 00:44:20,400 Well, you could write a rule and say it's mandatory that you scan 854 00:44:20,400 --> 00:44:23,934 all your container images. Or you could just build it 855 00:44:23,934 --> 00:44:27,544 directly into the workflow, so that when they, you know, when 856 00:44:27,544 --> 00:44:30,770 something gets committed, you know, there is within the 857 00:44:30,770 --> 00:44:33,901 platform the container image gets scanned itself 858 00:44:33,901 --> 00:44:36,622 automatically by design. Developer doesn't have to think 859 00:44:36,622 --> 00:44:38,512 about it and that's a golden path. 860 00:44:38,812 --> 00:44:40,982 They can do it manually if they'd like to. 861 00:44:41,742 --> 00:44:44,541 You know, there, there's a developer who really prefers 862 00:44:44,541 --> 00:44:46,642 doing things themselves. They like their own way. 863 00:44:46,942 --> 00:44:51,442 They have the ability to go off path, but why would they because 864 00:44:51,442 --> 00:44:53,002 the golden path is so much better. 865 00:44:53,332 --> 00:44:56,012 That's really the key way to to think about it. 866 00:44:56,552 --> 00:44:59,136 You know, there's a fantastic quote from Gregor Hohpe who 867 00:44:59,136 --> 00:45:01,132 wrote a wonderful book, Platform Strategy. 868 00:45:01,132 --> 00:45:03,562 I'm not sure if you've had him on the podcast but if you should 869 00:45:03,562 --> 00:45:06,292 definitely get him on here. He's, we love him in the 870 00:45:06,292 --> 00:45:09,862 platform engineering community. You know, this idea of golden 871 00:45:09,862 --> 00:45:13,462 path versus golden cages. And he has this wonderful 872 00:45:13,462 --> 00:45:18,112 illustration of the golden path is basically this great highway. 873 00:45:18,112 --> 00:45:20,092 It's got some guard rails on the side. 874 00:45:20,212 --> 00:45:23,872 And you've got your formula one car zipping down that highway. 875 00:45:24,322 --> 00:45:26,752 And then the other path, it's not closed. 876 00:45:26,962 --> 00:45:29,142 You can still go on it if you want. 877 00:45:29,842 --> 00:45:33,487 But it's rocky, it's bumpy, it doesn't have the guardrails. 878 00:45:33,727 --> 00:45:37,237 So it's why would you, as a developer, ever want to use the 879 00:45:37,237 --> 00:45:39,187 worst path, when you've got the golden one? 880 00:45:39,317 --> 00:45:43,714 So that's really the concept. It's a reframing of how we think 881 00:45:43,714 --> 00:45:45,877 about things like compliance like governance. 882 00:45:46,687 --> 00:45:49,963 Obviously, there's always gonna be the things where you have to 883 00:45:49,963 --> 00:45:53,137 enforce stuff. The golden path can't just be 884 00:45:53,137 --> 00:45:56,482 use Cursor however you want totally randomly within the 885 00:45:56,482 --> 00:45:57,967 organization. Obviously not. 886 00:45:58,207 --> 00:46:01,327 But it's thinking about a way that you can get all of the 887 00:46:01,327 --> 00:46:04,447 compliance and governance without needing to just enforce 888 00:46:04,447 --> 00:46:10,207 it and then cause these kind of off-path anti-patterns. 889 00:46:10,265 --> 00:46:13,545 Wow, I think, you kind of like put a lot of insights into this 890 00:46:13,545 --> 00:46:15,135 definition of Golden Path, right? 891 00:46:15,135 --> 00:46:18,151 So one thing for sure, Golden Path is not the same as Golden 892 00:46:18,151 --> 00:46:20,457 Cage, right? So it's not like a mandatory, 893 00:46:20,457 --> 00:46:24,165 like a forced mandatory way for people to, you know, implement 894 00:46:24,165 --> 00:46:26,049 something. It's, first of all, it's the 895 00:46:26,049 --> 00:46:29,467 best option for them. And the best, if you, you can 896 00:46:29,467 --> 00:46:33,175 make it such, such, such that it's easy for people to adopt 897 00:46:33,175 --> 00:46:35,655 without even sometimes knowing it is there. 898 00:46:35,955 --> 00:46:39,243 Or for example, they have to put a lot of efforts to just follow 899 00:46:39,243 --> 00:46:41,811 the golden path. I think this is also very 900 00:46:41,811 --> 00:46:44,454 important because I can see many organization when they adopt 901 00:46:44,454 --> 00:46:46,365 this platform engineering, so to speak, right? 902 00:46:46,665 --> 00:46:49,317 They kind of like enforce everybody to follow without 903 00:46:49,317 --> 00:46:51,435 thinking actually about the developer experience, right? 904 00:46:51,435 --> 00:46:55,010 So someone having to go through that path, even though it's 905 00:46:55,010 --> 00:46:58,554 painful. So in in a, in the consequence 906 00:46:58,554 --> 00:47:01,386 of the adoption, right? People want a high adoption, but 907 00:47:01,386 --> 00:47:03,660 actually they don't care about the developer experience. 908 00:47:03,900 --> 00:47:05,400 So thanks for mentioning about this. 909 00:47:05,610 --> 00:47:08,435 And yeah, I've got Gregor Hohpe a long time ago actually talking 910 00:47:08,490 --> 00:47:10,890 about platform engineering. So always fun to chat with him. 911 00:47:12,240 --> 00:47:17,095 So, I know that recently you had this PlatformCon, Platform 912 00:47:17,095 --> 00:47:20,500 Conference, you know, for 2025, and you kind of like summarize 913 00:47:20,500 --> 00:47:23,130 it in, you know, one YouTube video that I saw, right? 914 00:47:23,130 --> 00:47:24,840 There are five key takeaways from that. 915 00:47:25,170 --> 00:47:27,873 So maybe, if you don't mind just sharing us a little bit high 916 00:47:27,873 --> 00:47:30,510 level, what are some of these key takeaways that you think are 917 00:47:30,510 --> 00:47:34,050 important for us to understand within 2025, right? 918 00:47:34,920 --> 00:47:36,330 So yeah, maybe let's start from there. 919 00:47:37,542 --> 00:47:39,592 And I'll just, I have them written down, so I make sure I 920 00:47:39,592 --> 00:47:42,759 read exactly what they were. I know I gave that talk, but 921 00:47:42,759 --> 00:47:44,887 obviously sometimes I forget exactly what I said. 922 00:47:45,517 --> 00:47:49,863 So for those who don't know Platform Con is really the only 923 00:47:49,863 --> 00:47:52,507 platform engineering focused conference in the world. 924 00:47:52,837 --> 00:47:56,991 And it really tries to to focus in, you know, KubeCon is 925 00:47:56,991 --> 00:47:58,747 awesome. There's 10,000 people there. 926 00:47:58,927 --> 00:48:01,267 Reinvent is amazing, 60,000 people. 927 00:48:01,627 --> 00:48:05,131 But Platform Con is really on those who are like actively 928 00:48:05,131 --> 00:48:07,177 building, actively working on platform engineering. 929 00:48:07,447 --> 00:48:11,347 So you get a lot of like Head of Platform and their whole team, I 930 00:48:11,347 --> 00:48:15,025 mean we had a Dutch bank, who like had 18 platform engineers 931 00:48:15,025 --> 00:48:18,482 in their entire department. They like had printouts of their 932 00:48:18,482 --> 00:48:21,002 like problem statements and they were like asking people like, 933 00:48:21,002 --> 00:48:22,297 hey, how would you help with this? 934 00:48:22,477 --> 00:48:24,877 You know, they're there to learn, how to like grade 935 00:48:24,877 --> 00:48:27,869 themselves, build their roadmap. Like that's really that platform 936 00:48:27,869 --> 00:48:32,143 con energy. And it's also fantastic for me 937 00:48:32,143 --> 00:48:36,867 because almost every kind of, I'll say influencer, a thought 938 00:48:36,867 --> 00:48:39,937 leader in the space gives a talk there, shares their feedback. 939 00:48:40,327 --> 00:48:43,177 And I have conversations with literally hundreds of people 940 00:48:43,177 --> 00:48:47,317 over the, over the two days. So I'm able to get a real sense 941 00:48:47,317 --> 00:48:51,151 of what is key in the community, what's key in the industry, and 942 00:48:51,151 --> 00:48:54,487 this what's key in the kind of the software industry at large. 943 00:48:54,642 --> 00:48:57,342 Cause platform engineering is really one of these leading 944 00:48:57,342 --> 00:49:00,207 items. It's that foundational thing 945 00:49:00,207 --> 00:49:03,542 that all software builds off. It's the same with DevOps. 946 00:49:03,542 --> 00:49:05,720 Same with infrastructure. So platform engineering is that 947 00:49:05,720 --> 00:49:08,762 bucket that a lot of the software industry sits on. 948 00:49:08,762 --> 00:49:11,252 So you can really get a sense of where things are going. 949 00:49:11,732 --> 00:49:16,100 And the kind of big five takeaways that I gathered from 950 00:49:16,100 --> 00:49:20,162 it, were the first was on this platform engineering maturity 951 00:49:20,162 --> 00:49:23,198 point. You know, in 2024, I gave a 952 00:49:23,198 --> 00:49:25,052 panel called What is Platform Engineering. 953 00:49:25,352 --> 00:49:29,085 And then in 2025, I gave a panel on What is Great Platform 954 00:49:29,085 --> 00:49:31,602 Engineering. So most really leading 955 00:49:31,602 --> 00:49:35,202 organizations are not dealing with definitional problems 956 00:49:35,202 --> 00:49:37,603 anymore. They're really dealing with best 957 00:49:37,603 --> 00:49:40,161 practices. You know, you can talk to Ricky 958 00:49:40,161 --> 00:49:42,455 Zachary from ThoughtWorks. I just did a webinar with him 959 00:49:42,455 --> 00:49:44,072 last night. I'd recommend checking it out. 960 00:49:44,622 --> 00:49:48,702 And he already is able to break down, these are the 12 961 00:49:48,702 --> 00:49:51,422 capabilities that you should be starting off with. 962 00:49:51,422 --> 00:49:53,012 You can start off with right away. 963 00:49:53,012 --> 00:49:54,632 You should be building into your platform. 964 00:49:54,632 --> 00:49:58,062 They're the highest ROI items across 90% of organizations. 965 00:49:58,752 --> 00:50:00,272 That was not the case a year ago. 966 00:50:00,572 --> 00:50:04,180 You know, we are in the territory now where the amount 967 00:50:04,180 --> 00:50:07,312 of best practice and things to follow is is very clear. 968 00:50:07,862 --> 00:50:13,100 Then the other point is on this concept of of shifting down, not 969 00:50:13,100 --> 00:50:15,704 left. And, you know, what I like to 970 00:50:15,704 --> 00:50:17,432 call platform engineering eating the world. 971 00:50:17,912 --> 00:50:20,629 So when we first started talking about platform engineering and 972 00:50:20,629 --> 00:50:23,940 most of the conversation here other than some AI stuff has 973 00:50:23,940 --> 00:50:27,378 really been either on the DevOps, DevEx side or a little 974 00:50:27,378 --> 00:50:29,882 bit on that the infrastructure platform engineering side. 975 00:50:30,332 --> 00:50:35,162 We really saw this year things like observability, security, 976 00:50:35,372 --> 00:50:39,327 finops, data all becoming a part of the platform engineering 977 00:50:39,327 --> 00:50:42,022 puzzle. You know, these concepts of 978 00:50:42,022 --> 00:50:44,967 platform engineering are applicable to a data platform 979 00:50:44,967 --> 00:50:48,517 exactly the same way they are to an application developer 980 00:50:48,517 --> 00:50:50,472 platform. It's the same thing. 981 00:50:50,797 --> 00:50:53,971 You treat those internal processes like they're a 982 00:50:53,971 --> 00:50:56,077 product. You think about your data 983 00:50:56,077 --> 00:50:58,695 scientist like they're your customer rather than your 984 00:50:58,695 --> 00:51:00,925 developer. It's exactly the same thing and 985 00:51:00,925 --> 00:51:04,317 we've really been seeing huge success with that at lots of 986 00:51:04,317 --> 00:51:07,375 organizations. And then of course, the AI 987 00:51:07,375 --> 00:51:10,540 point. You know, I wrote a report 988 00:51:10,540 --> 00:51:13,266 called the State of AI in Platform Engineering which came 989 00:51:13,266 --> 00:51:16,726 out a few months ago. And it coincided quite 990 00:51:16,726 --> 00:51:20,482 conveniently with the DORA report from, which was put out 991 00:51:20,482 --> 00:51:22,510 by quite a few people. I think Google are one of the 992 00:51:22,510 --> 00:51:25,477 biggest contributors to that. Conveniently, both of them said 993 00:51:25,477 --> 00:51:27,382 the same thing. That was great. 994 00:51:27,382 --> 00:51:29,287 Would've been awkward if our data was different. 995 00:51:29,847 --> 00:51:34,360 Really on the sym symbiotic relationship between platform 996 00:51:34,360 --> 00:51:39,124 engineering and AI. All of the best and most 997 00:51:39,124 --> 00:51:42,316 successful AI experimentation and initiatives at enterprises 998 00:51:42,316 --> 00:51:45,052 have platform engineering behind them. 999 00:51:45,382 --> 00:51:47,032 You know, I touched on that at the beginning. 1000 00:51:47,092 --> 00:51:50,950 When you go and watch one of the talks at Reinvent last week, you 1001 00:51:50,950 --> 00:51:55,072 know, the Amazon conference. Every talk has AI in the title. 1002 00:51:55,402 --> 00:51:58,874 But what is the foundation layer that they're using to get the 1003 00:51:58,874 --> 00:52:01,200 successful AI? It's platform engineering 1004 00:52:01,200 --> 00:52:04,342 concepts. And this has really, really, 1005 00:52:04,342 --> 00:52:07,366 really massively accelerated the acceptance of platform 1006 00:52:07,366 --> 00:52:09,679 engineering, the onboarding of platform engineering, the 1007 00:52:09,679 --> 00:52:12,178 funding for platform engineering, and that's only 1008 00:52:12,178 --> 00:52:15,693 gonna continue. But then the other half of that 1009 00:52:15,693 --> 00:52:18,502 AI acceleration of platform engineering initiatives 1010 00:52:18,502 --> 00:52:21,843 themselves. You can use AI and agentic 1011 00:52:21,843 --> 00:52:24,532 platforms, agentic workflows, all through the platform. 1012 00:52:24,802 --> 00:52:27,562 All of these things are things that AI can support. 1013 00:52:27,952 --> 00:52:31,488 So when you look at some of the examples I've given today, using 1014 00:52:31,488 --> 00:52:34,534 a platform engineering initiative to make it easier to 1015 00:52:34,534 --> 00:52:38,607 experiment with AI tooling, you know, that's a great example of 1016 00:52:38,607 --> 00:52:40,192 how platform engineering helps AI. 1017 00:52:40,582 --> 00:52:43,702 But then when you think about the ability we have with some 1018 00:52:43,702 --> 00:52:47,002 machine learning stuff, some of the agentic workflows to make 1019 00:52:47,002 --> 00:52:50,422 your platform engineering itself better, you've just got this 1020 00:52:50,422 --> 00:52:53,538 incredible feedback loop. That's gonna make 2016, like 1021 00:52:53,538 --> 00:52:57,214 excuse me, ha teleported back for past, 2026, very, very, 1022 00:52:57,214 --> 00:53:00,200 very, exciting, really. So those are the key things we 1023 00:53:00,200 --> 00:53:02,332 were talking about in Platform Con in June this year. 1024 00:53:03,895 --> 00:53:06,169 Wow! So I can see a lot of new trends 1025 00:53:06,169 --> 00:53:08,365 coming up, right? So first thing is, you mentioned 1026 00:53:08,365 --> 00:53:10,810 about shift down, right? So people have been talking 1027 00:53:10,810 --> 00:53:13,375 about shift left since the DevOps era starting, right? 1028 00:53:13,615 --> 00:53:15,625 So now it's kind of like shifting down, right? 1029 00:53:15,625 --> 00:53:18,529 Thinking about your, the platform beneath, you know, your 1030 00:53:18,529 --> 00:53:20,935 team, your organization, how you run software teams, right? 1031 00:53:21,235 --> 00:53:24,775 So you mentioned about security, observability, finops, data. 1032 00:53:25,075 --> 00:53:28,220 I think that's very crucial. The other thing that I like you 1033 00:53:28,220 --> 00:53:32,235 mentioned is that, you know, AI can be an accelerant, right? 1034 00:53:32,625 --> 00:53:34,755 for people within the organization, right? 1035 00:53:34,755 --> 00:53:38,302 And platform engineering is actually behind what great 1036 00:53:38,302 --> 00:53:41,085 success stories for people using those AI. 1037 00:53:41,445 --> 00:53:43,553 So, which is something that I wanna understand a little bit 1038 00:53:43,553 --> 00:53:46,403 more, right? Because this, trend AI is 1039 00:53:46,403 --> 00:53:50,121 advancing rapidly every day. Probably we hear new invention, 1040 00:53:50,121 --> 00:53:54,285 new tools, new way of working, new protocols being mentioned. 1041 00:53:54,285 --> 00:53:55,905 And you mentioned about agentic workflow. 1042 00:53:55,905 --> 00:53:59,655 So these days, software teams don't just deal with people 1043 00:53:59,655 --> 00:54:02,265 working, you know, together, but also with agents. 1044 00:54:02,805 --> 00:54:05,280 So how do you think the evolution of platform 1045 00:54:05,280 --> 00:54:08,247 engineering now with so-called, for example, agentic workflow or 1046 00:54:08,247 --> 00:54:11,185 maybe MCP protocols available. Or even like security issues 1047 00:54:11,185 --> 00:54:14,445 that seems to be, you know, getting more complex these days. 1048 00:54:14,685 --> 00:54:18,131 So how do you think about this AI component apart from, you 1049 00:54:18,131 --> 00:54:21,047 know, a good AI success stories need a good platform 1050 00:54:21,047 --> 00:54:23,364 engineering, but how can platform engineering itself 1051 00:54:23,364 --> 00:54:27,480 benefits from AI or how can it leverages on some of these 1052 00:54:27,480 --> 00:54:33,502 capabilities these days? We'd have to for some of the 1053 00:54:33,502 --> 00:54:35,362 really clear best practice answers. 1054 00:54:35,392 --> 00:54:37,942 You know, we'll have to wait a few months for that, I think. 1055 00:54:38,332 --> 00:54:41,495 Um you know, this is an area where we're still quite 1056 00:54:41,495 --> 00:54:43,840 immature. But when you think about, you 1057 00:54:43,840 --> 00:54:47,024 know, what is a good platform and what does a good platform 1058 00:54:47,024 --> 00:54:49,369 do. A good platform allows you to 1059 00:54:49,369 --> 00:54:52,090 move fast while still maintaining all your governance 1060 00:54:52,090 --> 00:54:56,266 and all your guardrails. So when you think about that 1061 00:54:56,266 --> 00:54:59,737 kind of core fundamental idea of what successful platform 1062 00:54:59,737 --> 00:55:03,382 engineering is, you can immediately see how that's huge 1063 00:55:03,382 --> 00:55:07,004 for AI. And when you think about all the 1064 00:55:07,004 --> 00:55:09,431 different areas that your platform engineering requires, 1065 00:55:09,431 --> 00:55:13,284 you know, documentation, user research, and even kind of 1066 00:55:13,284 --> 00:55:16,724 simple things like this shared language point, this challenge 1067 00:55:16,724 --> 00:55:20,502 of of communicating. I've seen AI be fantastic for 1068 00:55:20,502 --> 00:55:23,936 the cultural stuff as well. You know, I give advice to 1069 00:55:23,936 --> 00:55:28,192 teams, and they ask like how do I know what is important to my 1070 00:55:28,192 --> 00:55:30,902 executives? And it's like well, actually 1071 00:55:30,902 --> 00:55:35,468 what you can do is just take the annual report of your company, 1072 00:55:35,468 --> 00:55:39,714 put it into ChatGPT and tell it I am a platform engineer who's 1073 00:55:39,714 --> 00:55:42,590 trying to figure out what are the highest priorities for my 1074 00:55:42,590 --> 00:55:45,624 executive team. Please give me advice on what I 1075 00:55:45,624 --> 00:55:48,292 should focus on in terms of my communication about the 1076 00:55:48,292 --> 00:55:50,665 platform. And I guarantee you, it will 1077 00:55:50,665 --> 00:55:53,507 probably give you a really fantastic answer to understand 1078 00:55:53,507 --> 00:55:57,232 what your executives care about. Whether it's churn, whether it's 1079 00:55:57,232 --> 00:56:01,176 ROI, whether it's cost control. You know, you can get that and 1080 00:56:01,176 --> 00:56:04,997 then start to think, aha, okay, how can I, what are the feature 1081 00:56:04,997 --> 00:56:08,455 sets that impact those things? And you can do that on the flip 1082 00:56:08,455 --> 00:56:10,705 side too. Say you've improved something, 1083 00:56:10,705 --> 00:56:14,520 you know, you're able to get an ephemeral environment 80% 1084 00:56:14,520 --> 00:56:16,177 faster. This improves dev time. 1085 00:56:16,177 --> 00:56:19,111 Amazing! Your executive has no idea what 1086 00:56:19,111 --> 00:56:21,647 that means and probably doesn't care about it at all. 1087 00:56:22,357 --> 00:56:25,360 Very rarely. So you can take that feature set 1088 00:56:25,360 --> 00:56:28,810 that you've put in or that data that you've got, put it into 1089 00:56:28,810 --> 00:56:31,912 ChatGPT and say like, hey, I need to communicate about the 1090 00:56:31,912 --> 00:56:36,228 benefits of this to a leadership team that's less technical and 1091 00:56:36,228 --> 00:56:38,900 convince them of the benefits of this platform, what we're 1092 00:56:38,900 --> 00:56:43,038 achieving, and it will help you. So when we think about like 1093 00:56:43,038 --> 00:56:46,565 agentic workflows, there is a lot of obviously technical 1094 00:56:46,565 --> 00:56:48,626 things. We'll be able to get code out 1095 00:56:48,626 --> 00:56:50,734 faster. We'll be able to do code review 1096 00:56:50,734 --> 00:56:53,095 faster. You know, I saw a fantastic demo 1097 00:56:53,095 --> 00:56:55,996 a few weeks ago of directly within Backstage, a developer 1098 00:56:55,996 --> 00:57:00,142 portal, the ability to generate a bunch of code for a problem, 1099 00:57:00,142 --> 00:57:03,562 then have another AI check the code for the problem, make sure 1100 00:57:03,562 --> 00:57:07,498 that it matches all of your prescribed rules, all of your 1101 00:57:07,498 --> 00:57:09,798 security policy. So you've got that policy 1102 00:57:09,798 --> 00:57:12,546 directly within there and then you can push commit right there 1103 00:57:12,546 --> 00:57:15,492 and it goes through. Sure, that's a great technical 1104 00:57:15,492 --> 00:57:18,652 example of how AI will speed things up massively. 1105 00:57:19,102 --> 00:57:23,032 But even the cultural stuff, AI is having a huge advantage 1106 00:57:23,032 --> 00:57:26,276 within platform engineering. So this question that you've 1107 00:57:26,276 --> 00:57:29,510 asked, it's too big. There's too many wonderful 1108 00:57:29,510 --> 00:57:33,444 examples to give. But what I would really say is, 1109 00:57:33,444 --> 00:57:36,802 you know, 2026 is the year of the agentic platform. 1110 00:57:37,102 --> 00:57:39,292 Almost everyone that I know is thinking about them. 1111 00:57:39,292 --> 00:57:41,122 Almost everyone I know is working on them. 1112 00:57:41,452 --> 00:57:46,080 Because lot of the work that a developer could be doing on your 1113 00:57:46,080 --> 00:57:49,372 platform, an agent probably could be doing as well. 1114 00:57:49,852 --> 00:57:52,502 And so if you think about building in those guardrails, 1115 00:57:52,502 --> 00:57:55,728 those best practices for the agent rather than for the 1116 00:57:55,728 --> 00:57:59,392 developer, you start to see a really powerful flywheel there. 1117 00:57:59,542 --> 00:58:02,838 So I think we're gonna see a lot of experimentation on that 1118 00:58:02,838 --> 00:58:04,950 topic. It's just still very immature at 1119 00:58:04,950 --> 00:58:06,898 the moment. And maybe by PlatformCon in June 1120 00:58:06,898 --> 00:58:10,046 we'll be able to have some really cool demos of some of the 1121 00:58:10,046 --> 00:58:11,752 success stories from the last six months. 1122 00:58:13,355 --> 00:58:16,542 It sounds very exciting, you know, you know, knowing the 1123 00:58:16,542 --> 00:58:18,669 possibilities that could happen, you know, within the next one 1124 00:58:18,669 --> 00:58:21,012 year or so, right? And I think that's a very 1125 00:58:21,012 --> 00:58:24,000 powerful tip for you to mention, when you mention that people can 1126 00:58:24,000 --> 00:58:26,690 just put a, for example, financial report or whatever key 1127 00:58:26,690 --> 00:58:28,340 message from the stakeholders, right? 1128 00:58:28,340 --> 00:58:30,925 And you kind of like relate that with your so-called persona, 1129 00:58:30,925 --> 00:58:32,720 right? Maybe like platform engineer. 1130 00:58:33,140 --> 00:58:37,148 And maybe, yeah, AI itself can kind of like analyze and come up 1131 00:58:37,148 --> 00:58:39,390 with some suggestions. I think that's quite a cool tip 1132 00:58:39,390 --> 00:58:43,550 for people to try out. So thinking about, you know, 1133 00:58:43,550 --> 00:58:47,115 accelerant, AI accelerant, one key aspect that people use AI 1134 00:58:47,115 --> 00:58:49,040 these days is actually for development, right? 1135 00:58:49,970 --> 00:58:54,290 There are a lot of productivity thing that people think that AI 1136 00:58:54,290 --> 00:58:57,470 could help a lot. But at the same time, people 1137 00:58:57,470 --> 00:59:00,548 also talking about risk. So for example, many people also 1138 00:59:00,548 --> 00:59:03,980 think that AI could, you know, accelerate the amount of tech 1139 00:59:03,980 --> 00:59:08,438 debt that the organization have. Also the amount of code that 1140 00:59:08,438 --> 00:59:10,670 needs to be churned, gets delivered. 1141 00:59:10,970 --> 00:59:13,970 Do you think this will create like enormous expectations as 1142 00:59:13,970 --> 00:59:19,113 well for software teams and also platform to, in order to deliver 1143 00:59:19,113 --> 00:59:23,625 something even faster, even more secure, even more x, right? 1144 00:59:23,685 --> 00:59:27,307 So what do you think about the danger of this kind of like 1145 00:59:27,307 --> 00:59:29,470 thinking in 10X or even 100X with AI now? 1146 00:59:31,201 --> 00:59:34,037 I think for really the leading platform engineering 1147 00:59:34,037 --> 00:59:37,573 organizations and, you know, kind of any advanced platform 1148 00:59:37,573 --> 00:59:40,155 engineering organization, this is not gonna be a problem at 1149 00:59:40,155 --> 00:59:42,691 all. I think for the organizations 1150 00:59:42,691 --> 00:59:45,745 that are thinking about things like a product, they're thinking 1151 00:59:45,745 --> 00:59:48,326 about things with this governance and guardrails built 1152 00:59:48,326 --> 00:59:51,517 in, they're using an internal developer platform, I don't 1153 00:59:51,517 --> 00:59:54,811 think that this AI generated code problem. 1154 00:59:55,171 --> 00:59:59,123 I can totally understand why for the last six months, it's been a 1155 00:59:59,123 --> 01:00:02,971 huge issue. I can absolutely understand why. 1156 01:00:03,181 --> 01:00:06,855 And I think for the next few months and for some 1157 01:00:06,855 --> 01:00:09,643 organizations who are really struggling to keep up and deal 1158 01:00:09,643 --> 01:00:11,821 with this problem, it will be a big issue. 1159 01:00:12,311 --> 01:00:17,673 But, you know, the lagging growth of AI code review tools 1160 01:00:17,673 --> 01:00:22,666 or AI code checking, those are really starting to pick up now. 1161 01:00:22,726 --> 01:00:28,477 You know, I just gave an example of a demo I saw last week, of a 1162 01:00:28,477 --> 01:00:31,216 really spectacular AI code review tool. 1163 01:00:31,636 --> 01:00:34,771 You know, we have been able to generate code incredibly fast 1164 01:00:34,771 --> 01:00:38,222 but our ability to check that code with AI has not been 1165 01:00:38,222 --> 01:00:41,917 particularly fast. That gap is is closing now and 1166 01:00:41,917 --> 01:00:44,656 it will continue to close through next year. 1167 01:00:45,046 --> 01:00:48,982 And so I, I don't think really based on what I've seen 1168 01:00:48,982 --> 01:00:52,654 conversations I've had with leaders that, you know, 12 to 18 1169 01:00:52,654 --> 01:00:57,006 months from now anyone is really gonna have, not to say anyone, 1170 01:00:57,006 --> 01:01:00,115 organizations will, you know, organizations who are really 1171 01:01:00,115 --> 01:01:01,966 struggling to adapt to the times. 1172 01:01:02,266 --> 01:01:05,806 But I think the majority of kind of faster moving enterprises, 1173 01:01:05,926 --> 01:01:08,776 especially if they're a little bit more technical, then they're 1174 01:01:08,776 --> 01:01:11,266 not gonna have an issue with this going forward. 1175 01:01:12,296 --> 01:01:16,427 Either because they're just going to mandate Copilot and 1176 01:01:16,427 --> 01:01:18,416 they're gonna slow everything down. 1177 01:01:18,746 --> 01:01:23,122 But probably because the rate at which AI is able to check 1178 01:01:23,122 --> 01:01:25,431 itself. And that's a key part of what a 1179 01:01:25,431 --> 01:01:28,514 platform team should be doing. You know, a platform team should 1180 01:01:28,514 --> 01:01:31,016 be able to think about its policy as code. 1181 01:01:31,076 --> 01:01:34,292 Think about it's, you know, what are the key policies that need 1182 01:01:34,292 --> 01:01:36,851 to be checked? What are the key security 1183 01:01:36,851 --> 01:01:38,966 governance frameworks that have to be checked? 1184 01:01:39,236 --> 01:01:42,068 You know, what are the key things the AI should be scanning 1185 01:01:42,068 --> 01:01:44,654 the code for? Should it be making sure that 1186 01:01:44,654 --> 01:01:47,906 the code is not too long? You know, is this the shortest 1187 01:01:47,906 --> 01:01:51,746 code that it could be? And as soon as we start to think 1188 01:01:51,746 --> 01:01:54,646 about those best practices, then it starts to get better. 1189 01:01:54,871 --> 01:01:59,022 And you don't even need, to be honest, at the moment, a new 1190 01:01:59,022 --> 01:02:01,081 fancy AI tool to check the AI code. 1191 01:02:01,081 --> 01:02:04,625 I mean, I was talking to a team who the most advanced AI thing 1192 01:02:04,625 --> 01:02:09,495 that they've been doing is just they have 130 default prompts 1193 01:02:09,495 --> 01:02:13,411 like a prompt library that they've built that really work. 1194 01:02:13,416 --> 01:02:15,091 And then they have sequences of them. 1195 01:02:15,481 --> 01:02:18,694 So that they're prompting after to check the code being like, is 1196 01:02:18,694 --> 01:02:21,381 this the shortest code this could be? 1197 01:02:21,971 --> 01:02:25,651 Is this the most succinct way you could solve this problem? 1198 01:02:26,011 --> 01:02:29,981 And then suddenly you're removing, you know, 20, 30, 40%, 1199 01:02:29,981 --> 01:02:33,931 of the code problems in there. Now that's still an imperfect 1200 01:02:33,931 --> 01:02:35,977 solution. But you can see already that 1201 01:02:35,977 --> 01:02:39,991 we're able to deal with this AI generated mass much faster. 1202 01:02:40,321 --> 01:02:42,901 And so just based on the conversations I have with 1203 01:02:42,901 --> 01:02:46,631 leaders and some of the tooling that I've seen so far, I think 1204 01:02:46,631 --> 01:02:50,542 12 months from now, we'll all be talking about, well, wasn't it 1205 01:02:50,542 --> 01:02:53,144 crazy back then? Rather than still being a 1206 01:02:53,144 --> 01:02:56,599 present problem for us. Yeah. 1207 01:02:56,599 --> 01:02:59,455 I find the key thing here is to actually thinking about the 1208 01:02:59,455 --> 01:03:01,474 governance, right? About the policies that you 1209 01:03:01,474 --> 01:03:05,479 wanna put in place because, you know, as you can speed up things 1210 01:03:05,479 --> 01:03:07,779 faster, right? You wanna think about how would 1211 01:03:07,779 --> 01:03:10,334 you take a break, right? So from that speed, right? 1212 01:03:10,334 --> 01:03:14,588 So for example, you to, to avoid crash, you know, like a very bad 1213 01:03:14,588 --> 01:03:16,670 crash, right? You would need to think about, 1214 01:03:16,670 --> 01:03:18,884 you know, how do you put an emergency brake? 1215 01:03:18,884 --> 01:03:21,509 How do you actually make sure that the velocity is actually 1216 01:03:21,509 --> 01:03:23,798 healthy enough, right? And putting in policies, 1217 01:03:23,798 --> 01:03:25,988 guardrails, I think is very important for engineering 1218 01:03:25,988 --> 01:03:28,708 leaders to think about. And best if you can actually 1219 01:03:28,708 --> 01:03:31,882 automate that as part of the workflow and process such that, 1220 01:03:31,882 --> 01:03:35,534 you know, people can have it checked out of the box. 1221 01:03:35,564 --> 01:03:37,883 Maybe it could be using agentic workflow like what you 1222 01:03:37,883 --> 01:03:39,464 mentioned, you know, AI code reviewer. 1223 01:03:39,824 --> 01:03:42,976 Or it could be some simple linting tools or policy as code, 1224 01:03:42,976 --> 01:03:45,649 whatever that is, that is already available without AI 1225 01:03:45,649 --> 01:03:47,492 component. I think that's also kind of like 1226 01:03:47,492 --> 01:03:49,779 a good thing. And tests, automated tests, I 1227 01:03:49,779 --> 01:03:52,766 think highly recommended to have this, because otherwise with, 1228 01:03:52,766 --> 01:03:56,522 you know, all this AI code that it gets generated, how do we 1229 01:03:56,522 --> 01:03:58,784 know actually that the output is correct all the time, right? 1230 01:03:59,084 --> 01:04:00,209 So I think that's kind of tricky. 1231 01:04:01,284 --> 01:04:03,444 So I think we have talked a lot about, you know, platform 1232 01:04:03,444 --> 01:04:06,924 engineering, AI and all that. Is there anything else that you 1233 01:04:06,924 --> 01:04:09,924 think important that we have to talk about, before we kind of 1234 01:04:09,924 --> 01:04:14,751 like go to the last question? Well, I think unless your last 1235 01:04:14,751 --> 01:04:17,941 question is on what I'm about to talk about. 1236 01:04:17,941 --> 01:04:22,161 So we'll see I think one of the things people need to understand 1237 01:04:22,161 --> 01:04:23,631 about platform engineering as well. 1238 01:04:23,691 --> 01:04:27,321 Obviously this is, you know, we are very tech oriented, you 1239 01:04:27,321 --> 01:04:30,081 know, so we're thinking about platform engineering from that 1240 01:04:30,081 --> 01:04:33,021 landscape. But the concepts of platform 1241 01:04:33,021 --> 01:04:35,271 engineering are really broadly applicable. 1242 01:04:35,511 --> 01:04:38,371 It's why when you get into the definitional point, it's like, 1243 01:04:38,371 --> 01:04:40,871 yes, there's a technical, there's a specific technical 1244 01:04:40,871 --> 01:04:45,948 definition I could give you, but the core concept is really about 1245 01:04:45,948 --> 01:04:49,870 thinking about your service, your internal service as a 1246 01:04:49,870 --> 01:04:54,556 product, and that could be, you know, of course an application 1247 01:04:54,556 --> 01:04:56,496 developer platform that you're using. 1248 01:04:57,076 --> 01:05:01,172 But when you really think about it, Henry Ford, what he was 1249 01:05:01,172 --> 01:05:04,936 doing a hundred years ago, seems like an out there example. 1250 01:05:05,236 --> 01:05:08,179 When you read about these changes to the way that we're 1251 01:05:08,179 --> 01:05:11,426 thinking about supply lines, golden path. 1252 01:05:11,446 --> 01:05:15,670 When you're thinking about a lot of what we saw with Kaizen, 1253 01:05:15,670 --> 01:05:19,856 these concepts of kind of automation, of organizational 1254 01:05:19,856 --> 01:05:23,596 change, those are foundational points of platform engineering. 1255 01:05:24,406 --> 01:05:26,836 It's just it's the exact same thing. 1256 01:05:26,956 --> 01:05:29,836 It's just thinking about something in that way. 1257 01:05:30,266 --> 01:05:33,416 If you imagine that you are a nurse working in a hospital. 1258 01:05:33,476 --> 01:05:36,886 And you have a service that calls in medication for the 1259 01:05:36,886 --> 01:05:40,154 patient. Well, you who is designing that 1260 01:05:40,154 --> 01:05:44,006 thing, you think about, okay, the nurse is my customer. 1261 01:05:44,876 --> 01:05:48,772 So this is the product. It's an internal product with a 1262 01:05:48,772 --> 01:05:51,686 customer. Think about it from a product 1263 01:05:51,686 --> 01:05:54,686 management standpoint. Interview the nurses, do user 1264 01:05:54,686 --> 01:05:56,636 research, think about what feature. 1265 01:05:57,356 --> 01:06:01,556 That's platform engineering. It doesn't have to be developers 1266 01:06:01,556 --> 01:06:04,286 writing code to be platform engineering. 1267 01:06:05,081 --> 01:06:08,689 Any user of your internal service, and if you think about 1268 01:06:08,689 --> 01:06:12,839 it like it's a product, and when you start to see that you start 1269 01:06:12,839 --> 01:06:16,637 to notice so many opportunities for thinking about this kind of 1270 01:06:16,637 --> 01:06:20,075 product mindset point. So that's really one of the key 1271 01:06:20,075 --> 01:06:23,271 takeaways that we've been having in the community recently. 1272 01:06:23,381 --> 01:06:26,085 And it's really helped when we think about a lot of the stuff 1273 01:06:26,085 --> 01:06:28,181 that we're building and that we're working on. 1274 01:06:28,481 --> 01:06:32,137 You know, thinking about things like a product and what that 1275 01:06:32,137 --> 01:06:34,871 brings with it is super, super, super valuable. 1276 01:06:34,931 --> 01:06:36,671 They don't have to just be developers. 1277 01:06:36,671 --> 01:06:41,309 It could be anything. So I like that you keep on, you 1278 01:06:41,309 --> 01:06:44,059 know, iterating on this thinking as a product, right? 1279 01:06:44,059 --> 01:06:46,534 So I'm sure the biggest takeaway from this conversation that we 1280 01:06:46,534 --> 01:06:49,819 have is actually to think a platform as a product, right? 1281 01:06:50,119 --> 01:06:53,149 So I think, for those of you who are embarking on this platform 1282 01:06:53,149 --> 01:06:55,683 engineering project within your organizations, whatever that is, 1283 01:06:55,683 --> 01:06:57,694 right? Always remember, think in, in 1284 01:06:57,694 --> 01:07:00,909 terms of product first, right? Product mindset, users, think 1285 01:07:00,909 --> 01:07:03,641 about users. How would the user, user adopt 1286 01:07:03,641 --> 01:07:05,821 it? And what kind of pain points 1287 01:07:05,821 --> 01:07:07,909 that you wanna solve in the first place, right? 1288 01:07:07,909 --> 01:07:10,885 The focus is very important so that you can start small and 1289 01:07:10,885 --> 01:07:13,893 iterate from there. So Sam, I think it's been a 1290 01:07:13,893 --> 01:07:15,969 great conversation. Unfortunately, due to time we 1291 01:07:15,969 --> 01:07:19,009 have to wrap up. But I have one last question, 1292 01:07:19,009 --> 01:07:22,295 which I always ask my guests. I call this the three technical 1293 01:07:22,295 --> 01:07:24,697 leadership wisdom. So you can think of it just like 1294 01:07:24,697 --> 01:07:26,209 an advice you wanna give to the listeners. 1295 01:07:27,019 --> 01:07:30,469 So maybe today, if you can share some, that will be great. 1296 01:07:32,471 --> 01:07:38,831 Sure, I mean I think my my answer will possibly be quite 1297 01:07:38,831 --> 01:07:41,939 obvious for some of the people listening and based on this 1298 01:07:41,939 --> 01:07:44,555 conversation. But I would say, as a leader, 1299 01:07:44,555 --> 01:07:48,251 think about more than just the domain that you are in. 1300 01:07:48,251 --> 01:07:51,524 And when I say domain, I don't just mean observability, 1301 01:07:51,524 --> 01:07:54,089 reliability. When you think about, say, you 1302 01:07:54,089 --> 01:07:58,529 are an engineering leader, there is a lot you can learn from 1303 01:07:58,529 --> 01:08:01,199 sales. There is a lot you can learn 1304 01:08:01,199 --> 01:08:03,761 from marketing. There's a lot you can learn from 1305 01:08:03,761 --> 01:08:05,351 your procurement and your HR teams. 1306 01:08:05,686 --> 01:08:10,311 And I think one of the biggest mistakes that a leader can make 1307 01:08:10,311 --> 01:08:13,091 is thinking, okay, I'm an engineering leader. 1308 01:08:13,781 --> 01:08:15,371 That's just what I'm gonna focus on. 1309 01:08:15,551 --> 01:08:17,977 I'm gonna focus on engineering and I'm gonna read great 1310 01:08:17,977 --> 01:08:19,596 engineering books. I'm gonna focus on that 1311 01:08:19,596 --> 01:08:22,456 engineering mindset. You'll notice the majority of 1312 01:08:22,456 --> 01:08:26,194 the most famous engineering books are things that talk about 1313 01:08:26,194 --> 01:08:29,010 things like marketing and sales and shift into those other 1314 01:08:29,010 --> 01:08:31,090 domains. It seems very obvious, but I 1315 01:08:31,090 --> 01:08:34,202 notice that so frequently when I talk to these enterprise 1316 01:08:34,202 --> 01:08:38,831 leaders, my 390th a year, the really successful ones are the 1317 01:08:38,831 --> 01:08:41,451 ones who are reading a marketing book. 1318 01:08:41,850 --> 01:08:45,298 They're reading a book on sales best practices to help them 1319 01:08:45,298 --> 01:08:47,649 think about how they can communicate about things in a 1320 01:08:47,649 --> 01:08:49,481 different way and get outside their wheelhouse. 1321 01:08:49,720 --> 01:08:53,350 So that's really been the kind of the eye-opening kind of 1322 01:08:53,350 --> 01:08:59,156 leadership tip for me. And then the flip side of that 1323 01:08:59,156 --> 01:09:04,832 is to really think about how you are approaching the work that 1324 01:09:04,832 --> 01:09:09,395 you are doing in that way. So your work, as an individual, 1325 01:09:09,395 --> 01:09:13,640 there's probably a lot of stuff you can learn from these other 1326 01:09:13,640 --> 01:09:16,636 domains. So it's really about this idea 1327 01:09:16,636 --> 01:09:20,917 of broadening your horizons. And I'll give a really fantastic 1328 01:09:20,917 --> 01:09:23,291 example. I won't name her but there's a 1329 01:09:23,291 --> 01:09:26,147 platform engineering leader who runs probably the largest 1330 01:09:26,147 --> 01:09:28,631 internal developer platform in the world. 1331 01:09:29,501 --> 01:09:33,719 I from all the ones that I've seen demos of, it's probably by 1332 01:09:33,719 --> 01:09:37,078 far the largest. And when I ask her what she's 1333 01:09:37,078 --> 01:09:40,481 reading to help her, she's reading books from the 1960s 1334 01:09:40,481 --> 01:09:44,225 about highway design. Because there's so much that's 1335 01:09:44,225 --> 01:09:48,785 applicable in there. It's great to read a modern book 1336 01:09:48,785 --> 01:09:52,862 on, you know, AI advancement. It's great to read a modern book 1337 01:09:52,862 --> 01:09:56,339 on engineering best practice. But a lot of these fundamentals 1338 01:09:56,339 --> 01:10:00,356 about infrastructure, a lot of these fundamentals about team 1339 01:10:00,356 --> 01:10:04,229 structure, organization, human psychology, you know, many of 1340 01:10:04,229 --> 01:10:06,605 these things are things that have been around for a long 1341 01:10:06,605 --> 01:10:08,582 time. So expanding your, your 1342 01:10:08,582 --> 01:10:11,903 wheelhouse about how you're thinking about problems and that 1343 01:10:11,903 --> 01:10:14,131 really stuck with me when I asked like, oh you know, what 1344 01:10:14,131 --> 01:10:15,941 are you reading to help with your platform? 1345 01:10:15,941 --> 01:10:19,631 She's like oh this book from the 1960s about American Highways. 1346 01:10:20,561 --> 01:10:23,061 Okay. So then I picked up the book and 1347 01:10:23,061 --> 01:10:26,311 I was like, oh my God, this is platform engineering gold. 1348 01:10:26,931 --> 01:10:30,580 You know, if I had just changed half the terminology in there, 1349 01:10:30,580 --> 01:10:33,356 that was a book on platform engineering right there. 1350 01:10:33,746 --> 01:10:37,030 And, you know, that's really I think the biggest advice that I 1351 01:10:37,030 --> 01:10:39,951 have been given or I've learned this year and that I think I 1352 01:10:39,951 --> 01:10:44,449 would want to impart. Really like that as well, right? 1353 01:10:44,479 --> 01:10:46,816 Because sometimes all these multidisciplinary thing, right, 1354 01:10:46,816 --> 01:10:49,009 different domains that you can mix together, right? 1355 01:10:49,009 --> 01:10:51,829 Especially the philosophy or maybe the learnings from those 1356 01:10:51,829 --> 01:10:54,772 things, can actually help us a lot in terms of engineering, 1357 01:10:54,772 --> 01:10:56,588 right? We can actually see a lot of 1358 01:10:56,588 --> 01:10:58,437 things. For example, anti-fragility, 1359 01:10:58,437 --> 01:11:01,339 right? And you know, iteration is also 1360 01:11:01,339 --> 01:11:04,369 one thing that I think from evolution and all that, right? 1361 01:11:04,819 --> 01:11:08,149 How do you actually, do this kind of, you know, I dunno, like 1362 01:11:08,149 --> 01:11:09,739 evolution, fitness test and all that. 1363 01:11:09,949 --> 01:11:12,139 Actually, we borrow that from biology to engineering. 1364 01:11:12,139 --> 01:11:15,529 So I think a lot of things, we can learn a lot, if we broaden 1365 01:11:15,529 --> 01:11:17,204 our horizon. So thanks for reminding us 1366 01:11:17,204 --> 01:11:20,369 again. And yeah, I think, that's a wrap 1367 01:11:20,369 --> 01:11:22,999 for today. Thank you so much, Sam, for 1368 01:11:22,999 --> 01:11:25,374 sharing everything about the new thing about platform 1369 01:11:25,374 --> 01:11:27,417 engineering. And I think just to remind 1370 01:11:27,417 --> 01:11:30,381 people one more time, if you still haven't got the message, 1371 01:11:30,381 --> 01:11:32,289 think about your platform as a product. 1372 01:11:32,979 --> 01:11:35,469 So that is the big message from today's conversation. 1373 01:11:35,469 --> 01:11:37,026 Thank you again Sam for today. Absolutely. 1374 01:11:37,246 --> 01:11:39,321 And thank you so much Henry for having me. 1375 01:11:39,471 --> 01:11:40,031 It's been awesome!