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,