Bus Factor Risk: Why More Engineers Isn't More Speed 

Capacity isn't usually the constraint. Context is.  

If your team is already documented and reasonably modern, and the live worry is keeping AI-assisted development inside your real architecture, this piece on context, not capability, for AI coding agents might be more useful. 

Every engineering leader we talk to has tried the obvious fix at least once: the roadmap's behind, so you add people. A contractor, a new hire, sometimes a whole outside team. For a few weeks, it looks like it's working. Then the new person's pull requests start coming back with "wait, that'll break X" in review. Then they're pulling your two most senior engineers into meetings just to explain how a piece of the system actually works. Six months later, you've spent real money and the roadmap hasn't moved the way you expected. 

The instinct isn't wrong, exactly. More hands should mean more throughput. But throughput assumes everyone added to a system already understands how it works. In practice, almost nobody does, not the new hire, not the contractor, often not even the two or three people on your own team who've been there the longest and just happen to hold the whole mental model in their heads. 

That's the part capacity math misses. Adding people to a system nobody fully understands doesn't add speed. It adds risk, wrapped in more meetings. 

Why new-engineer onboarding takes months 

The average new engineer needs three to six months before they can be trusted with anything genuinely complex. Not because they're slow, but because the fastest way to learn a system that isn't documented is to break something in it and get corrected. That's the actual onboarding process at most companies, whether anyone admits it out loud or not. 

During that window, the person who's supposed to be adding capacity is instead a draw on it. Every question routes back to the two or three people who already carry the system in their heads, the same people you can least afford to pull off real work. It's not a headcount problem. It's bus factor risk, and it's more common than most teams admit: a JetBrains Research and Bilkent University study found 63% of engineers had hit high bus factor risk on at least one project in the past year, and rated it their single biggest collective development problem. Too much of what makes the system work lives in too few places, and every new person, contractor or hire, has to go through that same narrow bottleneck to get productive. Fixing it is a matter of engineering knowledge management, not more hiring. 

Why Documentation Alone Isn't Enough 

Most teams have tried to fix this with documentation at some point. It rarely survives contact with reality. A doc is a snapshot; the system isn't. Six weeks after someone writes it, a service gets refactored, a dependency changes, an edge case gets patched in a way nobody wrote down, and the doc is now actively wrong, which is worse than no doc at all, because people still trust it. 

The problem was never that nobody wrote things down. It's that a static document can't keep up with a system that keeps changing, and nobody has time to be its full-time maintainer. 

What actually correlates with developer velocity 

McKinsey's Developer Velocity research looked at technology, working practices, and organizational enablement across more than 400 large companies, and found that top-quartile teams on their Developer Velocity Index grew revenue four to five times faster than bottom-quartile teams. The driver most executives underrated wasn't headcount. It was the tooling and clarity that let engineers actually move inside their own systems, something only about 5% of the leaders surveyed ranked as a top-three priority. 

Velocity by itself isn't the goal, either. A team can hit every sprint target while still shipping the wrong thing, or quietly cutting corners to keep the number up. What actually moves the needle is engineers who understand the system well enough to build the right thing correctly the first time, not just faster. 

We saw the same pattern up close with SightX, a SaaS platform in the market research space. Their engineering team wasn't short on people. They were short on a shared, current picture of how their own product actually worked, which meant every change came with a slow, careful excavation first. After we mapped the system before any code changed, their co-founder put it simply: "What used to feel like constant firefighting became a controlled, confident engineering operation." Discovery time dropped 90%. Engineering output tripled. 

How SightX got there → 

Map the system before anyone touches it 

Fixing bus factor risk was never just a developer's problem to solve alone. It takes leadership, the right process, and the right tooling working together, which is exactly what VelX, our structural mapping process, is built to do. Before an engineer of ours writes a line of code, on your team or embedded with it, VelX maps the system first, whether it's a fresh codebase or a decade-old legacy system: architecture, dependencies, the business logic that never made it into a doc, and the risk sitting quietly inside it. It's documented and handed back to you, whether or not anything else happens after that. 

We're offering that mapping as a complimentary discovery on one system of your choice right now. Normally it's a paid, scoped engagement. The first one's on us. 

See how a structural mapping process cut one team's discovery time by 90%, and what it could do for yours. → See how the mapping works