How I’m tackling the Bus Factor problem as Digital Gravy’s CTO

What is a Bus Factor, and Why Does it Matter?

In case you’ve never heard the term, here’s the Wikipedia’s definition:

The “bus factor” is 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.

In simple terms, when your team is reduced to this many members, your project becomes at risk. A bus factor of 1 means just one person’s absence could bring everything to a halt. Not fun, right?

I first learned about the bus factor around the time I became CTO at Digital Gravy. Since it was my first time in the CTO role, I brought on a seasoned tech leadership coach to help me navigate my new responsibilities and avoid making some silly mistakes.

When my coach started digging into how our teams operated, he quickly noticed two major issues:

1. Siloed knowledge: each part of our products had exactly one expert, and no one else knew much about it
2. Isolated work: team members were working alone, often on tasks that seemed disconnected from one another

For a small company like ours, this is a huge risk. It would take one – just one – person quitting, getting pulled into another project, or – and that’s horrible to even think about – falling seriously ill, to put everything in jeopardy. We’ve seen it happen time and again in the WordPress space: a cool plugin – that got popular really fast – hinges on a single developer, they get swamped with something else, and the entire thing derails.

But also, having bus factor of one isn’t fun for the team either. Knowing you’re the one on hook for a particular area of the codebase might make you feel safe, because you’re irreplaceable at the moment, but the downside is you can’t go anywhere. You’ll be needed every time there’s an issue, even when you really need some time off. It’ll be harder to move on to a different role, even if you want to, because you’ll be tied with a triple knot to that area you have so much experience with. The business can’t afford to move you anywhere. A low bus factor is a recipe for burnout.

How We’re Tackling It at Digital Gravy

If I was going to sort this out, I knew isolationism was the biggest threat. I needed everyone to:

1. Reach outside of their “comfort zone” and take on tasks in areas of the codebase they didn’t originally develop or weren’t familiar with
2. Start teaching others about their area of expertise
3. Start documenting their decisions and not just their code

So I started encouraging more paired work. Here’s a message I sent everyone:

We all like working in isolation, but that’s part of the bus factor problem. Give pair programming a try, even if it’s just for an hour each week. If you and someone else are tackling the same issue, great – work that together. If not, pick someone, spend half the time on your ticket and half the other person’s.

That was helpful, but our own work assignment processes were discouraging pairing: we were assigning tasks that felt disconnected, making it feel like everyone was on a different mission. We needed to encourage team thinking. So Kevin (Digital Gravy’s CEO) and I started trying to empower teams to decide what to work on, by setting goals for them instead of assigning them tasks (for the most part, there’s still some assignment culture… it’s a work in progress), and encourage them to decide among themselves who would do what.

That, too, helped. But it still felt like I was forcing an unproven method onto the teams. After all, all I had to support my decisions was the advice of my coach and my follow-up research. Sure, my coach is awesome and has seen plenty of stuff. I know it in my heart he’s right about this. But I was essentially asking my team to just “trust me bro”, and that’s not enough to motivate such massive changes in behavior and mindset.

If I was going to raise the bar on my teams, it was only fair that I cleared it first. And, as the co-founder CTO (yep, that’s a very specific type of CTO), I was still somewhat involved in coding our products. So I started practicing what I preached:

• Empowering teams to decide what to release
• Pairing with anyone who needed a sparring partner (even if I knew next to nothing about that area of our products)
• Asking others to pair with me when I was working on challenging problems (even if they knew next to nothing about that area of our products)
• Swapping between being the driver and the navigator
• Documenting my own decisions using Architecture Decision Records

And so on.

As I mentioned, this initiative is very much a work in progress, but one that is showing significant early results: our teams are more “chatty”, self-organized and empowered than they’ve ever been before. And that is fantastic news as we embark on building our 3rd and most ambitious software product yet.