Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / When Engineers Become Bottlenecks
Transcript
- Lucas: So there's this pattern I keep seeing in engineering teams — especially startups that just hit Series B or C. You've got one brilliant senior engineer who knows every line of the codebase. They're the hero. But they're also the bottleneck. Luna: The person who has to approve every pull request, right? Or the only one who can deploy to production? Lucas: Exactly. And it's not malicious — they genuinely want to help. But the cost is real. I looked at a case from a fintech startup last year. One principal engineer was the sole approver for production deployments. They had about 20 developers waiting on him. The average delay per deployment was 2.5 days. Luna: Two and a half days? That's huge. How much did that cost them? Lucas: They calculated the opportunity cost over 18 months at about $2.3 million. That's the value of features that could have shipped faster. And that's just the direct cost — doesn't include morale hits or attrition risk. Luna: I've seen this too. At my last company, we had a senior dev who was the only person who understood the payment processing module. Any change had to go through him. We called it the 'bus factor' problem — if he got hit by a bus, the whole system would grind to a halt. Lucas: Right, the bus factor. Or truck factor, depending on your preferred metaphor. Ideally you want it to be at least 2 for every critical system. But in practice, a lot of teams let it slip to 1 because it's comfortable to have a single expert. Luna: What's the real fix here? Do you just force the senior engineer to document everything? Or do you rotate responsibilities? Lucas: You need a combination. First, measure the bottleneck. Look at your code review queue. If one person has more than 30 percent of open reviews, that's a red flag. Second, set WIP limits — work in progress limits per developer. If someone can only have three active tickets at a time, they can't hoard all the critical work. Luna: But don't some engineers just naturally have more context? Like, they've been there longer. Lucas: Absolutely. And you don't want to punish that experience. But you also need to spread that context. One approach is to pair the senior engineer with a mid-level developer on each critical module. The senior reviews the work, but the mid-level actually writes the code and eventually becomes a co-owner. Luna: So it's about knowledge transfer, not just documentation. Because docs get stale. Lucas: Exactly. Documentation is important, but the real depth comes from hands-on pairing. I know a startup that rotated code review responsibilities every sprint. Each senior engineer had to teach two others how to review for a specific area. Within three months, their bus factor went from 1 to 4 on their main product. Luna: That's a great metric. Did they also track deployment frequency? Lucas: Yes — deployments went from once a week to three times a week. And the senior engineer told me he actually felt less stressed because he wasn't the single point of failure anymore. He could take vacation without his phone blowing up. Luna: So the bottleneck problem isn't just about throughput — it's also about burnout. The 'hero' engineer is often the most burned out. Lucas: Exactly. And the irony is that sometimes the bottleneck is self-imposed. I've interviewed engineers who admit they hoard knowledge because they think it makes them indispensable. But that's actually a career risk — if you're the only person who can fix something, you can never be promoted off that system. Luna: That's a great point. So how do you handle that conversation? 'Hey, you're a bottleneck, and it's bad for you too'? Lucas: It's a delicate conversation. You frame it as career growth. Say something like: 'We want you to work on higher-impact problems. To do that, we need to free you from being the only person who can handle this module. Let's mentor someone else so you can focus on architecture decisions.' Most senior engineers respond well to that. Luna: I've seen it go wrong too. I had a manager who told a senior engineer: 'You're a bottleneck, we need you to stop reviewing everything.' The engineer felt attacked and left within two months. Lucas: Yeah, you can't just criticize. You need a system. At the team level, you can introduce something like a 'code review SLA' — every pull request must get two approvals within 24 hours. That forces distribution. If one person is still the bottleneck, the data is right there in the metrics. Luna: Let's talk about measuring this. What specific data should a CTO look at to identify bottlenecks? Lucas: First, cycle time — how long from commit to deployment. If it's more than two days for most changes, you probably have a bottleneck. Second, review assignment distribution. If one person has more than 40 percent of reviews, that's a warning. Third, the 'wait time' in each stage. If code sits in review for 12 hours but only takes 30 minutes to review, the reviewer is the bottleneck. Luna: What about the reverse? Can you have too many reviewers? That also causes delays. Lucas: Great point. Two to three reviewers is the sweet spot for most teams. More than that and you get coordination overhead. Also, you want reviewers who actually have context. Rotating through a list of 10 people just for the sake of distribution doesn't help — you end up with shallow reviews. Luna: So it's about targeted distribution. Pair the right people with the right modules. Lucas: Exactly. Another technique is to enforce documentation as part of the definition of done. Any time a senior engineer fixes a critical bug, they must add a runbook entry. Over time, that builds a knowledge base that reduces dependency. Luna: I've seen teams that use 'fire drills' — they intentionally have the senior engineer go on vacation for a week and see who can handle incidents. That reveals gaps fast. Lucas: That's a controlled way to test the bus factor. But you need to do it in a low-stress environment. You don't want to simulate a real outage while the senior is away — that could be catastrophic. Instead, do a game day where you simulate a failure and the junior engineers have to fix it using documentation and pair programming. Luna: What about the cost of all this? Training, pair programming, documentation — it slows down the senior engineer in the short term. Lucas: It does. But the return on that investment is huge. I've seen estimates that every hour spent on knowledge transfer saves 4 to 6 hours of future interruptions. And it reduces the risk of a catastrophic bus factor event. Plus, the senior engineer becomes more valuable because they can now influence multiple teams instead of being stuck in one module. Luna: So the message to CTOs is: don't let your heroes become your bottlenecks. Lucas: Exactly. Celebrate their expertise, but build systems that spread it. Measure cycle time, review distribution, and bus factor. And have the career conversation early. Because a bottleneck that feels like a lifeline today is a time bomb tomorrow. Luna: Speaking of time bombs — do you think the industry is getting better at this? Or is it still common? Lucas: I think awareness is growing. More teams use DORA metrics now — deployment frequency, lead time, change failure rate, mean time to recovery. Those metrics naturally expose bottlenecks. But startups in particular still fall into the hero trap because they move fast and reward individual heroics. The key is to reward the person who makes the whole team faster, not just the person who writes the most code. Luna: I'd add one more thing: the bottleneck is often a symptom of a culture that doesn't prioritize documentation or pair programming. So fixing it requires changing the culture, not just the process. Lucas: That's spot on. Culture eats process for breakfast. But you can start with a simple change: make every critical system have at least two owners. And make that a non-negotiable part of your engineering standards. If someone leaves, you don't want to be scrambling. Luna: Great advice. So, next time you see a team that's 'too dependent on one person,' you know what to do. Lucas: Exactly. Measure it, spread the knowledge, and reward the multipliers. That's how you turn a bottleneck into a force multiplier.