Everybody thinks that tools is the problem, but it isn't.
I talked to around 390 platform engineering leaders this year.
One person said that tooling was their problem.
Today's guest is Sam Barlien, Community Organizer for the
world's largest platform engineering community.
Sam interviews engineering leaders to understand platform
engineering challenges and has uncovered surprising patterns
about why most organizations fail at it.
The problems will often be culture.
It'll be organizational challenges.
It's never, oh, did we use the right CI/CD tooling?
It's the culture around our CI/CD.
How would you describe platform engineering essentially?
Platform engineering as the discipline of treating internal
service like a product. Are you thinking about those
things like you are a product manager and the developers are
your customer? Are you doing user research?
That's the big differentiator. Why is it such a craze these
days that people want to adopt platform engineering?
If you are a developer 15 years ago, 9 out of 10 times, it was
just writing code. There probably wasn't that much
tooling. Now, zoom into today, the
average new tooling a developer had to onboard to was 12. 12 new
tools. This is insane!
Take every single problem I've just mentioned, add AI onto it.
And you see it's a 10x bigger problem now.
AI makes every single one of these issues 10x worse.
I was just at AWS re:Invent. And you can see for every talk
that has AI as the headline, it's platform engineering as the
core content within there. It's the thing that lets you do
AI safely, AI effectively, move fast.
Hey, quick pause. My goal with Tech Lead Journal
is simple. Learn from the best in tech so
we can all grow together. If this resonates with you, hit
subscribe to follow the channel. It's the biggest way for you to
support the show and help us keep bringing great guests and
insights to you. Thanks for being here, and let's
get back to it. Hello everyone.
Welcome back to another new episode of the Tech Journal
podcast. Today I have with me Sam
Barlien. He's the community organizer for
the Platform Engineering community.
So I think platform engineering has always been kind of like a
big topics these days. A little bit, you know,
overwhelmed by AI these days. But hopefully we can switch a
gear a little bit to platform engineering and what's so cool
about the latest and greatest in platform engineering.
Because Sam is really deep into platform engineering.
He's been running the community, running conference.
And I hope today we are going to learn a lot of things cool about
platform engineering lately. So Sam, welcome to the show.
Yeah, thank you very much. It is a, it's a big honor.
I've watched quite a few so it's quite cool being here and now
and getting to see myself up there with some pretty nice
ranks. So thank you so much, Henry.
I'm glad to be here and I think platform engineering, you know,
really is one of, in my view, the hottest but also equally
most forgotten enterprise trends at the moment.
You know, AI obviously takes over everything.
But I think I'll be able to make a pretty compelling argument as
we go through this, why platform engineering is absolutely not
something we should be sleeping on.
So super looking forward to talking to you about about it.
Yeah. So when you say AI is taking
over, it is indeed has been taking over, you know, maybe in
the news, in the topics, discussions, wherever.
We talk about always AI. AI engineering, AI-assisted
development. So yeah, hopefully today we can
learn something about platform engineering.
But before we go deep into that, I always love to invite my
guests to share a little bit more about yourself by maybe
telling us career turning points that you think we all can learn
from you. Sure.
I mean, I'll start with a quick intro, kind of even, of who I am
and the community at large. So we are really the world's
largest platform engineering focused community.
So we've got like 270,000 people who read our content,
newsletters, blogs, courses, yada yada yada.
And those are DevOps engineers, SREs, platform engineers,
FinOps. And I do a lot of our research.
I do some of our kind of conversations with enterprise
leaders. I mean, I talk to like 400
engineering leaders a year basically.
You know, I have these meetings every week to just delve into
their problems and I grill them. If some of them are listening
they know. I really, I harass them.
I grill them. It's like the inquisition and
then turns into a bit of therapy.
And I think the turning point for me is this kind of
interesting conversation I have with everybody in my life before
platform engineering. Cause they're like, huh?
You work in platform engineering?
Like, what? You know, I have a technical
marketing background. I worked, I mean 10 years ago, I
worked as an actor but since then I've really been this kind
of technical marketing focus. So it's like how can someone who
worked in kind of marketing, community, even a bit of sales,
like how can you have any relevance in platform
engineering which is like a very deep technical domain?
And it's really because of the big differentiator platform
engineering has around a lot of other engineering — and I think
we're gonna get into that a lot — where platform engineering
requires a lot of cultural stuff.
Way more cultural stuff than people expect.
We're gonna touch on that a lot, I'm sure.
And that often requires a different kind of voice.
We need the architects, we need the engineers.
I obviously have enough of an engineering background to know
what I'm talking about. You gotta have it.
But the challenge for most organizations is never, oh, you
know, we're trying to figure out the code we need to write.
Absolutely not. The challenge is how do I get
this user research? How do I convince a developer to
tell me their problems? You know, how do I get people to
onboard onto my platform or to use our internal tooling?
That's very rarely a technological challenge.
It's, you know, marketing is a dirty word so I try not to use
marketing too much. It's a marketing challenge.
How do you internally market a tool to get your, you know, your
developers to onboard onto it? So that has really been the
turning point for me where I started to have these
conversations about platform engineering.
I started to really work on the product management side.
And I would get invited to speak.
I would get asked, hey, could you give me advice on how to
market my internal platform? And turns out I have a lot to
add on that topic. right? Thank you for sharing such an
interesting thing. So I guess indeed it's, I mean
there's a bit of fun fact when I research you on Google, right?
When I type in your name, the first thing that it pops out is
actually actors. So it is actually true that you
were an actor before. So maybe a little bit of
curiosity, what brings you to, you know, a more deep technical
profession now compared to the previous one?
So what led you turning from an actor into this, doing this now?
Well, the irony is like all the things that I loved about
acting, which was storytelling, telling stories, meeting new
people, you know, trying to translate some kind of message
in an interesting way, you know, that storytelling element of
acting. Like that was the thing that I
loved. And that's the thing that
engineering struggles with the most.
You know, it's the thing that makes platform engineering so
hard for people. You know, that storytelling
element of like, well how do I, and I'm gonna keep harping onto
this idea. Anyone who's ever tried to
launch an internal tool or an internal product and probably
got zero adoption. Oftentimes it's not a technical
problem. Sometimes it is.
You know, we all know sometimes it is.
But often it's they're totally missing the storytelling
element. You know, why should I use this
tool? Where does this tool fit into my
universe? And it just...
It seemed like such an odd shift but it's been such a naturally
perfect thing to be able to tell some of these stories.
To speak to a platform leader, understand their problem, and
then translate it to an engineer or vice versa.
Speak to a developer, understand their pain, and then translate
it to a product person or to a leader who are thinking in
completely different terminology, completely
different language. It's really the that
storytelling side that, you know, blew my mind how valuable
it could be and how useful it would be.
That's really where the shift happened for me.
Yeah, so it sounds like you are the perfect guest today.
So a little bit of acting background for storytelling.
You need to be careful. I'll talk too much.
Yeah. Someone who is also deep in the
platform engineering community, talking to a lot of leaders
every day, every week, right? And also someone who is, who has
the technical background, technical capability to actually
know the stuff required for platform engineering.
But before we dive deep into strategy, you know, how to
adopt, how to sell platform engineering, we know that the
term platform itself is a bit convoluted, right?
Many different people associate platform with many different
things. Not to mention also vendors try
to sell their platform. So whatever platform it is.
So maybe by definition first, how would you describe a
platform and what is platform engineering essentially?
Sure. So I think the simpler way to
look at it. There's specific definitions for
platform engineering. But really platform engineering
is just the treatment of an internal platform.
And platform could be a catch-all term for service,
collection of tooling. It's to treat that tooling like
a product. That's really the simplest way
to think about it and I will go into more detail on that.
Now platform is a really confusing term.
You know, Meta has a platform, Facebook is a platform,
Salesforce is a platform. I understand that's totally
confusing. So we tend to use the term
internal developer platform, so like IDP for short because it's
that internal platform which is the conglomeration of all the
tech, the tools, the services, combined together with an
abstraction layer on top to serve developers.
Now in the last, you know, few months and years, it's grown
beyond developers to include, you know, SREs and data
engineers and especially with AI, now with agents.
But really you should just think about platform engineering as
the discipline of treating an internal, like an internal
service like a product. And when I say like a product
think about like a SaaS product, any SaaS product that you've
ever used. It probably has a name, it
probably has documentation, it has customer success, it has
product managers. And that's what really
differentiates platform engineering from say DevOps or
SRE. People will talk about the goal
of platform engineering and you'll have someone who's, you
know, very familiar with the philosophy of DevOps be like
well, I already do automation. You know, I already think about
self-service workflows for developers.
Sure. But are you thinking about those
things like you are a product manager and the developers are
your customer? Are you doing user research?
Are you interviewing your developers on the workflows?
That's the big differentiator between what is platform
engineering and what is not platform engineering.
And I can really say, you know, I'll have conversations with
people at conferences and I'll be like, hey, what do you do?
Oh I'm a platform engineer. I'm like, awesome.
You know how do you decide what features tp add to your
platform? I'm like, oh, well, you're doing
platform as a product? No.
Okay. How do you decide what features
to add to the platform? Oh we just have some beers and
we decide. Okay, so you're not a platform
engineer. You know, you're probably just
an operations team who has now renamed themselves platform
engineering. And that's really the key
differentiator that I think anyone here listening needs to
think about. If you are treating your
internal service like a product then you're probably doing
platform engineering. If you're not, then you aren't
doing platform engineering yet. Yeah, I like the angle that you
mentioned, you know, treating platform as a product, right?
Because I'm sure many people try to adopt so-called platform or
platform engineering within their organizations, but not
many actually treat them as a product, right?
It could be just a top-down approach.
Maybe this is the latest cool trend, people just wanna
implement that. And yeah, not treating it as a
product. But I think before we go into
that, right, why is it such a craze these days that people
want to adopt platform engineering?
Because in the past, maybe I don't know, 10 years ago, people
do not actually talk about platform.
They maybe talk more about cloud, you know, maybe
integrating SaaS product. And I feel actually cloud is
kind of like one of the biggest success stories of a platform or
platform engineering, right? Oh yeah.
So why all the craze these days about, you know, every
organizations want to adopt platform engineering?
Well I think, you know, there's a fantastic graphic that you can
find somewhere but I will verbalize the graphic for the
audience. And it's when you think about if
you are a developer, what you had to do 10 years ago.
Or we're in 2025 now, so I'll say 15 years ago.
Time's moving too fast, Henry. So 15 years ago, you think about
what was in the remit of a developer. 9 out of 10 times it
was just writing code. There probably wasn't that much
tooling, maybe one or two tools they had to use.
Your organization was not containerized.
Certainly not. There was no
infrastructure-as-code. If you were using the cloud you
were probably a very fast mover, you almost certainly weren't.
So the expectations for you as a developer were very minimal.
Now that also came with a kind of throw it over the fence
mentality. DevOps hadn't really caught on
yet in most organizations. So, you know, you had a much
simpler remit as a developer. What that meant was a
considerable less amount of cognitive load.
There was less challenge when onboarding.
It's like, okay, if you're, you just need to learn some
languages, maybe one or two tools.
Onboarding a person to that or finding people you can onboard
quickly is not too challenging. Now zoom into today, or
certainly two or three years ago before platform engineering
really took off, what does a developer have to learn?
You know, a new hire at Netflix. How much, how many tools do they
need to learn? I mean we did a survey in 2022
and the average new tooling a developer had to onboard to was
12. 12 new tools. And, you know, these are not,
oh, great, here we go I can just one click button.
It's not like a ChatGPT interface.
You know, it's 12 very complicated tools.
Probably a significant amount of ClickOps.
You're probably not able to just, you know, code base CLI
for everything. You're probably having to
navigate through a bunch of tools.
Maybe you're having to learn bits of Argo, bits of Terraform
because, oh, this little item. Ah, it's easier, you know, we
shift left. Let's just have the developer do
it themselves. Oh, they want an S3 bucket?
Well, let's, you know they can go into the AWS cloud console
themselves. This is insane.
You know, it's totally insane. And we all know I don't need to
talk about how great DevOps is. I think anybody listening knows
that DevOps was fantastic. At the time, it made perfect
sense, but you get a very muddled sense of what DevOps is
supposed to be in 2023 when the average developer now has to
deal with 10 tools, possibly even multi-cloud consoles.
They're having to deal themselves with bits of
Terraform. This is insane!
Makes onboarding impossible. It also makes the cognitive load
that's on that one developer impossible.
It also creates a huge overreliance on senior
developers. Because if you think, I'm a
junior dev, I don't really know Terraform, yeah, I need to do
this thing. Well, I'm gonna Slack message or
I'm gonna Teams message someone who can help me.
And so now you've got your highest paid developer make
real, the people making the big bucks, having to spend two,
three hours a day doing these shadow ops work.
It's not tenable. So that's really where the
platform engineering story came from.
And there have been people doing platform engineering for 10
years, just not calling it platform engineering.
But it wasn't something that was like absolutely necessary.
It was kind of an accelerator for fast movers or like a good
idea to improve things. But we get to the territory now,
you know, kind of 2021 and beyond where it's mandatory.
You can't have devs dealing with this current system anymore.
It just, the system is imploding in and itself.
And so having something like an internal developer platform
where you take those 10 tools, integrate them into one IDP, put
a single interface over it, and now your developers just dealing
with one interface. That can be a code-based
interface. It could even be a neural
language interface or natural language interface that could
just be using Claude or something.
And now you're able to have the developer onboard faster, less
cognitive load, less likelihood of mistakes.
I mean, think about, you know, I'm using Terraform as a big
example here cause I was just working with a team who's having
lots of Terraform problems. Think about how many
unstandardized Terraform files your organization might have if
every developer is having to make some of their own Terraform
files. Platform engineering would
standardize all of those. It would give you templates
within the platform that they would have to use.
So you can see immediately the security benefits, the
governance benefits, the observability benefits.
And then when I answer your next question why is things
accelerating so much now? Take every single problem I've
just mentioned, add AI onto it, and you see it's a 10x bigger
problem now. AI makes every single one of
these issues 10x worse. 10 times more bad Terraform files, a 100x
more clunky code, 10 times more security problems.
And that's where platform engineering has really shined
over the last six months. You know, I was just at AWS
Reinvent and you can see for every booth, every talk that has
AI as the headline, it's platform engineering as the core
content within there. Cause it's the thing that lets
you do AI safely, AI effectively, move fast.
So there we go. The big answer to your short
question but that's a question that's really on my mind and I
think is important for people to understand.
Yeah, I find it's such a great overview, right?
So you mentioned, kind of like all the pain, the problems that
engineers these days are experiencing.
So for example, cognitive load, right?
So we are always kind of like thankful for all the modern
technologies and toolings available.
But also with the amount of options that we have now, the
pace of change, the advancement, not to mention with the addition
of AI. So we need to learn more, we
need to do more. In fact, to deliver a single
piece of software or even a single line of code, it's not as
easy as, you know, just deploy one command or you push a button
and it gets deployed, right? And I would say the expectations
also changed a lot since maybe, I don't know, 15, 20 years ago.
We don't really software as frequent as now, but we now have
the DORA metrics saying that you have to deploy, you know,
multiple times a day. So that kind of like creates an
expectation for you to easily deploy software or make some
changes into your, you know, ecosystem, right?
So I think the challenge of platform engineering definitely
is huge. And a lot of developers,
especially in big organizations, you mentioned about security,
standardization, guardrails, and now with AI governance and all
that, I think it's very compelling to have platform
engineering. So we talk about the role.
You mentioned about SRE, DevOps, and now we have platform
engineer. Are there any differences in
terms of, you know, skillset, capabilities?
How would you differentiate all this?
Because, again, it's a convoluted term.
People call DevOps engineer, some companies called SRE, and
some called platform engineers. It's such a confusing place now.
Yeah and I think, you know, organizations are always
terrible with this terminology stuff.
I mean you can still, you can go on LinkedIn right now and you
can search for DevOps engineer and you can find a job that's
actually an SRE or is actually just an ops person or is
actually a platform engineer but it's called DevOps engineer.
And it's the same for SRE, it's the same for platform engineer.
So it's very hard for new joiners for sure.
But if I lay the three out next to each other, like I said kind
of at the beginning, the key differentiator for platform
engineer is the product mindset element.
It's the product management stuff.
So if you are someone who is, you know, working in ops, you
have the DevOps philosophy, you really believe in it, platform
engineering is just adding product management to that.
Now you don't have to become a genius product manager yourself,
but you do need to understand some of these core components of
product management. That's the big differentiator.
When you look at what are the the coding languages, what are
the tools, you know, what are the concept familiarity, it's
95% the same between SRE, platform engineering, and
DevOps. The core difference is that
platform engineering has the product management side.
And I think it's a very, very, very key difference.
You know, it solves a lot of the challenges that organizations
have had with DevOps. You know, it's, failing is a
strong word but the majority of organizations are failing at
DevOps. The majority of organizations
are failing at SRE. You know, I talk to teams all
the time and they're like ah, you know, we're trying to do
SRE, it's not working. I'm like well where do you get
your best practices? From the SRE book, of course.
And I'm like you're not Google. You are not Google.
You don't have Google resources. You don't have Google money, and
you don't have Google culture. So why are you trying to do
Google SRE without any of those things?
Of course, it's failing and it's the exact same thing for DevOps.
I talk to teams every single day who are like DevOps has been a
disaster for us. And I'm I go through and it's
like well, they're not really doing very good DevOps.
So it's you can't blame DevOps for it to an extent.
But that I see is such a problem so often with DevOps and with
SRE. And platform engineering really
aims to solve that. That's where the product
management side comes into it. Yeah, again, I like your
emphasis of adding the product mindset, right?
So think of it just like the, in the beginning you mentioned
about adding features, right? Do you decide it over a beer or
just a chat, casual chat within between colleagues?
Or do you actually put like user mindset, user research, user
pain problems, you know, you're trying to solve?
I think that's a key mindset thing.
And, and you mentioned about, you know, people adopting SRE by
following, you know, I dunno, Google or maybe other big
companies, Amazon, whatever that is.
I think that's also true in the market, right?
We always love to find Silver Bullet and especially also
vendors, consultants, trying to sell, you know, the best way of
doing something. And I think you mentioned before
we chat that actually all these tools, frameworks, and all that
actually don't really matter. And in fact, you validate that
by talking to, you know, hundreds of engineering leaders
out there. Oh yeah.
So tell us, this, I think these insights because people still
think we need to find a silver bullet, we need to find a tools,
framework, platforms out there that we can just plug and play
into our organization that then it'll work.
So maybe tell us why this is such, such a trap.
When you say everybody thinks that tools is the problem, I
will say everybody thinks that tools is the problem.
But it isn't. You know, every person who isn't
a leader or isn't leading a platform team or isn't an
experienced platform engineer thinks, oh, tech and tools.
I get asked by junior people about tech and tools all the
time. But I talked to around it's like
390 or something. I round it up to 400.
So spoilers for anyone, you know, for everyone listening
it's around 390. While the year's not over yet
maybe we'll get to 400. But around 390 platform
engineering leaders and engineering leaders this year,
one person said that tooling, a technological problem was their
problem. They couldn't find enough people
who are experienced with Kubernetes in their hiring.
That was their one one technological problem.
But overwhelmingly, the problems aren't tools.
The problems will often be culture.
Overwhelmingly, it will be organizational challenges.
It will be training, it will be documentation, it'll be product
management issues. And there are tooling
challenges, of course. If you think about some of the
AI tooling challenges teams are having.
You know, procurement is not designed for how fast new tools
are coming, how fast tools are improving, and how fast tools
are being replaced. If you think about an enterprise
procurement lifecycle, you know, it it could take like six
months. And the idea is that they wanna
lock in a tool for two to three years.
That doesn't work when an AI tool I pick now could be
replaced in a month. You know, that sounds like a
tooling problem. And someone might be like, oh
well that's the tool problem. Tools are getting better or
worse. No, it's a culture problem.
Your culture hasn't adapted to an environment of being able to
experiment with new tooling in a safe way.
So that you can be like, okay, this is the best in class tool
right now. Let's play around with it and
then find out in a month. Okay, it wasn't the tool that we
wanted. We need to experiment with
something else. That's a culture problem.
That's not a problem with the tools.
That's that our cultures are not able to keep up with how fast
things are moving now. And that's really, you know, I
keep harping back to this product idea.
When you think about a product, a product doesn't have a
deadline on it. It doesn't, you know, Facebook
doesn't end on January 1st. You don't get, you know, it's
constant. It's living.
It keeps getting updated. It keeps changing.
You have to keep thinking about is this the best it can be.
Is this some. Are there modules that should be
swapped out? Are there things that should
change? And your organization can be
thought about this as well. And it's always the cultural
things that are the big challenge there.
So when I talk to a lot of these engineering leaders what are the
types of problems that they're having.
Well, shared language is a really big one.
That's something that we have touched on extensively here.
The head of platform or the VP engineering might be like, okay
platform engineering I really get it.
You know, I know platform is a product, I understand all of
this. But then their whole team is,
you know, thinking DevOps, thinking SRE, doesn't understand
it. That's a big problem.
Or even worse when we get into like granularity of details.
They're thinking, oh, we have a platform.
You know, we use AWS cloud console.
Or, you know, Kubernetes is a platform, isn't it, technically?
So we have Kubernetes. That's our platform.
It's like, this is where you need to think about these shared
language ideas. And then, of course, it's things
like getting buy-in. Getting buy-in is always going
to be the number one problem. Now that can be, if you're, you
know, someone like you and I and you want to get the CTO, you
wanna get the money for your organization, getting the buy-in
from your executives or from your leadership, that is where a
lot of people struggle. But a lot of the time when I
talk to these engineering leaders their boss gets it.
They're like awesome. You know, this is fantastic.
It's getting buy-in from from more junior people getting
adoption of the platform. It's like we've built this
amazing platform. It's fantastic.
We gave it a cool name. No one's using it.
What's the problem? You know, it's those types of
cultural challenges which are the things that really, really,
really challenge teams. It's never the tool that they're
using. It's never, oh, did we use the
right, you know, CI/CD tooling? It's is the culture around our
CI/CD able to get the most out of it.
So really that's the key thing. Key takeaway I think from any
talk I've ever done, that's what people should get from it.
Yeah, again, it's to emphasize, right?
It's not about tooling, it's not about the tech stack that you
have within the organization. It's not about Kubernetes at
all. So, right, it's more about like,
you know, your mindset, your culture, your adoption, your
product thinking, right? So I think, if you're still
thinking platform is something that you can just buy, procure,
and implement in your organization, I think that's
probably one of the biggest trap.
And that's why probably your, your so-called project, platform
engineering does not succeed, right?
And you talk about, you know, many many organizations are
failing and I think, probably the first one I would assume
that, you know, thinking, building a platform as a
project, right? So it's like, okay, we have a
goal of, I don't know, implement something within a year.
So tell us, how should the leaders actually pitch, pitch it
differently, because I'm sure when people want to, you know,
so called, put a budget upfront about we, hey, we wanna build a
platform within our organization.
They'll think, okay, this is a timeline, right?
But actually you mentioned if we treat it as a product, it's
actually a continuous evolution and it'll always evolve over the
time. So I think this is the first
thing. Maybe if you can enlighten us,
how do we actually pitch it differently as a product instead
of a project? Well, I think the two things I
would say there is the immediate answer.
The first one is that you probably have some form of
platform already. You're just not treating one
like it's a product and you're not thinking about it in that
way. You know, I always talk about
how if you don't build your platform, it'll build itself.
And so you probably have your it kind of disjointed CI/CD.
There's probably some kind of DevOps philosophy workflows.
There's probably some observability stuff that's maybe
a bit disconnected or maybe it is connected.
It's just not being thought of in that kind of platform way
with that product mindset. So one of the first things I
would do is identify those things.
And then the second part is really thinking about starting
small. Really start small.
So we talk a lot about this concept of a minimum viable
platform. When you're talking about
platform engineering and these big cultural changes, it sounds
very scary. And it also clearly seems like
you could incorporate so much into it.
You're like oh my God, we could take the entire CI/CD.
We could put all of that in there.
We can put the AI stuff. We can put all the security
stuff. Well, we can have the data
platform built into it. And then suddenly you're like
wow, wow, okay. This is now three year timeline.
It's a huge org transformation. I need 10 million to do this.
Everything's gonna implode immediately.
Really think small. Think about, okay, what is a
sample app? What is a pioneer team?
What's the first way to really think about this in a small way?
Give yourself like, okay, we're gonna spend four weeks
onboarding a sample app, getting that on demonstrating how this
abstracted layer within the platform improves whatever
target thing you're looking at. The target thing is gonna be key
to your organization. It will be different in your org
versus in mine. I think testing is a great
landscape to look at. Onboarding is a good landscape
to look at. You know, if there's kind of
ticket ops, there's issues with your ticket flow and your CI/CD,
that's a good thing to look at, but it could be completely
different for you. And then identify that kind of
one easy thing on a sample app that's architecture looks the
same as 90% of the rest of the organization or your org.
And then absolutely nail that. Do that.
Do it very well. Get all the data you need to
improve. Figure out how this cultural
process works, how thinking about it as a product works.
You know, get these developer interviews, build that muscle
for yourself. And then expand from there.
I can tell you you will go 10 times faster than if you try and
get the entire state of your organization on board
immediately. Everyone I know who starts like
outrageously small, and then scales up in an MVP manner, ends
up being significantly further ahead than the people who try
and do everything at once. It also makes it way easier to
get buy-in. If you're coming and saying
like, hey I need half a million for two months.
This is what we're gonna do, that's a lot easier than being
like, yeah, we probably need like 5 million a year for three
years. And then after three years,
we'll see what happens. Really think small and then grow
big from there is always my advice.
So I think the thinking small, right, building the MVP relates
back to how you think of a platform as a product, right?
Because we always talk about building minimum viable product.
Start small, iterate, learn from the users, learn from the
experience. I think that's always kind of
like the biggest product mindset that people can adopt.
And I like what you mentioned about, you know, somehow either
we realize or not realize we do have something already running
in the organization, right? It could be some tooling that we
use, could, could be some process we used.
And in fact, if I'm not mistaken, I learned from Team
Topologies that the term platform itself doesn't always
mean, you know, you have to implement something or use a
product. It could be just a simple wiki
that you mentioned as a kind of like processes, how we do stuff.
That could be a start of the platform, right?
So I think don't try to overcomplicate things by, you
know, building a roadmap like three years, five years.
So yeah, always think small and try to measure, how the, the
platform has benefited the organization, right?
Which is my next question because sometimes it's very
difficult, first, to put forth the project, the budget, right,
to get, you know, in the first place.
And how to measure the success of this platform engineering,
you know, the ROI. So what are the typical
measurements that you think will be useful for organizations to,
you know, think about or try to aspire towards, right, so that
they know that their platform engineering effort actually is
successful. Well, the very obvious
non-answer at the beginning is that you need to measure at all.
You know, when I, we did our state of platform engineering
report. It's coming out next week and we
did one last year as well. And last year, 44% of those who
responded didn't measure anything.
They didn't measure a single thing.
That's almost half of platform teams weren't measuring.
So it's no surprise that when we ask them about ROI, improvement,
developer productivity, success of their platforms, they're like
either they're like, oh, I have no idea.
Or it wasn't going well. And of course, if you're not
measuring, how can you improve anything?
Now there's lots of frameworks for measuring which are really
great. You know, DORA, of course, it's
a bit of a leading indicator, but really looking at the DORA
metrics are is good. SPACE framework is great as
well. But I'll kind of break it down
rather than just the framework of measuring, more how you
should think about measuring in general.
Because it's such a wide topic. It's super confusing.
It's also not often a head space that engineers work in.
You know, it's why the platform product manager role having
someone who really gets that world is quite crucial to your
platform team. And when you think about
measuring, use that MVP idea that we thought about.
What is the thing that you are focusing on?
If you're focusing on 50 different things, obviously,
you're not gonna be able to measure.
Because you've got 50 different things that you're looking at.
So you will have no idea the impact of the platform on any of
those. It'll be too overwhelming.
Trying to get a baseline will be impossible.
But if we just take a simple thing like onboarding.
Onboarding is somewhere where I see lots of success.
So I talked to an organization about a month ago.
It took about four and a half weeks for a new developer to
push a single commit. They were quite, you know, four
and a half weeks is not too long but it's not particularly short.
And they wanted it to be way shorter.
So the platform team focused, okay, this is the next area of
feature set that we're gonna focus on.
So they thought about what are all the things that make it
difficult for a developer to do that first commit.
And they found most of it was compliance stuff.
It was because they would ha, they would write the code, the
code would then need to get checked by someone but then that
check would go into a ticketing flow.
The ticketing flow would go to someone that would go on their
list. Once it was on that person's
list, it would take a long time for them to get to it, because
it wasn't a low prio. It wasn't being marked in a
particularly high priority or not.
So when you think about measurement, they had a really
clear target. We know that it takes four and a
half weeks for a developer to push that first commit.
They wanted to get it down to sub-seven days.
Okay, so now they have their measuring baseline.
That isn't necessarily DORA, that's not SPACE.
That's not, but it's a really simple way to think about
improvement and ROI. Now the ROI question becomes,
okay, this is probably something that your product manager role.
But when you think about what is the value that a developer adds?
How much does a developer cost per month is often an easy way
to go about it. You can do the cost element and
you're like, okay, we hire a hundred developers per month.
Their average cost per month is this.
That lost month of coding time costs this.
Bam. There you go.
There's a number you can give to an executive.
Usually, that's the less sexy number.
The sexier number would be, you know, how much value is added
per month. And you can quantify those
things. You can see how I've taken a
wide universe of possibility and just broken it down really
simply into one metric. And it's like for this feature,
you know, for this problem, the measurement for that problem is
we wanna reduce from four and a half weeks to whatever that
reduction time is. And when you think about going
into a conversation about budget for your platform to secure
budget, to show improvement, and you're like, well, I can just
show on a slide with bright colors and a nice arrow pointing
in. Executives love stuff like that.
You can show it was four and a half weeks.
Now it's seven days. Developer time costs this.
This is the estimated increase in in benefit from that.
Bam. There you go.
What an incredibly valuable feature that you've done.
Now you can use DORA, you can use SPACE to help you think
about how you think you structure those types of
measurements. But that's really the way that I
would approach it. And it also forces you to think
small and think specific. Cause if you've got 25 things
you wanna focus on, you're never gonna be able to do any of what
I just suggested. So it's probably a pretty good
sign you're thinking about too much stuff if you are not able
to do that one example that I've just given there.
Yeah, so focus is the key, right?
So if you build, especially if you come from nothing, right, or
if you come from a non organized platform, right?
So always thinking in terms of focus.
What is the biggest user pain point that you're solving,
right? And try to focus on that.
And when you mentioned about all these, right?
I remember my conversation also with, you know, the DX team, the
developer experience team. Sometimes you don't even need to
come up with like a measurement number, metrics, right?
It could be a perception from developers, you know, thinking
about how you do onboarding, how you deploy software, how painful
it is, right? Yeah.
So that could also be a metric. And I think I wanna also
mention, since you've mentioned about storytelling, right?
I, I, we can, we can see just now when you mentioned about how
you actually put forth the, the kind of like the story for you
to start this platform engineering.
I think that's also very important.
How do you sell the story such that, you know, people
understand the benefits of this platform engineering?
So I think we can see all these, in, in play, right?
So the, the product thinking, the storytelling, and the
developer experience aspect. So speaking about, you know,
building a platform, right? I know that you mentioned it is
never ending, but people these days mention this term called
Golden Path. You know, this is like, also
another buzzword in the platform engineering thing.
What is Golden Path in your view, and is it something that
is kind of like the only way of doing something within the
organization, meaning that in an organization you should not have
different options of, you know, doing stuff?
So tell us, what is this golden path?
You can see I felt so strongly about that that I started
shaking my head preemptively. So a simple way to think about a
golden path is really to break it down is like, it's the either
it's the best route one could take to do something.
So if you have two options for pushing out code, one option is
you just do your own kind of disconnected IDE, maybe
you're... Or actually, I'm gonna give a
very, a very clear example, which any engineering leader
listening to is right now. And we'll talk about AI tooling.
So AI tooling, probably your enterprise forces you to use
Copilot. Most enterprises force people to
use Copilot. Copilot is not the best of the
AI tools, you know, it's great but comparatively it's not the
best. So when you start to go and
track AI usage in relation to people emailing themselves stuff
from ChatGPT or from Cursor, you see it's huge.
The number of developers emailing themselves code that
they have generated with Cursor or with with ChatGPT and then
they copy it from their email into their ID at work.
That is absolutely, you know, that's what we would consider
like an anti-pattern. That's a very negative thing to
happen. So you can see we are ripe for a
golden path there. Now you can see that is a really
problematic route. Using Copilot is too strict.
If forcing the usage of Copilot, that's too strict and it's
causing people to go off path in a negative way.
Well, a golden path there might be, okay, let's identify why do
we have to use Copilot. Because we're able to enforce
all of our governance, all of our guardrails.
It prevents people from, you know, blowing up the
organization or doing anything too crazy.
Well, how about use a cloud development environment to allow
people to experiment with other tools within the CDE.
And now you have all the governance, you have all the
guardrails. And people are allowed to use
the tools that they want without the risk to the rest of the
enterprise. That would be a golden path.
People are able to use Copilot, if they would like.
They could use the Copilot directly in the enterprise.
Or they can use the AI tooling that's provided within the cloud
development environment that lets them do everything that
they wanted to do, but with all of the enforcement, all the
safety, it's a disconnected box from the system.
Now this doesn't stop people from emailing themselves code
from ChatGPT. But why would they?
They don't need to, because they can just use the ChatGPT
directly within the CDE. They get all the benefit that
they wanted. And so you've removed an
anti-pattern. You've removed a risk vector by
giving people a better option. That's the concept of golden
path. It's like, you know, how do you
enforce ima, container image scanning.
Well, you could write a rule and say it's mandatory that you scan
all your container images. Or you could just build it
directly into the workflow, so that when they, you know, when
something gets committed, you know, there is within the
platform the container image gets scanned itself
automatically by design. Developer doesn't have to think
about it and that's a golden path.
They can do it manually if they'd like to.
You know, there, there's a developer who really prefers
doing things themselves. They like their own way.
They have the ability to go off path, but why would they because
the golden path is so much better.
That's really the key way to to think about it.
You know, there's a fantastic quote from Gregor Hohpe who
wrote a wonderful book, Platform Strategy.
I'm not sure if you've had him on the podcast but if you should
definitely get him on here. He's, we love him in the
platform engineering community. You know, this idea of golden
path versus golden cages. And he has this wonderful
illustration of the golden path is basically this great highway.
It's got some guard rails on the side.
And you've got your formula one car zipping down that highway.
And then the other path, it's not closed.
You can still go on it if you want.
But it's rocky, it's bumpy, it doesn't have the guardrails.
So it's why would you, as a developer, ever want to use the
worst path, when you've got the golden one?
So that's really the concept. It's a reframing of how we think
about things like compliance like governance.
Obviously, there's always gonna be the things where you have to
enforce stuff. The golden path can't just be
use Cursor however you want totally randomly within the
organization. Obviously not.
But it's thinking about a way that you can get all of the
compliance and governance without needing to just enforce
it and then cause these kind of off-path anti-patterns.
Wow, I think, you kind of like put a lot of insights into this
definition of Golden Path, right?
So one thing for sure, Golden Path is not the same as Golden
Cage, right? So it's not like a mandatory,
like a forced mandatory way for people to, you know, implement
something. It's, first of all, it's the
best option for them. And the best, if you, you can
make it such, such, such that it's easy for people to adopt
without even sometimes knowing it is there.
Or for example, they have to put a lot of efforts to just follow
the golden path. I think this is also very
important because I can see many organization when they adopt
this platform engineering, so to speak, right?
They kind of like enforce everybody to follow without
thinking actually about the developer experience, right?
So someone having to go through that path, even though it's
painful. So in in a, in the consequence
of the adoption, right? People want a high adoption, but
actually they don't care about the developer experience.
So thanks for mentioning about this.
And yeah, I've got Gregor Hohpe a long time ago actually talking
about platform engineering. So always fun to chat with him.
So, I know that recently you had this PlatformCon, Platform
Conference, you know, for 2025, and you kind of like summarize
it in, you know, one YouTube video that I saw, right?
There are five key takeaways from that.
So maybe, if you don't mind just sharing us a little bit high
level, what are some of these key takeaways that you think are
important for us to understand within 2025, right?
So yeah, maybe let's start from there.
And I'll just, I have them written down, so I make sure I
read exactly what they were. I know I gave that talk, but
obviously sometimes I forget exactly what I said.
So for those who don't know Platform Con is really the only
platform engineering focused conference in the world.
And it really tries to to focus in, you know, KubeCon is
awesome. There's 10,000 people there.
Reinvent is amazing, 60,000 people.
But Platform Con is really on those who are like actively
building, actively working on platform engineering.
So you get a lot of like Head of Platform and their whole team, I
mean we had a Dutch bank, who like had 18 platform engineers
in their entire department. They like had printouts of their
like problem statements and they were like asking people like,
hey, how would you help with this?
You know, they're there to learn, how to like grade
themselves, build their roadmap. Like that's really that platform
con energy. And it's also fantastic for me
because almost every kind of, I'll say influencer, a thought
leader in the space gives a talk there, shares their feedback.
And I have conversations with literally hundreds of people
over the, over the two days. So I'm able to get a real sense
of what is key in the community, what's key in the industry, and
this what's key in the kind of the software industry at large.
Cause platform engineering is really one of these leading
items. It's that foundational thing
that all software builds off. It's the same with DevOps.
Same with infrastructure. So platform engineering is that
bucket that a lot of the software industry sits on.
So you can really get a sense of where things are going.
And the kind of big five takeaways that I gathered from
it, were the first was on this platform engineering maturity
point. You know, in 2024, I gave a
panel called What is Platform Engineering.
And then in 2025, I gave a panel on What is Great Platform
Engineering. So most really leading
organizations are not dealing with definitional problems
anymore. They're really dealing with best
practices. You know, you can talk to Ricky
Zachary from ThoughtWorks. I just did a webinar with him
last night. I'd recommend checking it out.
And he already is able to break down, these are the 12
capabilities that you should be starting off with.
You can start off with right away.
You should be building into your platform.
They're the highest ROI items across 90% of organizations.
That was not the case a year ago.
You know, we are in the territory now where the amount
of best practice and things to follow is is very clear.
Then the other point is on this concept of of shifting down, not
left. And, you know, what I like to
call platform engineering eating the world.
So when we first started talking about platform engineering and
most of the conversation here other than some AI stuff has
really been either on the DevOps, DevEx side or a little
bit on that the infrastructure platform engineering side.
We really saw this year things like observability, security,
finops, data all becoming a part of the platform engineering
puzzle. You know, these concepts of
platform engineering are applicable to a data platform
exactly the same way they are to an application developer
platform. It's the same thing.
You treat those internal processes like they're a
product. You think about your data
scientist like they're your customer rather than your
developer. It's exactly the same thing and
we've really been seeing huge success with that at lots of
organizations. And then of course, the AI
point. You know, I wrote a report
called the State of AI in Platform Engineering which came
out a few months ago. And it coincided quite
conveniently with the DORA report from, which was put out
by quite a few people. I think Google are one of the
biggest contributors to that. Conveniently, both of them said
the same thing. That was great.
Would've been awkward if our data was different.
Really on the sym symbiotic relationship between platform
engineering and AI. All of the best and most
successful AI experimentation and initiatives at enterprises
have platform engineering behind them.
You know, I touched on that at the beginning.
When you go and watch one of the talks at Reinvent last week, you
know, the Amazon conference. Every talk has AI in the title.
But what is the foundation layer that they're using to get the
successful AI? It's platform engineering
concepts. And this has really, really,
really massively accelerated the acceptance of platform
engineering, the onboarding of platform engineering, the
funding for platform engineering, and that's only
gonna continue. But then the other half of that
AI acceleration of platform engineering initiatives
themselves. You can use AI and agentic
platforms, agentic workflows, all through the platform.
All of these things are things that AI can support.
So when you look at some of the examples I've given today, using
a platform engineering initiative to make it easier to
experiment with AI tooling, you know, that's a great example of
how platform engineering helps AI.
But then when you think about the ability we have with some
machine learning stuff, some of the agentic workflows to make
your platform engineering itself better, you've just got this
incredible feedback loop. That's gonna make 2016, like
excuse me, ha teleported back for past, 2026, very, very,
very, exciting, really. So those are the key things we
were talking about in Platform Con in June this year.
Wow! So I can see a lot of new trends
coming up, right? So first thing is, you mentioned
about shift down, right? So people have been talking
about shift left since the DevOps era starting, right?
So now it's kind of like shifting down, right?
Thinking about your, the platform beneath, you know, your
team, your organization, how you run software teams, right?
So you mentioned about security, observability, finops, data.
I think that's very crucial. The other thing that I like you
mentioned is that, you know, AI can be an accelerant, right?
for people within the organization, right?
And platform engineering is actually behind what great
success stories for people using those AI.
So, which is something that I wanna understand a little bit
more, right? Because this, trend AI is
advancing rapidly every day. Probably we hear new invention,
new tools, new way of working, new protocols being mentioned.
And you mentioned about agentic workflow.
So these days, software teams don't just deal with people
working, you know, together, but also with agents.
So how do you think the evolution of platform
engineering now with so-called, for example, agentic workflow or
maybe MCP protocols available. Or even like security issues
that seems to be, you know, getting more complex these days.
So how do you think about this AI component apart from, you
know, a good AI success stories need a good platform
engineering, but how can platform engineering itself
benefits from AI or how can it leverages on some of these
capabilities these days? We'd have to for some of the
really clear best practice answers.
You know, we'll have to wait a few months for that, I think.
Um you know, this is an area where we're still quite
immature. But when you think about, you
know, what is a good platform and what does a good platform
do. A good platform allows you to
move fast while still maintaining all your governance
and all your guardrails. So when you think about that
kind of core fundamental idea of what successful platform
engineering is, you can immediately see how that's huge
for AI. And when you think about all the
different areas that your platform engineering requires,
you know, documentation, user research, and even kind of
simple things like this shared language point, this challenge
of of communicating. I've seen AI be fantastic for
the cultural stuff as well. You know, I give advice to
teams, and they ask like how do I know what is important to my
executives? And it's like well, actually
what you can do is just take the annual report of your company,
put it into ChatGPT and tell it I am a platform engineer who's
trying to figure out what are the highest priorities for my
executive team. Please give me advice on what I
should focus on in terms of my communication about the
platform. And I guarantee you, it will
probably give you a really fantastic answer to understand
what your executives care about. Whether it's churn, whether it's
ROI, whether it's cost control. You know, you can get that and
then start to think, aha, okay, how can I, what are the feature
sets that impact those things? And you can do that on the flip
side too. Say you've improved something,
you know, you're able to get an ephemeral environment 80%
faster. This improves dev time.
Amazing! Your executive has no idea what
that means and probably doesn't care about it at all.
Very rarely. So you can take that feature set
that you've put in or that data that you've got, put it into
ChatGPT and say like, hey, I need to communicate about the
benefits of this to a leadership team that's less technical and
convince them of the benefits of this platform, what we're
achieving, and it will help you. So when we think about like
agentic workflows, there is a lot of obviously technical
things. We'll be able to get code out
faster. We'll be able to do code review
faster. You know, I saw a fantastic demo
a few weeks ago of directly within Backstage, a developer
portal, the ability to generate a bunch of code for a problem,
then have another AI check the code for the problem, make sure
that it matches all of your prescribed rules, all of your
security policy. So you've got that policy
directly within there and then you can push commit right there
and it goes through. Sure, that's a great technical
example of how AI will speed things up massively.
But even the cultural stuff, AI is having a huge advantage
within platform engineering. So this question that you've
asked, it's too big. There's too many wonderful
examples to give. But what I would really say is,
you know, 2026 is the year of the agentic platform.
Almost everyone that I know is thinking about them.
Almost everyone I know is working on them.
Because lot of the work that a developer could be doing on your
platform, an agent probably could be doing as well.
And so if you think about building in those guardrails,
those best practices for the agent rather than for the
developer, you start to see a really powerful flywheel there.
So I think we're gonna see a lot of experimentation on that
topic. It's just still very immature at
the moment. And maybe by PlatformCon in June
we'll be able to have some really cool demos of some of the
success stories from the last six months.
It sounds very exciting, you know, you know, knowing the
possibilities that could happen, you know, within the next one
year or so, right? And I think that's a very
powerful tip for you to mention, when you mention that people can
just put a, for example, financial report or whatever key
message from the stakeholders, right?
And you kind of like relate that with your so-called persona,
right? Maybe like platform engineer.
And maybe, yeah, AI itself can kind of like analyze and come up
with some suggestions. I think that's quite a cool tip
for people to try out. So thinking about, you know,
accelerant, AI accelerant, one key aspect that people use AI
these days is actually for development, right?
There are a lot of productivity thing that people think that AI
could help a lot. But at the same time, people
also talking about risk. So for example, many people also
think that AI could, you know, accelerate the amount of tech
debt that the organization have. Also the amount of code that
needs to be churned, gets delivered.
Do you think this will create like enormous expectations as
well for software teams and also platform to, in order to deliver
something even faster, even more secure, even more x, right?
So what do you think about the danger of this kind of like
thinking in 10X or even 100X with AI now?
I think for really the leading platform engineering
organizations and, you know, kind of any advanced platform
engineering organization, this is not gonna be a problem at
all. I think for the organizations
that are thinking about things like a product, they're thinking
about things with this governance and guardrails built
in, they're using an internal developer platform, I don't
think that this AI generated code problem.
I can totally understand why for the last six months, it's been a
huge issue. I can absolutely understand why.
And I think for the next few months and for some
organizations who are really struggling to keep up and deal
with this problem, it will be a big issue.
But, you know, the lagging growth of AI code review tools
or AI code checking, those are really starting to pick up now.
You know, I just gave an example of a demo I saw last week, of a
really spectacular AI code review tool.
You know, we have been able to generate code incredibly fast
but our ability to check that code with AI has not been
particularly fast. That gap is is closing now and
it will continue to close through next year.
And so I, I don't think really based on what I've seen
conversations I've had with leaders that, you know, 12 to 18
months from now anyone is really gonna have, not to say anyone,
organizations will, you know, organizations who are really
struggling to adapt to the times.
But I think the majority of kind of faster moving enterprises,
especially if they're a little bit more technical, then they're
not gonna have an issue with this going forward.
Either because they're just going to mandate Copilot and
they're gonna slow everything down.
But probably because the rate at which AI is able to check
itself. And that's a key part of what a
platform team should be doing. You know, a platform team should
be able to think about its policy as code.
Think about it's, you know, what are the key policies that need
to be checked? What are the key security
governance frameworks that have to be checked?
You know, what are the key things the AI should be scanning
the code for? Should it be making sure that
the code is not too long? You know, is this the shortest
code that it could be? And as soon as we start to think
about those best practices, then it starts to get better.
And you don't even need, to be honest, at the moment, a new
fancy AI tool to check the AI code.
I mean, I was talking to a team who the most advanced AI thing
that they've been doing is just they have 130 default prompts
like a prompt library that they've built that really work.
And then they have sequences of them.
So that they're prompting after to check the code being like, is
this the shortest code this could be?
Is this the most succinct way you could solve this problem?
And then suddenly you're removing, you know, 20, 30, 40%,
of the code problems in there. Now that's still an imperfect
solution. But you can see already that
we're able to deal with this AI generated mass much faster.
And so just based on the conversations I have with
leaders and some of the tooling that I've seen so far, I think
12 months from now, we'll all be talking about, well, wasn't it
crazy back then? Rather than still being a
present problem for us. Yeah.
I find the key thing here is to actually thinking about the
governance, right? About the policies that you
wanna put in place because, you know, as you can speed up things
faster, right? You wanna think about how would
you take a break, right? So from that speed, right?
So for example, you to, to avoid crash, you know, like a very bad
crash, right? You would need to think about,
you know, how do you put an emergency brake?
How do you actually make sure that the velocity is actually
healthy enough, right? And putting in policies,
guardrails, I think is very important for engineering
leaders to think about. And best if you can actually
automate that as part of the workflow and process such that,
you know, people can have it checked out of the box.
Maybe it could be using agentic workflow like what you
mentioned, you know, AI code reviewer.
Or it could be some simple linting tools or policy as code,
whatever that is, that is already available without AI
component. I think that's also kind of like
a good thing. And tests, automated tests, I
think highly recommended to have this, because otherwise with,
you know, all this AI code that it gets generated, how do we
know actually that the output is correct all the time, right?
So I think that's kind of tricky.
So I think we have talked a lot about, you know, platform
engineering, AI and all that. Is there anything else that you
think important that we have to talk about, before we kind of
like go to the last question? Well, I think unless your last
question is on what I'm about to talk about.
So we'll see I think one of the things people need to understand
about platform engineering as well.
Obviously this is, you know, we are very tech oriented, you
know, so we're thinking about platform engineering from that
landscape. But the concepts of platform
engineering are really broadly applicable.
It's why when you get into the definitional point, it's like,
yes, there's a technical, there's a specific technical
definition I could give you, but the core concept is really about
thinking about your service, your internal service as a
product, and that could be, you know, of course an application
developer platform that you're using.
But when you really think about it, Henry Ford, what he was
doing a hundred years ago, seems like an out there example.
When you read about these changes to the way that we're
thinking about supply lines, golden path.
When you're thinking about a lot of what we saw with Kaizen,
these concepts of kind of automation, of organizational
change, those are foundational points of platform engineering.
It's just it's the exact same thing.
It's just thinking about something in that way.
If you imagine that you are a nurse working in a hospital.
And you have a service that calls in medication for the
patient. Well, you who is designing that
thing, you think about, okay, the nurse is my customer.
So this is the product. It's an internal product with a
customer. Think about it from a product
management standpoint. Interview the nurses, do user
research, think about what feature.
That's platform engineering. It doesn't have to be developers
writing code to be platform engineering.
Any user of your internal service, and if you think about
it like it's a product, and when you start to see that you start
to notice so many opportunities for thinking about this kind of
product mindset point. So that's really one of the key
takeaways that we've been having in the community recently.
And it's really helped when we think about a lot of the stuff
that we're building and that we're working on.
You know, thinking about things like a product and what that
brings with it is super, super, super valuable.
They don't have to just be developers.
It could be anything. So I like that you keep on, you
know, iterating on this thinking as a product, right?
So I'm sure the biggest takeaway from this conversation that we
have is actually to think a platform as a product, right?
So I think, for those of you who are embarking on this platform
engineering project within your organizations, whatever that is,
right? Always remember, think in, in
terms of product first, right? Product mindset, users, think
about users. How would the user, user adopt
it? And what kind of pain points
that you wanna solve in the first place, right?
The focus is very important so that you can start small and
iterate from there. So Sam, I think it's been a
great conversation. Unfortunately, due to time we
have to wrap up. But I have one last question,
which I always ask my guests. I call this the three technical
leadership wisdom. So you can think of it just like
an advice you wanna give to the listeners.
So maybe today, if you can share some, that will be great.
Sure, I mean I think my my answer will possibly be quite
obvious for some of the people listening and based on this
conversation. But I would say, as a leader,
think about more than just the domain that you are in.
And when I say domain, I don't just mean observability,
reliability. When you think about, say, you
are an engineering leader, there is a lot you can learn from
sales. There is a lot you can learn
from marketing. There's a lot you can learn from
your procurement and your HR teams.
And I think one of the biggest mistakes that a leader can make
is thinking, okay, I'm an engineering leader.
That's just what I'm gonna focus on.
I'm gonna focus on engineering and I'm gonna read great
engineering books. I'm gonna focus on that
engineering mindset. You'll notice the majority of
the most famous engineering books are things that talk about
things like marketing and sales and shift into those other
domains. It seems very obvious, but I
notice that so frequently when I talk to these enterprise
leaders, my 390th a year, the really successful ones are the
ones who are reading a marketing book.
They're reading a book on sales best practices to help them
think about how they can communicate about things in a
different way and get outside their wheelhouse.
So that's really been the kind of the eye-opening kind of
leadership tip for me. And then the flip side of that
is to really think about how you are approaching the work that
you are doing in that way. So your work, as an individual,
there's probably a lot of stuff you can learn from these other
domains. So it's really about this idea
of broadening your horizons. And I'll give a really fantastic
example. I won't name her but there's a
platform engineering leader who runs probably the largest
internal developer platform in the world.
I from all the ones that I've seen demos of, it's probably by
far the largest. And when I ask her what she's
reading to help her, she's reading books from the 1960s
about highway design. Because there's so much that's
applicable in there. It's great to read a modern book
on, you know, AI advancement. It's great to read a modern book
on engineering best practice. But a lot of these fundamentals
about infrastructure, a lot of these fundamentals about team
structure, organization, human psychology, you know, many of
these things are things that have been around for a long
time. So expanding your, your
wheelhouse about how you're thinking about problems and that
really stuck with me when I asked like, oh you know, what
are you reading to help with your platform?
She's like oh this book from the 1960s about American Highways.
Okay. So then I picked up the book and
I was like, oh my God, this is platform engineering gold.
You know, if I had just changed half the terminology in there,
that was a book on platform engineering right there.
And, you know, that's really I think the biggest advice that I
have been given or I've learned this year and that I think I
would want to impart. Really like that as well, right?
Because sometimes all these multidisciplinary thing, right,
different domains that you can mix together, right?
Especially the philosophy or maybe the learnings from those
things, can actually help us a lot in terms of engineering,
right? We can actually see a lot of
things. For example, anti-fragility,
right? And you know, iteration is also
one thing that I think from evolution and all that, right?
How do you actually, do this kind of, you know, I dunno, like
evolution, fitness test and all that.
Actually, we borrow that from biology to engineering.
So I think a lot of things, we can learn a lot, if we broaden
our horizon. So thanks for reminding us
again. And yeah, I think, that's a wrap
for today. Thank you so much, Sam, for
sharing everything about the new thing about platform
engineering. And I think just to remind
people one more time, if you still haven't got the message,
think about your platform as a product.
So that is the big message from today's conversation.
Thank you again Sam for today. Absolutely.
And thank you so much Henry for having me.
It's been awesome!