„What would happen if you or one of your team members would be hit by a bus?“
Have you asked yourself this question before? I know it feels kind of weird to be thinking about stuff like this, but there is more to this morbid question than you would might think.
This question tries to estimate the „bus-factor“ and is a measurement for risk and assesses the consequences of losing a key technical member of your team.
Imagine a developer that is the only one of your team that has knowledge of a specific subsystem or someone who is the only one with the credentials to an important server. What would happen if this developer would get hit by a bus (or other scenarios, like illness, taking a new job, parental leave, sabbatical) and is not available anymore suddenly? Things would come to a halt quickly.
This is a problem if someone on your team (or yourself) is a single point of failure. There are two main aspects that I find most important but there are probably some more aspects that are true for specific situations:
Capabilities
Does one person hold the only access rights to specific parts of your system, or is a person the only one having the authentication details for something. You would not want to be locked out of your own system
Knowledge
Is one person the sole expert in one area, where other team members do not know how it works. This makes the expert a critical dependency and it is very hard for other people to take over, because the knowledge is too concentrated.
Ask yourself
Can you think of something in your current team and application where you would get problems if someone would get hit by a bus? Especially ask yourself, where would problems arise if I would be gone suddenly?
What to do about it?
You have identified some things where you have critical dependencies. Great, so how can you alleviate them?
Regarding authentication details, it makes sense to think about your access rights concept so that there is not one overall admin. But of course you would not also want to give everyone full admin rights.
To tackle the problem of knowledge concentration there are three ways to go:
- Reduce complexity: so lesser knowledge is required to understand a component
- Documentation: To provide an easier knowledge transfer document all processes and things you are working on and more importantly keep it up to date
- Cross training: do some pair programming to encourage thinking about other areas of your system
Also thinking about the bus factor is not a one time thing, but an ongoing tool to assess risks within your development team, especially if you are working in a small team or startup
Top comments (0)