Engineering-Leadership

Most tools that measure bus factor stop at the number. One person owns this module. Here is the percentage. Good luck. That’s useful context. It’s not useful guidance. The question a CTO or engineering manager actually needs answered isn’t how concentrated is the knowledge? — it’s what do I do about it, and where do I start? The Problem With Raw Risk Metrics Knowledge concentration exists in virtually every codebase. Run any ownership analysis on a real production repository and you’ll find modules where one person did 80% of the meaningful work. You’ll find files nobody else has touched in two years. You’ll find developers who accumulated knowledge across hundreds of commits that isn’t written down anywhere. ...

Bus factor is one of those concepts every engineering leader nods at and almost nobody measures. The definition is simple: how many people would need to leave — or get hit by a bus — before your project is in serious trouble? A bus factor of 1 means a single person holds knowledge that no one else has. If they leave, you’re exposed. Most teams estimate this. They name names. They have informal conversations about who knows which system. And then they file it away until someone actually leaves. ...

There is a conversation happening right now in engineering circles about code reviews. The argument goes roughly like this: AI is generating code faster than humans can review it, PR volume is exploding, and we need smarter tooling to keep up. That argument is correct. And it is solving the wrong problem. The deeper issue is not that reviews don’t scale. It is that we are still treating the review as the primary quality gate — a last line of defence before code enters the codebase. In the age of AI-assisted development, that assumption needs to be challenged at its root. ...