Let’s talk a bit today about your Bus Factor.
For those that don’t click the Wikipedia link above, “bus factor” is a measure of how many developers you could lose before whatever you’re working on goes tits up (to use a technical term).
I was reminded of this term at the day job earlier this week.
We have a site we manage for a client that’s getting a lot of updates right now and we had just sent our two primary developers on the project out for an on-site meeting.
While they were in the air, a fairly urgent but one-character change came in from the client.
And that’s when I realized the only two developers who knew how to deploy the site were currently hurtling through the air in a metal cylinder.
So we had to sit on this one-character change until the landed and got to the hotel.
Client got a touch mad, we got a touch frustrated and the whole thing is unacceptable and easily fixed.
The fix? Making sure that everyone on the team, even if they’re not working on that project from day-to-day either knows, or can find out, how the site gets deployed.
As a manager, your goal is to get that bus factor up to cover your entire team.
Too often, knowledge and information gets siloed — not just deployment procedures, but project history, server setups, whatever — and your job to a large degree is to break up those silos.
Get everything documented. It doesn’t have to be pretty, and can be as simple as READMEs in repos, but get that shit down on paper and out of people’s heads.
Because you never know when there’s a bus coming, and you want to be prepared.
I wanted to end this with a bit of a homework assignment.
If you’re a manager, what’s your current bus factor on your most critical project?
If you’re a developer, what knowledge are you carrying around in your head right now that would be lost to the winds of time if you met a crosstown bus on the way in tomorrow morning?
In either case, you owe it to your team to get that information out your (or your team’s) head and into a format other people can read and use.