Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How We Cut Deploy Times By Building an Internal Developer Platform
Transcript
- Lucas: So a few weeks back I was talking to a CTO at a Series B company — about 60 engineers, shipping to production maybe four times a week per team. And he told me their average deploy time from commit to production was 45 minutes. Luna: Forty-five minutes? That's not terrible for a regulated industry or something, but for a SaaS product that's pretty slow. Lucas: Yeah, and the kicker was — most of that time wasn't even running tests or building. It was just waiting. Waiting for someone to approve a config change, waiting for the right Kubernetes manifest to be generated, waiting for a ticket to be assigned to the right person. Luna: So the bottleneck wasn't infrastructure — it was process. Lucas: Exactly. So we spent an afternoon mapping out the actual path from 'I pushed a branch' to 'it's in production.' And there were, like, 11 distinct handoffs. Three of them involved Slack messages to a senior engineer asking 'does this YAML look right?' Luna: I've seen that. It's the 'ask an expert' pattern — it scales terribly. Lucas: Right. So what they did — and this is the part I want to dig into — is they built an internal developer platform. Not a huge one. Just enough to codify those decisions that were causing the human bottlenecks. Luna: And by 'internal developer platform' — let's be specific. What did that actually look like for them? Lucas: Sure. They used Backstage as the portal layer — that's the open-source developer portal from Spotify. Then they built a set of scaffolder templates that automated the whole 'new microservice' flow. When a developer wanted to create a new service, they'd fill out a form: service name, language, database, expected traffic patterns. The template would generate the repo, the CI/CD pipeline, the Kubernetes manifests, the monitoring dashboard — everything. Luna: So it removed that first big decision: 'what's the right config for this?' Lucas: Exactly. And they also built a simple deploy workflow on top of Argo CD that automated the manual approval steps. Instead of asking a senior engineer to review a YAML change, the platform ran a set of automated checks — linting, a simple policy engine that verified the service adhered to their security baseline, and then it deployed automatically if everything passed. Luna: So the senior engineers no longer had to be the gatekeepers. Lucas: Right. And that was the biggest unlock. After they rolled that out — it took them about three months to build the initial version — their average deploy time went from 45 minutes to 8 minutes. And their deploy frequency went from about four per week per team to about 12 per week per team. Luna: That's a huge improvement. But I imagine the senior engineers felt a bit weird about giving up that control. Lucas: Some did. There was definitely a 'but what if someone deploys something dangerous?' concern. But the platform wasn't removing all safety — it was just moving the safety checks earlier and automating them. The senior engineers actually ended up with more time to work on architecture reviews and tech debt, because they weren't doing the same YAML review five times a day. Luna: That's the classic platform engineering value proposition: reduce cognitive load for the developer without sacrificing reliability. Lucas: And that's the phrase I want to hold onto — cognitive load. The reason those 11 handoffs existed wasn't because everyone was lazy. It was because each team had accumulated a bunch of implicit knowledge about 'how we do things here.' The deploy process was a tribal ritual, not a documented pipeline. Luna: So by building the platform, they were essentially encoding that tribal knowledge into something executable. Lucas: Yeah. And the nice thing about the template approach is that it doesn't force all teams into the exact same mold. You can have different templates for different service tiers — a 'critical payment service' template with stricter deployment gates, versus an 'internal reporting service' template that's more permissive. Luna: So it's not a monolith — it's a menu of golden paths. Lucas: Exactly. And the teams still own their services. They can deviate from the template — they just have to explicitly justify the deviation. That's different from a top-down mandate that says 'everyone must use this exact setup.' Luna: So what about the teams that don't want to use the platform at all? Did they force adoption? Lucas: They didn't force it, but they made it significantly easier to use the platform than to do it manually. And they measured adoption. After six months, about 80 percent of new services were created through the scaffolder. The holdouts were mostly legacy services that were too complex to migrate — and that was fine. The platform team just made sure the deploy pipeline for those services was still supported, but they didn't try to force-fit them. Luna: That's smart. Forcing migration often backfires. Lucas: Right. And the other interesting metric was onboarding time. Before the platform, a new engineer took about two weeks to get their first deploy — mostly because they had to learn the tribal ritual. After the platform, that dropped to two days. New hires could create a simple service, get it deployed, and see it in production by the end of their second day. Luna: That's a huge productivity gain, especially for a fast-growing company. If you're hiring five engineers a month, that's weeks of cumulative ramp-up time saved. Lucas: Exactly. And that's often the hidden ROI of a platform — it's not just about deploy speed, it's about how quickly you can scale the engineering organization without adding proportional overhead. Luna: So if a listener is thinking about doing something like this, what's the first step? How do they avoid building a platform that nobody uses? Lucas: Great question. The CTO I spoke with told me their biggest lesson was: start with the pain point, not the technology. They didn't start by saying 'let's build a platform.' They started by saying 'our deploy process has too many handoffs — let's fix that.' The platform was just the solution that emerged. Luna: So map the pain points first, then pick the tool. Lucas: Exactly. And start small. They built just enough to solve the deploy bottleneck — the scaffolder templates and the automated deploy pipeline. They didn't try to build a full developer portal with documentation, service catalog, and everything on day one. That came later. Luna: That incremental approach also helps build buy-in. Teams see value before they're asked to change their whole workflow. Lucas: Right. And I think that's the key takeaway: an internal developer platform isn't necessarily a huge multi-year investment. It can be a focused, incremental effort that solves a specific bottleneck. And if you do it right, it doesn't just make your engineers faster — it makes them happier, because they're spending less time on YAML and more time on actual product work. Luna: If today's conversation gave you something useful, you know, the way we keep this ad-free is through listener support. People who find value in the show can help keep it going at buy me a coffee dot com slash fexingo. Lucas: Yeah, it's a small thing that makes a big difference. We really appreciate those who chip in — it lets us keep focusing on content without worrying about sponsors. Luna: So back to the platform story — you mentioned they used Backstage. What about teams that don't have the bandwidth to run an open-source platform? Are there managed alternatives? Lucas: Yeah, there are a few. Port and Roadie offer managed backstage as a service. There's also OpsLevel, which is a commercial product that sits on top of Backstage. And for smaller teams, even a well-documented set of scripts and a wiki page might be enough — the key is the principle of encoding the process, not the specific tool. Luna: So the tool is secondary to the mindset shift: treat your developers as customers, and their productivity as a product. Lucas: Exactly. And that mindset shift is probably the hardest part. It means the platform team needs to measure things like time-to-first-deploy, deploy frequency, and developer satisfaction — and treat those as key metrics. Luna: So it's not just an infrastructure project — it's a product management project. Lucas: Right. And the CTO I spoke with said that was the biggest internal shift: the platform team stopped thinking of themselves as 'the ops team' and started thinking of themselves as a product team serving developers. They did user research, they ran surveys, they showed usage dashboards. They even had a product manager for the platform. Luna: I love that. It's a very 'platform engineering' approach. Lucas: Yeah. And it's worth noting that this isn't just for big tech companies. This mid-stage startup with 60 engineers saw massive ROI. The platform cost about three engineer-months to build initially, and the time savings across the engineering org easily paid that back in a quarter. Luna: So the question for every engineering leader might be: what's the most painful handoff in your deploy process, and what would it take to automate it? Lucas: Exactly. Start there. You don't need to boil the ocean.