Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / Why Your Engineering Team Needs a Platform Team
Transcript
- Lucas: If today's tech conversation gave you something usable, you might want to hear how we keep making these shows. A handful of listeners chip in monthly through buy me a coffee dot com slash fexingo, and that's literally what funds a hundred episodes a year. Luna: It's a small thing that adds up. We keep it ad-free that way. Lucas: So last week I was talking to the CTO of a mid-size fintech company — about a hundred engineers — and he said something that stuck with me. He said, 'My best engineers spend half their time just setting up infrastructure for new services.' Luna: That sounds painful. And expensive. Lucas: Exactly. So they decided to build a platform team. Not a DevOps team, not an infrastructure team — a dedicated platform team whose sole job is to make every other engineering team faster. And it worked. They went from two weeks to provision a new microservice down to about two hours. Luna: Two hours from two weeks? That's a massive shift. What was the main change? Lucas: They built what's called an internal developer platform — or IDP. It's essentially a layer of tooling and self-service abstractions that hides the complexity of the underlying infrastructure. Developers don't have to think about Kubernetes clusters, networking rules, or database provisioning. They just submit a manifest — think of it like a config file — and the platform handles the rest. Luna: So it's like providing a golden path. A set of predefined choices that work well, without restricting creativity. Lucas: Exactly. Spotify calls it a 'golden path.' Their platform team — named 'Platform as a Product' — treats internal developers as customers. They measure adoption, satisfaction, and time to value just like you would for an external product. And that mindset shift is critical. Luna: I've read about Zalando doing something similar. They built a platform called 'Zalon' or something? Lucas: Close — they have a platform called 'Stylite,' I believe. But the principle is the same. Zalando's platform team provides standardized CI/CD pipelines, monitoring, and even database templates. Developers at Zalando can launch a new service with a single command. That kind of velocity matters when you're scaling from tens to hundreds of microservices. Luna: But this can't be universal. Some engineering leaders I've talked to say platform teams become bottlenecks themselves. Lucas: That's a real risk. If the platform team becomes the sole gatekeeper for infrastructure changes, you've just moved the bottleneck from the ops team to the platform team. The key is to design the platform as a self-service layer, not a ticket queue. The goal is that developers can do 90% of what they need without ever talking to the platform team. Luna: So the platform team builds the factory, not the products. They set up the assembly line, and then get out of the way. Lucas: Right. And they need to measure the right things. Adoption rate is the obvious one — what percentage of teams use the platform? But you also want to look at developer satisfaction, time to production for a new service, and the frequency of incidents caused by misconfiguration. If those metrics improve, the platform is working. Luna: What about the cost? Building a platform isn't free. If you're a CTO of a 50-person company, should you even consider this? Lucas: That's the right question. For a small team, say fewer than 20 engineers, a dedicated platform team might be overkill. You're better off with a couple of senior engineers who share platform responsibilities part-time. But once you cross around 50 engineers, the friction of managing infrastructure manually starts to compound. That's when a platform team starts to pay for itself. Luna: So the threshold is around 50 engineers. But what about the first steps? Where do you start? Lucas: Start with the biggest pain point. For the fintech CTO I mentioned, it was provisioning new services. For another company, it might be deploying to production or managing secrets. Pick one workflow that causes the most friction, build a self-service path for it, measure the improvement, and then expand. Don't try to build a 'platform that solves every problem' on day one. Luna: That reminds me of a story from a colleague at a large e-commerce company. They spent two years building an 'everything platform' — and by the time it launched, the company's tech stack had changed so much that most of the platform was obsolete. Lucas: Classic over-engineering. That's why the best platform teams start small and iterate. They treat their platform as a product, with a roadmap, user research, and regular releases. You want to ship something useful every two to four weeks, not a monolith after a year. Luna: And how do you get buy-in from engineering teams to actually use the platform? I've seen cases where teams build their own custom scripts because they don't trust the platform. Lucas: Trust is earned. If the platform is reliable and actually saves time, adoption follows. But you also need to make it easy to onboard. Provide good documentation, offer migration support, and celebrate early adopters. Some companies even appoint 'platform champions' in each team to help spread best practices. Luna: So the platform team's success depends heavily on change management. It's not just a technical challenge. Lucas: Absolutely. A platform team is 30% technology and 70% culture and process. You have to align incentives. If a team's performance metrics only count feature delivery, they won't want to spend time migrating to the platform. Tie part of their evaluation to platform adoption or operational efficiency. Luna: That makes sense. Let's come back to the fintech example. After they reduced service setup time from two weeks to two hours, what happened next? Lucas: They saw a huge reduction in deployment failures — about 60 percent fewer incidents related to misconfiguration. And developers reported feeling less stressed because they didn't have to remember all the steps. The platform team also started offering managed databases and message queues. Over six months, the platform team paid for itself just in reduced downtime and faster feature delivery. Luna: So it's not just about speed. It's about reducing cognitive load on developers, letting them focus on the actual product. Lucas: Exactly. And that's the core idea behind platform engineering: treat your infrastructure as a product, your developers as customers, and your platform team as the product team. If done right, you get better velocity, higher quality, and happier engineers. Luna: Is there any company doing this that you think is a model to follow? Lucas: Spotify is still the gold standard. They've written extensively about their 'Squad Health Check' model and how the platform team uses OKRs tied to developer experience. Another one is Netflix: their platform team built Spinnaker, which they eventually open-sourced. But even smaller companies can learn from the principles. The key is to start small, iterate, and measure. Luna: I think a lot of engineering managers listening might be wondering: is this just DevOps with a new name? Lucas: It's related but distinct. DevOps is about culture and practices for collaboration between dev and ops. Platform engineering is about building and maintaining a self-service platform that enables that collaboration. Think of DevOps as the philosophy, and platform engineering as the tool that operationalizes it. Luna: That's a helpful distinction. So if someone wants to convince their CTO to start a platform team, what's the elevator pitch? Lucas: I'd say: 'Right now, every team reinvents the wheel when it comes to infrastructure. A platform team can centralize that effort, give us a 10x improvement in developer velocity, and reduce operational risk — all while freeing up our best engineers to work on the product that differentiates us.' It's a hard argument to ignore. Luna: And if the CTO says 'We don't have the headcount for a dedicated team'? Lucas: Then start with a small cross-functional group — maybe two senior engineers and a product manager — that spends 50% of their time on platform work. Prove the value with one workflow, then ask for more headcount based on the results. That's how most successful platform teams I've seen got started. Luna: Low risk, high proof. I like it. Lucas: One last thing: platform teams can also help standardize observability and security. If every team uses the same monitoring stack and the same secret management, you get consistency that makes audits and incident response much easier. Luna: So it's a multiplier across many dimensions. Speed, reliability, security, developer happiness. Lucas: Exactly. It's not a silver bullet, but for the right size company, it's one of the highest-leverage investments you can make. Luna: Alright, we've covered a lot. If listeners want to dive deeper, where should they start? Lucas: I'd recommend the book 'Team Topologies' by Matthew Skelton and Manuel Pais. It's the best resource on organizing teams around streams of work, and it has a whole chapter on platform teams. Also, the Spotify engineering blog has a great series on their journey. Luna: Sounds like a plan. Thanks, Lucas. Lucas: Thanks, Luna. See you next time.