WEBVTT 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,