1 00:00:05,120 --> 00:00:10,679 Hello, and welcome everyone to another episode of Adventures and DevOps. I'm warrnt 2 00:00:10,720 --> 00:00:14,480 Broad your host, and unfortunately Will will not be joining us today. He'll 3 00:00:14,480 --> 00:00:20,120 be back next week when he returns from his vacation spot on the other side 4 00:00:20,120 --> 00:00:27,920 of the world. But today I'd like to introduce from more than twenty years 5 00:00:27,960 --> 00:00:34,479 in the industry, experience in platforms and consulting and advisory in many different areas 6 00:00:35,799 --> 00:00:43,039 work with the CNCF. With us today is David Stenglai, who great to 7 00:00:43,079 --> 00:00:47,280 be here. Yeah, thanks for joining us. You know, originally you 8 00:00:47,320 --> 00:00:52,679 said that we could talk anything about platforms, and this is actually a really 9 00:00:52,719 --> 00:00:57,079 interesting topic because a couple of weeks ago I had brought up that meeting with 10 00:00:57,320 --> 00:01:00,920 a bunch of DevOps folks experience in the industry. We were actually trying to 11 00:01:00,920 --> 00:01:07,280 define what platforms actually are, like what is what counts as a platform And 12 00:01:07,599 --> 00:01:11,280 one of those conversations, the one of the co authors from Team Topologies was 13 00:01:11,280 --> 00:01:18,480 suggesting that everything's a platform. And if everything's a platform, then I think 14 00:01:18,519 --> 00:01:22,319 there is this sort of a fear that it's very difficult to define. Maybe 15 00:01:22,319 --> 00:01:23,840 it's sort of one of those things that you, I know, when I 16 00:01:23,879 --> 00:01:29,480 see it, but you know, what it actually is can be difficult to 17 00:01:29,719 --> 00:01:34,359 identify and practice. What do you think? Uh yeah, And I kind 18 00:01:34,359 --> 00:01:40,040 of get where the team topologies people are coming from, especially with their minimum 19 00:01:40,159 --> 00:01:46,280 viable platform, right, they define documentation as a minimum viable platform. But 20 00:01:46,400 --> 00:01:51,560 I think when we think about and there are many different kinds of platforms, 21 00:01:52,319 --> 00:01:56,319 but we think about them a little differently over time, especially modern platforms. 22 00:01:56,760 --> 00:02:02,200 So I have a definition that is almost intentionally vague, but it kind of 23 00:02:02,280 --> 00:02:06,760 encompasses a lot of things and helps kind of determine what they are. And 24 00:02:06,799 --> 00:02:10,759 that is that a platform is a system that allows you to build things and 25 00:02:10,919 --> 00:02:16,360 gives them a home a place to run. And the other side of it 26 00:02:16,439 --> 00:02:23,199 is a platform either abstracts or completely captures work that the user of the platform 27 00:02:23,240 --> 00:02:29,520 would otherwise need to do. And so and that's it, because that is 28 00:02:29,560 --> 00:02:35,039 the basics of a platform, and it's it's kind of vague in general like 29 00:02:35,080 --> 00:02:39,439 that, because there's a lot of commonalities between what we think of as like 30 00:02:39,759 --> 00:02:44,800 end user platforms like an uber or something like that, and internal platforms. 31 00:02:45,520 --> 00:02:49,000 Where it gets a little different is you know whether or not you have like 32 00:02:49,080 --> 00:02:55,919 that network producer consumer. You know, network effect type thing going on in 33 00:02:57,240 --> 00:03:02,719 internal platforms, and it can happen. But you know, the reason I 34 00:03:02,840 --> 00:03:07,520 like this definition is I feel like I've been working on platforms for nearly thirty 35 00:03:07,599 --> 00:03:10,360 years. As an operating system, as a platform, you know, as 36 00:03:10,400 --> 00:03:15,919 a modern developer, even think about what the layout of blocks on disc is 37 00:03:15,680 --> 00:03:21,639 or how memory is managed for them, you know, out of system like 38 00:03:22,080 --> 00:03:24,520 that's a that to me is a platform. An operating system is something I 39 00:03:24,520 --> 00:03:30,560 can build and run on without having to worry about really low level stuff. 40 00:03:30,159 --> 00:03:35,680 But platforms kind of accrete over time, right, you know, they get 41 00:03:35,719 --> 00:03:38,680 pushed down lower and lower, and like twenty twenty five, thirty years ago, 42 00:03:38,759 --> 00:03:44,039 we used to care a lot more about how processes were managed and how 43 00:03:44,719 --> 00:03:49,400 discs were laid out, And you know, there's only a very specialized few 44 00:03:49,400 --> 00:03:53,520 people who actually still care about that because we've built layers on top of it. 45 00:03:53,599 --> 00:03:59,560 So the definition of platform is a moving target. Over time, we 46 00:03:59,599 --> 00:04:02,639 expect more and more to get pushed down below us and to be able to 47 00:04:02,680 --> 00:04:08,599 work with higher and higher abstractions. So to say everything is a platform, 48 00:04:09,719 --> 00:04:18,120 I wouldn't necessarily say that. I do agree that a minimum viable platform or 49 00:04:18,279 --> 00:04:24,160 minimum viable set of tools could include just documentation for a small group of people. 50 00:04:25,439 --> 00:04:30,199 But when you get to a modern platform that is especially now being defined 51 00:04:30,240 --> 00:04:36,040 around self service, right, you know, the criteria for it is a 52 00:04:36,079 --> 00:04:43,720 little different. And I think the distinction comes in between application and platform where 53 00:04:43,720 --> 00:04:48,560 it gets really fuzzy. Right. So take Minecraft. Minecraft is a platform 54 00:04:48,639 --> 00:04:53,800 you can build stuff and run on top of it, right. But another 55 00:04:53,879 --> 00:04:59,079 game, like you know, a multiplayer with no extensibility, Well, that's 56 00:04:59,160 --> 00:05:03,360 that's an application. You might build much more, you know, high level 57 00:05:03,519 --> 00:05:09,959 conceptual things like clans or something like that on a game, but you don't 58 00:05:09,959 --> 00:05:14,160 get to build arbitrary things like you can in Minecraft. Right, people built 59 00:05:14,240 --> 00:05:17,519 airplanes, computers. I think there's someone who wrote Doom to run inside of 60 00:05:17,560 --> 00:05:23,560 Minecraft. Right, so you know that's the proof of any sort of computer. 61 00:05:23,560 --> 00:05:27,519 It cannot run Doom. And so if it can run Doom, maybe 62 00:05:27,560 --> 00:05:30,240 that's a definition I never thought of. If it can run Doom, it's 63 00:05:30,279 --> 00:05:34,560 a platform, right. I mean, I think building on top of is 64 00:05:34,600 --> 00:05:40,439 an interesting way of looking at it, because even at very slow processing speeds, 65 00:05:40,800 --> 00:05:44,720 you could make any sort of chat interface run Doom. Right, So 66 00:05:46,000 --> 00:05:51,519 I think I like that because it makes the distinction between we're running the thing 67 00:05:51,759 --> 00:05:57,920 and it's running on top of something else. You didn't mention that. You 68 00:05:58,000 --> 00:06:02,680 feel like the attention to some of the lower level platforms is not We don't 69 00:06:02,680 --> 00:06:08,560 pay attention to it as much anymore. Is it because it's been highly optimized 70 00:06:08,600 --> 00:06:12,759 and there aren't a lot of further ways that we can take that, or 71 00:06:12,920 --> 00:06:15,720 is it that there's now a lot of different layers, a lot of different 72 00:06:15,720 --> 00:06:18,720 abstractions that people are paying more and more attention to. It's because we can't, 73 00:06:19,199 --> 00:06:25,800 right, you know, one of the earlier parts of platforms and computing 74 00:06:25,959 --> 00:06:30,879 was escaping assembly language, right, you know, And there are still people 75 00:06:30,879 --> 00:06:35,480 who work in assembly language, of course, but you can't manage higher and 76 00:06:35,560 --> 00:06:43,519 higher levels of abstraction while needing to know how to do everything at every level. 77 00:06:43,759 --> 00:06:46,839 I think it's important to understand how computers work, how like how the 78 00:06:46,920 --> 00:06:53,920 things work, But having the skill to work at all those levels doesn't really 79 00:06:53,959 --> 00:06:56,720 add up, right, So like, when you call yourself a full stack 80 00:06:56,759 --> 00:07:04,040 developer, you're probably not writing assembly right because you couldn't maintain your ability to 81 00:07:04,199 --> 00:07:10,000 work on higher level problems and all that low level stuff. You wouldn't be 82 00:07:10,079 --> 00:07:15,319 very productive. So I think it's it's to some degree optimized because I've had 83 00:07:15,360 --> 00:07:19,079 a long time to figure out how to manage discs, how to manage memory. 84 00:07:19,240 --> 00:07:24,000 You know, Linux is I came from a background of Unix when it 85 00:07:24,079 --> 00:07:27,920 wasn't Linux didn't even I wouldn't say it didn't exist, but it was not 86 00:07:28,040 --> 00:07:31,959 allowed to be used in most you know, sort of corporate environments. And 87 00:07:32,040 --> 00:07:36,839 so we were managing like five different flavors of Unix systems. And now it's 88 00:07:36,839 --> 00:07:43,360 consolidated and that level of abstraction to the operating system right is simplified. You 89 00:07:43,399 --> 00:07:46,800 know, you don't have to figure out where AUK is on like five different 90 00:07:46,879 --> 00:07:51,879 kinds of systems, So that that it's almost the necessity for us to be 91 00:07:51,920 --> 00:07:58,360 able to move up to higher level things to build on top that, even 92 00:07:58,399 --> 00:08:01,800 though they might be able to be optimized, we can't look at that. 93 00:08:01,079 --> 00:08:05,680 Now. The flip side of that is we tend to accrete things and get 94 00:08:05,720 --> 00:08:11,279 away from them and not optimize them, and we end up with our platform 95 00:08:11,399 --> 00:08:16,879 potentially being really bloated underneath us because we're not paying full attention to the cost 96 00:08:16,079 --> 00:08:20,040 of the abstraction that we're doing, right, And so you know, there's 97 00:08:20,040 --> 00:08:24,720 a necessity to go through sometimes and figure out, like those few people who 98 00:08:24,879 --> 00:08:28,560 understand, go down through the layers and figure out are we making the best 99 00:08:28,639 --> 00:08:33,159 use of this because hardware keeps getting so much faster, right, but yet 100 00:08:33,159 --> 00:08:37,679 we still manage to run at the same speed. Right, So we're doing 101 00:08:37,759 --> 00:08:45,559 something in order to like add new stuff but not make it more efficient that 102 00:08:45,919 --> 00:08:50,320 you know, for all that we've increased, I found an SD card that 103 00:08:50,480 --> 00:08:52,639 was two hundred and fifty six megs the other day, Right, you can 104 00:08:52,639 --> 00:08:56,759 get a terabyted SD card pretty easily now. And the fact that we were 105 00:08:56,799 --> 00:09:03,559 able to do so much and such constrain and environments and get things done and 106 00:09:03,639 --> 00:09:09,320 responsive, and now we've added so much and we've got our slack clients like 107 00:09:09,399 --> 00:09:16,720 crushing computers and adding up to responsiveness that is just still in the similar range. 108 00:09:18,000 --> 00:09:22,159 Right. So that's one of the risks of abstracting like that over time. 109 00:09:24,799 --> 00:09:26,600 I mean, you said something about that, and actually it sort of 110 00:09:26,600 --> 00:09:31,279 triggered me thinking if we add more levels of abstraction, can we still be 111 00:09:31,320 --> 00:09:35,679 in that situation where we understand enough about the stack in order to make optimizations 112 00:09:35,679 --> 00:09:39,000 like, I feel like I've heard a lot over my career. Oh, 113 00:09:39,000 --> 00:09:41,240 but we still need to know how assembly is going to get built, because 114 00:09:41,240 --> 00:09:46,159 there's optimizations that we could be making at higher levels if we know about that, 115 00:09:46,440 --> 00:09:50,519 And I feel like that's sort of eroded over time because the number of 116 00:09:50,559 --> 00:09:54,720 abstraction layers has definitely increased. I think there has been some return to that 117 00:09:56,320 --> 00:10:00,200 with like eBPF at the networking level, like sort of, okay, there 118 00:10:00,200 --> 00:10:03,440 are optimizations here, or there are things that we need to know at the 119 00:10:03,519 --> 00:10:07,799 lower levels inside the operating system, and we have multiple platforms on top of 120 00:10:07,799 --> 00:10:11,600 it, it's very difficult to see that. But I like you said assembly, 121 00:10:11,600 --> 00:10:13,600 I mean it even goes lower, like people aren't going to know exactly 122 00:10:13,600 --> 00:10:16,759 how to stack the silicon to make the transist. Well, yeah, and 123 00:10:18,360 --> 00:10:20,519 maybe some of those layers will need to go away, Like I think WLASM 124 00:10:20,559 --> 00:10:26,639 will have a big impact on the intermediate layers, Like I think you're going 125 00:10:26,720 --> 00:10:30,120 to see a whole lot wiped out once it's going to take a few more 126 00:10:30,240 --> 00:10:35,360 years, but once you have WAZI components. So that's a good acronym stop 127 00:10:35,480 --> 00:10:41,279 right. LASM is a web called web assembly and it's essentially an instruction set 128 00:10:41,440 --> 00:10:50,559 that allows browsers or originally browsers, to run sort of arbitrary code as opposed 129 00:10:50,639 --> 00:10:58,519 to you know, specific HTML and JavaScript and type stuff, so you can 130 00:10:58,559 --> 00:11:03,320 compile you know, used to be you had to target C code, you 131 00:11:03,320 --> 00:11:07,919 know, compiled code at a specific architecture and run it on that specific architecture, 132 00:11:09,279 --> 00:11:13,480 and WASM allows you to compile C code or other code that you normally 133 00:11:13,519 --> 00:11:18,919 targets real machines to run on a web browser or a node dass back end. 134 00:11:20,440 --> 00:11:22,080 It's been around for a while and people have been waiting for it to 135 00:11:22,279 --> 00:11:26,960 kind of like you know, become more prevalent, and it's been slow to 136 00:11:28,000 --> 00:11:31,240 develop, but in a I think a good way, they're being considered because 137 00:11:31,360 --> 00:11:35,399 you know, they're there. There have been a lot of provisional standards of 138 00:11:35,440 --> 00:11:39,759 things that get partially released and then you end up with lots of like incompatible 139 00:11:41,000 --> 00:11:45,799 implementations of things. So it's good that they're if they're building a universal format 140 00:11:45,879 --> 00:11:48,960 for running code that they you know, they take their time, and one 141 00:11:48,960 --> 00:11:58,919 of the big advancements that they've had recently is having high level an interface definition 142 00:11:58,000 --> 00:12:03,960 language with high level types between WASM modules so you'll be able to have a 143 00:12:05,080 --> 00:12:11,399 runtime with Python, Rust c code all interoperating with each other through the WASM 144 00:12:11,480 --> 00:12:16,799 runtime using high level types and not needing all those languages to know directly how 145 00:12:16,840 --> 00:12:20,600 to talk to each other or in bed or things like that. So, 146 00:12:20,720 --> 00:12:26,120 like all of the composition stuff that we do now in order to create software 147 00:12:26,759 --> 00:12:33,759 and either like making stubs for specific language run times or using even containers right 148 00:12:33,919 --> 00:12:37,600 like and saying oh, I need a sidecar and need another complete copy of 149 00:12:37,639 --> 00:12:41,799 Linux with its own libraries and all this other stuff, when really I just 150 00:12:41,840 --> 00:12:48,080 want this HTTP server with this specific kind of way of working that sort of 151 00:12:48,159 --> 00:12:52,879 thing. That complexity will go away, and the WASM runtime will actually run 152 00:12:52,440 --> 00:12:58,720 HTTP between components with no network involved. So you'll get down to like nanosecond 153 00:12:58,799 --> 00:13:03,679 lay incies for making HDCP calls between components. They'll all be in the same 154 00:13:03,759 --> 00:13:11,679 run time, and you will eliminate all of that network and operating system stuff 155 00:13:11,159 --> 00:13:16,039 that allows us to do composition now. And so I think that will a 156 00:13:16,080 --> 00:13:20,960 lot of its own complexities, right, but it will also eliminate a whole 157 00:13:20,960 --> 00:13:24,200 air of stuff that we're dealing with now to build software, which is I 158 00:13:24,240 --> 00:13:30,519 have to deal with a whole lot of operating system stuff and Docker and you 159 00:13:30,519 --> 00:13:35,039 know, all this other understanding when you know, I'd like to just be 160 00:13:35,360 --> 00:13:39,080 working in terms of higher level application tools, and so I think that kind 161 00:13:39,080 --> 00:13:45,360 of compaction is what we get over time. So like we figure out this 162 00:13:46,200 --> 00:13:50,039 set of platform layers. We're working with this now, but it may not 163 00:13:50,159 --> 00:13:56,080 become part of the permanent, you know, strata underneath us because it hasn't 164 00:13:56,120 --> 00:14:01,320 proven itself, and we're going to go some other direction and maybe eliminate that 165 00:14:01,399 --> 00:14:03,679 layer, try an alternative, and then eventually, like Linux became, you 166 00:14:03,759 --> 00:14:09,080 know, the sort of standard operating system substrate, right, and it took 167 00:14:09,120 --> 00:14:13,440 a long time to get that consolidated and sort of decided as an industry. 168 00:14:15,440 --> 00:14:16,480 No, I totally get that. I mean it makes a lot of sense 169 00:14:16,480 --> 00:14:20,080 actually when you if you're thinking about where the future of a particular component is 170 00:14:20,120 --> 00:14:24,279 going. And I've this isn't the first time I've heard web assembly. I 171 00:14:24,320 --> 00:14:28,559 think I've been brought up on a lot of teams I've led in the last 172 00:14:28,600 --> 00:14:31,559 decade, and it's always been like it's still too early in a way to 173 00:14:31,600 --> 00:14:37,000 have these modules built and then running. Even if you're you know, using 174 00:14:37,000 --> 00:14:41,159 the website, and historically it was there weren't bindings available, but the idea 175 00:14:41,240 --> 00:14:45,039 that Okay, we're trying to figure out where the top of the pyramid is, 176 00:14:45,679 --> 00:14:48,120 where the actual application, where the actual value is, and the interoperability 177 00:14:48,159 --> 00:14:52,799 between modules that could be built in any language and then run only at run 178 00:14:52,840 --> 00:14:56,799 time proves okay, we sort of figured out a success path here. You 179 00:14:56,799 --> 00:14:58,840 know. Now, let's get rid of all the crowd that doesn't directly deliver 180 00:14:58,919 --> 00:15:05,399 it that execution platform and focus on that. Rebuild it, rebuild what the 181 00:15:05,399 --> 00:15:11,840 browser is offering potentially, and get to the point where we can deliver the 182 00:15:11,879 --> 00:15:16,000 application on top of it. Yeah. One of the one of the sort 183 00:15:16,039 --> 00:15:24,120 of byproducts of web assembly that's been kind of useful already and probably increase is 184 00:15:24,240 --> 00:15:31,480 the access to the GPU from web assembly is starting to become standardized, which 185 00:15:31,519 --> 00:15:37,519 means that writing code to talk to the GPU gets drastically simpler. So like 186 00:15:37,639 --> 00:15:41,440 right now, in order to talk to a GPU, you need, like, 187 00:15:41,000 --> 00:15:46,120 you know, you need the library specific to that GPU, you need 188 00:15:46,159 --> 00:15:48,799 a lot of library, you need a lot of code, And now it's 189 00:15:48,799 --> 00:15:54,080 becoming easier to just write some rust code that uses the GPU in a fairly 190 00:15:54,240 --> 00:15:58,480 compact way without requiring you know, a half a gig or a gigb library 191 00:15:58,519 --> 00:16:03,639 downloads in order to get to it. So you know that that was done 192 00:16:04,000 --> 00:16:10,039 before AI was really prevalent, but like it's already sort of yielding some dividends 193 00:16:10,080 --> 00:16:15,080 in terms of simplifying being able to run, you know, and that you 194 00:16:15,080 --> 00:16:18,279 could think of that as a platform, Like that platform stack for running AI 195 00:16:18,399 --> 00:16:22,279 tools is enormous, but people have been working on sort of compacting it down, 196 00:16:22,399 --> 00:16:30,720 like the Mozilla Foundation has. They call it Lama file and it is 197 00:16:30,759 --> 00:16:37,080 a single binary solution for running a local LLM, and it comes It's essentially 198 00:16:37,120 --> 00:16:44,240 a very fancy self extracting shell script with a bunch of zips in it and 199 00:16:44,320 --> 00:16:49,360 a new kind of lips that will run the same four gig binary includes all 200 00:16:49,399 --> 00:16:53,840 the model weights and the binaries to run on Windows, mac Os, Linux, 201 00:16:55,519 --> 00:17:00,320 ARM and x eighty six. To just download this thing, make it 202 00:17:00,360 --> 00:17:04,160 executable and run it wherever you are, and suddenly you have you know, 203 00:17:04,440 --> 00:17:10,000 Olama running or sorry, open lama. This All of these things are named 204 00:17:10,079 --> 00:17:14,720 so similarly, right, it's like all some play on Lama. Olama is 205 00:17:14,759 --> 00:17:21,599 another system for running local LMS that's not related and they kind of make it 206 00:17:21,640 --> 00:17:26,359 easy, but they go through that gig download of just libraries. So like 207 00:17:26,400 --> 00:17:30,880 that's another like platform stack that's just going to like get squashed. And right 208 00:17:30,920 --> 00:17:37,799 now, understanding what's going on in terms of at least the software platform really 209 00:17:37,799 --> 00:17:42,920 difficult, right, But if you can squash down those layers into I just 210 00:17:44,000 --> 00:17:49,759 need you know, we're in that kind of turbulent situation of extreme innovation where 211 00:17:51,119 --> 00:17:55,599 everyone's just utilizing things from everywhere else and then in a few years it'll settle 212 00:17:55,640 --> 00:17:59,799 down and it'll be a little easier to understand what's going on because it'll standardize. 213 00:18:00,039 --> 00:18:03,559 It will be a much slimmer way of getting things done. I mean 214 00:18:03,640 --> 00:18:07,400 that seems like some like a great foresight there. Like I think everyone knows 215 00:18:07,519 --> 00:18:11,119 that the fads are going to end at some point and there's going to be 216 00:18:11,440 --> 00:18:15,559 what is left act the actual innovation. But that puts a name on it, 217 00:18:15,640 --> 00:18:18,839 right, It's it's that we are searching for the optimal usage here and 218 00:18:18,920 --> 00:18:22,440 when someone figures it out, all those other things will go away. And 219 00:18:22,480 --> 00:18:26,240 we're actually seeing this sort of playout what's happening right now? Yeah, right 220 00:18:26,279 --> 00:18:30,559 for sure? And I think there's a huge speed component as well, because 221 00:18:30,640 --> 00:18:33,400 unlike web assembly and the layers that came before it, which I want to 222 00:18:33,440 --> 00:18:38,200 say are things like infrastructure as code, especially in the develop space, there's 223 00:18:38,440 --> 00:18:45,400 a lot of companies putting a huge amount of financial capital behind quickly investing in 224 00:18:45,480 --> 00:18:52,000 hoping to both be the first and also most successful getting whatever it is user 225 00:18:52,000 --> 00:18:59,319 percentage numbers. So any thoughts like so I do I have? I think 226 00:18:59,359 --> 00:19:04,519 the there's a hype curve, right, and I wrote a blog post about 227 00:19:04,559 --> 00:19:08,079 it recently. Was they kept seeing, you know, the industry is just 228 00:19:08,119 --> 00:19:14,559 constantly one hype cycle after another, and you know, part of the Gartner 229 00:19:14,640 --> 00:19:17,839 hype cycles, it looks like this, and then it goes like there's that 230 00:19:17,920 --> 00:19:23,119 trough of disillusionment and then it climbs into a slope of you know what they 231 00:19:23,119 --> 00:19:30,640 call the the plateau of productivity or something like that, right, And there 232 00:19:30,680 --> 00:19:36,200 are some hype cycles which don't seem to result in a plateau of productivity. 233 00:19:36,960 --> 00:19:41,400 They just seem to come through like a wave, but then drop back down 234 00:19:41,400 --> 00:19:45,880 again and not everyone catches it. And I think micro services are an example 235 00:19:45,920 --> 00:19:55,279 of that. There's in larger, slower moving organizations micro services have not really 236 00:19:55,359 --> 00:20:00,920 had that much benefit and potentially even been detrimental, like had almost the opposite 237 00:20:00,960 --> 00:20:07,880 effect of making systems far more complex and just as slow and maybe even more 238 00:20:07,920 --> 00:20:11,279 dangerous than you know, the previous legacy systems that we're there. If you 239 00:20:11,359 --> 00:20:15,440 contrast that with something like big data, you know, big data as like 240 00:20:15,599 --> 00:20:22,559 the lifeblood of so many companies now and it and the difference between those two 241 00:20:22,680 --> 00:20:26,559 things, if you look at is business value, right, you know, 242 00:20:26,720 --> 00:20:34,359 big data was easy to translate into business value. Microservices is just a technical 243 00:20:34,559 --> 00:20:41,400 solution to things, and there can be business value to it, but it 244 00:20:41,440 --> 00:20:47,039 didn't originate necessarily there, and it was to solve an engineering problem and an 245 00:20:47,160 --> 00:20:56,240 organizational a socio technical issue, and that ability to move fast I think ends 246 00:20:56,319 --> 00:21:03,480 up being important but sometimes overplayed. So it's especially weird in a time like 247 00:21:03,559 --> 00:21:11,000 now when we have AI making everything move so much faster that there's this like 248 00:21:11,200 --> 00:21:18,240 big gap opening up between large and small players to the point where it's been 249 00:21:18,559 --> 00:21:26,319 you know, we're eighteen months little like maybe what twenty months in and the 250 00:21:26,359 --> 00:21:32,279 big players are trying to keep up and they're adopting things that are already legacy, 251 00:21:33,200 --> 00:21:37,240 right, So lang chain took so much mind share early on, and 252 00:21:37,279 --> 00:21:41,440 then they got a hold out of the thought Works radar, right, one 253 00:21:41,480 --> 00:21:45,759 of the few things on the recently published radar that was actually a hold and 254 00:21:45,119 --> 00:21:51,519 it it just it probably hit it right at the point where a lot of 255 00:21:51,519 --> 00:21:56,440 companies were finally ready to start like adopting tools like that. And so like 256 00:21:56,640 --> 00:22:03,359 all of this continuous disruption and figuring out out has a natural cost to it, 257 00:22:03,440 --> 00:22:06,960 and I think everyone wants to move fast, but they're going to end 258 00:22:07,039 --> 00:22:11,200 up wasting quite a bit in order to figure that out. And I think 259 00:22:11,240 --> 00:22:15,440 the companies that are more experimental with that rather than saying, oh, we're 260 00:22:15,480 --> 00:22:18,680 going to define the standard and go, it's not a time to define standards. 261 00:22:18,160 --> 00:22:23,359 It's a time to experiment and figure out what works and learn more nimble 262 00:22:23,400 --> 00:22:29,000 approaches to business, right, Because there's still plenty of companies that don't know 263 00:22:29,039 --> 00:22:33,160 how to experiment. They only know let's put it through a bureaucratic process that 264 00:22:33,240 --> 00:22:41,200 gets us something to work with in eighteen months. For those that are generically 265 00:22:41,240 --> 00:22:47,400 moving slower and aren't interested in defining the space or even experimenting. Is this 266 00:22:47,440 --> 00:22:51,160 the sort of thing where there's a lot of value in waiting and waiting it 267 00:22:51,200 --> 00:22:55,359 out, hopefully seeing where the leaders are and either I don't know, purchasing 268 00:22:55,400 --> 00:23:00,759 them through acquisitions or buying their products or partnering with them going forward, or 269 00:23:00,839 --> 00:23:04,480 is there still room everywhere for companies that are invested in technology in some way 270 00:23:04,559 --> 00:23:10,319 to also be experimenting. I think there are ways to experiment. I think 271 00:23:10,680 --> 00:23:15,720 banking on things is a little tough right now. And there's an old saying 272 00:23:17,039 --> 00:23:21,599 I wish I could attribute it, but used to you know, encouraging people 273 00:23:21,599 --> 00:23:29,480 to use boring technology. Right it's it gets dangerous and it is an important 274 00:23:29,480 --> 00:23:41,039 bit with platforms. If you throw too many sort of modern or non commodity 275 00:23:41,119 --> 00:23:45,400 things into your platform, you're going to end up with potentially a lot of 276 00:23:45,440 --> 00:23:51,200 parts that don't mesh very well together, and the experience of the users of 277 00:23:51,240 --> 00:23:56,960 your platform, both your internal and if you know, external users depend on 278 00:23:56,039 --> 00:24:02,000 it working, you know, well not be good. So you have to 279 00:24:02,160 --> 00:24:04,440 make a trade off of you know, I'm going to go for modern things 280 00:24:04,680 --> 00:24:11,839 for part of this, because they are still you know, bespoke and new 281 00:24:11,920 --> 00:24:15,640 parts of that I can't get anywhere else. But you know, for these 282 00:24:15,680 --> 00:24:21,960 other things like the eighty percent, Right, I should be going for commodity 283 00:24:22,000 --> 00:24:26,960 items and not you know, overburden myself with too many new things at the 284 00:24:26,000 --> 00:24:30,920 same time. So yeah, there's there's plenty to be gained for you know, 285 00:24:32,119 --> 00:24:34,839 mL and AI have been around for a long time, right, It's 286 00:24:36,920 --> 00:24:40,920 everyone wants to make it the core of everything. But you know, if 287 00:24:40,960 --> 00:24:45,599 you take a somewhat more experimental approach and figure out where the areas I could 288 00:24:45,680 --> 00:24:51,240 use it that are truly differentiating for my business as opposed to like a you 289 00:24:51,279 --> 00:24:55,319 know, a lot of executives are looking at AIS and cost savings, right, 290 00:24:56,000 --> 00:25:00,480 and it's not it's certainly not at the point of being that it is. 291 00:25:00,640 --> 00:25:03,799 It's a first mover advantage, not a cost savings right now, and 292 00:25:03,839 --> 00:25:11,039 when it's a first mover advantage that is almost like the opposite of being a 293 00:25:11,079 --> 00:25:15,640 cost saver. Those are people who are willing to put money into things in 294 00:25:15,759 --> 00:25:22,880 order to gain an advantage. There's a story from Simon Wordley about the beginning 295 00:25:22,920 --> 00:25:29,240 of cloud and how the cloud vendors were selling you know, corporations and such 296 00:25:29,400 --> 00:25:33,920 just you know, adopting cloud will save you money, right, And the 297 00:25:33,200 --> 00:25:38,920 first company to decide to use the cloud to accelerate basically threw that out the 298 00:25:38,960 --> 00:25:44,480 window because everyone else had to use the cloud to accelerate and therefore not save 299 00:25:44,559 --> 00:25:48,000 money. Right, So the same kinds of things play out with AI. 300 00:25:48,640 --> 00:25:52,559 You know, using AI to save money will only work if everyone decides to 301 00:25:52,599 --> 00:25:56,599 do it that way. If someone uses it to accelerate past you, well 302 00:25:56,680 --> 00:26:00,039 you're probably going to be forced to do the same thing. Yeah, that's 303 00:26:00,079 --> 00:26:03,240 for sure the case. I mean, I remember thinking about when awos came 304 00:26:03,279 --> 00:26:07,440 out. It wasn't it wasn't for everyone in a way. It was, 305 00:26:07,759 --> 00:26:11,160 oh, look at all these companies that are maybe in startup land where the 306 00:26:11,200 --> 00:26:14,759 tools they had were not really that effective, and we would just take all 307 00:26:14,799 --> 00:26:19,279 of that work, all of the capital expenditures that they would need to purchase 308 00:26:19,599 --> 00:26:25,279 physical machines, data centers, et cetera, and just immediately eliminate it. 309 00:26:25,319 --> 00:26:30,960 And for sure there is a capital expenditure sort of savings. They are cost 310 00:26:30,960 --> 00:26:36,359 savings, but realistically, for sure it's on the speed side. Yeah, 311 00:26:36,400 --> 00:26:42,279 and that you know, aws and cloud providers are mashing. You know, 312 00:26:42,319 --> 00:26:48,759 they are platforms. They've grown in scope to where they're not always the best 313 00:26:49,519 --> 00:26:56,759 self service platform for your internal developers, and they did originally try and sort 314 00:26:56,799 --> 00:27:03,880 of pitch that, but it gets messy really fast. But they did bring 315 00:27:03,920 --> 00:27:10,440 the whole concept of self service IT and computing to the four And what they 316 00:27:10,440 --> 00:27:14,960 did is they eliminated all that human in the loop stuff that people in itad 317 00:27:14,960 --> 00:27:17,319 traditional Like I want to set up an app, all right, I got 318 00:27:17,359 --> 00:27:21,759 to talk to procurement and get the hardware. I've got to get a team 319 00:27:22,359 --> 00:27:26,440 that will set it up for me. I will get another team to set 320 00:27:26,519 --> 00:27:29,359 up other stuff on top, and like, you go through this whole process, 321 00:27:29,400 --> 00:27:32,680 whereas they made it all right, you make an API call and we'll 322 00:27:32,680 --> 00:27:36,400 give you a database, right, and you don't have to go through months 323 00:27:36,599 --> 00:27:41,680 and many different teams. So that aspect of platforms has kind of been trained 324 00:27:41,720 --> 00:27:48,119 in from an early point in cloud. I think the difficulty is translating that 325 00:27:48,279 --> 00:27:53,440 between what cloud providers are sort of able to do and what organizations need to 326 00:27:53,480 --> 00:28:00,640 do either on top or beside that to provide a similar level of experience that 327 00:28:00,839 --> 00:28:06,559 is like specialized to what that organization needs. And you know, the people 328 00:28:06,759 --> 00:28:11,079 working on the cloud providers, they're all developers. They're used to building and 329 00:28:12,160 --> 00:28:18,839 systems that work as systems, whereas it people are not developers like systems, 330 00:28:18,880 --> 00:28:26,160 people glue things together. They don't build, you know, rock solid solutions 331 00:28:26,200 --> 00:28:29,400 that they can present as an API to people. And that's been some of 332 00:28:29,400 --> 00:28:33,039 the gap of platforms being adopted internally, is that, you know, it's 333 00:28:33,079 --> 00:28:37,960 been a phase of adapting to oh, I need to build a rock solid 334 00:28:38,079 --> 00:28:47,720 product. Now I can't just make this one narrow automation of some specific task. 335 00:28:48,400 --> 00:28:51,359 I need to make something other people can build on. That's a very 336 00:28:51,400 --> 00:28:56,839 different approach to things than what it is traditionally used to So it's taken time 337 00:28:56,920 --> 00:29:02,039 for that to filter out, and then you have vendors flooding into the space 338 00:29:02,160 --> 00:29:07,960 to try and make this easier for people to do and kind of build that 339 00:29:07,279 --> 00:29:12,200 product mindset as a product. But if you don't have the mindset of building 340 00:29:12,400 --> 00:29:18,440 products to begin with, you can misuse tools. I mean, the same 341 00:29:18,480 --> 00:29:22,359 thing happens with all of our other like sort of micro services and cloud. 342 00:29:23,359 --> 00:29:27,759 If you keep the wrong mindset, you'll just do data center in the cloud. 343 00:29:29,359 --> 00:29:32,400 If you keep the wrong mindset with micro services, you'll just make a 344 00:29:32,440 --> 00:29:37,559 giant distributed monolith. If you go and keep an old it mindset with platforms, 345 00:29:37,920 --> 00:29:44,359 maybe you're going to require a ticket submitted right that you use the platform 346 00:29:44,400 --> 00:29:48,440 on behalf of the user. So you know, there's a there's a continual 347 00:29:48,759 --> 00:29:53,359 like change in how we do things, but we tend to carry some of 348 00:29:53,400 --> 00:30:00,200 our existing ways of getting things done forward that is not usually pretty health think, 349 00:30:00,079 --> 00:30:03,440 yeah, for sure, that's a pretty good insight. I think. 350 00:30:03,559 --> 00:30:06,079 I mean, we're all we're talking about, and so you know you've nailed 351 00:30:06,119 --> 00:30:11,920 the web browser is for sure a platform for running code modules of all kinds, 352 00:30:11,960 --> 00:30:18,599 especially through web assembly, cloud AI? Are there we say there are 353 00:30:18,599 --> 00:30:22,720 platforms everywhere? Are there other prominent areas of tech that sort of encompass this 354 00:30:23,160 --> 00:30:26,680 that you know are constantly on your mind? Or you know, these are 355 00:30:26,720 --> 00:30:32,599 the big three? So I think the the thing that doesn't get as much 356 00:30:32,599 --> 00:30:38,880 attention is the actual you know, we call them internal developer platforms, but 357 00:30:40,599 --> 00:30:47,960 what we mean are portals to platforms in most cases. Right, But until 358 00:30:47,960 --> 00:30:52,839 WASM becomes really widespread, I still think we have the issue of what is 359 00:30:52,880 --> 00:30:59,480 the environment that the developer actually works in and builds and runs in. And 360 00:30:59,799 --> 00:31:03,480 there's a whole there's a giant stack in there that I don't think it's quite 361 00:31:03,599 --> 00:31:11,680 enough attention because a lot of the platform thinking happens from the system side and 362 00:31:11,880 --> 00:31:17,319 not always the developer side. So systems people think, well, you know, 363 00:31:17,440 --> 00:31:19,400 once I get Tomcat installed, you're good, right, Or once I 364 00:31:19,440 --> 00:31:22,960 get the OS installed, you know, it's all Tomcat and then you're good, 365 00:31:22,559 --> 00:31:27,599 and Tomcat or whatever or node or whatever environment is just it's just a 366 00:31:27,759 --> 00:31:32,960 very base layer, and we've been trying to accommodate them with more and more 367 00:31:33,000 --> 00:31:37,839 of the pipes, with meshes and stuff like that. But there is a 368 00:31:37,920 --> 00:31:45,640 whole aspect of building applications that could benefit from platforms in terms of, well, 369 00:31:45,759 --> 00:31:48,240 I need to talk to a database, how about I talk to it 370 00:31:48,279 --> 00:31:53,839 in a standardized way that's appropriate for my organization and what our local standards are 371 00:31:53,880 --> 00:32:00,559 and how we've architected for talking to databases. And that bit is kind of 372 00:32:00,839 --> 00:32:07,200 not as doesn't get as much attention because it always feels like some of these 373 00:32:07,759 --> 00:32:10,720 you know, evolutions or revolutions always get pushed from one side of the house, 374 00:32:12,519 --> 00:32:15,920 right, and they therefore there isn't necessarily this kind of balanced view. 375 00:32:16,400 --> 00:32:20,839 So I think there are plenty of areas like that in the you know, 376 00:32:21,000 --> 00:32:24,839 data I've had a few people ask is a is a data system a platform? 377 00:32:24,880 --> 00:32:28,200 Like, of course it is, but they don't, you know, 378 00:32:28,240 --> 00:32:32,960 they feel hesitant to bring it up because they don't feel I'm not sure why, 379 00:32:34,119 --> 00:32:37,559 Like, you know, it's easy to build stuff on top of data 380 00:32:37,559 --> 00:32:42,839 platforms and therefore call it a platform. But there's this perception that if it's 381 00:32:42,880 --> 00:32:45,519 not kubernetas, it's not a platform, right, And that's one of the 382 00:32:45,519 --> 00:32:52,200 things I think is a bit difficult, is the idea that like platforms have 383 00:32:52,279 --> 00:32:57,400 to look a certain way rather than be a mindset about something for people to 384 00:32:57,440 --> 00:33:00,759 build them. No, I mean, I think that makes a lot of 385 00:33:00,759 --> 00:33:07,759 sense realistically, just getting stuck on the if it's not Kubernetes, it's it's 386 00:33:07,839 --> 00:33:12,319 not a platform. I mean, I think the answer here is that there 387 00:33:12,319 --> 00:33:16,559 were platforms before and there's got to be platforms like after that. Otherwise the 388 00:33:16,599 --> 00:33:21,359 word sort of doesn't have a lot of meaning. It's just alternative to that. 389 00:33:22,200 --> 00:33:27,559 Yeah, and it really you know. So I am involved in the 390 00:33:27,559 --> 00:33:32,119 CNCF Working Group for Platforms, and I've been a little hesitant to get involved 391 00:33:32,119 --> 00:33:38,880 with the CNCF because their definition of cloud native is containers in kubernets right, 392 00:33:38,960 --> 00:33:47,880 And my definition of cloud native goes well longer in history than that. Like, 393 00:33:49,000 --> 00:33:53,200 I'm more like the twelve factor app type cloud native, right. And 394 00:33:54,359 --> 00:34:00,799 the nice thing it's been is the Working Group for Platforms has been very open 395 00:34:00,839 --> 00:34:07,640 minded in terms of what a platform is defined as and what is important about 396 00:34:07,680 --> 00:34:13,119 a platform, and it has not been about kubernet As specifically, So I 397 00:34:13,119 --> 00:34:19,440 think there is some there is some movement towards, you know, figuring out 398 00:34:19,599 --> 00:34:25,119 what cloud native platforms look like without it being completely bound to kun Is because 399 00:34:25,400 --> 00:34:29,400 I think, you know, everyone says that the you know, cloud native 400 00:34:29,440 --> 00:34:32,199 is built on containers, but like I said, WASM could throw that completely 401 00:34:32,280 --> 00:34:37,880 out the window within five years or so, so you know, making yourself 402 00:34:37,920 --> 00:34:46,159 completely dependent on a container development environment, workflow and mindset for building distributed applications 403 00:34:47,000 --> 00:34:52,159 might not be the best approach. So I mean, it's good for the 404 00:34:52,199 --> 00:34:57,119 CNCF because they're so heavily invested in a kubernet Is based ecosystem, with a 405 00:34:57,159 --> 00:35:04,000 few other things possible. But I like that the Working Group for Platforms is 406 00:35:04,559 --> 00:35:09,360 more open minded than that, and you know, we're focused on making good 407 00:35:09,400 --> 00:35:15,920 habits and hygiene around how you work with people in an organization to decide, 408 00:35:16,000 --> 00:35:20,639 you know, what should we build and how do we deliver value better. 409 00:35:21,199 --> 00:35:29,119 So their their maturity model, which got published right around cupcom Chicago last fall. 410 00:35:29,719 --> 00:35:37,800 It doesn't mention text acts right, and there is some eagerness for technical 411 00:35:38,239 --> 00:35:44,199 content from this working group, but I believe it has to be delivered in 412 00:35:44,239 --> 00:35:46,639 such a way as to not It needs to be sort of like you know, 413 00:35:46,679 --> 00:35:51,440 a cloud provider has, like you'll read the documentation, they'll be tabs 414 00:35:51,480 --> 00:35:54,440 for each language and SDK you could use to I think that's sort of the 415 00:35:54,519 --> 00:35:59,719 way we need to go about it in terms of providing you know, not 416 00:35:59,840 --> 00:36:05,840 a specific reference implementation, but here's an approach you could take using two or 417 00:36:05,840 --> 00:36:12,079 three different options for making your platform code testable or something like that, right, 418 00:36:12,320 --> 00:36:16,480 and rather than picking a specific like you know, test kitchen for terror 419 00:36:16,480 --> 00:36:20,960 forms, like, show them a few different options and give them the mindset 420 00:36:21,159 --> 00:36:23,199 that they need to get into. I mean, I think that's a really 421 00:36:23,199 --> 00:36:28,840 interesting point. Containers took us a very far distance, and you know, 422 00:36:28,920 --> 00:36:31,599 so thank you to Ducker for that. We got the oci out, the 423 00:36:31,599 --> 00:36:36,920 full initiative and now it is for sure an open standard. But you brought 424 00:36:37,000 --> 00:36:39,840 up a point earlier on where you that's not even really what you want to 425 00:36:40,119 --> 00:36:44,800 have to run or deploy, right, You may just want the HDP interface, 426 00:36:45,199 --> 00:36:47,119 and you still have to sort of decide, Okay, what's my base 427 00:36:47,239 --> 00:36:50,239 image, you know, where does that come from? You're really still just 428 00:36:50,280 --> 00:36:53,559 building on top of operating system or other technology, and no one for sure 429 00:36:53,599 --> 00:36:58,239 actually really cares about that. And now we've got I mean, someone does, 430 00:36:58,360 --> 00:36:59,920 Like I don't want to want to throw that up. Someone does. 431 00:37:00,079 --> 00:37:04,079 Someone does, But we I think there was a I think in some ways 432 00:37:04,119 --> 00:37:06,960 Doctor took us a long way, but it also took us backwards too, 433 00:37:07,079 --> 00:37:17,639 interesting because there was a move to application paths like cloud Foundry h which is 434 00:37:17,760 --> 00:37:22,760 just sort of like a uh, you know, an installable version of like 435 00:37:22,800 --> 00:37:29,760 a Heroku. That did a lot of you know, really looked at concerns 436 00:37:30,159 --> 00:37:37,360 from the engineer's perspective, like you know, people building systems as opposed to 437 00:37:37,400 --> 00:37:43,679 platforms, and it took a lot into account for them and really focused you 438 00:37:43,679 --> 00:37:49,000 know, it's very user focused. And we went a little backwards because of 439 00:37:49,480 --> 00:37:52,719 I mean, there were some issues with running up a platform that way and 440 00:37:52,960 --> 00:37:58,360 that level of abstraction. We kind of decided a we didn't want that level 441 00:37:58,360 --> 00:38:02,960 of abstraction in that way, but also is a lot of cost and licensing 442 00:38:04,320 --> 00:38:08,719 involved in the decision to sort of back off to something like kubernets. And 443 00:38:08,760 --> 00:38:15,559 then organizations find out that they're giving up all of these pass style features and 444 00:38:15,840 --> 00:38:19,679 suddenly, like I know of one organization that's figured out, oh, we 445 00:38:19,719 --> 00:38:24,280 went over to kubernets, and we didn't realize that, Like every app deployed 446 00:38:24,440 --> 00:38:31,199 in cloud Foundry got a like a managed ravi at MQ right and they had 447 00:38:31,239 --> 00:38:35,719 a key. They didn't have to think about messaging for their app, and 448 00:38:35,800 --> 00:38:40,199 suddenly we moved them to kubernets, and we're forcing all these teams to figure 449 00:38:40,199 --> 00:38:44,639 out how to run hundreds of instances of you know, a queuing system. 450 00:38:45,400 --> 00:38:50,599 So I think there, you know, there's been a little bit of a 451 00:38:50,639 --> 00:38:57,079 backstep that wasn't even necessary in some cases, like for instance, take build 452 00:38:57,119 --> 00:39:01,360 packs. Buill packs are wonderful for not caring about you know, the container 453 00:39:04,639 --> 00:39:10,920 stuff down below, but and there it's possible to use them with containers, 454 00:39:12,440 --> 00:39:16,840 but nobody does, I mean, same organization that's on cloud Foundry for some 455 00:39:16,880 --> 00:39:22,800 reason, instead of figuring out build packs on kubernets just went with making everyone 456 00:39:22,800 --> 00:39:27,280 produce Docker files, right, and so like all of that work invested in 457 00:39:27,519 --> 00:39:30,920 making their apps run as build packs needed to be you know, pretty much 458 00:39:31,000 --> 00:39:37,360 redone in order to run on kubernetas. So so I do appreciate some of 459 00:39:37,400 --> 00:39:42,960 the stuff that we got out of Docker, Like I come from that, 460 00:39:43,159 --> 00:39:45,800 Like I said, that time of oh, figuring out how to package up 461 00:39:45,840 --> 00:39:51,360 software on several different operats, Like it's it's still an issue on LINEX how 462 00:39:51,400 --> 00:39:55,079 to package and distribute software. Docker does so much for that, but it's 463 00:39:55,239 --> 00:40:00,559 it's a lower level than we need to be for people to be productive building 464 00:40:00,800 --> 00:40:07,800 applications and business value. I sort of want to dive into that because there 465 00:40:07,840 --> 00:40:15,119 seems like a really interesting corollary here between what you want out of the application 466 00:40:15,880 --> 00:40:21,559 layer that you're building and maybe some of the things that the YAMO file in 467 00:40:21,599 --> 00:40:24,079 the pod for Krubernetes offers, Like I can think about, you know, 468 00:40:24,119 --> 00:40:29,239 what does an application actually need? What would you prefer doctor to have provided 469 00:40:29,280 --> 00:40:32,280 it? Would it be like a the HTTP interface, the message bus, 470 00:40:32,400 --> 00:40:37,440 like you just hook into standard strategies for that. You don't have to know 471 00:40:37,480 --> 00:40:42,440 what the implementation is. Is that yeah, exactly like the if I'm building 472 00:40:42,440 --> 00:40:47,440 an application, I want abstractions. I want to build. You know, 473 00:40:47,679 --> 00:40:52,880 I'm going to build a diagram, a logical diagram of an application, and 474 00:40:53,400 --> 00:41:00,079 it will have, you know, connections that are logical between components and not 475 00:41:01,000 --> 00:41:07,079 I have to do this APT get install of this thing and wire it up. 476 00:41:07,800 --> 00:41:14,199 And there is a certain amount of there is a certain bit where developers 477 00:41:15,039 --> 00:41:20,280 don't understand those things so sometimes don't want to so they don't understand basics of 478 00:41:20,360 --> 00:41:27,480 like how network data moves right, and ports and firewalls and but you know, 479 00:41:28,320 --> 00:41:31,039 there's a like I said earlier, there's a difference between knowing about those 480 00:41:31,079 --> 00:41:37,559 things and being forced to deal with them, right. So I think there 481 00:41:37,639 --> 00:41:43,599 is far too much in a helm chart or docer file that we force developers 482 00:41:43,599 --> 00:41:47,360 to understand and deal with as opposed to figuring out how to you know, 483 00:41:47,920 --> 00:41:51,719 ease the way. And there's a lot I think there is a fair bit 484 00:41:51,760 --> 00:41:55,960 of work being done on that, but again we keep pushing it from the 485 00:41:57,000 --> 00:42:00,719 system side. Right, A lot of platforms dev so a lot of that 486 00:42:00,800 --> 00:42:04,519 stuff gets pushed from the system side, and we keep saying, well, 487 00:42:04,559 --> 00:42:07,440 we want you to work in this format, We're going to make it easier, 488 00:42:07,000 --> 00:42:12,519 and the developers are like, you know, it's just it's really complex. 489 00:42:12,679 --> 00:42:16,159 Like there were a lot of developers are really into it because it's exciting, 490 00:42:16,480 --> 00:42:21,599 right, but at the same time, many of them just want to 491 00:42:21,639 --> 00:42:25,119 be able to figure out how to build what their job is telling them to 492 00:42:25,119 --> 00:42:30,679 build, and not take all these like side trips to figure out on stack 493 00:42:30,719 --> 00:42:36,199 overflow, like how do I get this like Docker composed to work or something 494 00:42:36,280 --> 00:42:40,320 like that. So yeah, you know, it's part of that is like 495 00:42:40,360 --> 00:42:49,039 the whole shift left idea, which puts too much on people on the left. 496 00:42:49,440 --> 00:42:53,960 Right. The the idea of getting earlier on the process is good, 497 00:42:54,000 --> 00:42:58,760 but there's something else that came up and I don't know where it came from, 498 00:42:59,000 --> 00:43:02,920 but we were in we had a platform coffee before cupcon EU in the 499 00:43:02,960 --> 00:43:09,000 mornings, and someone brought up shift down so certain things should be shifted left 500 00:43:09,159 --> 00:43:13,239 and made a concern like, you know, testing, We've always had this 501 00:43:13,320 --> 00:43:16,320 idea that you know, separate QA team and everything, and there is a 502 00:43:16,320 --> 00:43:22,440 fair bit of the functionality of testing that should be done on the left, 503 00:43:22,960 --> 00:43:30,199 but figuring out test frameworks and all of the plumbing and mechanics and practices that 504 00:43:30,239 --> 00:43:34,599 shouldn't get all shifted left, that should get shifted down, and you still 505 00:43:34,679 --> 00:43:40,440 need a quality engineering team. They're just not black box testing anymore. They're 506 00:43:40,480 --> 00:43:45,880 responsible for a different set of things that offload. As we've shifted load over 507 00:43:45,960 --> 00:43:49,519 to the DEDs by shifting left, now let's figure out how to offload some 508 00:43:49,599 --> 00:43:53,519 more of it again and put that on a team that has a product that 509 00:43:53,599 --> 00:43:58,480 takes care of aspects of your testing. I thought for sure you're going to 510 00:43:58,519 --> 00:44:02,119 say platform, because you know the testers there are building maybe a platform for 511 00:44:02,239 --> 00:44:07,559 testing so that you can make it easier to pull those things in during the 512 00:44:07,559 --> 00:44:10,400 development cycle rather than having to be worried about each and every one of them. 513 00:44:10,800 --> 00:44:16,639 So that there's another definition of platforms that I came up with a while 514 00:44:16,679 --> 00:44:22,119 back and sort of defining what they look like. And to me, a 515 00:44:22,119 --> 00:44:28,960 platform is a set of runtime environments and pipelines connecting them, and then frameworks 516 00:44:28,960 --> 00:44:34,840 to interface with those two things. So you know, you might have a 517 00:44:34,960 --> 00:44:40,960 QA framework or testing framework that allows you to drop testing into your pipelines. 518 00:44:42,559 --> 00:44:47,000 You might have a you know, a discovery API or something like that that 519 00:44:47,079 --> 00:44:52,760 allows your app to function in the runtime environment. Right, So I think 520 00:44:52,800 --> 00:45:00,280 that some of these things are actual platforms and some of them are a little 521 00:45:00,280 --> 00:45:02,559 more distinct in terms of being frameworks to allow you to do things, and 522 00:45:02,559 --> 00:45:07,760 you're kind of building on the framework, but it's not actually the place where 523 00:45:07,760 --> 00:45:12,360 it runs, right, And so like think of maybe the build and pipeline 524 00:45:12,360 --> 00:45:16,880 systems as the platform and then other people, you know, giving you frameworks 525 00:45:16,920 --> 00:45:22,480 to make it easier to run on those platforms. I like this definition. 526 00:45:22,559 --> 00:45:27,039 It makes it much clearer that there's specific things that people could align with rather 527 00:45:27,119 --> 00:45:30,679 than maybe some more abstract ideas. And the fact everything is called a platform, 528 00:45:30,719 --> 00:45:35,679 So it's the pipeline and the interface for it, and whether like some 529 00:45:36,079 --> 00:45:40,199 level of abstraction, whether it's HGTP, TCP or a full SDK or framework 530 00:45:40,280 --> 00:45:45,679 interact with, and what was the third piece runtime environment and the environment to 531 00:45:45,679 --> 00:45:49,559 actually execute. Yeah, for sure that that makes a lot of sense realistically. 532 00:45:49,599 --> 00:45:52,320 And if it doesn't have all of that, it's marketing nonsense. Yeah, 533 00:45:52,400 --> 00:45:57,159 yeah, And that's why I, you know, like the whole idea 534 00:45:57,199 --> 00:46:05,639 of backstage and other things is internal developer platforms. I don't get the developer 535 00:46:05,679 --> 00:46:10,039 platform thing. You know, your system is built on some sort of platform 536 00:46:10,079 --> 00:46:15,559 that needs to accommodate all of that stuff the runtime, and so you know, 537 00:46:15,840 --> 00:46:21,199 I think it's more appropriate to call things like backstage portals that interface to 538 00:46:21,480 --> 00:46:25,760 the platforms, right. But you know, and it also leads to this, 539 00:46:27,000 --> 00:46:30,280 Well, there's some people who still don't quite get that when we say 540 00:46:30,599 --> 00:46:36,840 developer platform, I mean the platform for developers to build and operate things, 541 00:46:37,519 --> 00:46:42,159 and they're doing DevOps because everyone's thinking, oh, it's platform post DevOps is 542 00:46:42,760 --> 00:46:46,039 no. To me, it's the evolution of DevOps to the point where people 543 00:46:46,079 --> 00:46:52,679 can focus on their lane. Right. My lane is to build business value 544 00:46:52,760 --> 00:46:57,800 in the form of applications. I shouldn't have to consider how blocks are stored 545 00:46:57,800 --> 00:47:00,800 on disk or buckets are managing a you or you know those sorts of things. 546 00:47:01,199 --> 00:47:07,639 Right. It allows me to do DevOps for my application, not DevOps 547 00:47:07,719 --> 00:47:13,440 for patching vulnerabilities in the operating system or you know, like like we were 548 00:47:13,559 --> 00:47:19,159 kind of forcing people to do in earlier forms of like total freedom DevOps, 549 00:47:19,199 --> 00:47:22,599 but you know they're also totally responsible DevOps, right. I mean, I 550 00:47:22,639 --> 00:47:27,400 think it's a UX problem here, and maybe UX from a product standpoint, 551 00:47:27,440 --> 00:47:30,159 where as you said, it's being pushed from the system side, rather than 552 00:47:30,400 --> 00:47:34,440 if I really don't want to know about that stuff, there should be what 553 00:47:34,440 --> 00:47:37,519 what I like to call sensible defaults. I don't have to pick something it 554 00:47:37,559 --> 00:47:40,880 does. Give me the right block store and the right file system, and 555 00:47:40,920 --> 00:47:45,960 I don't have to know the difference between you know, ntfs and ext and 556 00:47:46,159 --> 00:47:50,440 et cetera in order to actually even deploy my thing. Give me something that 557 00:47:50,519 --> 00:47:54,079 sort of works. And if I say, wait, the I OPS read 558 00:47:54,119 --> 00:47:59,039 and write to my disc is this slow? Is that reasonable? And then 559 00:47:59,079 --> 00:48:02,480 maybe I want to investigate and choose the options available rather than having to decide 560 00:48:02,480 --> 00:48:07,519 that upfront. Yeah, And you want to be able to define your storage 561 00:48:07,559 --> 00:48:15,159 needs because you understand your storage needs in terms of maybe TPS right, and 562 00:48:15,719 --> 00:48:17,320 you know that, and you know, if you spend a little time with 563 00:48:17,400 --> 00:48:22,400 the work and you understand the application that you're building, you say, oh, 564 00:48:22,480 --> 00:48:28,639 if I'm trying to clear through you know, a thousand transactions of Jason 565 00:48:29,800 --> 00:48:32,400 of this rough set, like, oh, I need a diss that performs 566 00:48:32,440 --> 00:48:37,400 like this, And you can say to your maybe, to your platform, 567 00:48:37,760 --> 00:48:44,840 I have this storage requirement space and speed and latency potentially right, and then 568 00:48:44,920 --> 00:48:49,199 maybe it can help you by saying, oh, you fall into this class, 569 00:48:49,559 --> 00:48:55,880 right, and that's the that's one of the differentiators in terms of platforms 570 00:48:57,000 --> 00:49:02,079 is I feel like Amazon and others their general purpose platforms, they're just the 571 00:49:02,239 --> 00:49:07,239 kitchen sink, right, you can build anything you want. What organizations need 572 00:49:07,320 --> 00:49:14,039 are opinionated platforms built on top of those with all those sensible defaults and guardrails. 573 00:49:14,079 --> 00:49:19,280 And it's not just sensible defaults, it's sometimes just the inability to set 574 00:49:19,320 --> 00:49:22,280 things that are just not appropriate for you. Right, you should not be 575 00:49:22,519 --> 00:49:27,960 setting security related things that's set for you and you have no way to override 576 00:49:28,000 --> 00:49:34,639 it, and that and capsulates a whole bunch of things that make life easier 577 00:49:34,679 --> 00:49:37,360 for everyone, you know, the idea of like maintaining security, auditing, 578 00:49:38,119 --> 00:49:45,800 you know, controls and compliance, Like if you take that approach of people 579 00:49:45,880 --> 00:49:50,239 stay in their lane and it's not so easy for them to break out of 580 00:49:50,280 --> 00:49:53,320 it, then you know, we have a lot more control over the environment 581 00:49:53,800 --> 00:49:58,159 with a trade off and costs, like do you do you maintain speed and 582 00:49:58,199 --> 00:50:02,440 flexibility? And they get this is like where the pendulum swings is. Sometimes 583 00:50:02,679 --> 00:50:09,880 those controls and security and compliance end up taking on too much weight and you 584 00:50:09,920 --> 00:50:14,679 know, the people trying to produce things on a platform end up suffering because 585 00:50:15,079 --> 00:50:17,800 well, we put all you know, we put all these safeguards in without 586 00:50:17,840 --> 00:50:21,719 figuring out with you what you need to do to get your job done. 587 00:50:22,000 --> 00:50:28,679 And that's that product and user centric aspect of platforms as opposed that needs to 588 00:50:28,679 --> 00:50:32,000 be there to differentiate from how I used to work, which is we build 589 00:50:32,039 --> 00:50:35,519 it, you will use it. Yeah. No, I mean I think 590 00:50:35,639 --> 00:50:40,119 you still sort of see that problem with the user experience From an innovation standpoint, 591 00:50:40,239 --> 00:50:45,400 If the users who are building the applications on top of your platform don't 592 00:50:45,400 --> 00:50:49,679 have any way to give you feedback on where they're getting slowed down or what 593 00:50:49,719 --> 00:50:52,119 they could use, what their actual needs are, then you have this sort 594 00:50:52,159 --> 00:50:55,719 of issue where the innovation can only come from those that are building a platform, 595 00:50:55,840 --> 00:51:00,480 and they of course don't have the actual use case of building an application 596 00:51:00,519 --> 00:51:04,639 on top of it. And I've been struggling with this for a while now, 597 00:51:04,639 --> 00:51:07,320 and I'm not sure there is like a clean answer. I mean, 598 00:51:07,360 --> 00:51:10,719 if you have the best, perfect platform ever, a developer platform, then 599 00:51:10,840 --> 00:51:15,360 there is not really an issue, But how do you make real headway in 600 00:51:15,079 --> 00:51:19,440 how to change your platform and make it better if you aren't sort of dog 601 00:51:19,480 --> 00:51:24,199 fooding at yourself. There is an option that's kind of in between, because 602 00:51:24,239 --> 00:51:31,000 it's difficult to get systems people to dog food the platforms entirely because a they 603 00:51:31,000 --> 00:51:38,920 don't historically work like the typical SDLC developer cycle, and b the work that 604 00:51:38,960 --> 00:51:45,719 they do is difficult to have work that way. So good a good engineering 605 00:51:45,800 --> 00:51:50,960 life cycle. You know testing mostly unit tess you've got the test viearament mostly 606 00:51:51,119 --> 00:51:55,599 unit tests at the bottom, and you step off to integration functional and unfortunately, 607 00:51:55,960 --> 00:52:00,519 you know the way that systems people are required to work with cloud providers, 608 00:52:00,960 --> 00:52:05,159 it's very difficult for them to do lots of unit testing at the base. 609 00:52:05,199 --> 00:52:08,760 They end up getting stuck with integration. So it's immediately like a barrier 610 00:52:08,960 --> 00:52:14,440 to them, like changing the way they behave in the same way that their 611 00:52:14,559 --> 00:52:21,159 users do. But they could go and talk to their users, and they 612 00:52:21,199 --> 00:52:27,440 could shadow their users, and they could spend time seeing how they work even 613 00:52:27,480 --> 00:52:30,400 if they don't work the same way, and just spend the time to listen 614 00:52:30,639 --> 00:52:37,840 and understand and figure out if they're what they're building actually solves a problem for 615 00:52:37,880 --> 00:52:42,880 the user as opposed to its traditional It is they're solving a problem for themselves, 616 00:52:43,760 --> 00:52:46,199 Like they have requests coming in they need to automate in order to be 617 00:52:46,199 --> 00:52:50,320 able to survive the rate of requests. Yeah, for sure, And that's 618 00:52:50,599 --> 00:52:54,480 not what a you know. And the issue with like being built from one 619 00:52:54,559 --> 00:53:00,559 side is it's a massive loss in efficiency and a huge amount of cost. 620 00:53:01,239 --> 00:53:06,199 Say you have to build, say you build eight features in your platform, 621 00:53:06,760 --> 00:53:10,000 and only three of them are useful, like the developer, like you guessed 622 00:53:10,119 --> 00:53:15,920 right, right for three out of the eight. That means you spent time 623 00:53:15,039 --> 00:53:22,559 on five things that you have to maintain that you spent time building that are 624 00:53:22,599 --> 00:53:27,760 not solving problems, so like they don't get as much effective change and their 625 00:53:27,800 --> 00:53:32,599 ability to get value delivered. You spent lots of time doing stuff that people 626 00:53:32,679 --> 00:53:38,519 didn't need and it ends up being a big cycle of waste. Right because 627 00:53:39,199 --> 00:53:44,000 we're not startups. We're not startups that are looking for product market fit. 628 00:53:45,000 --> 00:53:50,239 We're not trying to figure out what customers want because we don't. It's a 629 00:53:50,239 --> 00:53:54,239 captive audience internally, you can just go talk to all of them, so 630 00:53:54,599 --> 00:53:59,599 you don't have the same constraints as a startup where you need to imagine what 631 00:53:59,599 --> 00:54:04,199 you're using will find useful you just go ask them, right, and then 632 00:54:04,239 --> 00:54:07,719 that allows you to prioritize what's going to be the most useful. Unfortunately, 633 00:54:07,800 --> 00:54:13,880 it has never functioned that way, right, or at least only partially ever 634 00:54:13,960 --> 00:54:16,960 gotten there. So in order for platforms to be really successful and for all 635 00:54:16,960 --> 00:54:22,960 this speed to happen, you have to figure out exactly what's going to solve 636 00:54:22,000 --> 00:54:28,000 a problem, not be not come up with solution first, which is how 637 00:54:28,079 --> 00:54:30,760 I mean, that's how I remember my boss coming to me, is like, 638 00:54:30,840 --> 00:54:31,960 you know, oh, we're doing annual planning. Need to figure out 639 00:54:31,960 --> 00:54:35,800 the budget. What should we build for next year? Right? Like, 640 00:54:36,079 --> 00:54:42,000 what's what's it's just not let's go find out what users need and solve their 641 00:54:42,039 --> 00:54:44,599 problems. It's way more fun that way, right, you know, these 642 00:54:44,639 --> 00:54:47,239 things seem fun, Let's go and deliver it. You know, I think 643 00:54:47,599 --> 00:54:51,320 five out of eight or three out of eight success, five out of eight 644 00:54:51,320 --> 00:54:53,920 failure. I think that's a great rate. Like everyone should be proud if 645 00:54:53,920 --> 00:54:59,519 they actually got three out of eight features. Yeah, that's true, that's 646 00:54:59,559 --> 00:55:05,760 true. Instead, what you get are entire platforms that are just not useful, 647 00:55:06,119 --> 00:55:10,840 right, and no adoption and become legacy you know, before ever being 648 00:55:10,880 --> 00:55:15,079 born. I mean, I think you're lucky if you get no adoption. 649 00:55:15,239 --> 00:55:19,760 I've seen this sinkhole of there's one team using it, who oh yeah, 650 00:55:19,800 --> 00:55:22,679 yeah in it forever, right, yeah, right, this big overblown thing 651 00:55:22,960 --> 00:55:29,320 and you only got partial adoption, and now you've just added to the stable 652 00:55:29,360 --> 00:55:35,199 of platforms you have to basically maintain forever because you never hit a solution that 653 00:55:35,320 --> 00:55:38,679 gets the clear adoption, which could actually have a negative impact in the organization 654 00:55:38,960 --> 00:55:45,320 if what you're actually providing is like automation of ticket you know, solves, 655 00:55:45,440 --> 00:55:49,199 right, and those are the things that people necessarily want. Actually, I 656 00:55:49,239 --> 00:55:52,559 think there's a huge trouble here in trying to actually identify what the value is 657 00:55:52,960 --> 00:55:57,480 or quantify for the for the platform or for the features that you're adding there. 658 00:55:57,800 --> 00:56:00,519 And so because you can't do that very effective, it's even more difficult 659 00:56:00,559 --> 00:56:05,840 to remove things and prove that that would be a problem for someone. That's 660 00:56:05,840 --> 00:56:09,800 where you get into at least a product mindset. And I hesitate to say 661 00:56:09,920 --> 00:56:17,840 product management because then people start to think they need to hire product managers and 662 00:56:16,440 --> 00:56:22,920 that's not necessary or even realistic. Like we go through these again, these 663 00:56:22,960 --> 00:56:27,960 hype cycles where like DevOps or story or everyone starts to think, oh, 664 00:56:28,079 --> 00:56:31,599 I need to create a job description and hire a few hundred people that fit 665 00:56:31,679 --> 00:56:37,880 that and put them on teams and we'll be set right. And that's not 666 00:56:37,360 --> 00:56:43,519 realistic through any of these cycles, it's never been realistic. And so if 667 00:56:43,559 --> 00:56:51,639 we focus on a product mindset of finding out user pain points, figuring out 668 00:56:51,719 --> 00:56:55,360 the problems are what to solve, what I think you can get to is 669 00:56:55,400 --> 00:57:00,239 also if you're getting closer to how value is produced, you can actually start 670 00:57:00,280 --> 00:57:06,840 to draw a connection between the things you're doing and the value being produced because 671 00:57:06,920 --> 00:57:10,519 you're having an impact on the engineers that are directly producing the value, so 672 00:57:10,880 --> 00:57:15,559 in a way, you're indirectly contributing to the same value. Whereas if you've 673 00:57:15,559 --> 00:57:21,360 just got a flow of tickets and you're just or you're just trying to make 674 00:57:21,360 --> 00:57:25,199 the system more reliable because you're in the way of things, like you're seen 675 00:57:25,239 --> 00:57:30,639 as a traditional cost center, right, we're trying to minimize your participation here 676 00:57:30,760 --> 00:57:36,199 because it seems like you just break things or you're only around to fix broken 677 00:57:36,280 --> 00:57:39,639 things. Whereas if you're solving pain points and you're making people work faster, 678 00:57:40,960 --> 00:57:46,920 that's contribution to value. Right. So I think that the again, the 679 00:57:46,960 --> 00:57:55,840 mindset of focusing on users and their pain points and potentially pulling that especially sentiment 680 00:57:57,079 --> 00:58:00,920 about that in is how you start to get to measuring. For instance, 681 00:58:00,960 --> 00:58:07,719 I know of a company where someone created a you know, went to QCon 682 00:58:07,920 --> 00:58:12,599 conferences, you know, five six years ago, started to see talk about 683 00:58:12,639 --> 00:58:19,719 platforms and DevOps and this kind of developer productivity type stuff, and started what 684 00:58:20,000 --> 00:58:25,760 amounted to a platform team. Instead of measuring things like Dora, they just 685 00:58:25,960 --> 00:58:36,000 measured for subjective things like developer satisfaction and they managed to go and as a 686 00:58:36,039 --> 00:58:38,719 by product fix all the you know, like their Dora metrics which they didn't 687 00:58:38,800 --> 00:58:43,639 track, went up, but they knew they were doing dozens of deployees a 688 00:58:43,719 --> 00:58:49,480 day instead of once every month, right, So which is more important People's 689 00:58:50,039 --> 00:58:54,400 ability to feel productive and get their work done when they're working directly on business 690 00:58:54,480 --> 00:59:00,480 value, and then the byproduct being well that value flows faster, or focusing 691 00:59:00,519 --> 00:59:04,760 on the thing that is potentially gameable, which is just a number, right, 692 00:59:05,360 --> 00:59:08,719 like a Doro metric for deploy rate or things like that. I think 693 00:59:08,760 --> 00:59:15,760 those are signals of the system not terribly useful in terms of measuring value. 694 00:59:15,280 --> 00:59:20,760 I mean there is this mantra of any metric that becomes the target ceases to 695 00:59:20,880 --> 00:59:24,400 be a good metric here, and I think the developer fulfillment is sort of 696 00:59:24,440 --> 00:59:28,960 an interesting I used to think that Doro metrics were well weighted to make it 697 00:59:29,199 --> 00:59:31,760 very hard to game in a way in which if you were to gain them, 698 00:59:31,760 --> 00:59:36,480 at least you would be doing something better than likely you are doing today. 699 00:59:36,800 --> 00:59:40,039 But now I've started to see them for sure being gamed in ways which 700 00:59:40,960 --> 00:59:45,920 we're not intended and have negative consequences, like throwing feature flags in everywhere so 701 00:59:45,960 --> 00:59:50,960 that you can just get your code into production without actually having it tested, 702 00:59:51,199 --> 00:59:55,679 without it having incident appeal, without users actually seeing the code, and then 703 00:59:57,159 --> 01:00:00,400 like, oh my Dora metric for cycle time is now low. Congrats, 704 01:00:00,559 --> 01:00:06,199 right, you know you just eliminated the metrics value and you threw all the 705 01:00:06,239 --> 01:00:08,559 work and all the tracking into a metric that you're not even paying attention to, 706 01:00:08,599 --> 01:00:14,599 which is sort of released to cycle time for the feature flag being enabled. 707 01:00:15,320 --> 01:00:20,840 Yeah, and so you've created a game so where I think Dora is 708 01:00:22,440 --> 01:00:28,599 appropriate. It's a system level signal that leadership should be using to figure out 709 01:00:28,599 --> 01:00:31,119 what they're doing wrong. Yeah, and that's not how I mean, most 710 01:00:31,119 --> 01:00:37,079 places are looking at commit rates and things like that and talking to people about 711 01:00:37,079 --> 01:00:44,719 it instead of reflecting on why does my organization have trouble? You know, 712 01:00:44,840 --> 01:00:50,159 trending these Dora metrics in the right direction. And because you know, way 713 01:00:50,280 --> 01:00:53,519 companies are traditionally managed, it's always some sort of performance. That's why there's 714 01:00:53,559 --> 01:00:59,320 all this like developer performance measurement and stuff like that. It's like, I 715 01:00:59,400 --> 01:01:02,079 can't POSSI simply, you know, have anything other than like a problem with 716 01:01:02,119 --> 01:01:06,440 the team or a person or like as soon as I fix that, you 717 01:01:06,440 --> 01:01:09,559 know, like gees, let's lay off the bottom ten percent every year like 718 01:01:09,760 --> 01:01:14,960 this, fire them and that will make everything better, right. And you 719 01:01:15,000 --> 01:01:19,840 know, I think more and more servant leaders are coming into existence who understand 720 01:01:19,920 --> 01:01:24,760 that they have to build systems in which people can be successful. Right, 721 01:01:24,920 --> 01:01:30,960 And Dora metrics are one of many things that you could use as signal to 722 01:01:30,039 --> 01:01:36,400 understand are you building a successful system? Sentiment also very good, you know, 723 01:01:36,440 --> 01:01:39,719 the new I find it interesting that like forest Ground was involved with Dora 724 01:01:40,440 --> 01:01:45,559 moved on to space, which is you know, more subjective, much broader, 725 01:01:45,920 --> 01:01:50,480 and then you've got DX, which is just this triangle of not really 726 01:01:50,679 --> 01:01:57,000 unmeasurable but far more user experience focused. Right. No, I mean that 727 01:01:57,800 --> 01:02:00,079 it brings me to ask, and I think maybe with with DX in space, 728 01:02:00,199 --> 01:02:04,400 maybe that's the answer. Is there a go to metric for you? 729 01:02:05,199 --> 01:02:07,880 Or is it? At least from my experience, it's like, let me 730 01:02:07,920 --> 01:02:12,440 take inventory of what the current situation is and see where there are opportunities for 731 01:02:12,480 --> 01:02:16,480 improvement which push something along in some way which I unblocks or you know, 732 01:02:16,559 --> 01:02:21,320 you look at the obstacles or something like that. But it feels very subjective, 733 01:02:21,440 --> 01:02:25,119 like I see people getting stuck or I see communication failing in some way 734 01:02:25,159 --> 01:02:30,519 here. Let's work on improving the communication or the collaboration or unifying we the 735 01:02:30,800 --> 01:02:36,599 dozens of platforms we're using down to only a handful. Is there any sort 736 01:02:36,679 --> 01:02:42,840 of concrete metric that you more tend to like? I mean, it's all 737 01:02:42,840 --> 01:02:47,679 perfect. I think from a technology perspective, you should be looking at things 738 01:02:47,679 --> 01:02:57,480 like SLOs that are inherently outward facing and relatively difficult to gain and kind of 739 01:02:57,480 --> 01:03:01,039 make you part of an ecosystem. And because there's a two, there's two 740 01:03:01,079 --> 01:03:07,800 sides to those sorts of metrics there's like, Okay, this is what our 741 01:03:07,880 --> 01:03:12,000 objective is. If we're not meeting an objective and it, you know, 742 01:03:12,559 --> 01:03:15,280 it doesn't match up with what the sentiment is in terms of user satisfaction. 743 01:03:15,639 --> 01:03:20,960 It kind of like puts some tension there into having you know, the right 744 01:03:21,039 --> 01:03:25,840 kinds of numbers and you know, But at the same time, I don't 745 01:03:25,880 --> 01:03:32,079 think it's I think metrics get over used and also stay around for too long. 746 01:03:34,039 --> 01:03:37,639 There should be trends and things, and that you should identify parts of 747 01:03:37,679 --> 01:03:44,199 the system that require attention for periods of time, find your constraints, exploit 748 01:03:44,280 --> 01:03:49,079 them, remove them, and then work on to other things. So in 749 01:03:49,199 --> 01:03:57,079 terms of like systems, metrics are useful for diagnosing right, and that they're 750 01:03:57,079 --> 01:04:00,400 not great to just watch all the time. Like you lots of data about 751 01:04:00,400 --> 01:04:04,840 how your system is functioning, but you should be looking at composite trends. 752 01:04:05,280 --> 01:04:10,679 You really should be business level things. Right, should be a combination of 753 01:04:10,760 --> 01:04:16,360 employee satisfaction, customer satisfaction, financial performance. Right. If those things are 754 01:04:16,360 --> 01:04:21,360 in balance, almost nothing else matters, right, So, and you know, 755 01:04:21,440 --> 01:04:25,920 those are the things I would go for. But that's almost like a 756 01:04:26,440 --> 01:04:30,760 wouldn't call a pipe dream. Most organizations are really far from understanding that because 757 01:04:30,800 --> 01:04:38,159 technology doesn't communicate in business terms. And there I've said this many times. 758 01:04:38,559 --> 01:04:43,440 Technologists are almost allergic to where their paycheck comes from. And I say that 759 01:04:43,559 --> 01:04:48,119 it was funny I got contradicted on that once in that I think in startup 760 01:04:48,199 --> 01:04:55,639 land people are fairly well connected to where their paycheck comes from. In big 761 01:04:56,039 --> 01:05:00,360 enterprise, they have no idea. In both cases, they find it very 762 01:05:00,400 --> 01:05:05,400 difficult to communicate with the business and get them to understand the value of what 763 01:05:05,440 --> 01:05:14,159 they're doing and you know that sort of thing. So it's so I don't 764 01:05:14,159 --> 01:05:17,599 think there is one easy metric. What I'd like to see start happening is 765 01:05:17,719 --> 01:05:23,920 better communication with the rest of the business and the ability to align on you 766 01:05:23,920 --> 01:05:26,880 know, the sort of fundament because if you do that, you can get 767 01:05:26,960 --> 01:05:30,280 people to work on the most valuable thing, because you'll have a straighter line 768 01:05:30,360 --> 01:05:33,440 tour. And this can go very deep in the organization too, and maybe 769 01:05:33,480 --> 01:05:38,960 allow the organization to make decisions about buy versus builds, like why are we 770 01:05:39,039 --> 01:05:44,639 spending so much of our human you know, capital on this thing which is 771 01:05:44,760 --> 01:05:49,360 like a commodity and you know, not paying for itself and I'm very careful 772 01:05:49,400 --> 01:05:55,440 with that because I also believe in the fact that you have you know, 773 01:05:55,519 --> 01:06:00,320 your humans are the most valuable thing, and simply treating them as resource so's 774 01:06:00,360 --> 01:06:03,000 to be added to or removed as part of your cost just seems foolish. 775 01:06:03,360 --> 01:06:10,400 Right. So again, it's like a systems level thing signals for how leadership 776 01:06:10,480 --> 01:06:13,880 is doing. I was I had this fear you were going to say, 777 01:06:13,960 --> 01:06:17,760 e NPS score. I mean for what I I don't particularly like it. 778 01:06:17,800 --> 01:06:23,880 I think there is this h survey. Survey is not done well, give 779 01:06:23,920 --> 01:06:27,880 you the wrong signals, and I think it's very challenging to be able to 780 01:06:27,920 --> 01:06:32,519 effectively actually grasp is their fulfillment. On the engineering side, are our customers 781 01:06:32,599 --> 01:06:36,519 actually happy? I mean, I think, so, here's here's one idea 782 01:06:36,679 --> 01:06:41,880 that we need to look out into the future in order to actually evaluate that. 783 01:06:42,360 --> 01:06:45,280 But then on the on the flip side, I think, oh wait, 784 01:06:45,320 --> 01:06:48,199 no, actually, companies are still bad even correctly evaluating where they're currently 785 01:06:48,239 --> 01:06:53,320 at. Let a let a load being able to correctly evaluate it on the 786 01:06:53,360 --> 01:06:58,280 line. The interesting thing with the SLO is uh, the service level objective 787 01:06:58,400 --> 01:07:01,039 is that it's still very it's stary subjective in nature. Right, It's not 788 01:07:01,280 --> 01:07:04,199 like your I mean, your SLA is what you put in your contract, 789 01:07:04,199 --> 01:07:08,480 and your SLI is you know, the thing that you can actually measure what 790 01:07:08,480 --> 01:07:11,039 what what is happening? But that's a lot is like we want this, 791 01:07:11,800 --> 01:07:15,400 and where does then our customers want this? We know our customers want this, 792 01:07:15,800 --> 01:07:20,760 right, But going back to the E NPS thing, I think that 793 01:07:20,880 --> 01:07:28,960 one of the mistakes I've seen is that if you're going to survey employees about 794 01:07:29,159 --> 01:07:34,719 their satisfaction or things like that, you you need to have a tread like 795 01:07:34,760 --> 01:07:40,039 you can't. You can't make your employee survey different every time you give it 796 01:07:40,039 --> 01:07:43,920 to them, right, it is it doesn't give you a signal. Right, 797 01:07:44,079 --> 01:07:47,599 So, and I think that happens with a lot of metrics is that 798 01:07:47,679 --> 01:07:53,039 you'll see like a KPI board and all you'll see is the absolute numbers for 799 01:07:53,079 --> 01:07:57,239 the current time period with no trends, Like how am I supposed to? 800 01:07:57,480 --> 01:08:01,320 Like? I have to contextually understand the value of this absolute you know, 801 01:08:01,480 --> 01:08:06,079 and and and for many businesses they can get that, right, But if 802 01:08:06,119 --> 01:08:10,000 you don't know the trend, what's the what's the value of this thing? 803 01:08:10,119 --> 01:08:14,519 Right? It should just be a binary a binary switch at that point, 804 01:08:15,840 --> 01:08:18,359 and so E NPS I think, yes, it's difficult to figure out, 805 01:08:18,560 --> 01:08:25,279 but what I think is more important is the trend in those things and deciding 806 01:08:25,319 --> 01:08:30,840 if you if you can tune it at all by making changes. The actual 807 01:08:30,960 --> 01:08:38,359 answers other than like a subjective rating might be difficult to interpret, but I 808 01:08:38,399 --> 01:08:41,279 think you could tell with an E NPS, like if you are going to 809 01:08:41,279 --> 01:08:45,520 make changes to a company, if it's going up or down, maybe you're 810 01:08:45,560 --> 01:08:48,560 having an impact or not. Right. Yeah, I mean I've seen this 811 01:08:48,720 --> 01:08:53,079 done. It's one of those things that I've only ever seen done poorly, 812 01:08:53,399 --> 01:08:56,479 and I'm still waiting for that circumstance where it's like, oh, you know, 813 01:08:56,520 --> 01:09:00,279 we did it and it worked out great. I think there's the the 814 01:09:00,319 --> 01:09:02,399 team's change. Too frequently, there are too many changes in the organization, 815 01:09:02,479 --> 01:09:06,760 not like from an individual standpoint, to actually accurately be able to trend that 816 01:09:06,840 --> 01:09:14,520 information over time. There's this knowledge that assuming the questions aren't bad, which 817 01:09:14,560 --> 01:09:18,119 they're usually bad in some way, you know, you're looking at the data 818 01:09:18,279 --> 01:09:24,000 and as a as a survey answer, you're you're filling that out and the 819 01:09:24,079 --> 01:09:27,760 result is often wait, I know what the right there's like a quote unquote 820 01:09:27,840 --> 01:09:31,479 right answer here, and if I answer negatively, I know what's Like, 821 01:09:31,840 --> 01:09:34,279 I fear what's going to come next. There's going to be a conversation I 822 01:09:34,279 --> 01:09:40,359 don't want to have and worst case I do answer negatively and then nothing happens. 823 01:09:41,359 --> 01:09:45,399 Yeah, yeah, and that and that's a lot of what the approach 824 01:09:45,640 --> 01:09:51,119 is of people doing the surveying, Like why are you surveying? Are you 825 01:09:51,239 --> 01:09:59,800 again doing it from a like you're doing some sensing? Yeah, what was 826 01:09:59,800 --> 01:10:03,600 your reasoning for doing that? And are you trying to figure out reactively how 827 01:10:03,600 --> 01:10:11,600 people are feeling and therefore say something different in the next town hall, right? 828 01:10:12,199 --> 01:10:17,560 Or are you actually interested in delivering change that addresses what is you keep 829 01:10:17,600 --> 01:10:24,399 scratching deeper with? You know, I think E NPS, well, a 830 01:10:24,720 --> 01:10:29,680 small teams very difficult, like that any any team under a certain size, 831 01:10:29,680 --> 01:10:32,640 And I wouldn't say what that is arbitrarily that that isn't E NPS is like 832 01:10:32,640 --> 01:10:38,000 doesn't have value, right, doesn't have a this a statistical minimum right for 833 01:10:38,119 --> 01:10:44,359 things like that to have value. And if you're above a certain point, 834 01:10:44,640 --> 01:10:46,800 I really think it should just be like a one to ten, right, 835 01:10:46,920 --> 01:10:51,720 there shouldn't be a survey. It should be something easy to get sensing and 836 01:10:51,760 --> 01:10:55,960 feedback on. And I've seen places where they even have like a kiosk and 837 01:10:56,039 --> 01:11:00,760 people just you know, bounce the numbers as a go through, like the 838 01:11:00,800 --> 01:11:08,760 bathroom ratings that they have and uh and uh you know that. Yeah, 839 01:11:08,880 --> 01:11:11,359 no, I mean that's for sure true. I think the problem with the 840 01:11:11,399 --> 01:11:14,520 one to ten. In a past life, we had some surveys in this 841 01:11:14,840 --> 01:11:18,399 area. We were focused on improving leadership and getting feedback around that, and 842 01:11:19,000 --> 01:11:23,319 oh we had a sas tool and everything, and that didn't work out because 843 01:11:23,359 --> 01:11:28,399 it turns out that people are some people are notoriously bad at even knowing where 844 01:11:28,399 --> 01:11:31,760 they're at personally. Right. They say something's an issue, but it really 845 01:11:31,760 --> 01:11:34,279 wouldn't affect them, Like, oh, yeah, I would leave if we 846 01:11:34,920 --> 01:11:39,319 throw Kubernetes into our platform. But then you do it and they don't leave. 847 01:11:39,399 --> 01:11:41,800 It's like, oh, I'll leave if we you know, I have 848 01:11:41,880 --> 01:11:45,760 to do manual testing and I'll have responsible for testing shift left, securities, 849 01:11:45,760 --> 01:11:47,319 shift left, you know, everything. Then they don't leave, right, 850 01:11:47,399 --> 01:11:50,079 So I think that's always been sort of a struggle there. I like, 851 01:11:50,199 --> 01:11:55,359 yeah, yeah, and that's an inner personal and that's you know, and 852 01:11:55,439 --> 01:12:00,720 again that's also size, right, I mean, sentimental is something you could 853 01:12:00,079 --> 01:12:03,439 you know, when you say true sentiment, that should be a statistical thing. 854 01:12:03,840 --> 01:12:06,600 If you're dealing with a small group, you're not getting sentiment. You're 855 01:12:06,640 --> 01:12:15,000 getting like opinions, you know, or yeah, And that's a trickier thing, 856 01:12:15,920 --> 01:12:19,560 you know. I used to think that platforms were and the kind of 857 01:12:19,640 --> 01:12:26,199 consulting I do, which is advise people on how to get started with platforms, 858 01:12:26,239 --> 01:12:30,800 evaluate what they need, we didn't even get the cognitive load, for 859 01:12:30,840 --> 01:12:38,720 instance, which is take a big on I wouldn't say misunderstood, but underutilized 860 01:12:38,760 --> 01:12:44,840 way of looking at platforms and how organizations function and at the organizational level, 861 01:12:45,760 --> 01:12:51,880 because they think there's a lot of emphasis on reducing cognitive load of developers. 862 01:12:51,920 --> 01:12:58,000 And you know that doesn't work well if you just shove all that cognitive load 863 01:12:58,119 --> 01:13:02,920 somewhere else in the organization. So you really need to have a in an 864 01:13:03,000 --> 01:13:11,479 internal platform situation, you need to look at the distribution of cognitive load and 865 01:13:11,600 --> 01:13:15,520 make sure that it's kind of even right when you're when you're building a Sas 866 01:13:15,560 --> 01:13:21,000 for external customers, the amount you're you're reducing their cognitive load for some problem. 867 01:13:21,760 --> 01:13:27,439 The amount that you take on really just has to do with your ability 868 01:13:27,479 --> 01:13:30,920 to be profitable and take on You could take on any amount of pain as 869 01:13:30,960 --> 01:13:35,000 long as you can be profitable for it, right, But with an internal 870 01:13:35,039 --> 01:13:39,960 platform, if you do that with your platform, you're just going to create 871 01:13:40,000 --> 01:13:45,359 bottle micks because there is no you know, with a platform team, there 872 01:13:45,439 --> 01:13:48,319 is no P and L. Ultimately, you know some people would like to 873 01:13:48,359 --> 01:13:53,039 think that way, but you know that there there isn't in the same way 874 01:13:53,079 --> 01:13:58,720 that you get with an external platform. So yeah, I'm hearing the message 875 01:13:58,720 --> 01:14:00,560 should be there. There needs to be PN now for any team building a 876 01:14:00,560 --> 01:14:05,920 platform internally. Well, I hope I didn't say that no for sure or 877 01:14:05,920 --> 01:14:09,399 not. I mean I have thought about this in the past, and there 878 01:14:09,439 --> 01:14:13,640 are some things with chargebacks that some organizations have tried. I think there's an 879 01:14:13,680 --> 01:14:16,600 interesting aspect here. The perfect market out in the world when you're selling to 880 01:14:16,640 --> 01:14:24,840 customers is realistically, you want the marginal value to go to zero, Like 881 01:14:24,880 --> 01:14:29,840 the amount you're getting your you're wasting or spending on building your thing is exactly 882 01:14:29,920 --> 01:14:31,439 how much customers are paying for it. If there's not, then either you 883 01:14:31,520 --> 01:14:34,399 know you're charging too much hypothetically. Now, of course you want to do 884 01:14:34,479 --> 01:14:38,279 that because then your business makes money and you can pay people, et cetera. 885 01:14:39,079 --> 01:14:43,920 But internally I do see without that there is this sort of lack of 886 01:14:43,960 --> 01:14:48,760 balance. The internal teams end up probably in deficit right there there. They 887 01:14:48,800 --> 01:14:53,880 don't get that feedback, so there's no measure for oh, you only have 888 01:14:54,039 --> 01:14:57,239 this much money coming in that we can support it, and they just keep 889 01:14:57,279 --> 01:15:00,399 adding features as you said, But now I'm wondering whether or not we need 890 01:15:00,439 --> 01:15:03,359 to be focusing on cognitive load more and if there's a way to directly calculate 891 01:15:03,399 --> 01:15:06,840 that, because you could figure out, oh, this is much cognitive load 892 01:15:06,840 --> 01:15:12,359 we're reducing from the organization, and this is how much cognitive load we're centralizing 893 01:15:12,479 --> 01:15:15,680 in this other area or in this team. Their cognitive load is going to 894 01:15:15,720 --> 01:15:17,960 increase over time, and you could and you're going to bottleneck. Yeah for 895 01:15:18,000 --> 01:15:23,199 sure. Yeah, is there a like well there isn't. Well, I've 896 01:15:23,239 --> 01:15:30,039 actually been working on something like a cognitive load map of an organization, so 897 01:15:30,720 --> 01:15:36,119 giving you the ability to visualize how cognitive load is distributed and combining that sort 898 01:15:36,119 --> 01:15:41,600 of like with the network of interactions that happen and figuring out if you can 899 01:15:41,600 --> 01:15:45,840 make it assignable, so assignable cognitive load. Can I assign it to the 900 01:15:45,920 --> 01:15:48,119 nature of work that I do? Can I assign it to some other team 901 01:15:48,159 --> 01:15:53,279 that I interact with? Can I assign it to how I'm met, like 902 01:15:53,640 --> 01:15:56,479 you know, and start coming up with a way of kind of rating this, 903 01:15:56,600 --> 01:15:59,279 and then you should be able to get, you know, what sort 904 01:15:59,279 --> 01:16:01,600 of looks like a heat map, and if it's really out of balance, 905 01:16:01,640 --> 01:16:08,079 it should be really clear and you should be working to try and like even 906 01:16:08,119 --> 01:16:11,840 out that heat map. And so you know, I think the team topologies 907 01:16:11,880 --> 01:16:16,439 focuses on the at the team level doing a cognitive load assessment figure out like 908 01:16:16,800 --> 01:16:21,439 when they're overloaded and when you might need a split and a team I actually 909 01:16:21,479 --> 01:16:26,479 also think we need to jump up and look at the whole organization and figure 910 01:16:26,520 --> 01:16:30,920 out how much flow are we trying to force through, Like take features you 911 01:16:30,960 --> 01:16:34,479 mentioned features, like what are we doing about features? Like features just tend 912 01:16:34,560 --> 01:16:40,680 to go up forever, especially for internal things like when are you going to 913 01:16:40,760 --> 01:16:43,840 remove features? When are you going to control the flow of features so that 914 01:16:43,920 --> 01:16:48,239 you're not overloading the whole system, And a cognitive load map could help you 915 01:16:48,239 --> 01:16:53,760 know, visualize what's going on in a given organization and figure out is it 916 01:16:53,880 --> 01:17:00,000 running really hot somewhere and does that correlate to you know, some other things 917 01:17:00,159 --> 01:17:03,119 you could do like value stream mapping and seeing like how is your value actually 918 01:17:03,119 --> 01:17:08,880 flowing? And oh if it tickles this one, you know point in the 919 01:17:08,960 --> 01:17:12,239 stream that seems to always be slow. Oh, and it happens to map 920 01:17:12,279 --> 01:17:17,039 to some team that's really read right in the map. Ah, there's maybe 921 01:17:17,039 --> 01:17:23,199 a constraint I can work on. And you know's I think platforms and I 922 01:17:23,239 --> 01:17:27,079 think I heard this on the the podcast you just publish it. Look at 923 01:17:27,199 --> 01:17:30,159 people tend to go big bang, right, It's been forever it initiatives have 924 01:17:30,239 --> 01:17:38,800 always been like massive undertakings and you need to focus on experiments. You need 925 01:17:38,840 --> 01:17:45,760 to focus on iterative value generation, right, and big bang is not about 926 01:17:45,760 --> 01:17:51,039 that. So it's another product mindset thing. Focus on your users, focus 927 01:17:51,079 --> 01:17:57,279 on the value you could get to them quickly, and figure out how you're 928 01:17:57,279 --> 01:18:00,640 going to measure whether or not that was a success. Do they feel any 929 01:18:00,640 --> 01:18:05,039 better about getting their work done right? And there's all sorts of tools for 930 01:18:05,199 --> 01:18:11,439 assessing that. There's a model from NASA son and we'll get into cognitive load 931 01:18:11,479 --> 01:18:17,079 for a minute. Cognitive load is a model for talking about learning. So 932 01:18:17,399 --> 01:18:20,159 there are three components to it, and I don't think we have time to 933 01:18:20,199 --> 01:18:26,680 go into it in any real depth. But it is primarily concerned with people's 934 01:18:26,680 --> 01:18:32,399 ability to learn new things, and so it doesn't map perfectly over to platforms. 935 01:18:33,840 --> 01:18:39,800 There's some sort of gaps with how that works. NASA came up with 936 01:18:39,840 --> 01:18:45,840 a model called mental workload that took into account cognitive load but also physical conditions, 937 01:18:46,600 --> 01:18:53,119 time constraints, things like that. We actually have a tool for surveying 938 01:18:53,239 --> 01:18:57,840 teams on this and it can kind of give you a better idea of the 939 01:18:58,600 --> 01:19:00,880 you know, they would use it with Astronaut and say, we gave you 940 01:19:00,920 --> 01:19:04,680 this problem to solve. You know, your spaceship is about to fall out 941 01:19:04,680 --> 01:19:09,439 of the sky, and how did you feel about solving that problem? Right? 942 01:19:10,000 --> 01:19:14,960 And you know that I think those kinds of signals could be really useful 943 01:19:15,000 --> 01:19:18,960 in figuring out if you're actually solving problems for teams. No, I mean 944 01:19:19,000 --> 01:19:23,239 it's it's such an interesting topic and I really wish we had more time. 945 01:19:23,279 --> 01:19:27,000 So maybe this is a part two, Part two, Yeah, yeah, 946 01:19:27,039 --> 01:19:30,640 back and tells us how to calculate cognitive flow and do it effectively in organizations. 947 01:19:30,920 --> 01:19:34,359 So there is something that we always do on this podcast, which is 948 01:19:34,800 --> 01:19:41,720 picked. Hey, you promised there was no I know, you know. 949 01:19:41,960 --> 01:19:46,760 I joked with Will early on that this is actually the struggle for me to 950 01:19:46,800 --> 01:19:48,880 come up with one of these, and that I have to come up with 951 01:19:48,960 --> 01:19:54,720 one every single week. So that's fifty two a year, and I just 952 01:19:54,760 --> 01:19:59,840 don't have that many many things to go through. So Grassmnets draws there, 953 01:20:00,560 --> 01:20:03,239 but I'll go first. So my pick of the week is going to be 954 01:20:03,399 --> 01:20:09,680 the Fifth Discipline by Peter Senge, which actually dives into how to think about 955 01:20:09,720 --> 01:20:13,359 systems thinking, how to apply it in organizations, how to apply it in 956 01:20:13,399 --> 01:20:18,399 situations. It's very this is an introductory topic to systems thinking and systems engineering 957 01:20:18,439 --> 01:20:21,640 and how to apply it. And I think it's something that a lot of 958 01:20:23,119 --> 01:20:27,359 engineers would really find beneficial, like how to actually think about organization in sort 959 01:20:27,359 --> 01:20:30,760 of a technical way and help us justify when to build platforms and what is 960 01:20:30,800 --> 01:20:35,439 that actually do to the organization. You know, what problems will that actually 961 01:20:35,479 --> 01:20:40,680 solve longer down the line. And it's something that I find is missing very 962 01:20:40,680 --> 01:20:50,479 frequently. I there's a bunch of things. I've one of the problems that 963 01:20:50,479 --> 01:20:57,920 we have with platforms and technologies is listening skills. Everyone in technology is really 964 01:20:57,960 --> 01:21:00,920 eager to jump to solutioning. You know, they'll hear the beginnings of a 965 01:21:00,960 --> 01:21:09,479 problem and they'll just start thinking solutions. So the ability to generate more ideas 966 01:21:09,520 --> 01:21:16,520 and be flexible about ideas is important. And it's an interesting book Adam Grant 967 01:21:16,720 --> 01:21:20,560 that I'm listening to I haven't even finished, called Originals, and it talks 968 01:21:20,600 --> 01:21:31,119 about how creative people just produce more and they're not necessarily as self critical. 969 01:21:31,199 --> 01:21:35,720 They're not necessarily good at judging what success is like. There's some other stuff 970 01:21:35,720 --> 01:21:41,720 in the book about how to figure out that success. So I think that 971 01:21:41,800 --> 01:21:49,199 there's a lot about interpersonal interactions and psychological safety and factors like that that are 972 01:21:49,359 --> 01:21:54,279 far more important. I guess my pick, and I'm always pitching. This 973 01:21:54,319 --> 01:21:59,359 one is actually a podcast called The Hidden Brain. It has given me so 974 01:21:59,720 --> 01:22:08,279 much insight into the counterintuitive ways that our brains work. We always we tend 975 01:22:08,279 --> 01:22:13,840 to assume one thing, and it's very frequently different from what we think, 976 01:22:14,359 --> 01:22:18,239 and that has a lot of impact about how we behave in you know organizational 977 01:22:18,319 --> 01:22:26,359 settings especially, so I would highly recommend The Hidden Brain is if you enjoy 978 01:22:26,399 --> 01:22:30,079 psychology or at all, or you'd like to know more about yourself. Sorry 979 01:22:30,119 --> 01:22:34,039 if that was seemingly off topic compared to your No, you know what. 980 01:22:34,199 --> 01:22:39,039 I actually had picked this before, and then you kept going into systems engineering. 981 01:22:39,079 --> 01:22:42,199 I'm like, wow, he's like selling my pick for me. No, 982 01:22:42,359 --> 01:22:44,159 I mean I like the Hidden Brain, you know. I think we'd 983 01:22:44,199 --> 01:22:48,119 get there realistically because those sorts of things affect our judgments, affect what we're 984 01:22:48,439 --> 01:22:51,720 where we focus on building. So I think that's highly relevant as well. 985 01:22:53,159 --> 01:22:56,319 No, I mean you can and I took two picks. Yeah, that's 986 01:22:56,720 --> 01:22:59,520 also fine. You're allowed to have two picks, you know. I like 987 01:22:59,560 --> 01:23:01,880 original. I think it is a great book by by Adam Grant as well. 988 01:23:01,960 --> 01:23:08,760 So okay, so that's it for today. Thank you David Thanking for 989 01:23:08,760 --> 01:23:11,880 for coming on and sharing your wisdom with us. It'd be really great to 990 01:23:11,920 --> 01:23:14,800 have you back on the show in the fund. Yeah we could go, 991 01:23:14,920 --> 01:23:18,079 we go all the way down into uh kangne of road. Yeah, definitely 992 01:23:18,119 --> 01:23:21,119 we should do it. Okay, So thank you everyone, Thank you for 993 01:23:21,119 --> 01:23:26,239 yours uh when We'll be back next week with well thanks for having me,