Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How a CTO Uses Platform Engineering to Tame a Monolith
Transcript
- Lucas: Last month, a mid-sized fintech company finished a migration that their CTO described as 'the single most impactful engineering investment we ever made.' And it wasn't a new feature or a rewrite of the core product. It was an internal developer platform. Luna: Platform engineering. It's been getting a lot of buzz. But I think a lot of people still see it as just DevOps with a new name. Lucas: Right, and I want to push back on that a little, because the difference is real — but you have to look at what the platform actually does. In this case, the company ran a monolithic Ruby on Rails application that had been built over twelve years. Deploying a single change took forty minutes, and the pipeline broke about once a week. Luna: Forty minutes for a deploy — that's brutal. I've been on teams where a long deploy means you just batch up changes and hope nothing breaks. Lucas: Exactly. And that's exactly the pattern the CTO wanted to break. So they built an internal developer platform — an IDP — using a combination of Backstage for the developer portal and a set of curated Kubernetes templates. The goal was to create what they called a 'golden path' for deploying services. Luna: Okay, define 'golden path' for someone who hasn't heard the term. Lucas: A golden path is the recommended, opinionated way to build and deploy a service. It's not a set of rigid rules — developers can deviate if they need to — but the path gives you default decisions for things like CI/CD pipeline, monitoring, secrets management, all pre-configured. So a developer doesn't have to think about 'how do I set up a database connection?' or 'which load balancer should I use?' — the platform handles that. Luna: So it's about reducing cognitive load for the developer. Let the platform own the infrastructure decisions. Lucas: Exactly. And this is where platform engineering differs from traditional DevOps. DevOps was about breaking down the wall between dev and ops — it was cultural. Platform engineering is about building an abstraction layer that hides the complexity of the underlying infrastructure. The platform team treats the platform as a product, with user research, roadmaps, and SLAs. Luna: That 'product' framing is key. A lot of internal tools fail because they're built without thinking about the developer as a customer. Lucas: Right. And this CTO specifically said they applied product management practices to the platform. They had a product manager who interviewed developers, tracked adoption, and prioritized features based on impact. In the first six months, they onboarded sixty percent of the engineering team onto the golden path. Deploy time went from forty minutes to four. Luna: Four minutes. That's an order of magnitude improvement. What about reliability? Lucas: Infrastructure-related incidents dropped by eighty percent. Because the platform enforces best practices — every service gets the same logging format, the same health check endpoints, the same alerting rules. So when something does break, you don't have to learn a bespoke setup for each team. Luna: That reminds me of something I heard from a platform engineer at a large e-commerce company. They said the real win wasn't speed — it was that junior engineers could deploy safely on day one because the platform prevented them from making dangerous mistakes. Lucas: That's a huge point. New hire onboarding in the fintech company went from two weeks to three days. Because the golden path included a template that generated a working microservice with the right dependencies, a health endpoint, a Dockerfile — all ready to go. The new engineer just had to write the business logic. Luna: So the platform essentially encodes institutional knowledge. Decisions that used to live in someone's head are now automated. Lucas: Right. And that's where the 'product' mindset really matters. The platform team has to keep those decisions up to date, and retire old ones gracefully. They can't just build it once and walk away. Luna: It's interesting — this also ties into the idea of treating your own tools with the same care you treat your customer-facing products. And that's something we really believe in on this show. If you're getting value from these conversations, one way to support that is at buy me a coffee dot com slash fexingo. It's a small gesture that helps us keep this ad-free and focused on the kind of depth we try to bring every episode. Lucas: Yeah, we really appreciate that. And speaking of depth — let's dig into one more layer of this platform engineering story. The CTO also shared that they had to overcome resistance from senior engineers who felt the platform would limit their flexibility. Luna: I can imagine that. The 'we know better' mindset. How did they handle it? Lucas: They made the golden path optional for existing services. Teams that already had a working setup could keep it, but any new service had to use the platform. And over time, the data spoke for itself — teams on the platform had fewer incidents and faster feature delivery. Eventually, most teams migrated voluntarily. Luna: So they let the results sell the platform. That's smart change management. Lucas: Exactly. And the platform team also committed to a ninety-day feedback loop. Every quarter they'd survey developers and publish a public roadmap. That transparency built trust. Luna: What about the cost? Building an IDP isn't free — you need a dedicated team, and you're investing in infrastructure that doesn't directly generate revenue. Lucas: The CTO estimated the platform team cost about one point two million dollars a year, including headcount and cloud resources. But they calculated that the productivity gains — faster deploys, reduced incidents, shorter onboarding — saved the company roughly four million a year in engineering time. So a three-to-one return within the first year. Luna: That's a compelling business case. And it's not just about speed — it's about enabling engineers to focus on what they were hired to do: solve business problems, not wrestle with YAML files. Lucas: Right. And that's really the core of platform engineering. It's about shifting the complexity from the developer's brain to a well-designed system. The best platforms are almost invisible — you just work, and the infrastructure takes care of itself. Luna: It sounds like the real unlock is treating the platform as a product. Not a project, not a side initiative, but an ongoing commitment. Lucas: Exactly. And that's the mindset shift that separates the successful platforms from the shelfware. Thanks for listening — we'll be back next week with another deep dive.