#247 - Why Your Platform Engineering Is Failing (And How to Fix It) - Sam Barlien

[00:02:02] Introduction

Henry Suryawirawan: 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.

Sam Barlien: 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.

[00:03:16] What Background Do You Need for Platform Engineering?

Henry Suryawirawan: 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.

Sam Barlien: 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.

[00:06:32] How Does Storytelling Help in Platform Engineering?

Henry Suryawirawan: 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?

Sam Barlien: 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.

Henry Suryawirawan: Yeah, so it sounds like you are the perfect guest today. So a little bit of acting background for storytelling.

Sam Barlien: You need to be careful. I’ll talk too much.

Henry Suryawirawan: 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.

[00:08:53] What Is Platform Engineering?

Henry Suryawirawan: 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?

Sam Barlien: 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.

Henry Suryawirawan: 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.

[00:12:27] Why Are Organizations Adopting Platform Engineering?

Henry Suryawirawan: 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?

Sam Barlien: Oh yeah.

Henry Suryawirawan: So why all the craze these days about, you know, every organizations want to adopt platform engineering?

Sam Barlien: 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.

Henry Suryawirawan: 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.

[00:19:51] What’s the Difference Between DevOps, SRE, and Platform Engineering?

Henry Suryawirawan: 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.

Sam Barlien: 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.

Henry Suryawirawan: 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.

Sam Barlien: Oh yeah.

[00:23:25] Why Is the “Plug and Play” Approach to Tools a Trap?

Henry Suryawirawan: 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.

Sam Barlien: 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.

Henry Suryawirawan: 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.

[00:28:45] How Do You Pitch Platform as a Product Instead of a Project?

Henry Suryawirawan: 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?

Sam Barlien: 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.

Henry Suryawirawan: 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?

[00:34:01] How Do You Measure the ROI of Platform Engineering?

Henry Suryawirawan: 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.

Sam Barlien: 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.

Henry Suryawirawan: 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.

[00:40:42] What Is the Golden Path in Platform Engineering?

Henry Suryawirawan: 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?

Sam Barlien: 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.

Henry Suryawirawan: 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 the, in the, in, in the, in, in a, 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.

[00:47:12] What Were the Key Takeaways from PlatformCon 2025?

Henry Suryawirawan: 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.

Sam Barlien: 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.

Henry Suryawirawan: 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.

[00:53:41] How Does Platform Engineering Leverage AI?

Henry Suryawirawan: 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?

Sam Barlien: 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.

Henry Suryawirawan: 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.

[00:58:41] What Are the Hidden Costs of AI-Generated Code?

Henry Suryawirawan: 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?

Sam Barlien: I think~~,~~ 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.

Henry Suryawirawan: 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.

[01:04:01] Why Is Platform Engineering Actually Product Management?

Henry Suryawirawan: 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?

Sam Barlien: 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.

Henry Suryawirawan: 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.

[01:07:12] 1 Tech Lead Wisdom

Henry Suryawirawan: 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.

Sam Barlien: 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.

Henry Suryawirawan: 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.

Sam Barlien: Absolutely. And thank you so much Henry for having me. It’s been awesome!

– End –