The Bus Factor

I’ll be Gone in a Day or Two
GIS
Python
Metadata
Career
Published

June 16, 2021

This article was originally published in URISA’s The GIS Professional Issue 301

The Bus Factor is a darkly humorous turn of phrase describing key person risk that arose from software development and the consequence of losing project members that possess critical skills/knowledge. Put in cruder terms: if you were hit by a bus tomorrow, who could do your job, or even know what your job was? While the metaphor is grim, it can accurately describe the finality of losing a team member with whom you had no contact with outside of work. The results of such a separation can range from mildly inconvenient to absolutely devastating in terms of systems going offline, projects stalling out, irreparable breaks, and deliverables undelivered. We’ll discuss strategies to mitigate these risks across the spectrum of organizational sizes along with instructions on using widely-available technologies.

The Loneliest Number

The term is meant to quantify the number of project members that would need to be absent to create chaos. A factor of 1 would be the riskiest model, with each increase providing substantially more protection to your organization. However, with most GIS shops being a one-person operation, it may seem that your Bus Factor could never be greater than 1. At this basic level, there will almost always be a disruption to the flow of work. Despite a quick turnaround in hiring, the interruptions could span months. It doesn’t take much to imagine the horrors of crawling through an unknown network, digging into the husk of a former employee’s Outlook data file for project archives, or being emailed a pdf map to replicate and then searching through mounds of “Export_Output”-style shapefiles and map templates with names like “final2_maprequest_new”.

At this size of organization, one of the best outcomes that we can hope for is mitigation through documentation. While not the most exciting of topics, project documentation is vital and plenty has been written about it by people far more knowledgeable than me. I’d like to hit on some of the highlights and ethos of where to spend your energy in the realm of documentation.

For digital work, data is both nonrival and has near zero marginal cost to replicate; meaning, the largest cost to an organization is the development of the deliverable, afterwards it can be used and maintained with minimal upkeep. As such, keeping track of template files is incredibly important– –this is relatively easy with an MXD or APRX but requires additional effort with documenting commercial off-the-shelf (COTS) products that may have a large degree of customization (I’m looking at you ArcGIS Online). With template files, one of the greatest dangers is not updating source destinations after a major infrastructure upgrade; think about the last time your GIS database had a name change or when you migrated networks?

The other foundational rule of documentation is one of the most overlooked areas of data governance generally, metadata. Your data needs a dictionary. It needs an intent. And if you aren’t aware of the data provenance then how will it be authenticated, updated, or re-created? If you would like a slightly terrifying exercise, try running this meta-data dump

gist.github.com/FeralCatColonist/7504ab0c380542f12220fe62142082c1

on your GIS repository and emailing it to your supervisor. Again, the goal of a one-person shop is not to prevent disruption but to ask yourself, if a competent replacement was hired, would they be able to step into this role with minimal effort?

A photograph with a pencil-sketch filter showing a person walking in front of a trolley car

A Broader View of Indispensable

Who on your team represents a single point of failure or bottleneck? As a thought experiment, go through each member of your team and enumerate their projects and skillset. If you’re having trouble with either of those, or their skillset is unique, you’ve found a Bus Factor of 1. This can be repeated for known deliverables or other statutory responsibilities. The management types among us practicing a “need-to-know” style represent a Bus Factor of 1 as well. While Saturday morning cartoons taught me that knowing is half the battle, the more exciting part of this story is what to do next.

Ideally, your Bus Factor should be as large as your team. If this strikes you as a hot take and you want to talk to me about the merits of specialization or titled roles, feel free; I’ll respond with this: you should be investing in your employees. Full stop. Aside from that, there are definite benefits for having a 360-degree view of your unit and how it interacts with the rest of your organization. This doesn’t mean that the efficacy of everyone’s skillset needs to be the same, but everyone should be familiar, and able to interact, with a workflow if the need arises.

There are many ways to increase the Bus Factor for common deliverables: lunch and learns, side-by-sides or shadowing, and how-to videos. The lunch and learn serves multiple purposes, it works as a team building activity, practice for presentations, and familiarizes staff members with a workflow; in the Before Time, this could be a fairly fun event with catered food from a local restaurant. In the Pandemic Time, this becomes a remote affair with lunch brought to you by your pantry. In the New Normal, a side-by-side or shadowing becomes a little less cramped as individuals don’t need to physically huddle around a desk and everyone can have a front seat using a screen sharing technology. How-to videos are great and we’ll delve into that in the companion video! Spoiler alert, it’s not complicated and the tools to do it are free.

