1 00:00:00,040 --> 00:00:01,800 The truth is, and most developers don't like to hear 2 00:00:01,800 --> 00:00:04,560 this, but when implementing platform engineering, we're kind 3 00:00:04,560 --> 00:00:06,680 of stealing some of your autonomy. 4 00:00:07,000 --> 00:00:08,880 The platform is built for software engineers. 5 00:00:08,960 --> 00:00:11,840 If the platform is bad, it could be the case that the platform 6 00:00:11,840 --> 00:00:14,480 team is building a platform for themselves, not for the software 7 00:00:14,480 --> 00:00:15,920 engineers. Is this a common thing? 8 00:00:16,320 --> 00:00:18,760 Sometimes I. Think it's even better to have 9 00:00:18,760 --> 00:00:20,960 no platform at all than a bad platform. 10 00:00:21,280 --> 00:00:25,200 How many developer hours have I saved by creating this coded 11 00:00:25,200 --> 00:00:27,360 path? Don't build a cool platform. 12 00:00:27,520 --> 00:00:29,680 Build a platform that developers want to use. 13 00:00:30,040 --> 00:00:32,800 We'll use in the end if. You want to learn about platform 14 00:00:32,800 --> 00:00:35,240 engineering, then this episode is for you. 15 00:00:35,400 --> 00:00:39,080 I have two platform engineering enthusiasts joining me at the 16 00:00:39,080 --> 00:00:41,240 table and the dynamic was just fantastic. 17 00:00:41,680 --> 00:00:44,360 Atnan Al Shar and Yomer do Yom, so enjoy. 18 00:00:48,400 --> 00:00:51,320 I saw this trend online and it was maybe a couple years ago. 19 00:00:51,600 --> 00:00:54,720 It was DevOps is dead and platform engineering is the new 20 00:00:54,880 --> 00:00:56,600 DevOps or it basically killed it. 21 00:00:57,320 --> 00:01:00,360 A lot of people are like click baiting and engagement farming 22 00:01:00,360 --> 00:01:03,160 specifically through that phase, but I'm curious what you think 23 00:01:03,160 --> 00:01:07,360 about that. I think the platform engineering 24 00:01:07,360 --> 00:01:11,480 as a discipline or as a practice that's coming up right now, it's 25 00:01:11,600 --> 00:01:15,880 getting more mature every year. I understand why the title was 26 00:01:15,880 --> 00:01:18,360 dev OPS is that I think they're trying to jump to the next 27 00:01:18,360 --> 00:01:22,360 phase. And the idea here is that how 28 00:01:22,360 --> 00:01:26,400 platform engineering is being pitched is try to counteract 29 00:01:27,280 --> 00:01:31,680 kind of the DevOps movement of look, we understand you build 30 00:01:31,680 --> 00:01:36,800 it, you run it, but we also want to make it better and remove all 31 00:01:36,800 --> 00:01:40,120 of the negative connotations that happened with DevOps over 32 00:01:40,120 --> 00:01:43,720 the past 10 years. So I think that makes the title 33 00:01:43,720 --> 00:01:45,720 that I think that's why they said it. 34 00:01:45,720 --> 00:01:47,880 I guess I don't. Know so do you agree? 35 00:01:47,880 --> 00:01:49,640 Do you disagree? Yeah, I agree. 36 00:01:49,840 --> 00:01:52,440 Yeah, yes, yeah. That's funny 'cause I disagree. 37 00:01:52,480 --> 00:01:53,640 OK, tell me why. Yeah. 38 00:01:53,680 --> 00:01:56,640 I, I don't think it's, I think that was that. 39 00:01:56,640 --> 00:01:59,960 I think it just doesn't work in a current age of technology 40 00:01:59,960 --> 00:02:01,960 anymore. That was, was of course created 41 00:02:02,040 --> 00:02:06,440 or thought of in 2008. The world has changed quite a 42 00:02:06,440 --> 00:02:08,440 lot since then, right? Containers were the thing, 43 00:02:08,440 --> 00:02:11,640 Kubernetes wasn't there. So teams taking full autonomy of 44 00:02:11,640 --> 00:02:15,400 their complete life cycle was possible back then move ahead to 45 00:02:15,400 --> 00:02:17,600 10 years later. Communities, clouds, 46 00:02:17,600 --> 00:02:21,720 infrastructure, codes, all these things were also put onto teams 47 00:02:21,800 --> 00:02:23,520 had to maintain all of these things as well. 48 00:02:23,840 --> 00:02:25,920 This is really where platform engineer stepped in and said, 49 00:02:25,920 --> 00:02:30,440 hey, we tried to take small things that you're currently 50 00:02:30,440 --> 00:02:33,800 doing and centralized them in the centralized team in this in 51 00:02:33,800 --> 00:02:38,320 this platform so that you can just focus on writing codes and 52 00:02:38,440 --> 00:02:40,880 being in flow. And we take care of all the 53 00:02:40,880 --> 00:02:42,720 other underlying infrastructure that's needed. 54 00:02:43,560 --> 00:02:47,480 So The thing is that I think it's OK. 55 00:02:47,480 --> 00:02:50,200 It's that's like it was in 2008. I would agree with that for 56 00:02:50,200 --> 00:02:52,840 sure, definitely. But in the current age of 57 00:02:52,840 --> 00:02:55,240 technology, I think platform engineering makes DevOps work 58 00:02:55,240 --> 00:02:56,760 again. OK, gotcha. 59 00:02:57,000 --> 00:02:58,560 Yeah. I like it. 60 00:02:58,560 --> 00:03:00,080 Yeah, yeah, yeah, I like the idea. 61 00:03:00,440 --> 00:03:03,680 I think it's, it's evolution. It's that's what we're seeing. 62 00:03:04,640 --> 00:03:09,080 I agree definitely on that. Just giving the chance for 63 00:03:09,800 --> 00:03:13,920 social engineers or developers in general to go back to what 64 00:03:13,920 --> 00:03:17,120 they do best and that's writing code that's that's talked about 65 00:03:17,840 --> 00:03:21,600 from 2008 to now. The amount of stuff a software 66 00:03:21,600 --> 00:03:26,440 engineer needs to maintain and work on and create and learn to 67 00:03:26,440 --> 00:03:29,880 get their idea to production has grown rapidly, right. 68 00:03:30,080 --> 00:03:33,160 You just mentioned how many AI tools are coming up every single 69 00:03:33,160 --> 00:03:36,040 day or other tooling related to the software development life 70 00:03:36,040 --> 00:03:38,640 cycle. A software engineer team to 71 00:03:38,640 --> 00:03:42,920 maintain that and keep an eye on it while writing code, while 72 00:03:42,920 --> 00:03:48,080 ensuring that code is secure, scale a bit, can be deployed to 73 00:03:48,080 --> 00:03:51,200 production. All of these things it's it does 74 00:03:51,320 --> 00:03:53,760 does not scale. And that's why platform 75 00:03:53,760 --> 00:03:57,480 engineering is what I say, I think what we see as the 76 00:03:57,480 --> 00:04:00,440 solution for this. But developers are also very 77 00:04:00,440 --> 00:04:03,360 particular with regards to the tools they like, or with regards 78 00:04:03,360 --> 00:04:06,920 to applications they like. Like if I, I put myself in a 79 00:04:06,920 --> 00:04:10,720 position where I have a platform that is made for me to be more 80 00:04:10,720 --> 00:04:12,600 productive, I really like the productivity side. 81 00:04:12,600 --> 00:04:15,280 So that if you're talking about marketing, that's what hooks me 82 00:04:15,280 --> 00:04:19,160 that I get buying for that. But then if I don't have that 83 00:04:19,160 --> 00:04:21,040 experience, I get frustrated, right? 84 00:04:21,040 --> 00:04:22,920 Because this is the platform that I'm on and I can't really 85 00:04:22,920 --> 00:04:25,360 change anything because this is the choice of the organization 86 00:04:25,720 --> 00:04:28,080 basically. So doing this I feel like is a 87 00:04:28,080 --> 00:04:31,000 fine balancing act. Is that what you've noticed as 88 00:04:31,000 --> 00:04:32,360 well? Yeah, it definitely is. 89 00:04:32,640 --> 00:04:35,560 I would say to the developers, be on the lookout for if it's a 90 00:04:35,560 --> 00:04:38,600 good platform or a bad platform. So it's a good platform can 91 00:04:38,600 --> 00:04:40,960 actually help you get more productive rights, gives you the 92 00:04:40,960 --> 00:04:44,520 right tools and a bad platform will have weird abstractions 93 00:04:44,520 --> 00:04:47,760 that nobody wants to use, makes it even more complex to do your 94 00:04:47,760 --> 00:04:50,120 work, which platform engineer was never set out to do right. 95 00:04:50,120 --> 00:04:54,000 I think it's even better to have no platform at all than a bad 96 00:04:54,000 --> 00:04:57,240 platform. And in the end, a good platform 97 00:04:57,240 --> 00:05:01,360 will also have escape hatches. So the moment you a tool is not 98 00:05:02,400 --> 00:05:05,480 supplied by the company or by the platform and you really need 99 00:05:05,480 --> 00:05:08,640 it for a specific use case, you should be able to use the escape 100 00:05:08,640 --> 00:05:11,720 hatch, get out of it and be able to use it to yourself. 101 00:05:12,000 --> 00:05:15,360 It does mean however, especially in compliance or regulated 102 00:05:15,360 --> 00:05:17,960 environments that you need to go to security yourself, get 103 00:05:17,960 --> 00:05:20,160 affected. Make sure that it's set up 104 00:05:20,160 --> 00:05:24,640 properly cause platform team will not do every small use case 105 00:05:24,640 --> 00:05:26,880 that there is right. They will just support the main 106 00:05:26,880 --> 00:05:28,640 tools that are needed within the company. 107 00:05:29,080 --> 00:05:32,600 So yeah, developers should definitely be on the lookout for 108 00:05:32,680 --> 00:05:34,720 a is the good platform or is it a bad platform? 109 00:05:34,760 --> 00:05:36,480 Yeah. And if people are listening and 110 00:05:36,480 --> 00:05:39,400 they say, OK, well, I have heard the term platform engineering. 111 00:05:39,400 --> 00:05:42,360 I'm on a platform, but I don't think it's a good platform. 112 00:05:42,360 --> 00:05:46,240 What can they do basically? In that sense, I guess you also 113 00:05:46,520 --> 00:05:49,480 want to see how the platform team is engaging with software 114 00:05:49,480 --> 00:05:52,320 developers. So in essence, in principle, the 115 00:05:52,320 --> 00:05:54,680 platform is built for software engineers, right? 116 00:05:54,680 --> 00:05:58,600 That's the main idea. If the platform is bad, it could 117 00:05:58,600 --> 00:06:01,040 be the case that the platform team is building a platform for 118 00:06:01,040 --> 00:06:03,040 themselves, not for the software engineers. 119 00:06:03,160 --> 00:06:05,520 Is this a common thing? Sometimes, yeah, yeah, yeah, 120 00:06:05,520 --> 00:06:08,520 yeah, yeah. Because building a platform is 121 00:06:08,520 --> 00:06:11,320 fun for platform engineer engineers, right? 122 00:06:11,560 --> 00:06:12,560 Definitely. I can say that. 123 00:06:13,160 --> 00:06:16,200 And I do want to build it in this nice looking way and stuff. 124 00:06:16,200 --> 00:06:18,560 But you're building a product, right? 125 00:06:18,560 --> 00:06:21,360 And the product is for customers and you need to know what they 126 00:06:21,360 --> 00:06:23,160 want. Otherwise there's no adoption. 127 00:06:23,960 --> 00:06:26,400 It's very simple, right? So it could be the case that the 128 00:06:26,400 --> 00:06:29,240 software engineers then need to address this with the platform 129 00:06:29,240 --> 00:06:31,920 team and tell them to set this is our requirements. 130 00:06:32,080 --> 00:06:35,480 This is what we want our like what what Kevin was talking 131 00:06:35,480 --> 00:06:38,960 about like golden paths or so have to be able to work and be 132 00:06:38,960 --> 00:06:42,280 productive. And that's the, that's the way 133 00:06:42,280 --> 00:06:44,800 where you can get a bad platform to a good platform, have 134 00:06:44,800 --> 00:06:48,560 feedback directly to the platform team and it's clear 135 00:06:48,560 --> 00:06:52,680 what you want as an end user. You're the main customer here 136 00:06:52,680 --> 00:06:54,920 for the product. So if you're able to do that, it 137 00:06:55,120 --> 00:07:00,000 it should be able to get you to a better platform with time and 138 00:07:00,000 --> 00:07:02,760 keep that feedback loop going with the platform team. 139 00:07:02,960 --> 00:07:06,560 Because in the end, what feedback you're giving should 140 00:07:06,560 --> 00:07:08,240 inform the road map for the product. 141 00:07:08,840 --> 00:07:10,560 It's interesting, right? Because if I'm building a 142 00:07:10,560 --> 00:07:14,000 product that is not for developers, in this case, I have 143 00:07:14,000 --> 00:07:16,320 to do I have to put out the best product for those users? 144 00:07:16,320 --> 00:07:17,800 Otherwise there's not going to be usage. 145 00:07:18,160 --> 00:07:19,840 But I feel like with platform engineering, the role is 146 00:07:19,840 --> 00:07:21,440 inverse. And you're saying if you're a 147 00:07:21,440 --> 00:07:23,320 developer, you have to go to your platform team. 148 00:07:23,680 --> 00:07:26,440 And I feel like they should come to me and ask me what the best 149 00:07:26,440 --> 00:07:26,960 thing is. Yeah. 150 00:07:27,360 --> 00:07:28,560 Of course, of course, of course, right. 151 00:07:28,560 --> 00:07:31,720 But like most of the time, people in platform engineering 152 00:07:31,720 --> 00:07:34,760 teams are very technical people, and I like to use new tools, use 153 00:07:34,760 --> 00:07:37,640 technologies. So they focus on building these 154 00:07:38,280 --> 00:07:41,320 do abstractions instead of actually solving what you need. 155 00:07:41,480 --> 00:07:42,880 Yeah. So one of the tips I always give 156 00:07:42,880 --> 00:07:45,560 teams is especially if they're a platform initiative starting in 157 00:07:45,560 --> 00:07:49,840 your organization, try to be a early adopter, engage early and 158 00:07:49,960 --> 00:07:53,440 show what kind of things you're running into, sell them 159 00:07:53,440 --> 00:07:56,560 solutions. So but for example, say, hey, 160 00:07:56,560 --> 00:07:59,680 it's getting something from ideation to production, takes me 161 00:07:59,680 --> 00:08:02,000 3 weeks. Like I want to be able to be 162 00:08:02,080 --> 00:08:04,000 able to quicker spin up services. 163 00:08:04,200 --> 00:08:05,920 That's not solutions, it's an issue, right? 164 00:08:05,920 --> 00:08:08,360 And then they can figure out, OK, how can we solve that with 165 00:08:08,360 --> 00:08:10,640 the tools that we already have? Gotcha. 166 00:08:11,160 --> 00:08:14,800 What is the best platform you've seen work in an organization 167 00:08:14,800 --> 00:08:17,960 when it comes to I think your example from idea to production? 168 00:08:19,880 --> 00:08:24,520 The best one, yeah, the I think the best one is the one that 169 00:08:24,520 --> 00:08:29,360 will really help developers. So and it's it's very smooth. 170 00:08:29,680 --> 00:08:33,159 So the interface, it can be a nice looking, nice looking 171 00:08:33,159 --> 00:08:34,880 portal. But in this case, it was 172 00:08:34,880 --> 00:08:36,840 actually AC light tool that they used. 173 00:08:37,120 --> 00:08:40,760 And they could basically just create this C light tool, create 174 00:08:40,799 --> 00:08:44,159 a YAML definition, send it to an to an to an API somewhere. 175 00:08:44,159 --> 00:08:47,240 And this would spin up stuff in the Kubernetes cluster so that 176 00:08:47,240 --> 00:08:49,120 they can run their their applications. 177 00:08:49,320 --> 00:08:53,040 And that would be exactly the same as it's locally being done, 178 00:08:53,280 --> 00:08:56,960 as in tests, as in excitation, as in production. 179 00:08:56,960 --> 00:08:59,360 The environments were identical. So the things you were doing 180 00:08:59,360 --> 00:09:02,600 locally, you could spin it up within seconds, would be exactly 181 00:09:02,600 --> 00:09:05,040 the same as production. And I think from a developer 182 00:09:05,040 --> 00:09:07,480 perspective, that is very cool, at least something that you 183 00:09:07,480 --> 00:09:09,440 don't see very often. Yeah, exactly. 184 00:09:11,240 --> 00:09:14,000 The environment and how you reproduce that locally compared 185 00:09:14,000 --> 00:09:16,360 to all the other test and production environments that you 186 00:09:16,360 --> 00:09:18,760 have. Also same with data 187 00:09:18,760 --> 00:09:21,040 availability. If those are not in place 188 00:09:21,040 --> 00:09:23,080 locally or on test and acceptance environments. 189 00:09:23,480 --> 00:09:26,160 I've just been frustrated because you want to go to 190 00:09:26,160 --> 00:09:28,240 production with confidence. You want to say I don't care 191 00:09:28,240 --> 00:09:30,280 that it's Friday. I have the confidence in all the 192 00:09:30,280 --> 00:09:33,760 safety net that we have to be able to do so There should not 193 00:09:33,760 --> 00:09:36,280 be this mantra of it's Friday. We don't release if we have a 194 00:09:36,280 --> 00:09:38,840 really good system that actually enables us to release whenever 195 00:09:38,840 --> 00:09:41,760 we want. So yeah, I definitely get. 196 00:09:42,080 --> 00:09:45,120 That and I think with the CLI tool part, that also brings it 197 00:09:45,120 --> 00:09:48,120 closer to developers, right? They're also in their IDE, they 198 00:09:48,120 --> 00:09:50,360 have the terminal, everything is in one place. 199 00:09:50,760 --> 00:09:54,320 We can do what you want to do without the need to go to 200 00:09:54,320 --> 00:09:58,760 different places and try open tickets with that operations or 201 00:09:58,760 --> 00:10:02,000 whoever know you have everything you need in one place and your 202 00:10:02,000 --> 00:10:06,160 productivity is much higher than going back and forth, right. 203 00:10:06,160 --> 00:10:09,280 So yeah, that that makes. Sense and that's also that's a 204 00:10:09,280 --> 00:10:10,920 very important part as well, right? 205 00:10:10,920 --> 00:10:14,040 Because we are the truth is and most developers don't like to 206 00:10:14,040 --> 00:10:17,000 hear this, but when implementing platform engineering we're kind 207 00:10:17,000 --> 00:10:19,120 of stealing some of your autonomy. 208 00:10:19,320 --> 00:10:22,000 Yeah, because now you don't get to decide how you do things 209 00:10:22,000 --> 00:10:24,480 specifically we lay out this pad for you. 210 00:10:24,480 --> 00:10:26,520 This called a pad like I've not explained before. 211 00:10:28,160 --> 00:10:30,520 And the moment you do that, we need to also give you something 212 00:10:30,520 --> 00:10:31,880 back, right? You cannot just always have to 213 00:10:31,880 --> 00:10:34,160 come to us and be like, hey, can you do this for me or create a 214 00:10:34,160 --> 00:10:37,320 ticket or use Slack. So we need to be able to deliver 215 00:10:37,320 --> 00:10:40,640 all of these capabilities in a self-service manner that can be 216 00:10:40,800 --> 00:10:43,480 can be done through a through a portal or through a CLI 217 00:10:43,480 --> 00:10:47,320 interface, depending on what the developers want, right? 218 00:10:48,400 --> 00:10:51,360 And a good platform engineering team will go to developers and 219 00:10:51,360 --> 00:10:53,200 actually ask like, hey, what do you want? 220 00:10:53,880 --> 00:10:56,640 But we don't see that happening that often. 221 00:10:56,640 --> 00:10:59,040 So again, I would like to encourage developers just to go 222 00:10:59,040 --> 00:11:01,720 to a platform team and say, hey, this is really something that 223 00:11:01,720 --> 00:11:04,200 would help us a lot or this is the pain points that we have. 224 00:11:04,840 --> 00:11:07,480 Yeah, you get that. What does a platform make sense, 225 00:11:07,680 --> 00:11:09,040 right. Because if I start to start up 226 00:11:09,040 --> 00:11:12,160 with you and I and you as well, the three of us start a start 227 00:11:12,160 --> 00:11:13,960 up, we're not going to start with a platform. 228 00:11:14,040 --> 00:11:15,040 I, I would assume. OK. 229 00:11:15,040 --> 00:11:16,720 Thank you. Because that's my assumption. 230 00:11:17,680 --> 00:11:18,800 That's a good, that's a good assumption. 231 00:11:19,680 --> 00:11:22,960 But then at some point, I don't know if it's a scale or amount 232 00:11:22,960 --> 00:11:25,360 of people or amount of applications or maybe even 233 00:11:25,360 --> 00:11:28,440 domain, and some of the complexity that comes with that 234 00:11:28,840 --> 00:11:31,120 defines when a platform does make sense. 235 00:11:31,920 --> 00:11:34,600 I think we, I remember reading somewhere, it's like there's a 236 00:11:34,600 --> 00:11:36,840 number of people, but that's very specific. 237 00:11:36,840 --> 00:11:39,040 So we also need to look in words and see how it is. 238 00:11:39,040 --> 00:11:46,680 I would say whenever you have a team that's growing and you see 239 00:11:46,680 --> 00:11:49,680 that, let's say the productivity or the speed, velocity, whatever 240 00:11:49,680 --> 00:11:54,040 is said the same, that's when you start considering what's 241 00:11:54,040 --> 00:11:56,040 happening, right? So within a start up, you're 242 00:11:56,040 --> 00:11:57,920 like 3-4 people, you work within each other. 243 00:11:57,920 --> 00:11:59,560 There's no need for a platform, right? 244 00:11:59,840 --> 00:12:02,880 When you start scanning a bit more and you see that, OK, we're 245 00:12:02,880 --> 00:12:06,040 getting more productivity, we're getting more features shipped. 246 00:12:06,600 --> 00:12:08,560 Perfect. As soon as you hit that, let's 247 00:12:08,560 --> 00:12:12,120 say stagnation and and velocity, this is where you might consider 248 00:12:12,280 --> 00:12:15,880 a platform and the reason behind it, I guess it's more people are 249 00:12:15,880 --> 00:12:17,920 working on more tooling. There's not a lot of 250 00:12:17,920 --> 00:12:21,360 standardization, which means some people are getting stuck 251 00:12:21,360 --> 00:12:27,080 somewhere or there's this no consistency in in deployment and 252 00:12:27,080 --> 00:12:30,520 then yeah, you have that issues. This is when the platform makes 253 00:12:30,520 --> 00:12:33,640 sense, I would say. How do you then start from that 254 00:12:33,640 --> 00:12:35,320 aspect? So you're saying velocity 255 00:12:35,320 --> 00:12:38,720 stagnates or it even goes down based on just time progressing 256 00:12:38,720 --> 00:12:41,840 and complexity building up? Does one person take ownership 257 00:12:41,840 --> 00:12:44,200 of building a platform? Do you form a group that then 258 00:12:44,200 --> 00:12:45,800 takes ownership or what is the next step? 259 00:12:45,960 --> 00:12:49,080 If you are at that scale, I would say one person would be 260 00:12:49,080 --> 00:12:50,000 enough. Really. 261 00:12:50,000 --> 00:12:52,280 Yes, I would say so. Because then you don't want to 262 00:12:52,280 --> 00:12:54,280 dedicate the whole platform team just yet. 263 00:12:54,360 --> 00:12:57,160 Yeah, You want that one person who is very close to what's 264 00:12:57,160 --> 00:12:59,720 happening with like in terms of the software development life 265 00:12:59,720 --> 00:13:03,400 cycle again and start talking to the developers and understanding 266 00:13:03,400 --> 00:13:07,840 what issues they're running into and then grabbing all of these 267 00:13:07,840 --> 00:13:09,960 issues and stuff and start working towards let's say the 268 00:13:09,960 --> 00:13:13,040 first golden path, right? This is where we want everyone 269 00:13:13,040 --> 00:13:17,600 to follow kind of. And with that, you start having 270 00:13:17,600 --> 00:13:20,080 a couple of people who are like you're evangelists, right? 271 00:13:20,080 --> 00:13:22,120 The people you're going to start with, they are, they are trusted 272 00:13:22,120 --> 00:13:26,120 people in the organization and they would be able to give you 273 00:13:26,760 --> 00:13:28,760 their feedback. Once you create the golden path. 274 00:13:29,400 --> 00:13:32,600 And with time you start obviously scaling that to the 275 00:13:32,600 --> 00:13:36,920 rest of the organization and see how it's performing. 276 00:13:36,920 --> 00:13:38,120 You need to measure it as well, right? 277 00:13:38,120 --> 00:13:39,680 So it's not just creating it and that's it. 278 00:13:39,680 --> 00:13:43,520 You need to measure it. And with the scaling that's 279 00:13:43,520 --> 00:13:45,600 happening to the organization, you start adding more people to 280 00:13:45,600 --> 00:13:51,120 the platform team to be able to support the the developers, 281 00:13:51,120 --> 00:13:53,480 right. So I would say that's how I see 282 00:13:53,480 --> 00:13:54,640 it at this deal. Nice. 283 00:13:54,840 --> 00:13:57,160 Let's put a pin on on measurements because I think 284 00:13:57,160 --> 00:14:00,080 that's interesting, but I want to learn from your perspective, 285 00:14:00,080 --> 00:14:03,120 Yalmer, the people that are, let's say first movers or that 286 00:14:03,120 --> 00:14:06,400 join a platform team, can that be anyone or what capabilities 287 00:14:06,400 --> 00:14:08,200 do they need to have? Can it be a software engineer? 288 00:14:08,680 --> 00:14:10,960 Does it need to be someone else? What have you seen? 289 00:14:11,240 --> 00:14:13,720 That's a good question. I always like that the platform 290 00:14:13,720 --> 00:14:16,560 team is a mix of people that are have been working in social 291 00:14:16,560 --> 00:14:18,880 developments because then you know the pay points, right? 292 00:14:18,920 --> 00:14:20,480 Yeah, you are the users. Yeah, indeed. 293 00:14:21,040 --> 00:14:23,120 Which is kind of the best ideal situation, right? 294 00:14:23,120 --> 00:14:25,960 But in the end, you also need to have the experience of, OK, I'm 295 00:14:25,960 --> 00:14:29,320 not just building a application for end users, but I'm building 296 00:14:29,320 --> 00:14:31,960 a platform that will be used by multiple different teams, 297 00:14:32,520 --> 00:14:35,320 different kinds of requirements. So you also want the experience 298 00:14:35,320 --> 00:14:38,560 of like more, well, system engineerish people. 299 00:14:38,560 --> 00:14:41,720 And I think the combination of combining them together is 300 00:14:41,720 --> 00:14:46,120 really when magic happens, then really the issues that are need 301 00:14:46,120 --> 00:14:48,880 to be solved in companies are being solved and being done in a 302 00:14:48,880 --> 00:14:52,160 matter that's easily repeatable, compliance and secure for an 303 00:14:52,160 --> 00:14:54,520 organization. And again, that's really the 304 00:14:54,520 --> 00:14:56,360 magic for platform engineering. Nice. 305 00:14:57,000 --> 00:15:00,040 But then the looking back into that first mover, can that then 306 00:15:00,040 --> 00:15:02,240 be either a system engineer or software engineer or what would 307 00:15:02,240 --> 00:15:03,760 be your preference? Do you have a? 308 00:15:03,760 --> 00:15:06,680 Preference. No, I don't. 309 00:15:06,760 --> 00:15:09,720 I think it doesn't really matter what kind of skills they have. 310 00:15:09,720 --> 00:15:11,440 I think it's where they will focus on. 311 00:15:11,800 --> 00:15:14,160 I think if you want to become a success with your platform 312 00:15:14,200 --> 00:15:17,000 initiative, it's not something that you should be like, OK, 313 00:15:17,000 --> 00:15:18,840 we're going to build this in two years and then we're going to 314 00:15:18,840 --> 00:15:21,200 release it like it's like horrible, right? 315 00:15:21,880 --> 00:15:25,080 It should really be something like, OK, what is currently the 316 00:15:25,080 --> 00:15:26,320 biggest bottleneck? OK. 317 00:15:26,360 --> 00:15:28,240 And let's just see if we can fix that it. 318 00:15:28,480 --> 00:15:30,240 Can be that simple? It can be that simple. 319 00:15:30,240 --> 00:15:32,800 Platform engineering is this is the discipline of building 320 00:15:32,800 --> 00:15:35,920 internal developer platforms, which sounds very scary, but we 321 00:15:35,920 --> 00:15:38,440 also tried to enable flow within developers. 322 00:15:38,680 --> 00:15:41,560 So just start there, figure out what's your biggest bottleneck, 323 00:15:41,560 --> 00:15:44,040 waiting three weeks for a COP approval. 324 00:15:44,400 --> 00:15:47,400 All right, let's talk to them. How can we improve this? 325 00:15:47,520 --> 00:15:49,080 Is there a COP approval always needed? 326 00:15:49,520 --> 00:15:52,440 Stuff like this is already platform engineering because 327 00:15:52,440 --> 00:15:55,080 we're increasing developer flow, developer experience. 328 00:15:55,760 --> 00:15:59,600 Maybe it's been my like kind of how I view the word platform 329 00:15:59,600 --> 00:16:00,880 engineering. It's not so grand. 330 00:16:01,400 --> 00:16:03,320 But if you're saying it's as simple as removing the biggest 331 00:16:03,320 --> 00:16:06,160 bottleneck and trying to figure that out already means that 332 00:16:06,160 --> 00:16:09,040 you're doing, you're thinking of or your platform engineering in 333 00:16:09,040 --> 00:16:11,720 that way, that makes it a lot more simple, makes it a lot more 334 00:16:11,720 --> 00:16:12,920 digestible. Yeah, yeah, yeah. 335 00:16:12,920 --> 00:16:15,400 Especially if you these days you heard these big tools coming 336 00:16:15,400 --> 00:16:18,600 around like backstage and platform orchestrations and all 337 00:16:18,600 --> 00:16:21,840 very scary things. Golden paths, paved roads is 338 00:16:21,840 --> 00:16:25,120 what I've heard is like the huge paths that are in my head, like 339 00:16:25,120 --> 00:16:27,160 yearly ventures. Yeah, yeah. 340 00:16:27,480 --> 00:16:30,120 It is. It takes like I think like one 341 00:16:30,120 --> 00:16:32,440 of the best one I've seen. I have built it myself. 342 00:16:32,440 --> 00:16:35,880 It took them like 7 years to get to the to the end state where 343 00:16:35,880 --> 00:16:38,000 they currently are where everything is self servers and 344 00:16:38,240 --> 00:16:40,760 done automatically to like a select bolt and stuff which is 345 00:16:40,840 --> 00:16:42,480 incredible. Seven years. 346 00:16:42,480 --> 00:16:43,960 Yeah, seven years. That's the way you start, right? 347 00:16:43,960 --> 00:16:47,640 You start with small things, soften bottlenecks, increasing 348 00:16:47,640 --> 00:16:49,520 flow for developers. Yeah, I was going to say, if 349 00:16:49,520 --> 00:16:51,480 they did nothing and then released the seven years, they 350 00:16:51,480 --> 00:16:54,760 must have had some serious business backing, some serious 351 00:16:54,760 --> 00:16:56,160 belief that this is going to work. 352 00:16:56,800 --> 00:16:59,480 Now they all start small, right? Every year a great story starts. 353 00:16:59,960 --> 00:17:02,360 That's nice. And they need to showcase the, 354 00:17:02,800 --> 00:17:04,960 the progress, right? You cannot say, OK, I'm going to 355 00:17:04,960 --> 00:17:07,720 do this in two years. Then the idea is already done. 356 00:17:07,720 --> 00:17:09,560 No one wants the platform anymore. 357 00:17:09,560 --> 00:17:13,640 They're already past the, the whole problems that they're 358 00:17:13,640 --> 00:17:16,000 they're into. And they're like, we're 359 00:17:16,000 --> 00:17:18,040 frustrated enough. We're not going to wait for two 360 00:17:18,040 --> 00:17:20,359 years. So getting that quick turn 361 00:17:20,359 --> 00:17:23,480 around, trying it with people. I think with the first movers I 362 00:17:23,480 --> 00:17:25,880 had a different also opinion on this. 363 00:17:25,880 --> 00:17:28,920 I think if you are able to find who are, who is the team or the, 364 00:17:28,920 --> 00:17:32,520 the, the people within the organiser are very excited and 365 00:17:32,520 --> 00:17:35,160 are like looking forward to it. Use these people, yeah. 366 00:17:35,240 --> 00:17:37,880 Yeah, use the energy. Go for them, yeah, because they 367 00:17:37,880 --> 00:17:39,760 are the ones that are going to help you the most. 368 00:17:39,760 --> 00:17:40,400 Most. Yeah, all the. 369 00:17:40,920 --> 00:17:43,840 People that complain go fix it now. 370 00:17:43,880 --> 00:17:47,560 Honestly, like that's feedback that's incredible. 371 00:17:47,560 --> 00:17:50,160 Like one of the hardest things is, is getting good feedback 372 00:17:50,160 --> 00:17:52,840 from from developers. How are they actually using the 373 00:17:52,920 --> 00:17:54,960 platform? And developers that are very 374 00:17:55,840 --> 00:17:58,360 angry about stuff within within an organization. 375 00:17:58,360 --> 00:18:00,800 Amazing. Use them if you can onboard them 376 00:18:00,800 --> 00:18:03,680 and make them a supporter. The rest is going to be smooth 377 00:18:03,680 --> 00:18:05,320 sailing. Yeah, yeah. 378 00:18:05,320 --> 00:18:08,200 I feel like the developers are very critical. 379 00:18:08,520 --> 00:18:11,400 And the way for them to keep being critical is to actually do 380 00:18:11,400 --> 00:18:13,160 something with the critique, right? 381 00:18:13,160 --> 00:18:15,040 Make them feel heard and then implement it. 382 00:18:15,520 --> 00:18:18,160 I've also seen companies or organizations or teams where 383 00:18:18,160 --> 00:18:20,960 critique is labeled as negativity and then people kind 384 00:18:20,960 --> 00:18:23,320 of shut down and they're like, well, if I said this, you would 385 00:18:23,320 --> 00:18:24,800 just think I'm, I'm very negative. 386 00:18:24,960 --> 00:18:27,920 You also have the those people that are very grumpy and 387 00:18:27,920 --> 00:18:30,200 everything is just shit. But yeah, I feel like if 388 00:18:30,200 --> 00:18:32,360 critique is very valid, something needs to be done with 389 00:18:32,360 --> 00:18:34,840 it or you need to accommodate for it in some way, right? 390 00:18:34,840 --> 00:18:37,800 We're focusing on this and this is then maybe next or This is 391 00:18:37,800 --> 00:18:39,440 why this is not a concern at all. 392 00:18:39,640 --> 00:18:40,960 So have you thought about XY and Z? 393 00:18:40,960 --> 00:18:43,560 But there needs to be a two way, an equal level of dialogue. 394 00:18:44,200 --> 00:18:47,120 Yeah, we mentioned that one of the success metrics is a 395 00:18:47,120 --> 00:18:50,120 seamless developer experience. How do you measure that? 396 00:18:50,120 --> 00:18:52,680 What does success look like for people that are building that 397 00:18:52,680 --> 00:18:56,960 platform? OK, that's a big sign. 398 00:18:56,960 --> 00:19:01,640 No, no, perfect, perfect. So multiple metrics obviously, 399 00:19:01,640 --> 00:19:03,000 and multiple things you need to look at. 400 00:19:03,080 --> 00:19:05,880 I really like them. So there are a couple of of 401 00:19:05,880 --> 00:19:07,080 metrics that I'll talk about now. 402 00:19:07,080 --> 00:19:10,320 It's first of all, it's the onboarding time. 403 00:19:10,480 --> 00:19:14,560 OK, So I read this summer, I think Spotify did this, can't 404 00:19:14,560 --> 00:19:15,360 remember. It could be. 405 00:19:16,000 --> 00:19:20,240 And they measured the time from the first day you start working 406 00:19:20,320 --> 00:19:22,920 at an organization until your 10th or request. 407 00:19:23,200 --> 00:19:25,200 OK, the 10th, not the first till. 408 00:19:25,600 --> 00:19:31,240 The 10th so they see how how much time it's taking you to be 409 00:19:31,240 --> 00:19:34,560 familiar with your work, be familiar with what's the 410 00:19:34,560 --> 00:19:41,480 landscape around you and how fast can you actually help and 411 00:19:41,480 --> 00:19:44,600 and assisted to collaborate and and provide your value. 412 00:19:44,920 --> 00:19:47,840 And that's why they tend. OK, so that's a really nice 413 00:19:47,840 --> 00:19:48,880 metric. I really like. 414 00:19:48,920 --> 00:19:51,000 I think another one is called service create time. 415 00:19:51,480 --> 00:19:55,440 How much time it takes to create a service goes to production as 416 00:19:55,440 --> 00:19:57,400 I'm not, by the way, correct me if I'm wrong. 417 00:19:57,480 --> 00:20:01,800 So I'm just reciting my head. So that's also a very nice one. 418 00:20:04,160 --> 00:20:07,480 Others could be obviously you can use also the space metrics, 419 00:20:07,480 --> 00:20:10,120 daughter metrics are typical frameworks that you can also 420 00:20:10,120 --> 00:20:15,640 have a nice one which is very small and can help is the NPS 421 00:20:15,640 --> 00:20:17,000 not promoter score. OK. 422 00:20:17,280 --> 00:20:20,400 And that's also to gauge the sentiment towards the platform, 423 00:20:20,560 --> 00:20:25,240 which it's a very lightweight, it's very small form where you 424 00:20:25,240 --> 00:20:27,920 can send it away like every month survey. 425 00:20:27,920 --> 00:20:31,120 And yeah, it's a very small survey, like 3 questions that's 426 00:20:31,120 --> 00:20:32,880 it. And then you can track it over 427 00:20:32,880 --> 00:20:37,440 time, see how people are are feeling about the platform. 428 00:20:37,480 --> 00:20:40,280 And then you can also correlate it with what features you've 429 00:20:40,280 --> 00:20:42,800 released. So then you can have an idea of 430 00:20:43,360 --> 00:20:45,480 am I right, Am I on the right path or not? 431 00:20:46,480 --> 00:20:49,600 Yeah, I think freeze out some stuff. 432 00:20:49,800 --> 00:20:52,640 No, I, I like it. I wish, I wish all companies 433 00:20:52,640 --> 00:20:54,800 would do this. OK, right. 434 00:20:54,800 --> 00:20:57,320 Because I think also the state-of-the-art platform 435 00:20:57,320 --> 00:20:59,880 engineering reports came out and again, like I think it was like 436 00:20:59,880 --> 00:21:02,200 60% of the companies under measuring that platform 437 00:21:02,200 --> 00:21:04,640 engineering success, yes. Interesting, I saw that 438 00:21:04,640 --> 00:21:06,880 yesterday I. Think, yeah, it's still crazy. 439 00:21:06,880 --> 00:21:09,600 Like the number is also not, not not going up or go down. 440 00:21:10,440 --> 00:21:13,400 So they're just basically just doing plus initiatives without 441 00:21:13,760 --> 00:21:16,280 measuring if what they're doing is a success. 442 00:21:16,280 --> 00:21:19,520 You know, plus engineering is all about flow and increasing 443 00:21:19,520 --> 00:21:21,120 productivity, right? That's the promise. 444 00:21:21,360 --> 00:21:23,960 So if we don't have a baseline like how do we know if we're 445 00:21:23,960 --> 00:21:26,360 actually becoming a success with our initiative? 446 00:21:28,800 --> 00:21:31,800 Also don't forget about business metrics, right? 447 00:21:31,840 --> 00:21:33,160 So we talk about all of these things. 448 00:21:33,160 --> 00:21:36,240 These are more platform engineering related to the team 449 00:21:36,240 --> 00:21:38,320 itself. Also want to look at the return 450 00:21:38,320 --> 00:21:41,200 on investment, right? Because you still want the buy 451 00:21:41,200 --> 00:21:43,840 in and you still want the funding and you still want the 452 00:21:43,840 --> 00:21:45,720 backing of the executive and the business. 453 00:21:45,840 --> 00:21:50,960 You also need to check the return on investment for your 454 00:21:50,960 --> 00:21:52,680 platform. How much money are we putting 455 00:21:52,680 --> 00:21:55,360 in? How does that match up to how 456 00:21:55,360 --> 00:21:57,000 much money we're getting out of it? 457 00:21:57,000 --> 00:22:00,080 Right? So one I think measurement I 458 00:22:00,080 --> 00:22:04,120 heard as well is how many developer hours have I saved by 459 00:22:04,120 --> 00:22:05,880 creating this golden path for example. 460 00:22:06,040 --> 00:22:07,280 Cool. Yeah, which is very nice. 461 00:22:07,720 --> 00:22:09,040 But then you also, that's a hard one. 462 00:22:09,040 --> 00:22:10,960 That's a hard one. But you need to measure before 463 00:22:10,960 --> 00:22:13,880 your platform as well. So the idea of measuring is not 464 00:22:13,880 --> 00:22:17,480 just after we're done, it's also before, right? 465 00:22:17,480 --> 00:22:20,640 So before we start, what's happening and the reason behind 466 00:22:20,640 --> 00:22:24,240 that, like memories and organizations are very short 467 00:22:24,240 --> 00:22:27,280 term because if the platform is successful, they're like, oh, 468 00:22:27,400 --> 00:22:31,080 life is amazing now, right? Five months ago we couldn't do 469 00:22:31,080 --> 00:22:32,920 anything, but now everything is perfect. 470 00:22:33,200 --> 00:22:36,080 So you need to also see what was happening before to justify how 471 00:22:36,080 --> 00:22:40,880 good your platform is. Yeah, I feel like like a survey 472 00:22:40,880 --> 00:22:44,000 is the easiest thing for me if I were to be in control, the 473 00:22:44,000 --> 00:22:45,600 lowest hanging fruit that I could do. 474 00:22:46,160 --> 00:22:47,640 The only thing is some people don't like surveys. 475 00:22:47,640 --> 00:22:51,760 But in any case, I feel like if the survey is something we do 476 00:22:51,760 --> 00:22:54,280 something with and people can see results, then that 477 00:22:54,280 --> 00:22:56,160 incentivizes people to give their feedback. 478 00:22:56,280 --> 00:22:59,680 That is 1 The other metrics I feel like are sometimes very 479 00:22:59,680 --> 00:23:01,600 hard, right? There are frameworks for 480 00:23:01,600 --> 00:23:04,160 measuring developer productivity, but they can also 481 00:23:04,160 --> 00:23:06,040 be manipulated, right? If people know how they're 482 00:23:06,040 --> 00:23:08,560 measured, especially on individual level, if it's 483 00:23:08,560 --> 00:23:11,360 actually going to that scale, then people manipulate it, 484 00:23:11,360 --> 00:23:12,640 right? I'm more productive. 485 00:23:12,640 --> 00:23:13,920 Actually. I do many pull requests. 486 00:23:13,920 --> 00:23:16,760 My 10th pull request was on the first day because I just changed 487 00:23:16,760 --> 00:23:19,320 10 read bases. So yeah, I think it's 488 00:23:19,320 --> 00:23:22,560 interesting to look at how metrics operate and then also 489 00:23:22,560 --> 00:23:24,880 how an organization revolves around those metrics. 490 00:23:25,360 --> 00:23:29,480 Now, the companies that don't do any metrics, that for me is very 491 00:23:29,480 --> 00:23:31,360 interesting. And I have no clue how they then 492 00:23:31,680 --> 00:23:34,520 indeed say, OK, this is successful, but it also how they 493 00:23:34,520 --> 00:23:36,640 keep investing. Is investing always a 494 00:23:36,640 --> 00:23:38,880 conversation? Because I feel like if you set 495 00:23:38,880 --> 00:23:41,720 up a team, even if you start from from something, if you 496 00:23:41,720 --> 00:23:44,480 start small, you need to have good backing, right, That this 497 00:23:44,480 --> 00:23:46,160 is actually going to increase productivity. 498 00:23:46,520 --> 00:23:48,480 And if you don't measure that, I don't know what people are 499 00:23:48,480 --> 00:23:51,560 actually doing or how they can do this continuously. 500 00:23:52,560 --> 00:23:55,160 That's a good question. Yeah, yeah, I, I also don't 501 00:23:55,160 --> 00:23:57,320 know, like I think in the beginning you also ask like when 502 00:23:57,320 --> 00:23:58,720 do we start the plus for engineering? 503 00:23:58,920 --> 00:24:01,800 And I think for me, it should always start with measuring that 504 00:24:01,800 --> 00:24:04,840 something's going wrong, like with the increased productivity, 505 00:24:05,200 --> 00:24:08,160 decreased productivity, decreased experience, and then 506 00:24:08,160 --> 00:24:12,040 you start the plus initiative. So the moment that they don't 507 00:24:12,040 --> 00:24:15,160 measure anything and then they try to uphold this story of 508 00:24:15,160 --> 00:24:18,400 being like, oh, we're going to increase productivity and 509 00:24:18,680 --> 00:24:20,520 developers are going to have a bad experience. 510 00:24:20,920 --> 00:24:24,880 It's all just fake because there's no numbers, just fluff. 511 00:24:24,880 --> 00:24:26,680 Yeah, it's just fluff. They just need to believe that 512 00:24:26,680 --> 00:24:29,160 it's it is and how. And then eventually, of course, 513 00:24:29,160 --> 00:24:32,240 they will stop talking to developers and then they will 514 00:24:32,240 --> 00:24:34,640 figure out that, oh, they are just building a platform because 515 00:24:34,640 --> 00:24:36,120 they're like building a platform. 516 00:24:36,400 --> 00:24:38,600 That's also probably why they're not measuring, because they're 517 00:24:38,600 --> 00:24:41,560 not actually helping developers. They're just building and using 518 00:24:41,560 --> 00:24:44,880 cool tools. So I think most of those 519 00:24:44,880 --> 00:24:47,760 companies that are not measuring are probably scared to measure. 520 00:24:47,760 --> 00:24:49,240 A lot of red. Flags. 521 00:24:49,240 --> 00:24:50,760 Yeah, it's definitely a red flag. 522 00:24:50,760 --> 00:24:52,080 Yeah, yeah, yeah. Yeah. 523 00:24:52,440 --> 00:24:56,800 I would I would tell them to go shameless plug or read my blog. 524 00:24:57,000 --> 00:24:59,840 OK, yeah. On the website platform 525 00:24:59,840 --> 00:25:02,440 Engineering Matrix on xavia.com. Go check it out. 526 00:25:02,440 --> 00:25:04,000 Go check it out. Interesting. 527 00:25:04,560 --> 00:25:06,840 When we talked about developer productivity, right, that's the 528 00:25:06,840 --> 00:25:08,680 smallest thing that you can do when you're already doing 529 00:25:08,680 --> 00:25:11,040 platform engineering, it kind of triggered something in me 530 00:25:11,040 --> 00:25:15,720 because nowadays, early 2026, organizations have an opinion on 531 00:25:15,720 --> 00:25:18,560 productivity for software engineers specifically because 532 00:25:18,560 --> 00:25:21,640 of AI tooling, right? If I have an agent that can do 533 00:25:21,640 --> 00:25:24,520 something or I can vibe code something myself, why is it so 534 00:25:24,520 --> 00:25:28,080 slow in my organization or what some leaders think? 535 00:25:28,520 --> 00:25:31,480 And then it's like, yeah, you guys need to be more effective 536 00:25:31,480 --> 00:25:34,360 or we need to modernize and we need to do that more quickly or 537 00:25:34,640 --> 00:25:37,320 we need to save developer time. And people all of a sudden have 538 00:25:37,320 --> 00:25:39,040 an opinion, which I think is very interesting. 539 00:25:39,440 --> 00:25:42,720 I'm curious to hear what you've seen or how you also view that 540 00:25:42,960 --> 00:25:44,880 people having opinions on developer productivity. 541 00:25:44,880 --> 00:25:46,240 Oh. Yeah, I like that. 542 00:25:46,400 --> 00:25:47,240 It's a good one. Yeah. 543 00:25:47,480 --> 00:25:50,160 You know, there's a lot of in the report words coming out that 544 00:25:50,160 --> 00:25:53,040 developers spend most of the time actually not developing. 545 00:25:53,400 --> 00:25:56,520 So let's say it's 2030% of the time actually writing codes, 546 00:25:56,520 --> 00:25:58,360 right? And the rest is just meetings 547 00:25:58,360 --> 00:26:01,800 and getting stuff to production and creating ServiceNow tickets 548 00:26:01,800 --> 00:26:07,240 and stuff like that. So if you then improve the way 549 00:26:07,240 --> 00:26:10,720 in how fast they can write codes, you're only improving the 550 00:26:10,720 --> 00:26:15,720 small increments of their work. It's 2030% if all the rest is 551 00:26:15,720 --> 00:26:19,360 just in getting stuff for production, making progress, all 552 00:26:19,360 --> 00:26:22,640 all all those kind of things. If you really want to improve 553 00:26:22,640 --> 00:26:25,120 the federal productivity, you should not look at you should 554 00:26:25,120 --> 00:26:29,200 also look at them helping AI right, But also how to get stuff 555 00:26:29,200 --> 00:26:31,880 faster into production, how to make sure that we actually get 556 00:26:31,880 --> 00:26:35,640 security on board faster. How these fast flows, these 557 00:26:35,640 --> 00:26:39,160 golden pads, because that's really where most of the ball is 558 00:26:39,160 --> 00:26:43,040 being dropped right now. That's the, yeah, basically the 559 00:26:43,080 --> 00:26:45,200 resistance where the device gets stuck, and if you just improve 560 00:26:45,200 --> 00:26:48,000 it in front of that, it gets stuck more and more and more. 561 00:26:49,040 --> 00:26:51,000 Yeah, I like that a lot actually, that perspective. 562 00:26:51,320 --> 00:26:54,200 Is that also If not. And I wanted to put you on the 563 00:26:54,200 --> 00:26:56,080 spot quickly. Why not? 564 00:26:56,840 --> 00:27:01,080 There's this statistics you always gave about, I think about 565 00:27:01,160 --> 00:27:05,360 AI adoption and how executives look at it versus development. 566 00:27:05,520 --> 00:27:07,080 Yeah, yeah. Because I feel like this is 567 00:27:07,080 --> 00:27:09,440 very. Yeah, yeah, very relevant. 568 00:27:09,640 --> 00:27:15,360 I think it's a new report from IBM and they say that 80% of the 569 00:27:15,360 --> 00:27:18,760 executives see that they need AI to stay ahead of the game from 570 00:27:18,760 --> 00:27:22,080 the competitors. And then 20% of the executives 571 00:27:22,080 --> 00:27:25,120 say that their infrastructure is ready for AI. 572 00:27:25,600 --> 00:27:29,800 So if we want this to work and we want to use AI to stay ahead, 573 00:27:29,800 --> 00:27:32,400 we actually need to first look at our infrastructure and how 574 00:27:32,400 --> 00:27:36,440 we're supplying tools and LLMS and models and APIs to our 575 00:27:36,440 --> 00:27:39,080 developers instead of just looking at the developers being 576 00:27:39,080 --> 00:27:43,800 a go fester with AI because your infrastructure, your platform is 577 00:27:43,800 --> 00:27:45,480 not ready for AI. It's. 578 00:27:46,680 --> 00:27:49,760 It's very revealing the statistic because then there's 579 00:27:49,760 --> 00:27:52,440 this huge disconnect and what you mentioned, like now with the 580 00:27:52,440 --> 00:27:55,800 advent of AI and how executives are looking at it, 2026 581 00:27:57,280 --> 00:28:00,480 executives think this is the current landscape where it's 582 00:28:00,480 --> 00:28:03,000 completely different. There's no connection 583 00:28:03,000 --> 00:28:05,400 whatsoever. Part of it is metrics and what 584 00:28:05,400 --> 00:28:06,920 we talked about. They have no idea what's 585 00:28:06,920 --> 00:28:08,520 happening. They cannot see numbers. 586 00:28:08,640 --> 00:28:10,920 This is what they love, right? They want to see numbers that 587 00:28:10,920 --> 00:28:15,040 are very easily measurable and they can describe something for 588 00:28:15,040 --> 00:28:18,240 them and they don't have that. So that's the disconnect. 589 00:28:18,960 --> 00:28:24,320 I think it's with metrics with more knowledge going up top 590 00:28:24,560 --> 00:28:28,440 about the current state school. And then also platform 591 00:28:28,440 --> 00:28:34,080 engineering, again, having it ready for hosting your LLMS or 592 00:28:34,080 --> 00:28:36,840 hosting your AI workloads, making sure that you're also 593 00:28:37,360 --> 00:28:41,000 using AI within the company in a secure way and it's a compliant 594 00:28:41,000 --> 00:28:42,880 way. Platform engineering also solves 595 00:28:42,880 --> 00:28:45,480 this problem, so. You mentioned the OK, if 596 00:28:46,200 --> 00:28:49,720 engineers are actually 30% doing hands on coding and 70% is 597 00:28:49,840 --> 00:28:53,560 processes or meetings or just somewhere it's clogged 598 00:28:53,560 --> 00:28:56,840 throughout the process. If I then as a platform team 599 00:28:56,840 --> 00:29:00,000 focus on removing those bottlenecks, less meetings, more 600 00:29:00,000 --> 00:29:02,200 focused time, is that also platform engineering? 601 00:29:03,320 --> 00:29:07,080 Good question. I think a part of it, yes, of 602 00:29:07,080 --> 00:29:09,520 course less meetings is not is not really platform engineering, 603 00:29:09,520 --> 00:29:10,880 right. Well, if you're having meetings 604 00:29:10,880 --> 00:29:13,720 about going to production and stuff and that gets automated, 605 00:29:13,720 --> 00:29:15,760 then it's probably is platform engineering. 606 00:29:16,040 --> 00:29:19,440 But I think it's on the the fence of just improving how you 607 00:29:19,440 --> 00:29:23,480 work being being more lean as a as a company and the platform 608 00:29:23,480 --> 00:29:25,120 engineering can also support that a little bit. 609 00:29:25,200 --> 00:29:26,120 Gotcha. Yeah. 610 00:29:26,320 --> 00:29:29,760 It's an extension of what what you're achieving is. 611 00:29:29,800 --> 00:29:33,720 Then an extension of it is maybe less meetings, less processes, 612 00:29:33,720 --> 00:29:36,640 less. Because it could be that all of 613 00:29:36,640 --> 00:29:40,680 us are in a platform engineering team at a client somewhere and 614 00:29:40,680 --> 00:29:42,560 then we see that meetings are actually the issue, right? 615 00:29:42,560 --> 00:29:43,880 So we can build whatever tooling. 616 00:29:43,880 --> 00:29:47,000 But yeah, we're going to optimize also that same 30% or a 617 00:29:47,320 --> 00:29:50,240 little bit more because there's it's not just coding to go into 618 00:29:50,240 --> 00:29:52,840 production. But if meetings are really the 619 00:29:52,840 --> 00:29:55,280 issue, then that's a very interesting bit for me. 620 00:29:55,480 --> 00:29:57,680 And that's kind of organizational behaviour that 621 00:29:57,680 --> 00:30:02,080 needs to change, right. I saw that SML kicked out. 622 00:30:02,320 --> 00:30:03,520 I don't know what the statistic was. 623 00:30:03,520 --> 00:30:06,920 I think it was like 1600 people and almost all of them were 624 00:30:06,920 --> 00:30:09,040 middle managers. And then I talked to some people 625 00:30:09,040 --> 00:30:11,600 that work there and they were like, yeah, one of the reasons I 626 00:30:11,600 --> 00:30:14,160 left was I was just getting dragged in meetings. 627 00:30:14,160 --> 00:30:17,360 And the people that were organizing those meetings, they 628 00:30:17,360 --> 00:30:18,920 didn't really have any influence. 629 00:30:18,920 --> 00:30:20,560 And they were kind of in the middle and they're trying to 630 00:30:20,560 --> 00:30:22,040 manage. But in the end, they just 631 00:30:22,040 --> 00:30:24,800 clocked the system throughout. He said that's the reason I 632 00:30:24,800 --> 00:30:27,080 left. So yeah, I think a lot of people 633 00:30:27,080 --> 00:30:30,200 are going to be a lot more happier, a lot happier in the 634 00:30:30,200 --> 00:30:32,520 end. While also ISML published kind 635 00:30:32,520 --> 00:30:34,520 of record numbers. So it's kind of a disconnect 636 00:30:34,520 --> 00:30:35,840 there. But I thought it was interesting 637 00:30:36,560 --> 00:30:39,560 that is more behaviour and organizational change. 638 00:30:40,000 --> 00:30:41,960 Because also throughout this conversation, I was wondering 639 00:30:41,960 --> 00:30:43,840 why platform engineering is not just called developer 640 00:30:43,840 --> 00:30:47,120 productivity, but all of those meetings and behavioral change 641 00:30:47,120 --> 00:30:49,240 that also influences developer productivity in the end. 642 00:30:49,880 --> 00:30:51,480 So yeah. Yeah, Maybe I'd speak a little 643 00:30:51,480 --> 00:30:53,840 bit because the definition as well, right, Platform sharing is 644 00:30:53,840 --> 00:30:56,160 the discipline of building an internal developer platform. 645 00:30:56,160 --> 00:30:58,840 So that's really the the product and what we are trying to 646 00:30:58,840 --> 00:31:01,080 achieve with the product is developed productivity. 647 00:31:01,640 --> 00:31:04,480 But you can also do developer productivity in other ways 648 00:31:04,480 --> 00:31:06,320 instead of having this centralized platform rights, 649 00:31:06,320 --> 00:31:08,400 because you just look at processes and change that 650 00:31:08,400 --> 00:31:11,520 instead of it would still fall on the platform engineering. 651 00:31:11,520 --> 00:31:13,840 But again, platform engineering is a slippery slope that 652 00:31:13,920 --> 00:31:16,400 everything can fall on the platform engineering these days. 653 00:31:16,440 --> 00:31:18,920 Yeah. But in the end, it's still about 654 00:31:19,160 --> 00:31:22,320 developer productivity, developer experience by having 655 00:31:22,320 --> 00:31:26,040 this internal developer platform available for your developers, 656 00:31:26,200 --> 00:31:27,360 but it doesn't have a start there. 657 00:31:27,440 --> 00:31:28,280 Gotcha. Yeah. 658 00:31:28,920 --> 00:31:33,160 If I then look at platform engineering, do AI tooling, does 659 00:31:33,160 --> 00:31:36,040 that also fall under that? So whether an organization uses 660 00:31:36,040 --> 00:31:39,200 cloud code or you mentioned Replit before the show and also 661 00:31:39,480 --> 00:31:43,600 Microsoft Copilot specifically or GitHub Copilot even, does 662 00:31:43,600 --> 00:31:45,880 that all fall under platform engineering in your perspective? 663 00:31:47,000 --> 00:31:48,200 Yes. Yeah, yeah. 664 00:31:48,200 --> 00:31:50,840 OK. I think it has this place there. 665 00:31:50,960 --> 00:31:54,160 Yeah. So platform, the platform 666 00:31:54,160 --> 00:31:56,000 especially if you have if you have like Kubernetes platform or 667 00:31:56,000 --> 00:31:59,320 something, it's the perfect way for orchestration of 668 00:31:59,760 --> 00:32:03,640 applications, but also large language models or other models 669 00:32:03,640 --> 00:32:07,680 or maybe you need specific GP us to train specific models. 670 00:32:07,680 --> 00:32:10,440 That's all something that the platform can orchestrate for 671 00:32:10,440 --> 00:32:12,600 you. So it's definitely has its place 672 00:32:12,600 --> 00:32:15,440 in order to enable AI within organizations. 673 00:32:16,120 --> 00:32:20,400 Plus especially in the clouds of entity these days you can 674 00:32:20,400 --> 00:32:25,120 actually have something running locally on sites offline ish in 675 00:32:25,120 --> 00:32:29,520 your internal network instead of buying something from open AI or 676 00:32:29,800 --> 00:32:33,800 or cloud for example. And then if you're setting up 677 00:32:33,800 --> 00:32:36,880 your, your landscape in a way which follows our the principles 678 00:32:36,880 --> 00:32:40,440 we talked about. And so your NLMS, your data, 679 00:32:40,720 --> 00:32:44,120 everything related to your organization stays within your, 680 00:32:46,320 --> 00:32:50,320 it's a environment because you are following the secure way of 681 00:32:50,320 --> 00:32:54,720 provisioning infrastructure. It's scalable, it's consistent, 682 00:32:54,720 --> 00:32:57,680 it's the same across from local up into production. 683 00:32:58,040 --> 00:33:02,600 You don't have any fear of let's say having these LMS go outside 684 00:33:02,600 --> 00:33:05,200 of the environment. Everything is compliant. 685 00:33:05,200 --> 00:33:09,040 That's if you still follow that before transfer engineering 686 00:33:09,040 --> 00:33:11,920 software, you build it to run it, and you have developers also 687 00:33:11,920 --> 00:33:15,360 creating infrastructure and there's like 300 tools. 688 00:33:15,360 --> 00:33:19,200 For one thing, you might find it very difficult to kind of clamp 689 00:33:19,200 --> 00:33:21,880 down on what's happening and understand what's running in 690 00:33:21,880 --> 00:33:28,040 your landscape with AI, with data being fed into the anonyms 691 00:33:28,040 --> 00:33:30,880 with all of that. You can see where this is going 692 00:33:30,880 --> 00:33:35,320 to go later on with like data breaches or problems within your 693 00:33:35,360 --> 00:33:38,920 organization or these things we've already seen like people 694 00:33:38,920 --> 00:33:43,040 use ChatGPT online and then upload company data, which is 695 00:33:43,040 --> 00:33:46,600 also a huge problem as well. So if you're following the 696 00:33:46,600 --> 00:33:49,920 principles, if you are providing these golden paths for 697 00:33:49,920 --> 00:33:52,640 developers and you have a very consistent way of provisioning 698 00:33:52,640 --> 00:33:56,240 infrastructure for developers, add on top of it AI. 699 00:33:56,240 --> 00:33:59,960 And that's also very good for you because then it's secure, 700 00:34:00,120 --> 00:34:02,240 it's compliant, and it's within your own environment. 701 00:34:02,560 --> 00:34:05,200 So it's stood for as the principles of building 702 00:34:05,200 --> 00:34:07,680 infrastructure that you already specified in the beginning. 703 00:34:08,800 --> 00:34:13,480 What is your opinion on I love this term shadow IT because we 704 00:34:13,480 --> 00:34:17,080 already mentioned, OK, if the platform is bad, then it's it's 705 00:34:17,080 --> 00:34:18,920 worse than not having a platform at all. 706 00:34:19,440 --> 00:34:21,239 And typically one of the symptoms that I see is that 707 00:34:21,239 --> 00:34:23,000 people just get whatever tune and they don't tell anyone. 708 00:34:23,000 --> 00:34:25,280 It's like very hush hush. And I know what I'm doing. 709 00:34:25,280 --> 00:34:27,360 OK, no personal data, no, no coding. 710 00:34:27,440 --> 00:34:30,320 But but yeah, I have this thing and it makes me more productive. 711 00:34:31,400 --> 00:34:33,920 Yeah, I get it right. And from a platform engineering 712 00:34:33,920 --> 00:34:37,440 perspective, it's it's horrible to to see shadow IT because it's 713 00:34:37,440 --> 00:34:40,440 the side effect of basically having this incompetent 714 00:34:40,440 --> 00:34:43,280 platform, right? I there's something that I 715 00:34:43,280 --> 00:34:45,400 cannot do or you're not providing me the service. 716 00:34:45,639 --> 00:34:47,960 All right, I'm going to my manager and he just puts his 717 00:34:47,960 --> 00:34:52,159 credit card on his new AWS account and well, I have a non 718 00:34:52,159 --> 00:34:56,080 compliant Awsifier, which is of course good for you, horrible 719 00:34:56,080 --> 00:34:58,120 for the company because it's it's not secure, it's not 720 00:34:58,120 --> 00:35:00,720 compliant, it's not regulated. Nobody's checking it. 721 00:35:00,720 --> 00:35:02,280 What happens if this manager leaves? 722 00:35:02,280 --> 00:35:04,520 Will the any of us account just closes? 723 00:35:04,640 --> 00:35:07,280 Yeah, so I I get it. But I would really say to 724 00:35:07,280 --> 00:35:10,800 developers, if you're on the brink of, of doing this, try to 725 00:35:10,800 --> 00:35:13,800 go to the plus regime and be like, hey, I really need you 726 00:35:13,800 --> 00:35:16,160 guys to either change step it up. 727 00:35:16,280 --> 00:35:19,920 Otherwise I will go and do the shadow IT route. 728 00:35:20,600 --> 00:35:22,560 Maybe that will be a wake up call for them. 729 00:35:22,600 --> 00:35:24,760 I'd be like, OK, maybe we should really change something because 730 00:35:24,760 --> 00:35:27,480 they are having actual issues we're not solving and they are 731 00:35:27,480 --> 00:35:29,520 figuring out themselves. Yeah, interesting. 732 00:35:29,720 --> 00:35:31,640 It's also the escape out, as you mentioned, right? 733 00:35:31,640 --> 00:35:37,040 So being able to I'm also also like a huge amount of people 734 00:35:37,040 --> 00:35:39,800 using the platform, but also taking their own path. 735 00:35:40,400 --> 00:35:43,200 That's fine. And the idea here is that there 736 00:35:43,200 --> 00:35:46,480 are still guard raids, of course, but you're also able to 737 00:35:46,480 --> 00:35:50,480 explore your on your path on yourself by yourself, sorry. 738 00:35:50,760 --> 00:35:52,040 And that's within the guard raids. 739 00:35:52,840 --> 00:35:56,560 So we're still secure, we're still compliant given you're not 740 00:35:56,560 --> 00:35:59,720 using the golden path, which is fine, but you also are on your 741 00:35:59,720 --> 00:36:04,280 own path to discover or innovate or have a new idea in mind, but 742 00:36:04,280 --> 00:36:07,680 within the card rates. So you're still within that area 743 00:36:07,840 --> 00:36:10,400 of the platform team. And that's I think also 744 00:36:10,400 --> 00:36:16,240 something that the platform team should be very clear on how 745 00:36:16,240 --> 00:36:19,040 intuitive it is to use the escape patches as well, is that 746 00:36:19,040 --> 00:36:20,520 it's very clear that you can go both ways. 747 00:36:20,960 --> 00:36:24,120 We always prefer Golden Path, yeah, but you also can take your 748 00:36:24,120 --> 00:36:26,640 own path if you need to. I think that a lot because I was 749 00:36:26,640 --> 00:36:29,760 thinking if everyone needs to go to this platform engineering 750 00:36:29,760 --> 00:36:32,040 team, right, Either for the escape hatch or for the golden 751 00:36:32,040 --> 00:36:35,120 path or for new requests or for this is not smooth yet. 752 00:36:35,120 --> 00:36:37,760 Can we fix XY and Z? They might also become a 753 00:36:37,760 --> 00:36:39,800 bottleneck, right? If you get so much feedback, 754 00:36:39,800 --> 00:36:42,240 then your throughput is kind of throttled and you have to shift 755 00:36:42,240 --> 00:36:44,120 through. OK, where's the value and what 756 00:36:44,120 --> 00:36:45,960 do we prioritize? But that also means you need to 757 00:36:45,960 --> 00:36:47,720 manage expectations of the priorities. 758 00:36:47,720 --> 00:36:50,400 You're not going to pick up yet or not going to do at all. 759 00:36:50,400 --> 00:36:53,200 And you have to have kind of an equal level of dialogue and make 760 00:36:53,200 --> 00:36:55,520 people feel heard. Otherwise you'd lose interest 761 00:36:55,520 --> 00:36:57,680 completely. And the bigger our organization 762 00:36:57,680 --> 00:37:01,280 skills, I feel like it is funneling towards this team that 763 00:37:01,280 --> 00:37:03,080 is then responsible for platform engineering. 764 00:37:03,720 --> 00:37:05,560 Have you seen something like that or how do you accommodate 765 00:37:05,560 --> 00:37:08,560 for platform engineering or the team that is responsible not 766 00:37:08,560 --> 00:37:11,320 being a bottleneck? I think you you start first of 767 00:37:11,320 --> 00:37:15,440 all with whatever the platform or the the minimum viable 768 00:37:15,440 --> 00:37:18,080 product is ready for the first team. 769 00:37:18,080 --> 00:37:20,920 You don't announce that to the whole organization. 770 00:37:21,040 --> 00:37:22,360 This is the first thing. It's not all in. 771 00:37:23,120 --> 00:37:26,200 They need to set to the team and they would be, as I mentioned, 772 00:37:26,200 --> 00:37:28,640 the evangelist. They would take you through and 773 00:37:28,640 --> 00:37:32,240 you work very intimately with them, get their older feedback, 774 00:37:32,400 --> 00:37:35,440 all of the bugs they're facing, making sure that the process is 775 00:37:36,240 --> 00:37:40,360 iteratively improved, and then you start scaling slowly across 776 00:37:40,360 --> 00:37:45,600 multiple teams with a full scale like organization. 777 00:37:46,120 --> 00:37:50,400 If the platform is very well adopted, I'm assuming people 778 00:37:50,400 --> 00:37:54,800 will help the platform team to get through a certain bottleneck 779 00:37:54,800 --> 00:37:56,680 when like a lot of things are not happening. 780 00:37:59,080 --> 00:38:02,160 If they are fully invested in the platform, then it comes to 781 00:38:02,160 --> 00:38:04,760 like huge scale. I don't know to be honest. 782 00:38:04,760 --> 00:38:07,000 Like maybe you know, I'm not sure. 783 00:38:08,440 --> 00:38:12,120 I think the best way of making sure that the platform team does 784 00:38:12,120 --> 00:38:15,520 not become a bottleneck is on to everything self-service. 785 00:38:15,720 --> 00:38:19,320 So take it OPS, you should not need to create a ticket for 786 00:38:19,320 --> 00:38:20,840 something standard, right? It should be self-service. 787 00:38:20,840 --> 00:38:24,280 You should go to portal, use CLI, use an API, whatever you 788 00:38:24,280 --> 00:38:25,440 should be able to request yourself. 789 00:38:25,880 --> 00:38:28,680 That's one. Two ways have very good in the 790 00:38:28,680 --> 00:38:31,040 sourcing. So the moment that you need 791 00:38:31,040 --> 00:38:34,720 something, for example, you're very particular on the Ruby for 792 00:38:34,720 --> 00:38:36,920 wheels, for example, you want that to be supported by the 793 00:38:36,920 --> 00:38:40,120 platform. Sure, here's a repo go implement 794 00:38:40,120 --> 00:38:41,520 it. We have an example for Java 795 00:38:41,520 --> 00:38:43,560 Spring Boot or something. You can figure it, you can 796 00:38:43,560 --> 00:38:44,920 figure it out. If you need some help, let us 797 00:38:44,920 --> 00:38:47,080 know, right. Just implement it themselves and 798 00:38:47,080 --> 00:38:48,920 then keep a little bit of control over it. 799 00:38:49,400 --> 00:38:53,080 That's the best case because in that way you can have a platform 800 00:38:53,080 --> 00:38:55,880 that supports build for use cases without having to skill 801 00:38:55,880 --> 00:38:58,680 the platform team increasingly. Yeah, interesting. 802 00:38:58,680 --> 00:39:01,120 That's nice. I was also wondering because 803 00:39:01,120 --> 00:39:02,960 I've been in a lot of small organizations. 804 00:39:02,960 --> 00:39:06,360 So then part of what I actually run in software, I need to be 805 00:39:06,360 --> 00:39:09,520 aware of the environment. I need to be conscious of get 806 00:39:09,520 --> 00:39:11,000 how much load can the team handle? 807 00:39:11,000 --> 00:39:13,360 Do we go serverless? What what trade off do we make 808 00:39:13,360 --> 00:39:15,840 for cost of ownership in the decisions that we make? 809 00:39:16,200 --> 00:39:19,040 And I like those thoughts. And now I'm in bigger 810 00:39:19,040 --> 00:39:21,680 organizations and in bigger organizations, it's kind of 811 00:39:21,680 --> 00:39:23,280 smooth sailing because I don't have to think about that. 812 00:39:23,280 --> 00:39:24,960 But that also kind of takes away from it. 813 00:39:25,320 --> 00:39:28,360 So then looking at my personal skills, if I were to be at a 814 00:39:28,360 --> 00:39:31,200 bigger organization and I don't think of that like that muscle 815 00:39:31,200 --> 00:39:34,320 will kind of atrophy. And I'm wondering what your 816 00:39:34,320 --> 00:39:37,760 perspective is on that because part of the developer ownership, 817 00:39:37,840 --> 00:39:39,960 it's, it's huge, it's way too much on their plate. 818 00:39:39,960 --> 00:39:42,920 I also say that the whole product sense is becoming more 819 00:39:42,920 --> 00:39:45,440 and more important as well. So if you talk about tooling, if 820 00:39:45,440 --> 00:39:47,280 you talk about creating software, if you talk about 821 00:39:47,280 --> 00:39:50,240 knowing your customer, thinking from a business outcome 822 00:39:50,240 --> 00:39:52,520 perspective, it's a lot that falls on the plate. 823 00:39:53,080 --> 00:39:56,440 So I'm good with having some stuff fall away, but I'm, I'm 824 00:39:56,440 --> 00:39:59,480 very aware that the right stuff needs to fall away. 825 00:39:59,480 --> 00:40:02,560 And if I am in a bigger organization where things are 826 00:40:02,560 --> 00:40:06,200 kind of accommodated for? Will I then feel pain or 827 00:40:06,200 --> 00:40:08,560 experience kind of difficulties if I move into a smaller 828 00:40:08,560 --> 00:40:11,440 organization and all of a sudden those responsibilities fall 829 00:40:11,440 --> 00:40:12,920 again into the plate of the developer? 830 00:40:13,880 --> 00:40:16,720 I think that's really the balance between a good and a bad 831 00:40:16,720 --> 00:40:19,920 platform. So in the end if you go back to 832 00:40:19,920 --> 00:40:23,760 before dev OPS, it was really separated by dev and OPS and OPS 833 00:40:23,760 --> 00:40:27,480 would be gatekeeping of rights and and ownership of of servers 834 00:40:27,480 --> 00:40:29,160 running and what kind of skill you need. 835 00:40:29,720 --> 00:40:33,400 Then DevOps, it became completely the something for the 836 00:40:33,400 --> 00:40:36,840 developers to take into account. And then you can say platform 837 00:40:36,840 --> 00:40:40,320 engineering supports developers that you are still responsible. 838 00:40:40,720 --> 00:40:43,880 We just help make it go faster. But you still need to think 839 00:40:43,880 --> 00:40:45,280 about it. So we're not gatekeeping 840 00:40:45,280 --> 00:40:47,480 anything. We're not trying to just trying 841 00:40:47,480 --> 00:40:50,440 to make your life a little bit easier, but it's still on you. 842 00:40:50,440 --> 00:40:53,520 You're still responsible for making sure that the there's the 843 00:40:53,520 --> 00:40:55,560 right skill. And that's all those things 844 00:40:55,560 --> 00:40:57,360 still on you. We just help make your life 845 00:40:57,360 --> 00:40:58,960 easier. That's good, yeah. 846 00:40:59,840 --> 00:41:01,600 What were your thoughts? Yeah, I think, yeah, makes 847 00:41:01,600 --> 00:41:03,880 sense. I'm just trying to think of how 848 00:41:04,160 --> 00:41:06,840 you would go from like a huge organization of just doing one 849 00:41:06,840 --> 00:41:10,280 thing and then back. I can see the pain in it because 850 00:41:10,280 --> 00:41:16,920 then it's a huge organization. Everything is very organised in 851 00:41:16,920 --> 00:41:18,080 a way. There are processes for 852 00:41:18,080 --> 00:41:20,400 everything and then you go back into like a small organiser, 853 00:41:20,400 --> 00:41:22,560 say, OK, how did they used to do this before? 854 00:41:23,080 --> 00:41:25,720 Yeah, that's a kind of a chaos. Might be why you leave. 855 00:41:26,200 --> 00:41:27,640 Though yeah, it could be, definitely. 856 00:41:28,320 --> 00:41:30,920 But yeah, definitely with a good bad platform part. 857 00:41:30,920 --> 00:41:36,280 I think I still believe in the fact that developers should be 858 00:41:36,280 --> 00:41:40,440 able to let go of all of the things that made their cognitive 859 00:41:40,440 --> 00:41:44,240 load really high in the past years and make sure to focus on 860 00:41:44,240 --> 00:41:47,320 writing code, very good quality code. 861 00:41:47,480 --> 00:41:49,280 Yeah. And that's the main thing. 862 00:41:50,200 --> 00:41:53,400 And then if they need to go back to it like a small organizations 863 00:41:53,400 --> 00:41:56,880 where the roles are a bit murky and you need to take more wear 864 00:41:56,880 --> 00:41:59,360 and more hearts, then yeah, I think you just need to exercise 865 00:41:59,360 --> 00:42:03,360 that once again and help with like the platform team or all of 866 00:42:03,360 --> 00:42:05,720 the learnings you had in the bigger organization, how things 867 00:42:05,720 --> 00:42:06,920 are done so. Fair. 868 00:42:07,040 --> 00:42:08,720 Yeah, there might not be a good answer there. 869 00:42:08,720 --> 00:42:10,400 It's just a choice in the end. Yeah, exactly. 870 00:42:10,400 --> 00:42:12,320 Yeah. I really enjoyed picking both of 871 00:42:12,320 --> 00:42:14,160 your brains about platform engineering. 872 00:42:14,440 --> 00:42:16,920 Is there anything that's missing that we haven't discussed yet 873 00:42:17,040 --> 00:42:18,520 that you want to address before you round off? 874 00:42:18,520 --> 00:42:21,720 I'm going to give you both the second. 875 00:42:23,120 --> 00:42:24,840 This is the curveball I always throw, yeah. 876 00:42:25,600 --> 00:42:32,400 I would say at least from my end, the thing that usually is 877 00:42:32,400 --> 00:42:37,960 missing when we're talking about like tech or trends or stuff 878 00:42:37,960 --> 00:42:42,480 like that is we talk a lot about the technicals part, but you 879 00:42:42,480 --> 00:42:46,920 forget the business part a lot, which is like, and then these 880 00:42:46,920 --> 00:42:49,360 are the people that are going to fund your initiative. 881 00:42:49,600 --> 00:42:52,200 These are the people that have the money, these are the 882 00:42:52,200 --> 00:42:55,600 decision makers, and these are the people you need to make 883 00:42:55,600 --> 00:42:57,880 happy so that your initiative keeps going. 884 00:42:58,640 --> 00:43:03,280 So I think that sometimes gets lost, but it's very good to 885 00:43:03,280 --> 00:43:05,880 always focus on that part as well, I would say. 886 00:43:06,320 --> 00:43:08,000 Gotcha. You know, don't lose your your 887 00:43:08,080 --> 00:43:10,560 champions from the business. Side you need the money, yeah. 888 00:43:10,880 --> 00:43:14,400 So yeah, and and don't don't build a cool platform. 889 00:43:14,520 --> 00:43:17,280 The other platform that developers want to use and will 890 00:43:17,280 --> 00:43:20,560 use in the end and for developers, help your platform 891 00:43:20,560 --> 00:43:23,480 team build something that they want that you want to use. 892 00:43:24,240 --> 00:43:25,400 Good stuff. I love it. 893 00:43:25,400 --> 00:43:27,120 Thanks guys. Thank you so much for coming on. 894 00:43:27,400 --> 00:43:28,760 This was a blast. Yeah, no worries. 895 00:43:28,960 --> 00:43:29,800 Thank you. Cool. 896 00:43:29,800 --> 00:43:32,000 We'll round off here. If you're still with us, let me 897 00:43:32,000 --> 00:43:33,920 know in the comments section what you thought of this episode 898 00:43:33,920 --> 00:43:34,880 and we'll see you on the next one.