As those of you who have been reading my articles can obviously tell, I'm a huge fan of small to mid-sized teams. Regardless of whether you're talking about standalone teams or those incorporated into larger organizations, there are some huge advantages to keeping them lean and efficient. However, I have to be realistic and say it's not all wine and roses. While I do think the positives far outweigh the negatives, there are certainly negatives that need to be addressed. One of the most glaring of these is single points of failure. With larger teams you can build in redundancy, making it easier to absorb those unexpected bumps in the road.
What do you do when someone goes on vacation, and they're the only one who knows how to perform a specific task? What if they go on maternity or paternity leave for a longer period of time? If you're given enough lead time, you can attempt to adjust. But what if the absence is immediate and unexpected like a death in the family or sudden illness? If you haven't planned ahead for how to deal with this, progress can grind to a halt for the entire team. How do we deal with this? Well, I think there are three main legs to this proverbial coverage stool.
The first of these legs is the obvious cross-training, but how does one go about that? One thing I've done with my last couple teams is create a skills/task spreadsheet. The concept is simple. Each row represents a skill or task necessary for team success. Each team member is represented by their own column. Now have each person go through that list and put a one for items they are somewhat comfortable with and a 2 for those they are very comfortable with. Blank cells indicate no knowledge of the skill or task. I do color code these, with cells containing a 1 colored yellow, and cells with a 2 colored green. It allows me to evaluate things quickly, but I'd hardly call it essential. Don't overcomplicate this by making people prove their competence. This is entirely a self-reporting exercise. Also, don't overcomplicate it by employing some fine-grained rating system. Stick with the 1's and 2's I mentioned. That will do just fine. I can use this sheet for a few things, but when it comes to identifying things that need cross-training, it's simple. If a row has only a single 2 in it, this should go on the list for cross-training. If there are no 2's in a row... well, you've got a bigger problem to deal with then.
The second leg is permissions. It doesn't matter if someone knows how to perform a particular task if they don't have permission to do it. This is especially troublesome for technical teams operating in multiple workspaces and environments. Invariably, one person ends up being the only one capable of logging into a particular platform. I've seen this happen even when a concerted effort is made to stop it. People just forget about that isolated corner of their world that ends up stymieing the whole team while they're missing. Yes, we want to follow the principle of least privilege, but least privilege doesn't mean no privilege. This may be controversial, but I believe the sweet spot is to have three people with admin permissions for any given environment. With larger organizations, you have more options since you might have a dedicated IT team to deal with issues, but remember, we're talking about smaller teams here. Of course, you do need to build logging and auditing capabilities into the system, but I'm glossing over those because it's not the focus of this article.
Of course, I'm never going to suggest you have a list of usernames and passwords in an unencrypted, centralized place, I would suggest that, just like the skills spreadsheet I mentioned earlier, you might want to create a spreadsheet that tracks your environments and who has access to them. Be very careful here, though. This should be very generic and not provide the keys to the kingdom if it falls into the wrong hands.
The final leg of our stool is Work Instructions. I'm not going to go over these in much detail here because I've got an article devoted to this topic coming in the future. The point is that they allow you to capture the detail of routine and common tasks that should allow virtually anyone on the team (provided they have the permissions) to complete many tasks without being a subject matter expert. This can be a daunting endeavor, so my advice is start slow. Find a central location for these documents and as people perform their day-to-day duties have them create rudimentary work instruction. You can always go back and refine them later.
Am I saying that, by following these three suggestions, you can eliminate the single point of failure problem with smaller teams completely? Of course, not. But I am saying that this will at least alleviate some of the pain and let you focus on all the advantages that small teams bring.