Most teams consist of smart people, and some team members really excel at their work. The optimist sees a strong individual. The pessimist sees Key Person Risk (KPR).
KPR is often cynically dubbed "the bus factor"—what happens when your star player gets hit by a bus? The realist needs to prepare for this.
While losing your top gun to a bus accident is fortunately rare, the trigger doesn't have to be nearly as dramatic. People get offers they can't refuse. They might take an extended holiday. They might be out for pregnancy, medical reasons, or paternity leave.
When we uncover Key Person Risk during due diligence audits, the advice is always simple: increase knowledge sharing. Like many recommendations, this is easy to say but hard to do.
Let's say you have a senior engineer at the heart of your team. They are a great full-stack developer and also your specialist at all things AWS. They're the only dev who can maintain and improve the infrastructure. Such a specialist is a clear KPR.
So how do you start tackling this?
While you could send your entire team on an AWS course, there is a difference between book knowledge and experience. Even after getting a certificate, most AWS rookies will feel insecure upgrading the production database – and rightfully so. As a result, it will still be that specialist doing those big interventions. Nobody really learns anything.
A pragmatic way of getting started is to agree with the team that from now on, one developer is no longer allowed to make changes to the infra. All AWS work will have to be done as a mob programming exercise under the supervision of the specialist.
They can explain the steps and walk the team through each of the hurdles. They can answer questions and give context. But under no circumstances are they allowed to change the code or touch the AWS console. The specialist becomes an advisor who leaves the coding and documenting to the others.
This approach creates a shift in mindset. AWS is everyone's problem now. Gone are the days of taking the path of least resistance and always delegating it to the specialist. While those first mobbing sessions will feel wasteful and slow, knowledge will be transferred to the rest of the team, and documentation will improve. After a while, team members will feel comfortable picking up routine infrastructure tasks on their own.
There is no quick fix to sharing knowledge, but there is a simple way to start right away.
If your team has a specialist dev who can't take extended holidays, give it a shot. Turn them into an advisor and watch the knowledge-sharing happen in real-time.
Member discussion