Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses Internal Developer Platforms to Reduce Friction
Transcript
- Lucas: So we are talking about internal developer platforms today, which is a term that gets thrown around a lot in engineering leadership circles. But I want to ground it in a specific story — a CTO at a mid-size fintech company who decided to build what they called a 'golden path' platform. Luna: I love that term — golden path. It suggests there's a paved way to do things, not a constraint, but a recommended route. Lucas: Exactly. And this CTO's big insight was that their engineers were spending way too much mental energy on infrastructure decisions that weren't adding value. Things like 'which cloud region should I deploy to?' or 'should I use a managed database or run my own?' — decisions that every team was making from scratch. Luna: Right, that's classic cognitive load. Every team reinventing the wheel. Lucas: So they decided to productize the common path. They built an internal platform that offered a set of pre-approved, opinionated choices. If you wanted to spin up a new microservice, you clicked a button, filled in maybe five fields, and thirty minutes later you had a CI/CD pipeline, a Kubernetes namespace, monitoring, logging — the whole stack. Luna: And what was the before-state? How long did that take previously? Lucas: Before the platform, a new service deployment could take anywhere from two to three weeks. Because you had to go through ops reviews, security reviews, manually set up infrastructure — it was a bottleneck. After the platform, it was two days. But the real win wasn't speed — it was that senior engineers stopped being pulled into every single deployment. Luna: That's a big deal. So they freed up their most expensive talent to work on the actual product. Lucas: Exactly. But here's the thing: they didn't just throw a bunch of tools together. The CTO framed this as a product. They had a product manager for the platform, they did user research with developers, they tracked adoption metrics. The key metric they used was something they called 'platform adoption score' — basically the percentage of new services that used the golden path within their first week. Luna: So how did that score start, and where did it end up? Lucas: It started at around 30 percent, because early versions were clunky. They had a lot of resistance from teams who preferred their own scripts. But over six months, they iterated on the developer experience — adding self-service options, better documentation, and a feedback loop. By the end of the year, adoption was over 80 percent. Luna: That's impressive. But I have to ask — what about teams that have genuinely different needs? Does a golden path force everyone into the same mold? Lucas: That's the smartest critique of this approach. And the answer is that a good platform is opinionated but not rigid. This platform allowed teams to opt out if they had a legitimate reason — for example, if they needed a specific database engine that wasn't in the catalog. But opting out required a lightweight review, so it wasn't the path of least resistance. Luna: So the friction was intentional. Make the default path easy, but allow exceptions with a reason. Lucas: Precisely. And the CTO told me that about 95 percent of teams ended up staying on the golden path because it genuinely solved their problems. The exceptions were rare and usually justified. Luna: I want to bring in a counterexample. I recently talked to a startup CTO who decided to build a platform from scratch — spent six months on it — and when they launched, almost nobody used it. Because they hadn't actually talked to their developers about what they needed. Lucas: That's the classic 'build it and they will come' fallacy. And it's why the product thinking piece is so crucial. The fintech CTO started by interviewing a dozen engineers across different teams, asking them what their biggest pain points were. The top answer was 'setting up deployment pipelines is tedious and error-prone.' So they focused on that first. Luna: So they didn't try to solve everything at once. They found the biggest pain point and solved it well. Lucas: Exactly. They shipped a minimal version that just automated pipeline creation. That alone saved teams days per month. Then they added monitoring, then databases, then secrets management — one piece at a time. Each addition was driven by user requests. Luna: That incremental approach also makes it easier to measure impact. You can point to 'this feature reduced setup time by X hours' rather than saying 'we built a platform' and hoping for the best. Lucas: Right. And in fact, they tracked developer satisfaction with a simple nps style survey every quarter. The platform's NPS went from negative 20 in the first quarter to plus 40 after a year. That's a huge swing. Luna: I think one of the underrated aspects is that a platform like this can actually reduce security risk. If all services use the same hardened base image and the same logging standard, you have fewer surprises. Lucas: Absolutely. The CTO said their security team loved the platform because it enforced encryption and authentication policies automatically. Before the platform, they would find services that had accidentally exposed a database port to the public internet. After, that just couldn't happen. Luna: So it's not just about developer productivity — it's also about governance without gatekeeping. Lucas: That's the ideal: guardrails, not roadblocks. And that's what a well-designed internal platform delivers. Luna: You know, conversations like this about reducing friction in engineering teams — they remind me why it's valuable to have ad-free shows that can go deep without interruption. If you find this kind of practical tech leadership content useful, and you want to keep it free of sponsor breaks, listeners can support the show at buy me a coffee dot com slash fexingo. Lucas: Yeah, every bit of support helps us keep doing deep dives like today's. And speaking of deep dives — let's talk about what happens when a platform team doesn't treat their users as customers. Luna: Oh, I have a story for that. A friend at a large e-commerce company told me their internal platform had a 'portal' that required three separate tickets just to request a database. It was so bad that teams started spinning up their own instances on the side — shadow IT. Lucas: That's the exact opposite of what you want. The platform should be the easiest path, not the hardest. If your platform is harder to use than doing it yourself, you've failed as a platform team. Luna: Exactly. And that's why the product mindset is non-negotiable. You have to treat developers as customers, and their time as the valuable resource it is. Lucas: I think the bottom line is this: an internal developer platform is not a set of tools, it's a product that reduces friction. And the CTOs who succeed with them are the ones who start small, listen to their users, and measure everything. One final stat from the fintech CTO: after two years, their engineering team grew by 40 percent without adding any additional ops headcount. That's the leverage. Luna: That's a powerful outcome. And it makes you wonder — if you're a CTO listening, what's the one piece of friction you could remove today that would have the biggest impact on your team? Lucas: That's the right question to sit with. Thanks for joining us on this episode of Tech Leadership with Fexingo.