Some years back, while working as a lead on a product team in a large corporation, I decided to take a much-needed break and go ice fishing. I had never been before and wasn’t sure what to expect, but I was looking forward to getting away from work and unplugging for a while. It was exciting to know that there would be no Wi-Fi or cell service on the ice, so I wouldn’t be able to check in on work, even if I wanted to.

I met at a friends, we loaded up and set off on a freezing January morning, I grabbed my laptop in case of an emergency. After a two-hour drive to the lakes edge. As we were about to drive out to the ice house, my phone rang. It was my scrum master, and they had backed out a recent release from production due to a major bug. They had been working on it all morning and needed my help, or the majority of the team would be “blocked.”

We backed up the truck and pulled into the restaurant next door, where I pulled out my laptop and got to work.

Taking a step back

To explain how I got into this situation, I need to provide more context about what had been happening recently. The team I was a part of, which consisted of engineers, had undergone considerable turnover. This coincided with tight deadlines for the project at hand. As the team leader, I had two primary responsibilities: to onboard the new engineers and to ensure the timely completion of the project. To do this, I delegated simpler tasks to others while tackling the more complex aspects of the project. By doing so, I was able to address any concerns from the new team members while freeing up my own time to focus on the more significant components of the work. I fell into a trap that many have experienced, and which is well-known in the community.

The Bus Factor

the bus factor, 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. src

In my case the team had a bus factor of one, me. After learning the hard way, I have since made a conscious effort to avoid them in the future. Here’s are some ways I’ve found to improve the bus factor.

Write Documentation

Write documentation as you work and providing an overview, along with cross-links to external resources for more detailed information.

Parallel Development

When researching or developing new technologies for the team, two individuals take on the same work. They can work together or separately, however they prefer. When they finish, both present their findings and walk through their solutions.

Knowledge Transfer Session

A technical session where a contributor takes the team through their work at a high and low level.

Plan for Risk, Not Just Speed

Rotate through work, it might add a little time in the short term. It’s the only way to truly increase the bus factor.

Code Review, Not Syntax Review

Lean into code reviews. Share notes, screenshots, and alternative ideas when it makes sense.

Double Up on Planning

Bring in a second developer for their perspective when planning more future-facing work.

Back on Ice

When individuals are isolated, a low bus factor can exhibit various other symptoms. These include a lack of diversity in perspectives, which can hinder the drive for better outcomes. Employees may become disengaged or uninterested in their work, and only focus on a narrow set of tasks. This, in turn, can lead to fewer opportunities for career growth. Although prioritizing speed may seem appealing, and some team members may prefer to work in isolation, it’s crucial for the team to take measures to prevent such silos in the long run for the greater benefit of the organization.

Regarding my ice fishing trip, I was able to debug the issue and push a fix to product. Once the issue was resolved, my plans for the afternoon resumed as normal. However, this experience served as a reminder that unforeseen circumstances can occur, and as a team, we must remain prepared to address them quickly and efficiently