One of the ‘best metrics ever’ is the classic “bus number”. This measures how many people in an organization can be hit by a bus before that organization’s operations or progress is severely hindered due to that person’s absence. This was a slightly funny way of measuring resilience of an organization versus the anti-pattern of knowledge hoarding in an individual’s brain. The idea is that a resilient organization should have a very high bus number and not be vulnerable to ‘critical staff’.
Think about it next time you are looking at any part of your system. Ask yourself who you would ask about that particular module, image, or whatever. Then ask yourself who you would go to if the first person was unavailable. How confident are you that you would quickly / expediently get your answer? How confident are you that you could just look the information up in a Wiki or other documentation?
If you look at the questions above and start thinking that ‘we would figure it out after a while’ or making other excuses, you minimally have a problem with communications and collaboration. You almost certainly have a process problem. And you may well have a cultural problem. Make no mistake, what it means is that your team/organization/project are playing in traffic and simply waiting for the inevitable to happen.
And when something does happen, say, for example, one of the project’s “hero coders” takes a new job, it will be miserable for all who remain as they try to figure out what the hero was doing. Meanwhile the project’s progress languishes and the deadline becomes unachievable. Morale goes down as frustration goes up. Maybe someone else decides to leave out of a sense of futility; making the problem worse. And it will have been completely avoidable. It will be completely the fault of the leadership that was either not assertive enough to make the hero share their knowledge or undisciplined enough to not include sustainability in their coaching, plans, and day-to-day execution priorities.
This is serious stuff and is worth the investment of time to solve. The habit of focusing on the overall sustainability of the organization is well documented as something that successful, resilient, and sustainable organizations emphasize. This is well documented in the classic book “Good to Great” by Jim Colins, where the book describes the organizations being built as sophisticated machines using the analogy of clock building. The notion is simple, really. That the goal is to build a lasting thing that continues on as people come and go. The project / organization must be bigger than any individual, the individuals involved must understand that, and management must encourage or enforce that mindset. In the book, the organizations that did this radically outperformed their peers in the same markets in the same timeframe.
The reality is that you will probably always have some stuff (ideally only non-critical or very new stuff) that is not well disseminated, but take those in the lens of what they are and triage / prioritize them so that you do not accumulate the knowledge gap as technical debt. Or, if you do, you should do so consciously, visibly, and at a level at which you know you can tolerate the risk.