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. ...

Your architecture diagram shows what your system is supposed to look like. Your Git history shows what it actually does. Those two things are rarely identical. What Change Coupling Is Change coupling measures how often two modules change in the same commit — without any static code analysis, without reading a single line of source code. Just commit metadata and file paths. If module A and module B consistently appear together in commits, something connects them. Maybe it’s a shared interface. Maybe it’s a hidden dependency. Maybe it’s one team doing the work of two. Whatever the reason, the Git history captures it. ...

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. ...