Can We Measure "Hit By the Bus" Risk in the Enterprise?

I know you've heard or even said, "what happens if you get hit by a bus?!" when discussing individuals with critical knowledge, but have you ever thought to measure the “hit by the bus” risk in your IT organization? It might be impossible to know exactly what this risk looks like but we can take a step back and take the temperature of the teams to get an idea. Humor me a bit here and take some time to think about what overall knowledge risk might look like across the org.

What's Your "Hit By the Bus" Knowledge Risk?

How much does your organization rely on “tribal knowledge” to operate day to day? And how much critical knowledge exists in this same category? If you’re able to quantify it, this might be what your “hit by the bus” risk factor actually looks like.

Ok, it may be a little gruesome if you think about it and you might prefer to use the “wins the lottery” analogy to provide more positive imagery, but the result is the same: You’ve got some risk that feels a lot like organizational technical debt. It exists to some degree in every organization and I think we should do our best to take an honest look at where this risk exists in our teams so we can take steps to change the culture. Because even though we're likely discussing gaps in technical knowledge, this is ultimately a cultural challenge.

I'll first admit that I believe that this exercise is really a gut check and a thought exercise but sometimes it helps to have another way to look at a problem.

At a high level, my "hit by the bus" measurement attempts to capture some of the risk associated with key individuals in an IT organization suddenly becoming unavailable (ok, you can use your imagination on how that happened). This involves identifying critical knowledge holders and assessing the impact of their potential absence on the team and organization. The exercise itself is ultimately just a health check across each individual and team, and then calculating the overall organizational risk.

One thing I'd like folks to come away with is that just because someone has a ton of experience and is a "super senior team member" doesn't mean that's where the risk is necessarily.

This could be something your team does over a lunch-and-learn workshop or as a team-building activity. By acknowledging this problem exists to some degree in every org, we're going to be able to help our teams take steps to correct it.

Calculating Your "Hit By the Bus" Risk (HBBR)

Let's get started. We'll need to do the following to calculate HBBR across the org:

• Assign Knowledge Values to Team Members
• Calculate Individual HBBR
• Determine your Knowledge Redundancy Factor
• Calculate Adjusted Individual to Yield Team HBBR
• Calculate Average Organizational HBBR

1) Assigning Knowledge Values for Individuals

Assign a knowledge value to each individual based on their role’s criticality. This can be done through peer reviews, manager assessments, or self-assessments. We're just looking to take a quick pulse to get a value we can use in our calculations. For my purposes this is an integer value between 1 and 10.

2) Calculating Individual "Hit By the Bus Risk"

To calculate the HBBR for specific individual, we estimate their critical knowledge relative to the total knowledge that may be exist across all team members.

Here the Critical Knowledge Value or (CKV) is the importance of the knowledge held by an individual, which can be a score based on the criticality of their tasks, their unique skills, and their role's impact. If they have "more critical knowledge", they get a higher score. It's fine to estimate here and you may give folks more points for their experience with a specific technology or time with the organization.

You can score this yourself or ask team members to anonymously rank themselves or their team members. You don't need to know names to get this (although you probably already know them) but you are looking for a measurement.

The Total Knowledge Value (TKV) is the sum of CKV for each of the team members. Once you have this number you can calculate the initial individual HBBR. This will yield an individual percentage value of the individual's effective overall knowledge within their team.

HOWEVER, while this is good to know it may end up being somewhat of a red herring. It could just be the most senior engineer. The person who has the most knowledge, while they may be missed if they disappear from the team, may not cause the most impact to day to day work if they left. It's a good exercise to see where the weight of responsibility exists either way.

3) Determine the Knowledge Redundancy Factor (KRH)

The initial percentage HBBR calculation might tell you who "knows the most" or potentially who seems the most valuable, but losing that individual may not be the largest impact to the team. Often these are high-performers and it's possible they have done a great job distributing their knowledge to others on the team. To take into account "tribal knowledge" or knowledge that isn't distributed well amongst the team, we need another factor here. Let's call it the "Knowledge Redundancy Factor".

Here, we are performing a redundancy assessment by calculating if the individual's knowledge is shared amongst others on the team. KRF = 1/N where "N" is the number of people who share the individual's critical knowledge. If their knowledge is distributed well, this calculated number will be lower.

For the KRF, we're looking for a couple things:

