Is there a ‘single point of failure’ (SPOF) on your team?
People as SPOFs and how to reduce risk
Simply put, a single point of failure (SPOF) is any piece of technology hardware or software, a design flaw in a product or any other component in a system; and if this piece fails, it causes the entire system or process to fail. This creates significant business risk.
People can also be SPOFs.
How many times have you seen it happen that a colleague announces that they are leaving the company. It sends everyone around scrambling to learn and absorb what they can from the individual before they move on to a new chapter. In this situation, at least you get a heads-up. But, what if you don’t?!
That’s right! SPOF risk is around us much more than we notice. But, it can be reduced with some planning and purpose.
This article is about People as SPOFs, which is less talked about than tech-related issues.
Let me share three true people-SPOF stories.
True story 1-
Setting: Don’t know but my guess is that it is a very small company
SPOF: Single point for data access
I recently hosted a webinar on a data topic. One of the comments from an attendee was that the sole data person in their organization left abruptly and now they didn’t have anyone who could fix their data access issues - aka SPOF! This company did not know how to get out of this one. The likelihood is very high that this is a very small company or team with limited resources to throw at a costly solution.
True story 2:
Setting: Medium-sized mobility company
SPOF - Single point for writing code
At one point in the recent past, I was a part of a small team of consultants working on developing a data product for a medium-sized mobility client. There were two senior and highly experienced programmers on the team. Each of them was responsible for writing code for a specific part of the program.
One of the them diligently stored code on the shared drive and willingly walked anyone who asked through it. The second programmer wrote the code in a different programming language, saved it on their personal hard drive and never offered to walk anyone through it. Due to limited resources and time, nobody asked to see it either and it slipped through the cracks for a very long time.
When it came time to put the different pieces of the project together and deliver, this second individual’s actions led to major delays and almost-failure of the project.
And just when you might be thinking this happens only in small-ish companies or teams, wait, there’s more!
True story 3:
Setting - Large media company
SPOF - Single point for running a predictive model in real time
I was a consultant on a project in this company that required providing real-time insights for a few weeks. After the first week went by smoothly, the team member who was responsible for running the predictive model and sharing results immediately with senior executives, had to attend to a personal emergency.
Not his fault. But, that meant that the rest of the team, which was dependent on that model to influence urgent decision-making, had to pause for the rest of the day and missed the deadline by several hours.
Why does this happen?
No one plans to have just one person be in charge of a key task. There’s often intention to do it differently. Yet, many times action is taken only after something breaks down. Very rarely are the reasons for these events extraordinary. They are, in fact, pretty basic. Like the ones listed here.
Insufficient resources
Failure to delegate or share
Poor planning
Poor leadership
Lack of experience or inadequate employee training
“We will get to it later” - but later never comes on time
Assuming that someone else knows what’s happening
This won’t happen to me/us
Lack of standardized processes or practices across teams
How can you avoid becoming a SPOF or prevent your team from having one
👉Documentation
This is the simplest way to keep everyone around you in the loop - to record or document all tasks with detailed steps that you plan to complete and then actually complete.
Here are some best practices for project documentation.
Create and save documentation on a shared drive or app where all your team members can easily access it. Set them up with credentials if that is a required step for access. Ask users to test access to confirm that they can use it. This final point is super important. Or believe you me, you only discover that someone cannot access it when they urgently need it.
Organize the documentation by topic and sub-topics so that users can easily drill down to and quickly find what they are looking for.
Provide all details of the project including plans, tasks, prioritization and progress.
The primary documentation should be in non-technical language targeted to a general audience.
But, any and all code or technical details should also be described and maintained as-is in dedicated sections. The goal should be that if anyone were to copy-paste that code and put it in a program, it should produce the same output as the original code. There are specialized platforms available for code and technical collaboration such as GitHub and others. These should be integrated or at least linked to in the primary documentation.
Where possible, include your reasoning for making key decisions so that users can understand the ‘why’ behind a certain choice.
Assign someone to be in charge of checking that all relevant information has been entered by all users in a timely manner.
Make project team members contribute information that they are responsible for and hold them accountable for it by setting up check-ins on the calendar. Better yet, schedule a time on the daily or weekly calendar for each person to add to the documentation. This makes it a habit, and a great way to build consistency. If you wait too long to record something you did, the more likely you are to forget key details.
Maintaining documentation should ideally be a part of the onboarding process for a new team member so that they can start contributing immediately.
Save documentation in multiple locations if there is no in-built back-up provision.
AI is making it easier and faster to create documentation through voice-to-text, text-to-video and other modes. Use AI tools so that you can save time on this extremely important activity.
👉Optimize your team for success
Assigning multiple team members to the same tasks is neither time-efficient nor cost-efficient. That said, SPOF risks can put your deliverables and business results in jeopardy. There are some ways to find the middle ground. In fact, the approaches mentioned below offer bonus benefits in that they can enhance learning, improve performance and increase overall productivity.
Like the practice of an understudy in live theater - i.e. someone who learns the primary character’s role and is able to step in at short notice - you can assign task partners and schedule 30-min weekly knowledge-sharing sessions between them. Only one person actually completes the tasks but shares and shows all steps taken to the ‘understudy’ partner. The partner should ask questions to make sure that they understand all the underlying details and be able to complete the same tasks themselves, if required.
To take it one step further into this approach, you can cross-train team members and introduce team rotation. Through this, individuals work on certain tasks for a fixed length of time (usually in months to give each person enough time to absorb and deliver). At the end of that period, they rotate and work on a colleague’s tasks. To execute this successfully, you need to ensure that the folks in rotating roles have similar skillsets and training. They should also be engaged in knowledge-sharing sessions as mentioned in the point above in the time leading up to the rotation.
Keep in mind that none of these steps are easy to implement mid-way through a project. It can be done but it causes some amount of chaos in the short-term.
Therefore, a best practice is to plan for it in the beginning stages of a project and educate everyone on the team about it before kicking it off. Make sure you create schedules for knowledge-sharing and a timeline for rotation to set expectations and have things go smoothly.
👉Pair Programming
This one pertains more to programming and developer roles. I first came across it through Lenny’s Newsletter. It involves intense collaboration to write code together via one workstation. At any given point in time, one person is writing the code and the other is reviewing and giving feedback in real time.
At first sight, it seems like doubled effort. Proponents of this approach contend that it improves code quality, reduces errors and immediately solves problems, all of which actually make it faster and more efficient.
Still, there are others who believe that it only works for complex projects and requires good camaraderie between the paired colleagues. Nevertheless, it is an approach worth trying out to see if it could work for your team to reduce SPOF risks and get its other benefits.
Final Thoughts
None of the ideas mentioned here are mutually exclusive. Documentation should be a must. In addition to reducing SPOF issues, it provides a relatively easy way to do checks and balances for your project and maintain a record of processes and procedures. Shadowing, knowledge-sharing and pair programming can be introduced to your teams depending on your resource availability and business context.
Finally, SPOFs can create blockers for your project and reducing those risks are a worthy effort.