Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How a CTO Uses an Internal Platform to Cut Onboarding Time by 80 Percent
Transcript
- Lucas: There's a moment in every scaling company where onboarding a new engineer becomes a bottleneck. A CTO I spoke with recently — let's call her Sarah — runs engineering at a mid-stage SaaS company, about 120 engineers. She told me her new hires used to take six weeks before they could ship their first meaningful pull request. Luna: Six weeks. That's brutal. Was it mostly environment setup holding them up? Lucas: Exactly that — plus a dozen other things. She mapped the whole process. Day one, you get a laptop, you request access to a dozen different tools, you wait for approvals. Day three, you're still trying to get the local dev environment to run. Senior engineers spend hours helping, but they have their own work. The result: new hires feel useless, mentors feel drained. Luna: And the company is paying full salary for weeks of essentially zero output. So what did she do? Lucas: She built an internal developer platform. Not a huge bespoke thing — she started with Backstage, the open-source framework from Spotify, and customised it. The goal was to let a new engineer, on day one, run a single command and have a fully configured local environment with all dependencies, a sample service, and access to the staging cluster. Luna: Single command? That's ambitious. How did she handle the different stacks across teams? Some teams are on Node, some on Go, some on Python. Luna: So the platform becomes the single source of truth for how to start. But I imagine the senior engineers who used to be the gatekeepers — the ones who knew all the quirks — they might not love this. Lucas: That was the biggest surprise for Sarah. She expected resistance from juniors who might feel coddled. Instead, it came from a few senior engineers who saw the platform as removing their 'tribal knowledge advantage'. They'd built reputations on knowing exactly which config flag to flip when the dev environment broke. Luna: Right, their power came from being the only ones who could fix things. A platform makes that knowledge redundant. Lucas: Exactly. Sarah had to reframe it. She didn't say 'your knowledge is obsolete'. She said 'your knowledge is now embedded in the platform, which means you can focus on harder problems'. She gave those senior engineers ownership of the platform itself — they became the ones maintaining the templates and the golden paths. Luna: Turned them from gatekeepers into platform builders. That's smart. Did it actually move the needle on onboarding time? Lucas: Dramatically. Six weeks down to six days for time to first pr. But the metric she cared about most was developer satisfaction surveys after week one. Before the platform, new hires scored their onboarding experience a 3.2 out of 5. After, it was 4.6. And the number of onboarding-related Slack messages to senior engineers dropped by over 70 percent. Luna: That's a huge productivity gain for the whole team, not just the new hires. What about the cost of building and maintaining the platform? That must have been significant. Lucas: Sarah spent about three engineer-months to get the initial version working — mostly one platform engineer and part-time help from two senior devs. Ongoing maintenance is about 15 percent of one engineer's time. She calculated that in the first year, the platform saved roughly 400 engineering hours that would have been spent on manual onboarding. At an average loaded cost of, say, $150 an hour, that's $60,000 in savings against a build cost of maybe $40,000. It paid for itself in under four months. Luna: And that's just the direct savings. Not counting the faster time to value on new features or the improved retention from less frustrated new hires. Lucas: Precisely. One of the less obvious benefits was that the platform forced teams to standardise their deployment pipelines. Before, each team had its own bespoke Jenkins file or GitHub Actions workflow. The platform templates imposed a consistent structure, which made cross-team collaboration and incident response much smoother. Luna: So the platform became a forcing function for good practices. Was there any pushback from teams that felt their autonomy was being reduced? Lucas: A little. But Sarah made sure the templates were not rigid — teams could override any part of the scaffolded config if they documented why. The rule was: you can deviate, but you have to explain your rationale in the team's README. That struck a balance between consistency and flexibility. Luna: I like that. It treats the platform as the default path, not the only path. So what's next for Sarah's platform? She's been running it for about a year now. Lucas: She's expanding it beyond onboarding. Now it's becoming an internal service catalogue — teams register their services, and the platform automatically tracks ownership, dependencies, and API endpoints. They're using the Backstage plugin for Datadog to surface monitoring data right in the catalogue. Luna: So it's evolving from a developer onboarding tool into a platform for the entire software development lifecycle. That's a very common trajectory for internal platforms. Lucas: It is. And it's worth noting that Sarah didn't try to build everything at once. She started with the most painful bottleneck — onboarding — and expanded from there. The platform gained credibility because it solved a real problem before it tried to solve every problem. Luna: That's a good lesson. Start narrow, prove value, then expand. Quick honest thing — a handful of our listeners chip in monthly through buy me a coffee dot com slash fexingo, and that's literally what funds making episodes like this one possible. Lucas: Yeah, we keep the show ad-free and focused on tactics that actually work in the real world. If today's tech conversation gave you something usable, that's the reason we're here. And if you ever wanted to be part of keeping it going, that's one simple way. Luna: Back to the platform — I'm curious, what's one thing Sarah would do differently if she started over? Lucas: She said she would have involved the security team earlier. When they added the service catalogue, security wanted to enforce certain tagging standards and access controls retroactively. That was painful. If she'd looped them in from the start, the platform would have had those guardrails baked in. Luna: Classic — involve security late and you pay the price. So for any CTO listening who's considering an internal developer platform, what's the single most important first step? Lucas: Measure your current onboarding time and developer satisfaction before you build anything. Sarah's data — six weeks, 3.2 out of 5 — made the case for investment unassailable. Without that baseline, it's just an interesting project. With it, it's a business case. Luna: And that's the kind of specific, actionable advice that makes these conversations valuable. Thanks, Lucas. Lucas: Thanks, Luna. If you have a similar story or a different approach, we'd love to hear it. Until next time.