# Platform Engineering: Product Mindset Over Tooling

**Podcast:** Tech Lead Journal
**Published:** 2026-02-16

## Transcript

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 the problem.
Today's guest is Sam Barlian, 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 will be organizational challenges.
It's never, oh, did we use the right CI CD tooling?
It's is the culture around our CI CD.
How would you describe platform engineering essentially?
Platform engineering as the discipline of treating an internal service like a product.
Are you thinking about those things like your product manager and the developers of 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 picture?
If you're a developer, 15 years ago, nine out of ten times it was just writing code.
There probably wasn't that much tooling.
Now zoom in to today when the average new tooling a developer had to on board 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 it's a 10x bigger problem.
Now AI makes every single one of these issues 10x worse.
I was just at AWS reInvent, and you can see for every talk that has AI as the headline, it's platform engineering as the core content within there.
Because it's the thing that lets you you do AI safely, AI effectively, move fast.
Hey, quick boss.
My goal with Techly 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 Techly Journal podcast.
Today I have with me Sam Barlian.
He's the community organizer for the platform engineering community.
So I think platform engineering has always been kind of like a big topic these days.
A little bit um, you know, overwhelmed by AI these days, but uh hopefully we can switch a gear a little bit to uh 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 uh cool about platform engineering lately.
So Sam, welcome to the show.
Yeah, thank you very much.
It is uh it's a big honor.
I've watched quite a few, so it's it's quite cool being here now and getting to see myself up there with 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 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 uh 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 it.
Yeah, so when you say uh AI is taking over, it is indeed has been taking over uh, you know, maybe in the news, in the topics, discussions, wherever we talk about, always AI, um, AI engineering, AI assistance 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 I'll start with a quick intro, kind of even of who I am and the and the community at large.
So we're 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 gr I grill them.
If some of them are listening, they know I really 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.
Because 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.
And 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 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 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 um, I mean, like a bit of a fun fact when I research you on Google, right?
When I type in your name, the first thing that it pops out is actually actor.
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 to 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 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 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 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 um a little bit of acting background for storytelling.
Um I'll talk too much.
Someone who is also deep in the platform engineering community, talking to a lot of leaders every day, every uh 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 a 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, uh, how would you describe a platform and what is platform engineering essentially?
Sure.
So I think the the simpler way to look at it, there's specific definitions for 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 conclusion 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 goals 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're a product manager and the developers of 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.
Like, awesome.
You know, how do you decide what features to 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're 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 want to implement that.
And yeah, not treating it as a product.
But uh, 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, uh, 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?
So, why why all the craze these days about you know, every organization's want to adopt platform engineering?
Well, I think you know, there's a fantastic graphic that you can find somewhere, but I will I will verbalize the graphic for the audience.
And it's when you think about if you're a developer, what you had to do 10 years ago.
Or I were actually 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.
Nine 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 higher 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 click-ops.
You're probably not able to just, you know, code-based 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 well, this little item, uh, 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 them, 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.
It makes onboarding impossible.
It also makes the cognitive load that's on that one developer impossible.
It also creates a huge over reliance on senior developers.
Because if you think, ah, 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 developer is just dealing with one interface.
That can be a code-based interface, it could even be a neural language interface or natural language interface.
I could just be using Claude or something.
And now you're able to have the developer on board faster, less cognitive load, less likelihood of mistakes.
I mean, think about, you know, I'm using Terraform as a big example here because 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 it's a 10x bigger problem now.
AI makes every single one of these issues 10x worse.
10 times more bad Terraform files, 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.
Because it's the thing that lets you do AI safely, AI effectively, move fast.
So there we go.
The big big answer to your short question, but that's a question that's that's really on my mind and I think is important for people to understand.
Yeah, I find it's uh 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?
Um, so we we are always kind of like um 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.
I mean, 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 change 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 on 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 uh a lot of developers, especially in big organizations.
Uh, uh 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 skill set capabilities?
How would you differentiate all this?
Because again, it's a convoluted term.
People call DevOps engineer, some companies call it SRE, uh, and some called platform engineers, it's it's such a confusing place now.
Yeah, and I 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 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 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, oh, 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.
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 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?
Um, you know, you're trying to solve.
I think that's a key mindset thing.
And and you mentioned about, you know, uh, people adopting SRE by following, you know, I don't know, 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 um 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 uh engineering leaders out there.
So yeah.
So tell us uh this, I think these insights because people still think we need to find a silver bullet, we need to find a tools, uh framework, platforms out there that we can just plug and play into organization that then it will 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 our tech and tools.
I get asked by junior people about tech and tools all the time.
But I talk to around it's like 390 or something.
I rounded up to 400.
So spoilers for anyone, you know, for everyone listening, it's around 390.
Um, well, 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, uh a technological problem was their problem.
They couldn't find enough people who are experienced with Kubernetes in their hiring.
That was their one technological problem.
But overwhelmingly, the problems aren't tools.
You know, the problems will often be culture, overwhelmingly.
It will be organizational challenges.
It will be training, it will be documentation, it will 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 can take like six months.
And the idea is that they want to 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, or you know, Kubernetes is a platform, isn't it?
Technically.
So we have Kubernetes, that's our platform.
And 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 want to 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.
I 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, um, your product thinking, right?
So I think um, 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.
Um, and that's why probably your your so-called project platform engineering uh does not succeed, right?
And you talk about you know, maybe many organizations are failing.
And I think uh probably the first one I would uh 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.
Um so tell us um how should the leaders actually pitch pitch it differently because I'm sure when people uh want to, you know, so called put a budget uh up front about hey, we want to build a platform within our organization, they'll think okay, this is the timeline, right?
Uh, but actually you mentioned uh if we treat it as a product, it's actually a continuous evolution and it will always evolve over the time.
So I think this is the first thing, maybe if you can uh enlighten us, how do we actually pitch it differently as a product instead of a project?
Well, I think the two things I would 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 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.
And 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 C D, we could put all of that in there, we could put the AI stuff, we can put all the security stuff.
Wow, we can have the data platform built into it.
And then suddenly you're like, okay, this is now a 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 a 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 it 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 NVP 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 by 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 five 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 is always my advice.
Yeah, so I think the thinking small, right?
Building the MVP uh relates back to how you think a platform as a product, right?
Because we always talk about building minimum viable product, uh, start small, iterate, uh, 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, um, 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 this could be some process we use.
And in fact, if I'm not mistaken, I learned from team topologists 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 process.
This is how we do stuff.
Uh that could be a uh the start of the platform, right?
So I think don't uh try to overcomplicate things by you know building a roadmap next three years, five years, uh so yeah, always think small and try to measure uh how 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 um, you know, in the first place, and how to measure the success of this platform engineering, you know, the ROI.
Um, so what are the typical measurements that you think would 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 our state of platform engineering report, uh, 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.
And so it's no surprise that when we asked 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 headspace that engineers work in.
You know, it's why the platform product manager role, having someone who really gets that world is a quite crucial to your platform team.
And when you think about measuring, use that NVP 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 going to 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 will 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 uh 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 going to focus on.
So they thought about what are all the things that make it difficult for a for a developer to do that first commit.
And they found most of it was compliance stuff.
It was because they would have 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 prior.
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 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 100 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.
But 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 want to 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.
Because if you've got 25 things you want to focus on, you're never going to 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 uh thinking in terms of focus, what is the biggest user pain point that you're solving, right?
And try to focus on that.
Um, and when you mentioned about all this, right?
I remember my conversation also with you know the DX team, the developer experience team.
Um, 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 people do this, right?
Yeah.
So that could also be a metric.
And I think I want to also mention, since you 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 uh in in play, right?
So the the product thinking, the storytelling, uh, and the developer experience aspect.
So speaking about um, you know, um building a platform, right?
I know that you mentioned it is never ending, but people these days um mention this term called golden path.
You know, this is like uh also another buzzword in the platform engineering thing.
Uh, 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 uh what is this golden path?
You can see I felt so strongly about that that I sort of shaking my head preemptively.
So uh 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 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 co-pilot.
Most enterprises force people to use co-pilot.
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 uh with Chat GPT, and then they copy it from their email into uh their IDE 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're ripe for a golden path there.
Now you can see that that is a really problematic route.
Using copilot is too strict, it's 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, 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 can 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 paths.
It's like, you know, how do you enforce 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'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 think about it.
You know, there's a fantastic quote from Gregor Hope, 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 paths versus golden cages.
And he has this wonderful illustration of the golden path is basically this great highway.
It's got some guardrails 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 going to 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.
Well, I think uh you kind of like uh 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 um you know implement something.
It's first of all, it's a best option uh for them.
And the best if you if you can make it such such such that it's easy for people to adopt without even sometimes knowing um, you know, it is there, or for example, they have to put a lot of effort to just follow the golden path.
I think this is also uh very important because I can see many organizations when they adopt this platform engineering, so to speak, right?
They kind of like enforce everybody to follow uh without thinking actually about the developer experience, right?
So someone having to go through that path, uh even though it's painful.
Um, so in in a in a consequence uh of the adoption, right?
People want uh high adoption, but actually they don't care about the developer experience.
So thanks for mentioning about this.
And yeah, I've got Gregor Hope uh a long time ago actually talking about platform engineering, so always fun to chat with him.
So um I know that recently you had this uh platform con, platform conference uh 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?
Um 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 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 a Dutch bank who like had 18 platform engineers, 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 or 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 kind of the software industry at large, because platform engineering is really one of these leading items.
It's it's that foundational thing that all software builds off of.
It's the same with DevOps, the 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 from Boltworks.
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're in the territory now where the amount of best practice and things to follow is very clear.
Then the other point is on this concept 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 and most of the conversation here, other than some AI stuff, has really been either on the DevOps, DevX side or a little bit on 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 uh called The State of AI and Platform Engineering, which came out a few months ago, and it coincided quite conveniently with the Dora report from uh 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 have been awkward if our data was different, really on this 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 uh 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 going to continue.
But then the other half of that, AI's 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 and some of the agentic workflows to make your platform engineering itself better, you've just got this incredible feedback loop that's going to make 2016, like excuse me, teleported back per path.
2026 very, very, very exciting, really.
So those are the key things we're talking about in platform con in June this year.
Wow.
So I can see a lot of uh new trends coming up, right?
So, first thing is uh you mentioned about shift down, right?
So people have been talking about ShiftLab since the DevOps era starting, right?
So now it's kind of like shifting down, right?
Thinking about your the platform beneath, you know, you know, your team, your organization, how you run software teams, right?
So you mentioned about security observability, FinOps uh data.
I think that's very crucial.
The other thing that I like you mentioned is that um, you know, AI can be an accelerant, right?
Uh for people um within the organization, right?
And platform engineering is actually behind what great success stories uh for people using those AI.
So it's just something that I want to understand a little bit more, right?
Because this um trend AI is advancing rapidly.
Every day, probably we hear new invention, new tools, new way of working, uh new protocols being mentioned, and you mentioned about agentic workflow.
So these days, software teams don't just deal with people working um you know, together, but also with agents.
So, how do you think the evolution of platform engineering now with so-called, for example, agenc 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 leverage us on some of these capabilities these days?
Well, 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 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 Chat GPT, and tell it, I'm 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 and what we're achieving.
And it will help you.
So when we think about like agentic workflows, there's 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 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 a 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 platform con in June, we'll be able to have some really cool demos of some of the success stories from the last six months.
And I think that's a very powerful tip for you to mention when you mentioned 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 AI itself can kind of like um analyze and come up with some suggestions.
I think that's uh quite a cool tip for people to try out.
Um, so thinking about, you know, accelerant AI accelerant, one key aspects that people use AI this days is actually for development, right?
Um, there are a lot of uh productivity things that people um um think that AI could help a lot, but at the same time, people also talking about risk.
So, for example, uh many people also think that AI could um you know accelerate the amount of tech depth that the organization have.
Uh also the amount of code that needs to be churned, uh gets delivered.
Do you think this will create like uh enormous expectations as well for software teams and also platform to in it 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 going to be a problem at all.
I think for the organizations that are thinking about things like a product, they're thinking about things where there's 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 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 of a demo I saw last week of a 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 governments 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 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 wouldn't want to put in place because, you know, as you can speed up things faster, right?
You want to 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 uh put an emergency break?
How do you actually uh make sure that the philosophy is actually healthy enough, right?
And putting in policies, gut rails, 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 uh checked out out of the box maybe it could be using a genetic 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 uh generated how do we know actually that the output is correct all the time right so I think that's uh 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 uh before we kind of like go to the last question well I I think unless your last question is on what I'm about to talk about so we'll we'll see I think one of the things people need to understand about platform engineering as well obviously this is you know we're 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 difference 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 paths, when you're thinking about how 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're 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 adding.
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 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.
Yeah, so I like that you keep on you know iterating on this uh 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 uh for those of you who are embarking on this platform engineering project within your organizations, whatever that is, right?
Always remember, think in uh in terms of product first, right?
Product mindset, users, thinking about users, how would your use uh user adopt it and what kind of pain points that you want to uh 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.
Um, unfortunately, due to time, we have to wrap up.
Uh, but I have one last question, uh, which I always ask my guests.
I call this the tree technical leadership wisdom.
So you can think of it just like an advice you want to give to the listeners.
Um, so maybe today, um, if you can share some, that would be great.
Sure.
I I mean, I think I think my my answer will will will possibly be quite obvious for some of the people listening in 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're 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 going to focus on.
I'm going to focus on engineering and I'm going to read great engineering books.
I'm going to 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 390 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 that I have been given or I've learned this year, and that I I think I would want to in part.
Really like that as well, right?
Because sometimes all this multidisciplinary thing, right?
Different domains that you can mix together, right?
Especially the philosophy or maybe the learnings uh from those things, uh, can actually help us a lot in terms of engineering, right?
We can actually see a lot of things, for example, anti-fragility, right?
Um, and you know, um, iteration is also one thing that I think from evolution and all that, right?
Uh, how do you actually uh do this kind of uh, you know, I don't know, like evolution fitness tests and all that.
Actually, we borrow that from biology to engineering.
So I think a lot of things uh we can learn a lot uh if we broaden our horizon.
So thanks for reminding us again.
Uh and um yeah, I think um 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 uh 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.