Picture this. You’re the manager of a software team. The team is working on the MVP for a new SaaS product. Your company, still young and growing, has put the “aces in their places”. Considering the company’s size, team members own particular sections of code. The frontend engineer focuses on JavaScript. The backend team member is heads down on Python. DevOps keep the product humming. The team is making great progress, and is nearing release.
One night, as you settle in for the evening, your phone rings. It’s one of your senior engineers. Bad news. One of your key team members was injured in a car accident and will be out of office for the foreseeable future. What do you do next? Is the team able to mitigate issues, or are they facing an uphill battle?
The concept at hand is often referred to as “the bus problem”. Key personnel on a project are hit by a bus. With their loss, the team also loses a breadth of institutional knowledge and insight. The team is left scrambling to cover the loss.
Managers, especially those of small teams, are often placed in compromising positions that naturally encourage the bus problem. External constraints force their hands. Deliverable schedules favor technical experience. Budgetary concerns limit excess labor. Business demands dictate operational policy.
Fortunately, teams will rarely experience such grave circumstances as an employee injured in a tragic car accident. More commonly, “the bus problem” manifests when an employee submits his or her resignation. The team is suddenly left scrambling, trying to condense months or years of lessons learned into a few days of knowledge transfer.
No matter the outward cause, the underlying issues remain the same. The bus problem is the byproduct of a single point of failure system. Naturally, this becomes problematic. If one team member is disposed or delayed, the effects are felt throughout the team. And with only one person in tune to the functions of that role, rectifying delays or dispositions becomes that much harder.
Beyond lack of oversight into critical roles, the bus problem also forms functional silos. Team members withdraw from the team and only work on their scope. “Not my job” becomes a common phrase. The team stops being a team. When the team stops working together, releases will slow. The whole system falls apart.
So what can we do to mitigate the bus problem? In an ideal world, we would hire multiple developers to fill roles. With more budget or more time, we would implement a peer programming policy. In either case, we would remove the single point of failure. Business constraints often limit solutions, leaving us to mitigate problems in other ways. So how else could we prevent the bus problem? We could:
- Implement a code review process. By getting a second set of eyes on code, the team can avoid code smells and anti-patterns that would impede transition.
- Encourage cross-functional communication. While the back end engineer may not know the idiosyncrasies of JavaScript, they assuredly know underlying engineering patterns and approaches. Notwithstanding syntax knowledge, their engineering insight is invaluable.
- Require documentation to communicate functionality. While good code is often self-documenting, it cannot possibly communicate the assumptions made by the author. By requiring code comments, the author can add context and explain assumptions, further framing the code.
- Enforce testing. With an adequate test suite, the team can make changes to pieces of functionality with confidence.
The bus problem is a real thing. It happens to companies all the time. But it doesn’t have to. By increasing communication and removing single points of failure, teams can avoid the problem all together.