Hello, and welcome everyone to another episode of Adventures and DevOps. I'm warrnt Broad your host, and unfortunately Will will not be joining us today. He'll be back next week when he returns from his vacation spot on the other side of the world. But today I'd like to introduce from more than twenty years in the industry, experience in platforms and consulting and advisory in many different areas work with the CNCF. With us today is David Stenglai, who great to
be here. Yeah, thanks for joining us. You know, originally you said that we could talk anything about platforms, and this is actually a really interesting topic because a couple of weeks ago I had brought up that meeting with a bunch of DevOps folks experience in the industry. We were actually trying to define what platforms actually are, like what is what counts as a platform And one of those conversations, the one of the co authors from Team Topologies was
suggesting that everything's a platform. And if everything's a platform, then I think there is this sort of a fear that it's very difficult to define. Maybe it's sort of one of those things that you, I know, when I see it, but you know, what it actually is can be difficult to identify and practice. What do you think? Uh yeah, And I kind of get where the team topologies people are coming from, especially with their minimum
viable platform, right, they define documentation as a minimum viable platform. But I think when we think about and there are many different kinds of platforms, but we think about them a little differently over time, especially modern platforms. So I have a definition that is almost intentionally vague, but it kind of encompasses a lot of things and helps kind of determine what they are. And that is that a platform is a system that allows you to build things and
gives them a home a place to run. And the other side of it is a platform either abstracts or completely captures work that the user of the platform would otherwise need to do. And so and that's it, because that is the basics of a platform, and it's it's kind of vague in general like that, because there's a lot of commonalities between what we think of as like end user platforms like an uber or something like that, and internal platforms.
Where it gets a little different is you know whether or not you have like that network producer consumer. You know, network effect type thing going on in internal platforms, and it can happen. But you know, the reason I like this definition is I feel like I've been working on platforms for nearly thirty
years. As an operating system, as a platform, you know, as a modern developer, even think about what the layout of blocks on disc is or how memory is managed for them, you know, out of system like that's a that to me is a platform. An operating system is something I can build and run on without having to worry about really low level stuff.
But platforms kind of accrete over time, right, you know, they get pushed down lower and lower, and like twenty twenty five, thirty years ago, we used to care a lot more about how processes were managed and how discs were laid out, And you know, there's only a very specialized few people who actually still care about that because we've built layers on top of it. So the definition of platform is a moving target. Over time, we expect more and more to get pushed down below us and to be able to
work with higher and higher abstractions. So to say everything is a platform, I wouldn't necessarily say that. I do agree that a minimum viable platform or minimum viable set of tools could include just documentation for a small group of people. But when you get to a modern platform that is especially now being defined around self service, right, you know, the criteria for it is a little different. And I think the distinction comes in between application and platform where
it gets really fuzzy. Right. So take Minecraft. Minecraft is a platform you can build stuff and run on top of it, right. But another game, like you know, a multiplayer with no extensibility, Well, that's that's an application. You might build much more, you know, high level conceptual things like clans or something like that on a game, but you don't get to build arbitrary things like you can in Minecraft. Right, people built
airplanes, computers. I think there's someone who wrote Doom to run inside of Minecraft. Right, so you know that's the proof of any sort of computer. It cannot run Doom. And so if it can run Doom, maybe that's a definition I never thought of. If it can run Doom, it's a platform, right. I mean, I think building on top of is an interesting way of looking at it, because even at very slow processing speeds,
you could make any sort of chat interface run Doom. Right, So I think I like that because it makes the distinction between we're running the thing and it's running on top of something else. You didn't mention that. You feel like the attention to some of the lower level platforms is not We don't
pay attention to it as much anymore. Is it because it's been highly optimized and there aren't a lot of further ways that we can take that, or is it that there's now a lot of different layers, a lot of different
abstractions that people are paying more and more attention to. It's because we can't, right, you know, one of the earlier parts of platforms and computing was escaping assembly language, right, you know, And there are still people who work in assembly language, of course, but you can't manage higher and higher levels of abstraction while needing to know how to do everything at every level.
I think it's important to understand how computers work, how like how the things work, But having the skill to work at all those levels doesn't really add up, right, So like, when you call yourself a full stack developer, you're probably not writing assembly right because you couldn't maintain your ability to work on higher level problems and all that low level stuff. You wouldn't be
very productive. So I think it's it's to some degree optimized because I've had a long time to figure out how to manage discs, how to manage memory. You know, Linux is I came from a background of Unix when it wasn't Linux didn't even I wouldn't say it didn't exist, but it was not allowed to be used in most you know, sort of corporate environments. And so we were managing like five different flavors of Unix systems. And now it's
consolidated and that level of abstraction to the operating system right is simplified. You know, you don't have to figure out where AUK is on like five different kinds of systems, So that that it's almost the necessity for us to be able to move up to higher level things to build on top that, even though they might be able to be optimized, we can't look at that.
Now. The flip side of that is we tend to accrete things and get away from them and not optimize them, and we end up with our platform potentially being really bloated underneath us because we're not paying full attention to the cost of the abstraction that we're doing, right, And so you know, there's a necessity to go through sometimes and figure out, like those few people who understand, go down through the layers and figure out are we making the best
use of this because hardware keeps getting so much faster, right, but yet we still manage to run at the same speed. Right, So we're doing something in order to like add new stuff but not make it more efficient that you know, for all that we've increased, I found an SD card that was two hundred and fifty six megs the other day, Right, you can
get a terabyted SD card pretty easily now. And the fact that we were able to do so much and such constrain and environments and get things done and responsive, and now we've added so much and we've got our slack clients like crushing computers and adding up to responsiveness that is just still in the similar range. Right. So that's one of the risks of abstracting like that over time.
I mean, you said something about that, and actually it sort of triggered me thinking if we add more levels of abstraction, can we still be in that situation where we understand enough about the stack in order to make optimizations
like, I feel like I've heard a lot over my career. Oh, but we still need to know how assembly is going to get built, because there's optimizations that we could be making at higher levels if we know about that, And I feel like that's sort of eroded over time because the number of
abstraction layers has definitely increased. I think there has been some return to that with like eBPF at the networking level, like sort of, okay, there are optimizations here, or there are things that we need to know at the lower levels inside the operating system, and we have multiple platforms on top of it, it's very difficult to see that. But I like you said assembly, I mean it even goes lower, like people aren't going to know exactly
how to stack the silicon to make the transist. Well, yeah, and maybe some of those layers will need to go away, Like I think WLASM will have a big impact on the intermediate layers, Like I think you're going to see a whole lot wiped out once it's going to take a few more years, but once you have WAZI components. So that's a good acronym stop
right. LASM is a web called web assembly and it's essentially an instruction set that allows browsers or originally browsers, to run sort of arbitrary code as opposed to you know, specific HTML and JavaScript and type stuff, so you can compile you know, used to be you had to target C code, you know, compiled code at a specific architecture and run it on that specific architecture, and WASM allows you to compile C code or other code that you normally
targets real machines to run on a web browser or a node dass back end. It's been around for a while and people have been waiting for it to kind of like you know, become more prevalent, and it's been slow to develop, but in a I think a good way, they're being considered because you know, they're there. There have been a lot of provisional standards of things that get partially released and then you end up with lots of like incompatible
implementations of things. So it's good that they're if they're building a universal format for running code that they you know, they take their time, and one of the big advancements that they've had recently is having high level an interface definition language with high level types between WASM modules so you'll be able to have a runtime with Python, Rust c code all interoperating with each other through the WASM
runtime using high level types and not needing all those languages to know directly how
to talk to each other or in bed or things like that. So, like all of the composition stuff that we do now in order to create software and either like making stubs for specific language run times or using even containers right like and saying oh, I need a sidecar and need another complete copy of Linux with its own libraries and all this other stuff, when really I just want this HTTP server with this specific kind of way of working that sort of
thing. That complexity will go away, and the WASM runtime will actually run HTTP between components with no network involved. So you'll get down to like nanosecond lay incies for making HDCP calls between components. They'll all be in the same run time, and you will eliminate all of that network and operating system stuff
that allows us to do composition now. And so I think that will a lot of its own complexities, right, but it will also eliminate a whole air of stuff that we're dealing with now to build software, which is I have to deal with a whole lot of operating system stuff and Docker and you know, all this other understanding when you know, I'd like to just be working in terms of higher level application tools, and so I think that kind of compaction is what we get over time. So like we figure out this
set of platform layers. We're working with this now, but it may not become part of the permanent, you know, strata underneath us because it hasn't proven itself, and we're going to go some other direction and maybe eliminate that layer, try an alternative, and then eventually, like Linux became, you know, the sort of standard operating system substrate, right, and it took a long time to get that consolidated and sort of decided as an industry.
No, I totally get that. I mean it makes a lot of sense actually when you if you're thinking about where the future of a particular component is going. And I've this isn't the first time I've heard web assembly. I think I've been brought up on a lot of teams I've led in the last decade, and it's always been like it's still too early in a way to
have these modules built and then running. Even if you're you know, using the website, and historically it was there weren't bindings available, but the idea that Okay, we're trying to figure out where the top of the pyramid is, where the actual application, where the actual value is, and the interoperability between modules that could be built in any language and then run only at run time proves okay, we sort of figured out a success path here. You
know. Now, let's get rid of all the crowd that doesn't directly deliver it that execution platform and focus on that. Rebuild it, rebuild what the browser is offering potentially, and get to the point where we can deliver the application on top of it. Yeah. One of the one of the sort of byproducts of web assembly that's been kind of useful already and probably increase is the access to the GPU from web assembly is starting to become standardized, which
means that writing code to talk to the GPU gets drastically simpler. So like right now, in order to talk to a GPU, you need, like, you know, you need the library specific to that GPU, you need a lot of library, you need a lot of code, And now it's becoming easier to just write some rust code that uses the GPU in a fairly compact way without requiring you know, a half a gig or a gigb library
downloads in order to get to it. So you know that that was done before AI was really prevalent, but like it's already sort of yielding some dividends in terms of simplifying being able to run, you know, and that you could think of that as a platform, Like that platform stack for running AI tools is enormous, but people have been working on sort of compacting it down,
like the Mozilla Foundation has. They call it Lama file and it is a single binary solution for running a local LLM, and it comes It's essentially a very fancy self extracting shell script with a bunch of zips in it and a new kind of lips that will run the same four gig binary includes all the model weights and the binaries to run on Windows, mac Os, Linux, ARM and x eighty six. To just download this thing, make it executable and run it wherever you are, and suddenly you have you know,
Olama running or sorry, open lama. This All of these things are named so similarly, right, it's like all some play on Lama. Olama is another system for running local LMS that's not related and they kind of make it easy, but they go through that gig download of just libraries. So like
that's another like platform stack that's just going to like get squashed. And right now, understanding what's going on in terms of at least the software platform really difficult, right, But if you can squash down those layers into I just need you know, we're in that kind of turbulent situation of extreme innovation where everyone's just utilizing things from everywhere else and then in a few years it'll settle
down and it'll be a little easier to understand what's going on because it'll standardize. It will be a much slimmer way of getting things done. I mean that seems like some like a great foresight there. Like I think everyone knows that the fads are going to end at some point and there's going to be what is left act the actual innovation. But that puts a name on it, right, It's it's that we are searching for the optimal usage here and
when someone figures it out, all those other things will go away. And we're actually seeing this sort of playout what's happening right now? Yeah, right
for sure? And I think there's a huge speed component as well, because unlike web assembly and the layers that came before it, which I want to say are things like infrastructure as code, especially in the develop space, there's a lot of companies putting a huge amount of financial capital behind quickly investing in hoping to both be the first and also most successful getting whatever it is user
percentage numbers. So any thoughts like so I do I have? I think the there's a hype curve, right, and I wrote a blog post about
it recently. Was they kept seeing, you know, the industry is just constantly one hype cycle after another, and you know, part of the Gartner hype cycles, it looks like this, and then it goes like there's that trough of disillusionment and then it climbs into a slope of you know what they call the the plateau of productivity or something like that, right, And there are some hype cycles which don't seem to result in a plateau of productivity.
They just seem to come through like a wave, but then drop back down again and not everyone catches it. And I think micro services are an example of that. There's in larger, slower moving organizations micro services have not really had that much benefit and potentially even been detrimental, like had almost the opposite effect of making systems far more complex and just as slow and maybe even more
dangerous than you know, the previous legacy systems that we're there. If you contrast that with something like big data, you know, big data as like the lifeblood of so many companies now and it and the difference between those two things, if you look at is business value, right, you know,
big data was easy to translate into business value. Microservices is just a technical solution to things, and there can be business value to it, but it didn't originate necessarily there, and it was to solve an engineering problem and an organizational a socio technical issue, and that ability to move fast I think ends
up being important but sometimes overplayed. So it's especially weird in a time like now when we have AI making everything move so much faster that there's this like big gap opening up between large and small players to the point where it's been you know, we're eighteen months little like maybe what twenty months in and the big players are trying to keep up and they're adopting things that are already legacy, right, So lang chain took so much mind share early on, and
then they got a hold out of the thought Works radar, right, one of the few things on the recently published radar that was actually a hold and it it just it probably hit it right at the point where a lot of companies were finally ready to start like adopting tools like that. And so like all of this continuous disruption and figuring out out has a natural cost to it, and I think everyone wants to move fast, but they're going to end
up wasting quite a bit in order to figure that out. And I think the companies that are more experimental with that rather than saying, oh, we're going to define the standard and go, it's not a time to define standards. It's a time to experiment and figure out what works and learn more nimble approaches to business, right, Because there's still plenty of companies that don't know how to experiment. They only know let's put it through a bureaucratic process that
gets us something to work with in eighteen months. For those that are generically
moving slower and aren't interested in defining the space or even experimenting. Is this the sort of thing where there's a lot of value in waiting and waiting it out, hopefully seeing where the leaders are and either I don't know, purchasing them through acquisitions or buying their products or partnering with them going forward, or is there still room everywhere for companies that are invested in technology in some way to also be experimenting. I think there are ways to experiment. I think
banking on things is a little tough right now. And there's an old saying I wish I could attribute it, but used to you know, encouraging people to use boring technology. Right it's it gets dangerous and it is an important
bit with platforms. If you throw too many sort of modern or non commodity things into your platform, you're going to end up with potentially a lot of parts that don't mesh very well together, and the experience of the users of your platform, both your internal and if you know, external users depend on it working, you know, well not be good. So you have to make a trade off of you know, I'm going to go for modern things for part of this, because they are still you know, bespoke and new
parts of that I can't get anywhere else. But you know, for these other things like the eighty percent, Right, I should be going for commodity items and not you know, overburden myself with too many new things at the same time. So yeah, there's there's plenty to be gained for you know, mL and AI have been around for a long time, right, It's
everyone wants to make it the core of everything. But you know, if you take a somewhat more experimental approach and figure out where the areas I could use it that are truly differentiating for my business as opposed to like a you know, a lot of executives are looking at AIS and cost savings, right, and it's not it's certainly not at the point of being that it is.
It's a first mover advantage, not a cost savings right now, and when it's a first mover advantage that is almost like the opposite of being a cost saver. Those are people who are willing to put money into things in
order to gain an advantage. There's a story from Simon Wordley about the beginning of cloud and how the cloud vendors were selling you know, corporations and such just you know, adopting cloud will save you money, right, And the first company to decide to use the cloud to accelerate basically threw that out the window because everyone else had to use the cloud to accelerate and therefore not save money. Right, So the same kinds of things play out with AI.
You know, using AI to save money will only work if everyone decides to do it that way. If someone uses it to accelerate past you, well you're probably going to be forced to do the same thing. Yeah, that's for sure the case. I mean, I remember thinking about when awos came
out. It wasn't it wasn't for everyone in a way. It was, oh, look at all these companies that are maybe in startup land where the tools they had were not really that effective, and we would just take all of that work, all of the capital expenditures that they would need to purchase physical machines, data centers, et cetera, and just immediately eliminate it. And for sure there is a capital expenditure sort of savings. They are cost
savings, but realistically, for sure it's on the speed side. Yeah, and that you know, aws and cloud providers are mashing. You know, they are platforms. They've grown in scope to where they're not always the best self service platform for your internal developers, and they did originally try and sort
of pitch that, but it gets messy really fast. But they did bring the whole concept of self service IT and computing to the four And what they did is they eliminated all that human in the loop stuff that people in itad traditional Like I want to set up an app, all right, I got to talk to procurement and get the hardware. I've got to get a team
that will set it up for me. I will get another team to set up other stuff on top, and like, you go through this whole process, whereas they made it all right, you make an API call and we'll give you a database, right, and you don't have to go through months and many different teams. So that aspect of platforms has kind of been trained
in from an early point in cloud. I think the difficulty is translating that between what cloud providers are sort of able to do and what organizations need to do either on top or beside that to provide a similar level of experience that is like specialized to what that organization needs. And you know, the people working on the cloud providers, they're all developers. They're used to building and systems that work as systems, whereas it people are not developers like systems,
people glue things together. They don't build, you know, rock solid solutions that they can present as an API to people. And that's been some of the gap of platforms being adopted internally, is that, you know, it's been a phase of adapting to oh, I need to build a rock solid product. Now I can't just make this one narrow automation of some specific task.
I need to make something other people can build on. That's a very different approach to things than what it is traditionally used to So it's taken time for that to filter out, and then you have vendors flooding into the space to try and make this easier for people to do and kind of build that product mindset as a product. But if you don't have the mindset of building
products to begin with, you can misuse tools. I mean, the same thing happens with all of our other like sort of micro services and cloud. If you keep the wrong mindset, you'll just do data center in the cloud. If you keep the wrong mindset with micro services, you'll just make a giant distributed monolith. If you go and keep an old it mindset with platforms, maybe you're going to require a ticket submitted right that you use the platform
on behalf of the user. So you know, there's a there's a continual like change in how we do things, but we tend to carry some of our existing ways of getting things done forward that is not usually pretty health think, yeah, for sure, that's a pretty good insight. I think. I mean, we're all we're talking about, and so you know you've nailed the web browser is for sure a platform for running code modules of all kinds, especially through web assembly, cloud AI? Are there we say there are
platforms everywhere? Are there other prominent areas of tech that sort of encompass this that you know are constantly on your mind? Or you know, these are the big three? So I think the the thing that doesn't get as much attention is the actual you know, we call them internal developer platforms, but what we mean are portals to platforms in most cases. Right, But until WASM becomes really widespread, I still think we have the issue of what is
the environment that the developer actually works in and builds and runs in. And there's a whole there's a giant stack in there that I don't think it's quite enough attention because a lot of the platform thinking happens from the system side and
not always the developer side. So systems people think, well, you know, once I get Tomcat installed, you're good, right, Or once I get the OS installed, you know, it's all Tomcat and then you're good, and Tomcat or whatever or node or whatever environment is just it's just a very base layer, and we've been trying to accommodate them with more and more
of the pipes, with meshes and stuff like that. But there is a whole aspect of building applications that could benefit from platforms in terms of, well, I need to talk to a database, how about I talk to it in a standardized way that's appropriate for my organization and what our local standards are
and how we've architected for talking to databases. And that bit is kind of not as doesn't get as much attention because it always feels like some of these you know, evolutions or revolutions always get pushed from one side of the house, right, and they therefore there isn't necessarily this kind of balanced view. So I think there are plenty of areas like that in the you know, data I've had a few people ask is a is a data system a platform?
Like, of course it is, but they don't, you know, they feel hesitant to bring it up because they don't feel I'm not sure why, Like, you know, it's easy to build stuff on top of data platforms and therefore call it a platform. But there's this perception that if it's not kubernetas, it's not a platform, right, And that's one of the things I think is a bit difficult, is the idea that like platforms have to look a certain way rather than be a mindset about something for people to
build them. No, I mean, I think that makes a lot of sense realistically, just getting stuck on the if it's not Kubernetes, it's it's not a platform. I mean, I think the answer here is that there were platforms before and there's got to be platforms like after that. Otherwise the word sort of doesn't have a lot of meaning. It's just alternative to that.
Yeah, and it really you know. So I am involved in the CNCF Working Group for Platforms, and I've been a little hesitant to get involved with the CNCF because their definition of cloud native is containers in kubernets right, And my definition of cloud native goes well longer in history than that. Like,
I'm more like the twelve factor app type cloud native, right. And the nice thing it's been is the Working Group for Platforms has been very open minded in terms of what a platform is defined as and what is important about a platform, and it has not been about kubernet As specifically, So I think there is some there is some movement towards, you know, figuring out what cloud native platforms look like without it being completely bound to kun Is because
I think, you know, everyone says that the you know, cloud native is built on containers, but like I said, WASM could throw that completely out the window within five years or so, so you know, making yourself completely dependent on a container development environment, workflow and mindset for building distributed applications might not be the best approach. So I mean, it's good for the CNCF because they're so heavily invested in a kubernet Is based ecosystem, with a
few other things possible. But I like that the Working Group for Platforms is more open minded than that, and you know, we're focused on making good habits and hygiene around how you work with people in an organization to decide, you know, what should we build and how do we deliver value better. So their their maturity model, which got published right around cupcom Chicago last fall.
It doesn't mention text acts right, and there is some eagerness for technical content from this working group, but I believe it has to be delivered in such a way as to not It needs to be sort of like you know, a cloud provider has, like you'll read the documentation, they'll be tabs for each language and SDK you could use to I think that's sort of the way we need to go about it in terms of providing you know, not
a specific reference implementation, but here's an approach you could take using two or three different options for making your platform code testable or something like that, right, and rather than picking a specific like you know, test kitchen for terror forms, like, show them a few different options and give them the mindset that they need to get into. I mean, I think that's a really interesting point. Containers took us a very far distance, and you know,
so thank you to Ducker for that. We got the oci out, the full initiative and now it is for sure an open standard. But you brought up a point earlier on where you that's not even really what you want to have to run or deploy, right, You may just want the HDP interface, and you still have to sort of decide, Okay, what's my base image, you know, where does that come from? You're really still just building on top of operating system or other technology, and no one for sure
actually really cares about that. And now we've got I mean, someone does, Like I don't want to want to throw that up. Someone does. Someone does, But we I think there was a I think in some ways Doctor took us a long way, but it also took us backwards too, interesting because there was a move to application paths like cloud Foundry h which is just sort of like a uh, you know, an installable version of like
a Heroku. That did a lot of you know, really looked at concerns from the engineer's perspective, like you know, people building systems as opposed to platforms, and it took a lot into account for them and really focused you know, it's very user focused. And we went a little backwards because of I mean, there were some issues with running up a platform that way and
that level of abstraction. We kind of decided a we didn't want that level of abstraction in that way, but also is a lot of cost and licensing
involved in the decision to sort of back off to something like kubernets. And then organizations find out that they're giving up all of these pass style features and suddenly, like I know of one organization that's figured out, oh, we went over to kubernets, and we didn't realize that, Like every app deployed in cloud Foundry got a like a managed ravi at MQ right and they had
a key. They didn't have to think about messaging for their app, and suddenly we moved them to kubernets, and we're forcing all these teams to figure out how to run hundreds of instances of you know, a queuing system. So I think there, you know, there's been a little bit of a backstep that wasn't even necessary in some cases, like for instance, take build
packs. Buill packs are wonderful for not caring about you know, the container stuff down below, but and there it's possible to use them with containers, but nobody does, I mean, same organization that's on cloud Foundry for some reason, instead of figuring out build packs on kubernets just went with making everyone produce Docker files, right, and so like all of that work invested in making their apps run as build packs needed to be you know, pretty much
redone in order to run on kubernetas. So so I do appreciate some of the stuff that we got out of Docker, Like I come from that, Like I said, that time of oh, figuring out how to package up software on several different operats, Like it's it's still an issue on LINEX how to package and distribute software. Docker does so much for that, but it's it's a lower level than we need to be for people to be productive building
applications and business value. I sort of want to dive into that because there seems like a really interesting corollary here between what you want out of the application layer that you're building and maybe some of the things that the YAMO file in the pod for Krubernetes offers, Like I can think about, you know, what does an application actually need? What would you prefer doctor to have provided it? Would it be like a the HTTP interface, the message bus,
like you just hook into standard strategies for that. You don't have to know what the implementation is. Is that yeah, exactly like the if I'm building an application, I want abstractions. I want to build. You know, I'm going to build a diagram, a logical diagram of an application, and it will have, you know, connections that are logical between components and not I have to do this APT get install of this thing and wire it up.
And there is a certain amount of there is a certain bit where developers don't understand those things so sometimes don't want to so they don't understand basics of like how network data moves right, and ports and firewalls and but you know, there's a like I said earlier, there's a difference between knowing about those
things and being forced to deal with them, right. So I think there is far too much in a helm chart or docer file that we force developers to understand and deal with as opposed to figuring out how to you know, ease the way. And there's a lot I think there is a fair bit of work being done on that, but again we keep pushing it from the
system side. Right, A lot of platforms dev so a lot of that stuff gets pushed from the system side, and we keep saying, well, we want you to work in this format, We're going to make it easier, and the developers are like, you know, it's just it's really complex.
Like there were a lot of developers are really into it because it's exciting, right, but at the same time, many of them just want to be able to figure out how to build what their job is telling them to build, and not take all these like side trips to figure out on stack overflow, like how do I get this like Docker composed to work or something like that. So yeah, you know, it's part of that is like the whole shift left idea, which puts too much on people on the left.
Right. The the idea of getting earlier on the process is good, but there's something else that came up and I don't know where it came from, but we were in we had a platform coffee before cupcon EU in the mornings, and someone brought up shift down so certain things should be shifted left and made a concern like, you know, testing, We've always had this idea that you know, separate QA team and everything, and there is a fair bit of the functionality of testing that should be done on the left,
but figuring out test frameworks and all of the plumbing and mechanics and practices that shouldn't get all shifted left, that should get shifted down, and you still need a quality engineering team. They're just not black box testing anymore. They're responsible for a different set of things that offload. As we've shifted load over to the DEDs by shifting left, now let's figure out how to offload some more of it again and put that on a team that has a product that
takes care of aspects of your testing. I thought for sure you're going to say platform, because you know the testers there are building maybe a platform for testing so that you can make it easier to pull those things in during the development cycle rather than having to be worried about each and every one of them. So that there's another definition of platforms that I came up with a while
back and sort of defining what they look like. And to me, a platform is a set of runtime environments and pipelines connecting them, and then frameworks to interface with those two things. So you know, you might have a QA framework or testing framework that allows you to drop testing into your pipelines. You might have a you know, a discovery API or something like that that
allows your app to function in the runtime environment. Right, So I think that some of these things are actual platforms and some of them are a little more distinct in terms of being frameworks to allow you to do things, and you're kind of building on the framework, but it's not actually the place where it runs, right, And so like think of maybe the build and pipeline systems as the platform and then other people, you know, giving you frameworks
to make it easier to run on those platforms. I like this definition. It makes it much clearer that there's specific things that people could align with rather than maybe some more abstract ideas. And the fact everything is called a platform, So it's the pipeline and the interface for it, and whether like some level of abstraction, whether it's HGTP, TCP or a full SDK or framework interact with, and what was the third piece runtime environment and the environment to
actually execute. Yeah, for sure that that makes a lot of sense realistically. And if it doesn't have all of that, it's marketing nonsense. Yeah, yeah, And that's why I, you know, like the whole idea of backstage and other things is internal developer platforms. I don't get the developer
platform thing. You know, your system is built on some sort of platform that needs to accommodate all of that stuff the runtime, and so you know, I think it's more appropriate to call things like backstage portals that interface to
the platforms, right. But you know, and it also leads to this, Well, there's some people who still don't quite get that when we say developer platform, I mean the platform for developers to build and operate things, and they're doing DevOps because everyone's thinking, oh, it's platform post DevOps is no. To me, it's the evolution of DevOps to the point where people can focus on their lane. Right. My lane is to build business value
in the form of applications. I shouldn't have to consider how blocks are stored on disk or buckets are managing a you or you know those sorts of things. Right. It allows me to do DevOps for my application, not DevOps for patching vulnerabilities in the operating system or you know, like like we were kind of forcing people to do in earlier forms of like total freedom DevOps,
but you know they're also totally responsible DevOps, right. I mean, I think it's a UX problem here, and maybe UX from a product standpoint, where as you said, it's being pushed from the system side, rather than if I really don't want to know about that stuff, there should be what what I like to call sensible defaults. I don't have to pick something it does. Give me the right block store and the right file system, and I don't have to know the difference between you know, ntfs and ext and
et cetera in order to actually even deploy my thing. Give me something that sort of works. And if I say, wait, the I OPS read and write to my disc is this slow? Is that reasonable? And then maybe I want to investigate and choose the options available rather than having to decide
that upfront. Yeah, And you want to be able to define your storage needs because you understand your storage needs in terms of maybe TPS right, and you know that, and you know, if you spend a little time with the work and you understand the application that you're building, you say, oh, if I'm trying to clear through you know, a thousand transactions of Jason of this rough set, like, oh, I need a diss that performs like this, And you can say to your maybe, to your platform,
I have this storage requirement space and speed and latency potentially right, and then maybe it can help you by saying, oh, you fall into this class, right, and that's the that's one of the differentiators in terms of platforms is I feel like Amazon and others their general purpose platforms, they're just the kitchen sink, right, you can build anything you want. What organizations need are opinionated platforms built on top of those with all those sensible defaults and guardrails.
And it's not just sensible defaults, it's sometimes just the inability to set
things that are just not appropriate for you. Right, you should not be setting security related things that's set for you and you have no way to override it, and that and capsulates a whole bunch of things that make life easier for everyone, you know, the idea of like maintaining security, auditing, you know, controls and compliance, Like if you take that approach of people stay in their lane and it's not so easy for them to break out of
it, then you know, we have a lot more control over the environment with a trade off and costs, like do you do you maintain speed and
flexibility? And they get this is like where the pendulum swings is. Sometimes those controls and security and compliance end up taking on too much weight and you know, the people trying to produce things on a platform end up suffering because well, we put all you know, we put all these safeguards in without figuring out with you what you need to do to get your job done.
And that's that product and user centric aspect of platforms as opposed that needs to be there to differentiate from how I used to work, which is we build
it, you will use it. Yeah. No, I mean I think you still sort of see that problem with the user experience From an innovation standpoint, If the users who are building the applications on top of your platform don't have any way to give you feedback on where they're getting slowed down or what they could use, what their actual needs are, then you have this sort of issue where the innovation can only come from those that are building a platform,
and they of course don't have the actual use case of building an application on top of it. And I've been struggling with this for a while now, and I'm not sure there is like a clean answer. I mean, if you have the best, perfect platform ever, a developer platform, then there is not really an issue, But how do you make real headway in how to change your platform and make it better if you aren't sort of dog
fooding at yourself. There is an option that's kind of in between, because it's difficult to get systems people to dog food the platforms entirely because a they don't historically work like the typical SDLC developer cycle, and b the work that they do is difficult to have work that way. So good a good engineering
life cycle. You know testing mostly unit tess you've got the test viearament mostly unit tests at the bottom, and you step off to integration functional and unfortunately, you know the way that systems people are required to work with cloud providers, it's very difficult for them to do lots of unit testing at the base. They end up getting stuck with integration. So it's immediately like a barrier to them, like changing the way they behave in the same way that their
users do. But they could go and talk to their users, and they could shadow their users, and they could spend time seeing how they work even if they don't work the same way, and just spend the time to listen and understand and figure out if they're what they're building actually solves a problem for the user as opposed to its traditional It is they're solving a problem for themselves, Like they have requests coming in they need to automate in order to be
able to survive the rate of requests. Yeah, for sure, And that's not what a you know. And the issue with like being built from one side is it's a massive loss in efficiency and a huge amount of cost. Say you have to build, say you build eight features in your platform, and only three of them are useful, like the developer, like you guessed
right, right for three out of the eight. That means you spent time on five things that you have to maintain that you spent time building that are not solving problems, so like they don't get as much effective change and their ability to get value delivered. You spent lots of time doing stuff that people didn't need and it ends up being a big cycle of waste. Right because we're not startups. We're not startups that are looking for product market fit.
We're not trying to figure out what customers want because we don't. It's a captive audience internally, you can just go talk to all of them, so you don't have the same constraints as a startup where you need to imagine what you're using will find useful you just go ask them, right, and then that allows you to prioritize what's going to be the most useful. Unfortunately, it has never functioned that way, right, or at least only partially ever
gotten there. So in order for platforms to be really successful and for all this speed to happen, you have to figure out exactly what's going to solve a problem, not be not come up with solution first, which is how I mean, that's how I remember my boss coming to me, is like, you know, oh, we're doing annual planning. Need to figure out the budget. What should we build for next year? Right? Like, what's what's it's just not let's go find out what users need and solve their
problems. It's way more fun that way, right, you know, these things seem fun, Let's go and deliver it. You know, I think five out of eight or three out of eight success, five out of eight failure. I think that's a great rate. Like everyone should be proud if they actually got three out of eight features. Yeah, that's true, that's true. Instead, what you get are entire platforms that are just not useful, right, and no adoption and become legacy you know, before ever being
born. I mean, I think you're lucky if you get no adoption.
I've seen this sinkhole of there's one team using it, who oh yeah, yeah in it forever, right, yeah, right, this big overblown thing and you only got partial adoption, and now you've just added to the stable of platforms you have to basically maintain forever because you never hit a solution that gets the clear adoption, which could actually have a negative impact in the organization if what you're actually providing is like automation of ticket you know, solves,
right, and those are the things that people necessarily want. Actually, I think there's a huge trouble here in trying to actually identify what the value is or quantify for the for the platform or for the features that you're adding there. And so because you can't do that very effective, it's even more difficult to remove things and prove that that would be a problem for someone. That's
where you get into at least a product mindset. And I hesitate to say product management because then people start to think they need to hire product managers and that's not necessary or even realistic. Like we go through these again, these hype cycles where like DevOps or story or everyone starts to think, oh, I need to create a job description and hire a few hundred people that fit that and put them on teams and we'll be set right. And that's not
realistic through any of these cycles, it's never been realistic. And so if we focus on a product mindset of finding out user pain points, figuring out the problems are what to solve, what I think you can get to is also if you're getting closer to how value is produced, you can actually start to draw a connection between the things you're doing and the value being produced because you're having an impact on the engineers that are directly producing the value, so
in a way, you're indirectly contributing to the same value. Whereas if you've just got a flow of tickets and you're just or you're just trying to make the system more reliable because you're in the way of things, like you're seen as a traditional cost center, right, we're trying to minimize your participation here because it seems like you just break things or you're only around to fix broken things. Whereas if you're solving pain points and you're making people work faster,
that's contribution to value. Right. So I think that the again, the mindset of focusing on users and their pain points and potentially pulling that especially sentiment about that in is how you start to get to measuring. For instance, I know of a company where someone created a you know, went to QCon conferences, you know, five six years ago, started to see talk about platforms and DevOps and this kind of developer productivity type stuff, and started what
amounted to a platform team. Instead of measuring things like Dora, they just measured for subjective things like developer satisfaction and they managed to go and as a by product fix all the you know, like their Dora metrics which they didn't track, went up, but they knew they were doing dozens of deployees a day instead of once every month, right, So which is more important People's ability to feel productive and get their work done when they're working directly on business
value, and then the byproduct being well that value flows faster, or focusing on the thing that is potentially gameable, which is just a number, right, like a Doro metric for deploy rate or things like that. I think those are signals of the system not terribly useful in terms of measuring value.
I mean there is this mantra of any metric that becomes the target ceases to be a good metric here, and I think the developer fulfillment is sort of an interesting I used to think that Doro metrics were well weighted to make it very hard to game in a way in which if you were to gain them, at least you would be doing something better than likely you are doing today.
But now I've started to see them for sure being gamed in ways which we're not intended and have negative consequences, like throwing feature flags in everywhere so that you can just get your code into production without actually having it tested, without it having incident appeal, without users actually seeing the code, and then
like, oh my Dora metric for cycle time is now low. Congrats, right, you know you just eliminated the metrics value and you threw all the work and all the tracking into a metric that you're not even paying attention to, which is sort of released to cycle time for the feature flag being enabled. Yeah, and so you've created a game so where I think Dora is appropriate. It's a system level signal that leadership should be using to figure out
what they're doing wrong. Yeah, and that's not how I mean, most places are looking at commit rates and things like that and talking to people about it instead of reflecting on why does my organization have trouble? You know, trending these Dora metrics in the right direction. And because you know, way companies are traditionally managed, it's always some sort of performance. That's why there's
all this like developer performance measurement and stuff like that. It's like, I can't POSSI simply, you know, have anything other than like a problem with the team or a person or like as soon as I fix that, you know, like gees, let's lay off the bottom ten percent every year like this, fire them and that will make everything better, right. And you know, I think more and more servant leaders are coming into existence who understand
that they have to build systems in which people can be successful. Right, And Dora metrics are one of many things that you could use as signal to understand are you building a successful system? Sentiment also very good, you know, the new I find it interesting that like forest Ground was involved with Dora moved on to space, which is you know, more subjective, much broader, and then you've got DX, which is just this triangle of not really
unmeasurable but far more user experience focused. Right. No, I mean that it brings me to ask, and I think maybe with with DX in space, maybe that's the answer. Is there a go to metric for you? Or is it? At least from my experience, it's like, let me take inventory of what the current situation is and see where there are opportunities for improvement which push something along in some way which I unblocks or you know,
you look at the obstacles or something like that. But it feels very subjective, like I see people getting stuck or I see communication failing in some way here. Let's work on improving the communication or the collaboration or unifying we the dozens of platforms we're using down to only a handful. Is there any sort of concrete metric that you more tend to like? I mean, it's all
perfect. I think from a technology perspective, you should be looking at things like SLOs that are inherently outward facing and relatively difficult to gain and kind of make you part of an ecosystem. And because there's a two, there's two sides to those sorts of metrics there's like, Okay, this is what our objective is. If we're not meeting an objective and it, you know, it doesn't match up with what the sentiment is in terms of user satisfaction.
It kind of like puts some tension there into having you know, the right kinds of numbers and you know, But at the same time, I don't think it's I think metrics get over used and also stay around for too long. There should be trends and things, and that you should identify parts of the system that require attention for periods of time, find your constraints, exploit
them, remove them, and then work on to other things. So in terms of like systems, metrics are useful for diagnosing right, and that they're not great to just watch all the time. Like you lots of data about how your system is functioning, but you should be looking at composite trends. You really should be business level things. Right, should be a combination of
employee satisfaction, customer satisfaction, financial performance. Right. If those things are in balance, almost nothing else matters, right, So, and you know, those are the things I would go for. But that's almost like a wouldn't call a pipe dream. Most organizations are really far from understanding that because technology doesn't communicate in business terms. And there I've said this many times.
Technologists are almost allergic to where their paycheck comes from. And I say that it was funny I got contradicted on that once in that I think in startup land people are fairly well connected to where their paycheck comes from. In big enterprise, they have no idea. In both cases, they find it very difficult to communicate with the business and get them to understand the value of what they're doing and you know that sort of thing. So it's so I don't
think there is one easy metric. What I'd like to see start happening is better communication with the rest of the business and the ability to align on you know, the sort of fundament because if you do that, you can get people to work on the most valuable thing, because you'll have a straighter line
tour. And this can go very deep in the organization too, and maybe allow the organization to make decisions about buy versus builds, like why are we spending so much of our human you know, capital on this thing which is like a commodity and you know, not paying for itself and I'm very careful with that because I also believe in the fact that you have you know, your humans are the most valuable thing, and simply treating them as resource so's
to be added to or removed as part of your cost just seems foolish. Right. So again, it's like a systems level thing signals for how leadership is doing. I was I had this fear you were going to say, e NPS score. I mean for what I I don't particularly like it. I think there is this h survey. Survey is not done well, give you the wrong signals, and I think it's very challenging to be able to effectively actually grasp is their fulfillment. On the engineering side, are our customers
actually happy? I mean, I think, so, here's here's one idea that we need to look out into the future in order to actually evaluate that. But then on the on the flip side, I think, oh wait, no, actually, companies are still bad even correctly evaluating where they're currently at. Let a let a load being able to correctly evaluate it on the line. The interesting thing with the SLO is uh, the service level objective
is that it's still very it's stary subjective in nature. Right, It's not like your I mean, your SLA is what you put in your contract, and your SLI is you know, the thing that you can actually measure what what what is happening? But that's a lot is like we want this,
and where does then our customers want this? We know our customers want this, right, But going back to the E NPS thing, I think that one of the mistakes I've seen is that if you're going to survey employees about their satisfaction or things like that, you you need to have a tread like you can't. You can't make your employee survey different every time you give it
to them, right, it is it doesn't give you a signal. Right, So, and I think that happens with a lot of metrics is that you'll see like a KPI board and all you'll see is the absolute numbers for the current time period with no trends, Like how am I supposed to? Like? I have to contextually understand the value of this absolute you know, and and and for many businesses they can get that, right, But if you don't know the trend, what's the what's the value of this thing?
Right? It should just be a binary a binary switch at that point, and so E NPS I think, yes, it's difficult to figure out, but what I think is more important is the trend in those things and deciding if you if you can tune it at all by making changes. The actual answers other than like a subjective rating might be difficult to interpret, but I think you could tell with an E NPS, like if you are going to make changes to a company, if it's going up or down, maybe you're
having an impact or not. Right. Yeah, I mean I've seen this done. It's one of those things that I've only ever seen done poorly, and I'm still waiting for that circumstance where it's like, oh, you know, we did it and it worked out great. I think there's the the team's change. Too frequently, there are too many changes in the organization, not like from an individual standpoint, to actually accurately be able to trend that
information over time. There's this knowledge that assuming the questions aren't bad, which they're usually bad in some way, you know, you're looking at the data and as a as a survey answer, you're you're filling that out and the result is often wait, I know what the right there's like a quote unquote right answer here, and if I answer negatively, I know what's Like,
I fear what's going to come next. There's going to be a conversation I don't want to have and worst case I do answer negatively and then nothing happens. Yeah, yeah, and that and that's a lot of what the approach is of people doing the surveying, Like why are you surveying? Are you again doing it from a like you're doing some sensing? Yeah, what was
your reasoning for doing that? And are you trying to figure out reactively how people are feeling and therefore say something different in the next town hall, right? Or are you actually interested in delivering change that addresses what is you keep
scratching deeper with? You know, I think E NPS, well, a small teams very difficult, like that any any team under a certain size, And I wouldn't say what that is arbitrarily that that isn't E NPS is like doesn't have value, right, doesn't have a this a statistical minimum right for things like that to have value. And if you're above a certain point, I really think it should just be like a one to ten, right, there shouldn't be a survey. It should be something easy to get sensing and
feedback on. And I've seen places where they even have like a kiosk and people just you know, bounce the numbers as a go through, like the bathroom ratings that they have and uh and uh you know that. Yeah, no, I mean that's for sure true. I think the problem with the one to ten. In a past life, we had some surveys in this
area. We were focused on improving leadership and getting feedback around that, and oh we had a sas tool and everything, and that didn't work out because it turns out that people are some people are notoriously bad at even knowing where they're at personally. Right. They say something's an issue, but it really wouldn't affect them, Like, oh, yeah, I would leave if we throw Kubernetes into our platform. But then you do it and they don't leave.
It's like, oh, I'll leave if we you know, I have to do manual testing and I'll have responsible for testing shift left, securities, shift left, you know, everything. Then they don't leave, right, So I think that's always been sort of a struggle there. I like, yeah, yeah, and that's an inner personal and that's you know, and again that's also size, right, I mean, sentimental is something you could you know, when you say true sentiment, that should be a statistical thing.
If you're dealing with a small group, you're not getting sentiment. You're getting like opinions, you know, or yeah, And that's a trickier thing,
you know. I used to think that platforms were and the kind of consulting I do, which is advise people on how to get started with platforms, evaluate what they need, we didn't even get the cognitive load, for instance, which is take a big on I wouldn't say misunderstood, but underutilized way of looking at platforms and how organizations function and at the organizational level, because they think there's a lot of emphasis on reducing cognitive load of developers.
And you know that doesn't work well if you just shove all that cognitive load somewhere else in the organization. So you really need to have a in an internal platform situation, you need to look at the distribution of cognitive load and make sure that it's kind of even right when you're when you're building a Sas for external customers, the amount you're you're reducing their cognitive load for some problem.
The amount that you take on really just has to do with your ability to be profitable and take on You could take on any amount of pain as long as you can be profitable for it, right, But with an internal platform, if you do that with your platform, you're just going to create bottle micks because there is no you know, with a platform team, there is no P and L. Ultimately, you know some people would like to think that way, but you know that there there isn't in the same way
that you get with an external platform. So yeah, I'm hearing the message should be there. There needs to be PN now for any team building a platform internally. Well, I hope I didn't say that no for sure or not. I mean I have thought about this in the past, and there are some things with chargebacks that some organizations have tried. I think there's an
interesting aspect here. The perfect market out in the world when you're selling to customers is realistically, you want the marginal value to go to zero, Like the amount you're getting your you're wasting or spending on building your thing is exactly how much customers are paying for it. If there's not, then either you know you're charging too much hypothetically. Now, of course you want to do that because then your business makes money and you can pay people, et cetera.
But internally I do see without that there is this sort of lack of
balance. The internal teams end up probably in deficit right there there. They don't get that feedback, so there's no measure for oh, you only have this much money coming in that we can support it, and they just keep adding features as you said, But now I'm wondering whether or not we need to be focusing on cognitive load more and if there's a way to directly calculate that, because you could figure out, oh, this is much cognitive load
we're reducing from the organization, and this is how much cognitive load we're centralizing in this other area or in this team. Their cognitive load is going to increase over time, and you could and you're going to bottleneck. Yeah for
sure. Yeah, is there a like well there isn't. Well, I've actually been working on something like a cognitive load map of an organization, so giving you the ability to visualize how cognitive load is distributed and combining that sort of like with the network of interactions that happen and figuring out if you can make it assignable, so assignable cognitive load. Can I assign it to the nature of work that I do? Can I assign it to some other team
that I interact with? Can I assign it to how I'm met, like you know, and start coming up with a way of kind of rating this, and then you should be able to get, you know, what sort of looks like a heat map, and if it's really out of balance, it should be really clear and you should be working to try and like even
out that heat map. And so you know, I think the team topologies focuses on the at the team level doing a cognitive load assessment figure out like when they're overloaded and when you might need a split and a team I actually also think we need to jump up and look at the whole organization and figure out how much flow are we trying to force through, Like take features you
mentioned features, like what are we doing about features? Like features just tend to go up forever, especially for internal things like when are you going to
remove features? When are you going to control the flow of features so that you're not overloading the whole system, And a cognitive load map could help you know, visualize what's going on in a given organization and figure out is it running really hot somewhere and does that correlate to you know, some other things you could do like value stream mapping and seeing like how is your value actually flowing? And oh if it tickles this one, you know point in the
stream that seems to always be slow. Oh, and it happens to map to some team that's really read right in the map. Ah, there's maybe a constraint I can work on. And you know's I think platforms and I think I heard this on the the podcast you just publish it. Look at people tend to go big bang, right, It's been forever it initiatives have always been like massive undertakings and you need to focus on experiments. You need to focus on iterative value generation, right, and big bang is not about
that. So it's another product mindset thing. Focus on your users, focus on the value you could get to them quickly, and figure out how you're going to measure whether or not that was a success. Do they feel any better about getting their work done right? And there's all sorts of tools for assessing that. There's a model from NASA son and we'll get into cognitive load
for a minute. Cognitive load is a model for talking about learning. So there are three components to it, and I don't think we have time to go into it in any real depth. But it is primarily concerned with people's ability to learn new things, and so it doesn't map perfectly over to platforms. There's some sort of gaps with how that works. NASA came up with a model called mental workload that took into account cognitive load but also physical conditions,
time constraints, things like that. We actually have a tool for surveying teams on this and it can kind of give you a better idea of the you know, they would use it with Astronaut and say, we gave you this problem to solve. You know, your spaceship is about to fall out of the sky, and how did you feel about solving that problem? Right? And you know that I think those kinds of signals could be really useful
in figuring out if you're actually solving problems for teams. No, I mean it's it's such an interesting topic and I really wish we had more time. So maybe this is a part two, Part two, Yeah, yeah, back and tells us how to calculate cognitive flow and do it effectively in organizations. So there is something that we always do on this podcast, which is picked. Hey, you promised there was no I know, you know.
I joked with Will early on that this is actually the struggle for me to come up with one of these, and that I have to come up with one every single week. So that's fifty two a year, and I just don't have that many many things to go through. So Grassmnets draws there, but I'll go first. So my pick of the week is going to be the Fifth Discipline by Peter Senge, which actually dives into how to think about systems thinking, how to apply it in organizations, how to apply it in
situations. It's very this is an introductory topic to systems thinking and systems engineering and how to apply it. And I think it's something that a lot of engineers would really find beneficial, like how to actually think about organization in sort of a technical way and help us justify when to build platforms and what is that actually do to the organization. You know, what problems will that actually solve longer down the line. And it's something that I find is missing very
frequently. I there's a bunch of things. I've one of the problems that we have with platforms and technologies is listening skills. Everyone in technology is really eager to jump to solutioning. You know, they'll hear the beginnings of a problem and they'll just start thinking solutions. So the ability to generate more ideas
and be flexible about ideas is important. And it's an interesting book Adam Grant that I'm listening to I haven't even finished, called Originals, and it talks about how creative people just produce more and they're not necessarily as self critical. They're not necessarily good at judging what success is like. There's some other stuff
in the book about how to figure out that success. So I think that there's a lot about interpersonal interactions and psychological safety and factors like that that are far more important. I guess my pick, and I'm always pitching. This one is actually a podcast called The Hidden Brain. It has given me so
much insight into the counterintuitive ways that our brains work. We always we tend to assume one thing, and it's very frequently different from what we think, and that has a lot of impact about how we behave in you know organizational settings especially, so I would highly recommend The Hidden Brain is if you enjoy psychology or at all, or you'd like to know more about yourself. Sorry if that was seemingly off topic compared to your No, you know what.
I actually had picked this before, and then you kept going into systems engineering. I'm like, wow, he's like selling my pick for me. No, I mean I like the Hidden Brain, you know. I think we'd get there realistically because those sorts of things affect our judgments, affect what we're where we focus on building. So I think that's highly relevant as well. No, I mean you can and I took two picks. Yeah, that's also fine. You're allowed to have two picks, you know. I like
original. I think it is a great book by by Adam Grant as well. So okay, so that's it for today. Thank you David Thanking for for coming on and sharing your wisdom with us. It'd be really great to have you back on the show in the fund. Yeah we could go, we go all the way down into uh kangne of road. Yeah, definitely we should do it. Okay, So thank you everyone, Thank you for yours uh when We'll be back next week with well thanks for having me,