Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How to Build an Internal API Platform That Developers Actually Use
Transcript
- Lucas: Let me tell you about the platform team at a company I'll call CloudLogix — a mid-size SaaS firm with about 300 engineers. Their platform team spent eight months building a gorgeous internal developer portal. Think custom Backstage instance, self-service infrastructure, the works. Six months after launch, fewer than twenty percent of services were using it. Luna: That's brutal. Was it a technical problem? Lucas: Not really. The platform worked fine. The problem was that the team built for the developer they wished they had, not the developer they actually had. They cargo-culted patterns from companies like Spotify and Uber — assuming their engineers wanted total abstraction from infrastructure. Luna: But don't developers want that? Less ops, more coding? Lucas: In theory, yes. In practice, CloudLogix's engineers were mostly backend devs who had been managing their own Kubernetes manifests for years. They had hard-won tribal knowledge about how their services interacted with the cluster. The platform abstracted all that away behind a friendly UI — which meant when something broke, they couldn't debug it. Luna: So the platform actually made them feel less in control. That's a recipe for abandonment. Lucas: Exactly. And there was another mistake: the platform team set a hard deadline. 'All new services must use the internal API platform by Q3, and existing services must migrate by Q4.' Teams panicked. They either ignored it or built workarounds. The platform became a compliance checkbox, not a tool they wanted to use. Luna: I've seen that before. Deadlines breed resentment. But without a deadline, how do you drive adoption? Lucas: The CTO stepped in. She killed the mandate. Instead, she told the platform team to focus on one single metric: time to first deploy for a new service. At the time, it took about four days — provisioning, CI setup, secrets, the whole dance. She asked them to cut that to under two hours for teams that opted in. Luna: That's a concrete, measurable goal. Did they hit it? Lucas: They did. Within three months. And here's the thing — they didn't add new features. They stripped the platform down. They removed the custom UI and exposed the underlying Terraform modules and Helm charts directly. They wrote excellent documentation with runbooks. They made the opt-in frictionless: a single CLI command that scaffolded everything. Luna: So they went from 'here's a black box' to 'here's a set of well-documented building blocks.' That feels more like what engineers actually want. Lucas: Right. And adoption followed naturally. Within six months of the opt-in approach, over seventy percent of new services were using the platform. Existing teams started migrating on their own schedule because they saw their peers shipping faster. The platform team shifted from being a bottleneck to being an enabler. Luna: It's interesting — the best platform teams I've seen are the ones that treat their internal developers as customers. They do user research, they ship incrementally, they measure satisfaction. Lucas: Exactly. And they resist the urge to build everything upfront. The CloudLogix team initially had service discovery, secret management, logging, monitoring, CI pipeline, all bundled. That's overwhelming. The CTO's constraint forced them to focus on the highest-leverage pain point: getting started. Luna: I want to push back a little. Isn't there a risk that by stripping down the platform, you're just punting complexity to individual teams? They still have to wire up monitoring themselves, configure logging — that's not exactly platform thinking. Lucas: It's a fair point. But the philosophy here is progressive enhancement. Start with a thin layer that solves the most painful bottleneck. Then add capabilities as teams demand them — not because you think they need them. The CloudLogix team later added monitoring as an optional add-on, but only after teams complained about setting it up themselves. Luna: So you let demand pull features, rather than pushing them from the center. That requires a lot of discipline from the platform team — and from leadership. Lucas: It does. And it's harder than building a monolith platform upfront because you have to constantly listen and iterate. But the payoff is real adoption. I think a lot of platform teams fall into the trap of making decisions for their users instead of with them. Luna: And if today's tech conversation gave you something usable — a pattern you might apply in your own team — that's the whole point of this show. We deliberately don't run ads on these. If you want to support that choice, the link is buy me a coffee dot com slash fexingo. It keeps the host's job sustainable. Lucas: Yeah, it's a small way to keep this independent. Back to CloudLogix — there's another lesson about measurement. The platform team initially tracked metrics like 'number of services onboarded' and 'API calls to the platform.' Those are vanity metrics. Luna: What should they have tracked instead? Lucas: They started tracking developer satisfaction surveys — simple ones, like 'how easy was it to deploy your last change?' on a scale of one to five. They also tracked time to first deploy, which I mentioned, and time to recover from a failure. Those are outcomes that actually matter to engineers. Luna: So they moved from measuring platform output to measuring developer outcomes. Lucas: Yes. And that shift changed their prioritization. They stopped building features that nobody asked for and started fixing pain points that developers actually reported. The survey data was brutal at first — scores around two point five. After a year of iterative improvements, they got to four point two. Luna: That's a huge leap. What was the biggest driver of that improvement? Lucas: Surprisingly, it wasn't a new feature. It was documentation. They invested heavily in runbooks and examples. They also started doing office hours — twice a week, any engineer could drop in and ask questions or pair with a platform engineer. That built trust and showed that the platform team was there to help, not to enforce. Luna: The human element. That's something you can't abstract away. Lucas: Right. And it's easy to overlook when you're focused on building software. But ultimately, an internal developer platform is a product, and your colleagues are your users. Treat them that way, and you'll get adoption. Treat them like a captive audience, and you'll get a ghost town. Luna: I think there's a parallel here with how we think about tech debt. A platform can become a form of tech debt if it's imposed without buy-in. Lucas: Absolutely. Platforms are supposed to reduce cognitive load, but they can increase it if they're not designed for the actual context. The CloudLogix CTO often said, 'A platform is only successful if the teams it serves are more productive than they would be without it.' That sounds obvious, but it's easy to lose sight of. Luna: So what's the one takeaway for a CTO or VP of Engineering listening? If they're about to build an internal platform, what should they do first? Lucas: Interview your engineers. Not once, but regularly. Ask them what their biggest friction point is in the development lifecycle. Don't ask them what features they want in a platform — they'll give you a laundry list. Ask them what makes them angry or slows them down. Then build the smallest possible thing to fix that. Luna: And don't set a mandate. Let adoption be a pull, not a push. Lucas: Exactly. If your platform is good enough, teams will come. If it's not, no amount of policy will make them stay.