If you’ve got the best engineers in the world building the greatest product nobody uses, what was the point? That’s a core question that was lingering in my mind in this episode of Inside Platform Engineering, with Kian Rogerdi. Kian has spent over 20 years in software, the last 10 of them in leadership, running cloud engineering, SRE, and Platform Engineering departments at companies ranging from startups to big enterprises.
What stood out to me most was how much of this conversation ended up being about mindset rather than tooling. In fact, it’s been a common theme in many conversations I’ve had on Inside Platform Engineering, and I’m seeing it as a crucial element in successful platform teams. We didn’t talk much about specific platforms or products. We talked about how easy it is for a platform team to lose sight of who they’re serving, and what that looks like when it goes wrong.
Watch the episode
You can watch the episode with Kian below.
Inside Platform Engineering with Kian Rogerdi
Business value is the point
Kian’s framing is simple, but as a technologist, can be easy to lose sight of. Everything a platform team does only matters if it’s actually helping someone else move faster and safer. He pointed out that plenty of teams still measure themselves on technical excellence alone, building the most secure, most powerful, most elegant system, without asking whether anyone’s using it or whether it’s solving a real problem. Product teams sorted this out years ago because they have a customer staring back at them. Platform teams don’t get that same forcing function, since their customers are internal, which is exactly why it’s harder and why it gets missed. That mindset needs to be a deliberate choice from day 1 when forming a platform team, backed by sensible success metrics to help platform teams showcase their value.
Treat your internal teams like customers
This idea of treating internal teams as real customers has come up in previous conversations, even even as far back as Inside Platform Engineering episode 001 with Luke Philips. Kian leaned on Team Topologies, and it’s worth a read if you haven’t. His point was that platform teams are supposed to reduce cognitive load for stream-aligned teams, but that only works if you’re listening to those teams the way a product team listens to its customers. He talked about embedding platform engineers with the teams they serve, just to watch what actually happens, which templates get ignored, which pipelines get quietly replaced with something homegrown. I really love this take, and I’ve seen versions of this myself, where teams don’t abandon your tooling because they’re difficult, they abandon it because it doesn’t solve their problem.
It reminds me of when I was in a consultative role as a DevOps Engineer, and we were a little too on the reactive side where we were waiting for customers to come to us when they needed help. We decided to flip the model on its head, and asked to sit in with our customers’ developers on their daily standup. We weren’t in every standup, just one or two a week. Just doing this paved the way for a much better way of working with their teams. We could ask questions like “why are you doing it that way” or suggest “we can make that a lot easier”, and because we were in the room, they would ask for our opinion on the topics of discussion in that meeting. Dev and Ops coming together, who would have thought! I see this same pattern as crucial for platform teams, who need to spend time with the teams they’re trying to enable.
Enablers, not gatekeepers
Speaking of enabling, Kian described a pattern he’s seen play out at companies he’s worked at, where a platform team that starts dictating instead of enabling, vetoing decisions, and effectively becomes a gate that other teams have to get through. He drew a clear line around genuine compliance requirements in regulated industries like fintech or healthcare, which are legitimately non-negotiable, but said everything beyond that is a red flag. He also noted this tends to get worse as companies scale, because politics creeps in and platform work becomes a source of power over other teams rather than a service to them. The fix, in his words, isn’t complicated; it’s remembering the purpose. It just takes deliberate effort to keep remembering it.
Happy deployments!
Inside Platform Engineering is a series of conversations with Matt Allford and a guest, bringing their own experience and perspective from the world of Platform Engineering.
You can find more episodes on YouTube.
