The Bus Test 🏃🚌

A simple test of how disaster proof your business is

Image by Mike Wilson on Unsplash — https://unsplash.com/@mkwlsn

One day, Crew CTO Angus Woodman and I were walking home (yes, we walk home together sometimes), deep in conversation about some important, world-changing feature for Crew and as we stepped off the sidewalk a bus went flying by, narrowly missing Angus by only a few inches.

Without Angus, yes, the company’s average age would have been considerably lower (I’m calling you old, Angus). And yes, the company’s Slack messages would have been a little more politically correct. But who would have written all the backend code that keeps Crew running smoothly?

Who would have handled the deployments?

Who would have ripped apart our Github pull-requests?

Who would have named the Github priority labels Priority Weak Sauce and Priority Hot Sauce?

Okay, so the bus thing never happened (though we do walk home together sometimes — so what?), but we did, at some point for some reason, think about the problem of having knowledge only exist in one teammate’s head.

If something happened to that person (like, say, they get hit by a bus), how would we keep moving forward?

We named the principle the Bus Test, as it sounds a lot more exciting, albeit slightly more macabre, than the Somebody Takes a Vacation/Leaves Crew Test.

How to run the Bus Test

The Bus Test is a simple principle:

“Knowledge should be duplicated between multiple team members.”

Knowledge doesn’t just mean facts and history, it also means processes, development, and access to accounts, to name a few.

Things tend to get more complicated as you grow and over the past year, we’ve made a big effort to duplicate, document, and organize Crew’s knowledge. Some of it we’re still working out, but here’s a little behind-the-scenes look at how we’re trying to spread knowledge between teammates.

Account sharing

There was a dark time where we shared accounts either by:

1. Using the same email/password combo (yah, that was a thing 😳)
2. Sharing the old-school way (“Hey Steph, whats the login for Skype again?”)

It was slow, insecure, and most of all, it didn’t pass the Bus Test.

One person gone and poof no more logins.

Meldium (no, not Medium) is a tool we started using to share passwords securely between teammates. It has a bunch of useful features, but the most important one is that Crew-related accounts (think Twitter, analytics, developer tools, etc…) are accessible to everyone on the team.

When we sign up for a new account on some service, we add it to Meldium.

If a password needs to be reset, we update it in Meldium.

As soon as we update an account or password, Meldium makes sure to automatically share it with the rest of the team.

It’s quick, it’s easy, and it passes the Bus Test. ✅ 🏃🚌

Processes

Processes sounds like one of those words that you try to stay away from at a startup — they’re for slow, boring, old people, right? Or at the very least, you try minimize them (that’s what I always thought).

However, a few months back, it became obvious that we did have processes. We’d just never documented them.

They weren’t formalized and they weren’t easy to discover. They were the equivalent of the “Hey Steph, whats the login for Skype again?” problem, but at a much larger scale.

We were wasting time and we were making it hard for new teammates to pass the 4AM Test (oh yeah, that’s another test we’ll talk about in the future). Worst of all, they didn’t pass the Bus Test.

Stephanie Liverani and Mikael Cho were the first ones to figure out that we needed to properly document how we do everything from writing a blog post to creating a new product, and so we brought all that information together in the appropriately-named ‘Processes’ board on Trello.

The premise of the board is simple: any repeatable action (aka: a process) should be documented and assigned a lead.

The lead is responsible for updating the process when it changes and answering any questions about the process.

Everything from on-boarding new teammates to IT issues to filing an expense is documented on the board. It’s the first place you look when you don’t know how to do something and it’s the last place you look when you’re looking for something fun to do on a Saturday night.

Trello process card for Meldium and passwords (so meta)

Most importantly, it takes the knowledge out of one person’s head and shares it with the rest of the team. Bus Test passed. ✅ 🏃🚌

Development

The hardest thing about development is understanding product context (let’s start a flamewar Hacker News). It’s fairly easy to understand how a feature works, but understanding why it works that way and the thought process behind that choice is the hardest and most important part of product development.

I’ll give you a quick example (though, feel free to skip it):

On Unsplash there are two types of tags for a photo: a suggested tag and an authoritative tag. Suggested tags are created by the community and authoritative tags are created by our team. There are three types of suggested tags: auto-tags (created by an algorithm), community generated tags, and the tags created by the photo’s photographer. There are two types of authoritative tags: primary (for example, this is a picture of a cow) and secondary (this picture contains a cow, but it isn’t only a cow).

It’s not simple, right?

For any developer who wasn’t a part of creating that system, it’s confusing, complex, and when you read the code, you get it, but you don’t understand why it was done that way (I swear, there was a reason).

Communicating that knowledge is crucial when it comes to fixing bugs, improving the feature in the future, and for not thinking your fellow teammates are complete idiots. If that knowledge only exists in the original developer’s head, well, the rest of us are sh*t out of luck when that person isn’t around.

We’re still working out the best way to communicate that knowledge (should it be in a wiki, in the code itself, in Trello, or in Github?).

Right now we’re using a combination of tools to make it happen but that might change (and probably will change) in the future.

The main outcome is that the knowledge needs to be written somewhere. Github pull-requests are a good place, the dev channel on Slack is another, and the codebase is probably the best.

Unlike the other areas, we sort of pass the Bus Test for development, but it’s something we’re definitely going to figure out (whoever is the lead on that process Trello card has a fun year ahead of them). ❔ 🏃🚌

So yeah, that’s the Bus Test. If you’re not passing it, you probably should, because, well.. you never know.

Hey, I’m Luke. I’m currently building Unsplash. I’m @lukechesser on Twitter and would love to hear your thoughts about the Bus Test, alternatives, and any tools you’re using to make it happen.

Find the best teammates (who won’t disappear on you).

Check out Crew, a talent marketplace where you can meet and work with the best designers and developers. Over 10 million people have used products made on Crew. And over 3 million people have read our blog. Join them here.