In terms of programming and knowledge work, increasing the Bus Factor takes a bit more effort or rather, a dedicated framework. My recommendation here is to adopt an agile methodology that makes use of the following artifacts: personal Kanban boards, code reviews, and version control. A publicly visible Kanban prioritizes what’s important and allows the collaborative and inquisitive team to cross-train on new projects that enter the workspace. While a common practice in software engineering, code review is unheard of in most spatial departments. For the uninitiated, code review is a public assessment of programming scripts in terms of style, patterns, and overall usability. It’s an excellent way to inform team members about the mechanics of an automation and to make sure that coding is consistent and legible amongst peers. This goes to the heart of the Bus Factor: your scripts are useless if the only person who knows how it works is you. Finally, version control attempts to cushion your code base against significant errors by providing provenance; when an item changed and why, and the ability to rollback your code to a point where it actually worked. You should be using Git. It’s easy to learn and there are a variety of platforms to choose from. Consider also opening your source code (through platforms like GitHub or GitLab). It’s a way to collaborate across organizations and to benefit beyond the numbers/talent of your immediate team.

An Ounce of Prevention

Another photograph with a pencil-sketch filter showing a person walking in front of a trolley car

The axiom attributed to Benjamin Franklin places a 16:1 ratio on preventing a disaster as opposed to the cost of responding to it; in a world of mega-fires, pandemic, and Snowmageddons that ratio seems somewhat provincial. In terms of our own organizations, the disruption of any instantaneously available deliverable incurs an astronomical cost above what was effectively zero. As horrifying as these worst-case scenarios may be, people are pretty great at being complacent. From a biological perspective, it probably helps us to live longer if we’re not in a constant state of anxiety about the future. Our underlying motivations for increasing our Bus Factor do not need to be rooted in these sorts of negative emotions, and can instead be undertaken in a spirit of commitment to transparency and life-long learning.

One of the great tragedies of the digital revolution is the abuse of the principle of least privilege, restricting access to data and programs unless ordained as necessary for a certain user or workflow. Aside from over-securing data and inhibiting innovation, this process tends to bleed well beyond the system architecture and deprives an organization of its greatest resources: access to human capital. Transparency is both prevention and cure for this state of affairs. Obviously, building a culture of transparency is harder than maintaining one. Some ideas to increase transparency are daily standups, personal Kanban boards, weekly one-on-ones, and open-door policies for executive-level meetings. The undercurrent here is a level respect for employees at all levels of the organization and the idea that contributions can come from anywhere. These contributions don’t happen in a vacuum, work must be visible!

During this Second Machine Age, some of the defining hallmarks are velocity, volume, and variety of information. If there was ever a time when a person could satisfy themselves with never learning anything new, that time has most certainly passed. Aside from the benefits of personal actualization, our current environment demands that we constantly learn to maintain our position within it. At your organization learning should be encouraged, subsidized, and celebrated. The absolute worst outcome here is failing to invest in your employees; a self-inflicted anemia, starving them of new knowledge and skills. In the pandemic, we have been inundated with an enormous amount of remote learning opportunities that were previously restricted to paid, in-person offerings; a future struggle will be to maintain our access to these resources when the masks come off.

With the end in mind, both figuratively and literally, the Bus Factor is less klaxon and more health gauge for your organization. While some areas of your organization may be quite technically advanced, your overall maturity is low if those capabilities are based on personality and not institutionally defined. The paths to increase your Bus Factor follow many best practices of winning organizational cultures: personal growth, collaboration, and effective communication. In that sense, the Bus Factor is less about the destination and more the journey. Taking the time to document your work, working well with others, and learning new things, saves time in the long-term and fosters a more attractive workplace overall.

An animated gif of several photographs with a pencil-sketch filter showing a person walking in front of a trolley car

Companion Video Demonstrating Common Video Documentation Workflows https://www.youtube.com/watch?v=S-biFgYKdNY