Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Used Platform Teams to Double Developer Throughput
Transcript
- Lucas: There's a CTO I've been following at a mid-sized fintech company — about 200 engineers — and earlier this year she made a bet that I think a lot of leaders are going to copy. She restructured her entire engineering org around platform teams. Luna: Platform teams as in internal developer platforms, or more like infrastructure teams with a different name? Lucas: Good question. She created three specific platform teams: an API gateway team, a data pipeline team, and a CI/CD team. Each one owns a horizontal slice of the stack that every product team depends on. And the goal wasn't just better tooling — it was to reduce cognitive load on product developers. Luna: Cognitive load is a big phrase in engineering org design right now. How did she measure it? Lucas: She tracked context switches. Before the reorg, the average product developer was context-switching between seven different concerns per day — API design, data modeling, deployment pipelines, monitoring, security reviews, you name it. After platform teams took ownership of those horizontals, that number dropped to about two switches per day. Luna: That's a huge reduction. But I imagine spinning up three platform teams wasn't free. How many engineers did she pull from product teams? Lucas: She moved about 15 percent of engineering into platform roles — so around 30 people total, split across the three teams. Product teams got smaller, but the bet was that they'd ship faster because they were no longer building and maintaining their own bespoke infrastructure. And the numbers back that up. Luna: What kind of numbers are we talking about? Lucas: Deployment frequency went from twice a week to four times a day. Mean time to recovery dropped by 60 percent. And here's the one that made the CTO smile: developer throughput — measured by story points delivered per sprint — doubled within six months. Luna: Double? That's not incremental improvement, that's a step change. But did product teams resist losing headcount? I've seen that backfire when teams feel like they're being stripped. Lucas: She said the first month was rough. Developers complained that the platform teams didn't understand their needs — the API gateway team was enforcing standards that broke existing workflows. But she put a feedback loop in place: each platform team had a rotating product team liaison who attended their sprint reviews. After about two months, trust started building. Luna: That sounds like a classic Conway's Law problem. The platform teams' structure reflected the architecture they were building, but it took time to align incentives. Lucas: Exactly. And she was very deliberate about the platform teams' charters. The API gateway team didn't just build a gateway — they owned the developer experience around it. They wrote documentation, created SDKs, and ran office hours. The CTO's philosophy was: if a product developer has to file a ticket and wait three days for a change, the platform team has failed. Luna: So the platform teams were measured on product developer satisfaction, not just uptime or latency? Lucas: Yes. She used a simple survey: once a month, every product developer rated each platform service on a scale of one to five, with an open text field for complaints. The platform teams' bonuses were tied to those scores. That's a strong incentive to care about usability. Luna: I love that. It turns platform teams into internal product teams. But what about the risk of over-abstracting? If the platform team builds too much abstraction, developers lose the ability to debug when things go wrong. Lucas: She thought about that. The API gateway team, for example, exposes raw request logs and metric dashboards to every product team. Developers can drill down into exactly what the gateway is doing. The abstraction is in the configuration, not in the observability. So when a request fails, the product developer can trace it end to end without needing to know how the gateway's internals work. Luna: That's a smart design principle. Abstract the complexity, not the visibility. Lucas: Right. And the data pipeline team took a similar approach. They built a self-service data ingestion platform where product teams could define their data schemas in a YAML file and get a fully managed streaming pipeline. The team handles scaling, fault tolerance, and schema evolution — but the product team can still query the raw data in real-time through a query interface. Luna: Honestly, this sounds like the kind of episode that makes me want to go redesign my own org. If today's conversation gave you something usable, maybe consider supporting the show? We keep it ad-free, and listener support is what makes that possible. It's literally just buy me a coffee dot com slash fexingo. Lucas: Yeah, that tiny bit of support goes a long way. And we mean tiny — a coffee's worth. But it keeps the conversation going without any sponsor interruptions. Luna: Exactly. So back to the platform teams — the CI/CD one I think is the most interesting case. Lucas: Why's that? Luna: Because CI/CD is so personal to developers. Everyone has their own preference for how builds and deploys should work. How did the platform team standardize without creating rebellion? Lucas: They didn't standardize everything. They created a set of composable pipeline templates — think of them as building blocks. One template for a Node.js service, one for a Go service, one for a Python service. Each template comes with sensible defaults but allows customization through environment variables and hooks. The product team can inject custom steps, but they don't have to write the whole pipeline from scratch. Luna: So it's a spectrum from full control to full abstraction. The platform team provides the rails, but developers can still step off them when necessary. Lucas: Exactly. And the CI/CD team runs regular 'pipeline clinics' where developers can bring their customizations and ask for help simplifying. Over time, most teams converge on the templates because they realize the custom stuff is just maintenance burden. Luna: What was the biggest surprise for the CTO during this transition? Lucas: She said the hardest part was not the technology — it was the people. The engineers she moved into platform teams were often the most senior on their product teams, and they felt like they were being demoted. She had to reframe the role as a promotion: you now own a system that every team depends on. Your impact is multiplied. And she gave them titles like 'Principal Engineer, Platform' to signal the importance. Luna: That's a crucial point. If platform teams are seen as second-class, the whole model fails. You need to attract top talent into those roles. Lucas: Absolutely. And the results speak for themselves. After a year, the company had shipped three major product features that had been stalled for quarters because product teams were bottlenecked on infrastructure work. The platform teams unblocked them. Luna: So would you recommend this approach to any CTO, or does it depend on org size? Lucas: I think it works best when you have at least 50 engineers. Below that, you can't afford the specialization. But the principle applies at any scale: identify the tasks that every team does badly and repeatedly, and centralize them with a product mindset. Even a two-person platform team can make a difference. Luna: That's a good takeaway. Don't wait until you have 200 engineers to start thinking about platform teams. Start small, prove the model, then scale. Lucas: Exactly. And measure everything. The CTO I mentioned tracks a dashboard of four metrics: deployment frequency, mean time to recovery, developer satisfaction score, and throughput. Without those, you're just guessing. Luna: Alright, I'm convinced. Next time I talk to a CTO, I'm asking them how many platform teams they have. Lucas: And if they say none, you can tell them about this episode. That's the kind of conversation worth having.