Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How a CTO Uses an Internal Developer Platform to Cut Cognitive Load
Transcript
- Lucas: There's this moment every engineering leader knows. You walk into a standup and a senior developer is staring at a Kubernetes YAML file with a thousand lines, trying to figure out why a deployment is failing. Not because the code has a bug, but because the infrastructure config is wrong. Luna: Right, that's the classic 'I wrote the feature in two hours and spent the rest of the week wrestling with the platform' problem. Lucas: Exactly. And that friction isn't just an annoyance. It's cognitive load — the mental overhead that has nothing to do with the actual problem a developer is supposed to solve. This episode is about how one CTO used an internal developer platform, or IDP, to cut that load dramatically. Luna: Okay, I want to hear the specifics. Who's the CTO and what was the situation? Lucas: It's a company I'll call DataFlow — a mid-stage SaaS firm with about 80 engineers. Their CTO, Sarah Chen, had joined two years earlier. The team was using microservices on Kubernetes, but every service had its own custom deployment pipeline. There were five different CI/CD tools in use. Some teams used Helm, some used Kustomize, one team was still pushing Docker images via scp. Luna: So basically the Wild West. That sounds familiar. Lucas: Right. Sarah told me that the average developer spent about 40 percent of their time on infrastructure tasks. Not just deploying, but debugging networking issues, managing secrets, updating base images. The team's DORA metrics were poor — deployment frequency was about twice a week, and mean time to recover was around 90 minutes. Luna: And her solution was to build an internal developer platform. Lucas: Yes. But the key thing is how she defined it. She didn't want to build a 'platform' in the abstract. She wanted a thin abstraction layer that gave developers a single path to deploy code. In platform engineering, that's called the golden path. Luna: And how did she get started? Because I imagine you can't just roll out a platform across 80 engineers overnight. Lucas: She did it iteratively. First, she formed a small platform team — three people — and they built a minimal viable platform in eight weeks. The MVP was essentially a web interface where a developer could pick their service, choose a branch, and click deploy. Behind the scenes, it generated a standard Kubernetes manifest with sensible defaults, ran a CI pipeline, and deployed to a staging environment. Luna: So it automated the golden path. But what about teams that had unusual requirements — like a service that needed a GPU, or a special database config? Lucas: That's the hardest trade-off. Sarah's approach was to support 80 percent of use cases with the default path, and for the remaining 20 percent, the platform exposed escape hatches — you could inject custom YAML or specify additional containers. But the key rule was that the default path had to be the easiest path. If you used the golden path, deployment was three clicks. If you went custom, it was on you to maintain it. Luna: That's a classic platform engineering principle. Make the right thing easy and the wrong thing hard. Lucas: Exactly. And the results were striking. Within six months, 70 percent of services had migrated to the golden path. Deployment frequency went from twice a week to four times a day. Mean time to recovery dropped from 90 minutes to 12. Because when something broke, the platform team could fix it once — in the platform — and every team benefited. Luna: Those are the metrics that matter. But I'm curious about the team's reaction. Did developers feel like they were losing control? Lucas: Some did, initially. Especially the senior engineers who had built their own custom pipelines. There was a sense of 'I know my service better than the platform does'. Sarah told me she handled that by making the platform team an enabling team, not a controlling one. They held office hours, did pair programming sessions, and encouraged feedback. Over time, the seniors saw that they could focus on features they actually cared about. Luna: So it shifted their identity from 'I'm the Kubernetes expert on my team' to 'I'm the business-logic expert on my team'. Lucas: That's exactly what happened. And that's where the cognitive load reduction really shows up. Developers reported in surveys that they felt less anxious about deployments. They trusted the platform. They knew that if they followed the golden path, their code would deploy safely. Luna: I think a lot of engineering leaders listening right now are probably thinking, 'Okay, but building a platform sounds expensive. How many people do you need?' Lucas: Sarah started with three. After a year, the platform team grew to five. That's less than seven percent of the total engineering headcount. And the ROI is clear: if you reclaim 40 percent of developer time, that's like adding 32 engineers without hiring. Even if the platform team costs half a million a year, it pays for itself quickly. Luna: And I imagine they also saved on infrastructure costs. If you standardize deployments, you can right-size resources more easily. Lucas: Absolutely. Sarah's team added cost dashboards to the platform, so developers could see how much their service cost to run. That alone led to a 15 percent reduction in cloud spend in the first quarter. Because teams started cleaning up unused resources and picking cheaper instance types. Luna: If today's conversation gave you something usable — maybe you're a CTO thinking about platform engineering, or an engineering manager wondering how to sell this to your team — the best way to keep these episodes ad-free is listener support. You can head to buy me a coffee dot com slash fexingo. It's a small gesture that lets us keep digging into real-world cases like this one. Lucas: Yeah, absolutely. We don't run ads, so listener contributions are what make this possible. And we appreciate every single one. Luna: Alright, back to the platform. One thing I want to dig into is the tooling. What did Sarah actually use to build the platform? Lucas: She chose a combination of Backstage for the developer portal, with custom plugins. Backstage is Spotify's open-source platform, and it gave her a consistent UI. Under the hood, they used Terraform for infrastructure provisioning, and a CI/CD engine that wrapped GitHub Actions. The key was that developers didn't need to learn any of that. They just saw a service catalog, clicked a button, and got a deployment. Luna: So Backstage was the front door. Did they have to customize it heavily? Lucas: Not as much as you'd think. They built three custom plugins: one for deployment, one for cost reporting, and one for incident management. The rest was out of the box. The platform team spent most of their effort on the integration layer — making sure that when a developer clicked deploy, the right Terraform modules ran, the right secrets were injected, and the right monitoring was set up. Luna: And what about on-call? Did the platform change how incidents were handled? Lucas: Significantly. Before the platform, each service had its own runbook, often out of date. After, the platform provided a consistent observability stack. Every service got the same logging, the same metrics, the same alerting rules. The on-call engineer could jump into any service and know exactly where to look. That's part of why MTTR dropped so much. Luna: It sounds like the platform became a force multiplier for reliability as well as velocity. Lucas: It did. And Sarah told me that the biggest surprise was the cultural shift. Teams started treating the platform as a product. They submitted feature requests, they wrote docs, they evangelized it to new hires. The platform team ran a 'platform day' every quarter where they showcased new capabilities and collected feedback. Luna: That's the dream, right? The platform becomes self-sustaining. Lucas: Right. And I think the lesson for other CTOs is: start small, focus on the golden path, and measure everything. Sarah started with just one deployment path. She didn't try to solve every problem at once. She listened to the pain points and solved the most common one first. Luna: Which was? What was the number one pain point? Lucas: It was actually not deployment — it was environment parity. Developers would write code that worked on their laptop, but then fail in staging because a dependency version was different. The platform forced every environment to use the same base images and the same configuration. That alone eliminated a huge class of bugs. Luna: So the platform wasn't just about speed, it was about consistency and correctness. Lucas: Exactly. And that's the deeper value of platform engineering. It's not just a tool; it's a system that encodes best practices and reduces variability. When every team does things the same way, your organization learns faster. Luna: I think the key takeaway for our listeners is: you don't need to be a giant tech company to benefit from an internal developer platform. Sarah's team was 80 engineers, and they saw massive improvements. Lucas: Right. And the barrier to entry is lower than ever. Open-source tools like Backstage, Humanitec, and Port are making it accessible. The real investment is in the team culture and the willingness to treat the platform as a product. Luna: So if you're an engineering leader thinking about this, what's the first step you should take? Lucas: I'd say: measure your current cognitive load. Survey your developers. Ask them what fraction of their time is spent on infrastructure vs. business logic. Then pick one pain point — the most common one — and build a thin automation layer around it. That's your first platform increment. Luna: Great advice. And we've linked to Sarah's talk on platform engineering in the show notes if you want to hear her story directly. Lucas: Yeah, definitely check that out. And if you have a case study from your own experience, we'd love to hear about it. You can reach us on the Fexingo website. Luna: I think the big picture here is that platform engineering is one of the highest-leverage investments an engineering organization can make. Lucas: Completely agree. It reduces cognitive load, accelerates delivery, improves reliability, and even cuts costs. That's a rare combination. Luna: Alright, that's all for this episode. We'll see you next time on Tech Leadership with Fexingo.