Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How a CTO Uses Platform Engineering to Cut Developer Onboarding from Weeks to Hours
Transcript
- Lucas: If you've ever joined a new engineering team, you know the drill: day one, you get a laptop, a sparse README, and a ticket to request access to a dozen internal tools. If you're lucky, by the end of week two you can push code to staging. One CTO I spoke with recently decided that was unacceptable. Luna: That's a pretty common pain point. What did they do differently? Lucas: They built an internal developer platform — an IDP — around Backstage, the open-source platform from Spotify. But the interesting part is how they approached it. They didn't try to abstract away all infrastructure at once. They started with the single most painful moment for new developers: the local setup. Luna: So instead of a massive cloud migration, they focused on the first day. Lucas: Exactly. The CTO told me that in their previous setup, a new hire spent an average of three weeks just getting their local environment to match production. Different OS versions, missing dependencies, stale documentation. So they built what they called a 'golden path' — a single, opinionated template that provisions a fully configured local environment with one command. Luna: One command? That sounds almost too good to be true. What's under the hood? Lucas: They used a combination of Docker Compose for local services, a shell script that pulls the right versions of everything, and a Backstage template that generates the whole thing. The template asks the developer three questions — team name, service name, and which database they need — and then it creates a repository with CI/CD pipelines, a Kubernetes config, and monitoring dashboards already wired up. Luna: So the golden path isn't just local — it extends all the way to production. Lucas: Right. That's the key insight. The CTO called it 'the paved road.' You can still go off-road if you need to, but the default path is safe, fast, and supported. And they measured the result: onboarding time dropped from three weeks to under four hours. Four hours to first pull request merged. Luna: That's a dramatic shift. But I'm wondering — does this approach work for teams with complex microservice architectures? Or is it more suited to a monolith? Lucas: Great question. This particular company runs about 80 microservices. The golden path templates are per service type — web API, background worker, data pipeline, et cetera. Each template encapsulates the best practices for that service archetype, including logging, error handling, and observability hooks. Luna: So the templates encode institutional knowledge. That must reduce the cognitive load on senior engineers who used to answer repetitive setup questions. Lucas: Exactly. The CTO said that before the platform, senior engineers were spending roughly 15 percent of their time just helping new folks get unstuck. After the golden paths, that dropped to almost zero. But here's the thing — they had to fight a cultural battle to get senior engineers to contribute to the platform itself, not just use it. Luna: I can imagine. There's often a bias toward building features rather than improving developer tooling. Lucas: Right. So they made platform contributions part of the engineering level rubric. To reach senior or staff level, you had to have shipped at least one significant improvement to the IDP. That changed the incentive structure completely. Suddenly, the coolest engineers were the ones who made the platform better. Luna: That's a smart move. But doesn't platform engineering risk creating a new bottleneck? Now every team depends on a central platform team. Lucas: That's the classic concern. The CTO addressed it by making the platform self-service. Teams don't file tickets to the platform team — they use Backstage's software catalog to provision their own infrastructure. The platform team focuses on building and maintaining the templates and the underlying infrastructure as code. Luna: So the platform team is like an enabler, not a gatekeeper. Lucas: Exactly. They also implemented scorecards in Backstage — automated checks that rate each service on things like ownership, documentation, and security posture. If a service falls below a certain score, it gets flagged. That gives teams visibility without central control. Luna: Scorecards sound like a way to scale governance without slowing people down. Lucas: That's the idea. And they're using Crossplane to manage cloud resources as Kubernetes custom resources, so developers can request an S3 bucket or a database instance through the same Backstage interface they use to deploy their code. Luna: That's elegant. So the platform abstracts the cloud provider entirely? Lucas: Mostly. They run on AWS, but developers don't need to know that. They just ask for a PostgreSQL database with a certain size, and the platform provisions it. The CTO said this eliminated about 80 percent of the infrastructure tickets that used to go to the ops team. Luna: Eighty percent is huge. But I'm curious — what about existing services that don't fit the golden path templates? Lucas: That was the hardest part. They had about 30 legacy services built before the platform existed. They didn't force migration. Instead, they built a 'service migration tool' that analyzes a legacy service's Dockerfile and CI config and generates a Backstage entity file. Then the team can gradually adopt the golden path components. Luna: So they meet teams where they are. That seems like a more realistic approach than a big bang rewrite. Lucas: Definitely. And they set a three-year runway for the platform investment. The CTO was very clear that this isn't a six-month project — it's a long-term capability. They treat the IDP as a product, with a product manager, user research, and quarterly OKRs. Luna: That level of commitment is rare. Most companies give up after the first sprint if they don't see immediate ROI. Lucas: Right. But the early metrics helped justify the continued investment. Within six months, developer cycle time decreased by 40 percent, and the number of production incidents caused by configuration drift fell by over 60 percent. Luna: Configuration drift is such a silent killer. I've seen teams spend days debugging something that was just a mismatch between environments. Lucas: Exactly. And the golden path eliminates that because every environment — local, staging, production — is defined by the same Terraform and Helm charts. The CTO said the biggest surprise was how much it improved incident response. When something breaks, engineers can spin up an exact replica of the production environment in minutes, not hours. Luna: That alone probably justifies the investment. Lucas: And then there's the cultural shift. The CTO mentioned that after the platform was in place, the engineering team started having more conversations about architecture and less about who forgot to update the environment variables. That's a sign of a mature engineering culture. Luna: Yeah, moving from firefighting to strategic thinking is a huge win. Lucas: If today's conversation about platform engineering gave you something usable, I want to quickly mention something about how this show works. We deliberately don't run ads on these episodes — no sponsor segments, no product placements. It's just the conversation, because we believe good technical content shouldn't be interrupted. Luna: Right. And that's only possible because some listeners choose to support us directly. If that's something you've been thinking about, the link is buy me a coffee dot com slash fexingo. Lucas: Totally. It's a small way to keep this ad-free and focused on what matters. And now back to the platform story — one more detail I found fascinating. The CTO also built a 'developer experience dashboard' that tracks metrics like time from commit to production, build failure rate, and onboarding satisfaction scores. Luna: So they're measuring the impact in real time. That helps make the case for continued investment. Lucas: Exactly. And they share that dashboard with the whole company, not just engineering. The CTO said it helped non-technical leaders understand why the platform investment mattered — because they could see the velocity gains. Luna: That's a good lesson in communicating technical work to the rest of the business. Lucas: For sure. So if you're considering platform engineering, the takeaway is: start with the biggest pain point, make the platform self-service, treat it as a product, and measure everything. It's not a silver bullet, but for this fintech team, it transformed how they build software. Luna: And the three-year runway commitment is a reminder that real change takes time. I think that's a great note to end on. Lucas: Next time, we'll talk about how one CTO uses value stream mapping to eliminate waste in the software delivery process. Until then, keep building.