This is Gerald Cotten, the founder of QuadrigaCX. QuadrigaCX is a cryptocurrency exchange that was launched in 2013 to give Canadians a better option to buy Bitcoin. It grew quickly, amassing $190,000,000 in investment. On December 8, 2018, Gerald died, taking with him the password for the cryptocurrency wallets. By design, without this password, those wallets are inaccessible. $190,000,000 locked away forever.
On a related note, as of this writing, 25% of the Bitcoin block chain, an estimated $16 billion dollars has been lost due to malicious activity and people forgetting the password to their wallets.
New term: bus factor. Bus factor is defined by Wikipedia as “…the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel.” QuadrigaCX’s bus factor was 1 – about as low as you can get.
A low bus factor isn’t necessarily a bad thing – particularly in the early days of a startup if you are a team of one building your product. However, as the company grows, acquires users, and builds a data repository, you need to make sure you are managing your risk properly. One aspect of that is awareness of the bus factor in your organization.
So what’s yours?
What is the one piece of data, password, or knowledge that only exists in one person’s head?
Now an employee does not literally have to get hit by a bus. There are a variety of reasons a team member may no longer be able to work on your project. It could be a short-term absence like they get sick, go on vacation or other leave of absence. It could be long-term. Maybe you terminated them, or they suddenly quit. I’m going to call this “getting bused out”.
I have been often surprised by encountering the scenario where a developer in a smaller startup holds the digital keys to the company. When coming into the company to troubleshoot an issue, I needed access to the server or source code. A typical response might be, “I need to get with Bob, he’ll get you the password.” Not good! What happens if Bob gets suddenly bused out?
Now fortunately for many instances, you can reset passwords, rebuild data, or reconstruct business processes. You may even have to go through a process with the third-party vendor to prove your identity and ownership, and they may be able to restore access for you. However, a process like that could cost you hours or days where you are unable to access your system.
Let’s talk about a few more scenarios –
Your developer is writing a new feature for you but they haven’t been regularly saving their work in a source code management system. They get bused out. Their laptop is encrypted, no one else knows the password. All your new code is gone. Back to square one for you.
How about this? An assistant manages a social media account for your business. You don’t use a password manager. They get bused out. Did they use their own email for the account? If their absence is permanent, do you have a way to access or forward their email?
Imagine that you’re team has launched a new feature for your product. A couple of days later you have a critical fix that needs to go out. However, your senior developer got sick and is out for a few days. Unfortunately, that is when you realize that they are the person that typically deploys code and no one else on the team is capable or confident they can do it correctly.
It’s all about risk management. Some risks might be acceptable but at least be aware of them and offset them with backups or contingency plans.
So how do you address points of risk in your organization that contribute to a high bus factor?
Document. If you only have one person working on a particular project, make sure it’s being documented and necessary access privileges are stored in a well-known location or shared with you.
Rotate. If you have that one person who has critical knowledge of a business process, rotate the task that makes use of that knowledge among multiple people. This practice will force knowledge transfer as people unfamiliar with the task face challenges and unanswered questions.
Automate. Institutionalize organizational knowledge with automated processes which become living documentation. In our previous example of a critical fix, implement an automated process which deploys code for your application. The process will always be up to date as it is the only way in which code is deployed for your application.
How do you know what points of risk need to be addressed?
Inventory. Take an inventory of all third-party software, system access, and business processes. Make sure you have all the usernames, passwords, or email address access to log in. Regularly update this list and audit these things.
Now a quick note to founders. As the founder, particularly if you are a sole founder, you have many inherent risks. You are likely to be the sole user or owner of accounts as well as have sole access to payment details and funds.
I use a password manager which contains all my online accounts and passwords. The master password is stored offline in a very secure location. In the event that I get bused out long-term or permanently, someone is able to access and provide the password to a trusted technical partner who can work with responsible parties to address various business concerns.
So that wraps us up for today. When you start a new project or bring in a new tool, consider what risks it might bring that could lower your organizational bus factor.