1. Potential Unique Knowledge: If an individual holds unique knowledge (i.e., no one else shares this knowledge), then N = 1

2. Limited Shared Knowledge: If the knowledge is shared with one other person, then N = 2. The KRF should reflect that the knowledge is less unique but still critical.

Once we know if the team's knowledge is shared, we have a better idea of what the true risk factor is.

4) Calculate Adjusted HBBR to Yield the Team Level HBBR

To calculate the Individual Adjusted HBBR (HBBR_individual) we multiply the individual HBBR by their KRF score.

To find the team HBBR, I select the highest Adjusted Individual HBBR as the team HBBR:

This is something you could choose to adjust for yourself but I don't think we need to make it more complicated than it needs to be.

5) Calculate Organizational Level HBBR

This is the easy part. I think ultimately it's just an average score for the organizational HBBR.

Let's see what this looks like in some example calculations.

Example HBBR Calculations

Individual Level:

By adding up the individual Critical Knowledge Values from each of the team members we can get the Total Knowledge Value. We'll use this to get the unadjusted individual HBBR percentage.

Member A: CKV = 8; HBBR = 8/36 = 0.222
Member B: CKV = 5; HBBR = 5/36 = 0.139
Member C: CKV = 10; HBBR = 10/36 = 0.278
Member D: CKV = 7; HBBR = 7/36 = 0.194
Member E: CKV = 6; HBBR = 6/36 = 0.167        

As mentioned before, just seeing who knows the most isn't enough. We need to account for knowledge not evenly distributed amongst others on the team. We'll find whomever has the highest adjusted HBBR impact and consider that the team's actual risk level.

Knowledge Redundancy Factor Calculation:

Assume the following knowledge distribution:

• Member A: Knowledge is distributed via 2 others, N = 3
• Member B: Knowledge is not shared, N = 1
• Member C: Knowledge is distributed via 3 others, N = 4
• Member D: Knowledge is distributed via 2 others, N = 3
• Member E: Knowledge is distributed via 1 other, N = 2

Calculate KRF for each team member:

KRF_A = 1/3 = ~0.33 
KRF_B = 1/1 = 1 
KRF_C = 1/4 = 0.25 
KRF_D = 1/3 = ~0.33
KRF_E = 1/2 = 0.5         

Calculate Adjusted HBBR:

Adjusted HBBR_A = 0.222 x 0.33 = 0.073
Adjusted HBBR_B = 0.139 x 1 = 0.139
Adjusted HBBR_C = 0.278 x 0.25 = 0.070 
Adjusted HBBR_D = 0.194 x 0.33 = 0.064 
Adjusted HBBR_E = 0.167 x 0.5 = 0.084        

By adjusting for unique or unshared knowledge, we can see that Team Member B at 14% has the highest potential "hit by a bus" impact. For my purposes, I chose to to take this number as the promoted team value to explain the potential risk.

Team Level HBBR:

To find the team HBBR, I select the highest adjusted HBBR as the team HBBR:

Team HBBR = max(0.073, 0.139, 0.070, 0.064, 0.084) = 0.139         

In this example, we have a value of ~14% risk for this team due to the individual with unique knowledge. We could have had lower risk if there was shared knowledge across the team.

Organizational Level HBBR:

Assume the adjusted team HBBR scores for three teams:

Team 1: 0.139
Team 2: 0.150
Team 3: 0.120        

While I chose the max adjusted HBBR for each team HBBR value, I chose averaging team HBBRs for the overall Org score.

Overall for the org it's still effectively around ~14%. This isn't such a bad score here, but it may be much different in your organization if team collaboration is limited.

Ok, that was fun. So now what?

The goal here is to take time to think about where you've got the most siloed knowledge and help the organization know you take this problem seriously.

These calculations are certainly a bit of a "best guess" metric but it provides us with a way to make what is likely a largely subjective metric an objective discussion. The risk associated with isolated critical knowledge in the organization is real. We can use this as a reminder to take time to understand potential vulnerabilities or gaps across teams and once we know where these gaps are, we can take steps to address them. In many organizations this is improving documentation, increasing collaboration, and building more automation as part of our day-to-day work.

Thanks for taking time to run through that little exercise with me. My aim was to just get us thinking about ways to discuss how tribal or tacit knowledge impacts our organizations. I'd love to discuss it further so feel free to reach out any time!