This is a piece reflecting on what I took away from the book “How Google Engineers Work.” Please note that it contains the author”s subjective experiences.

Who’s Left If You Get Hit by a Bus?

While reading “How Google Engineers Work,” I came across a concept that really resonated with me: the bus factor.

Put simply, the bus factor is a number that represents “how many team members would have to get hit by a bus and be unable to come to work before the project falls apart?”

Think about it. What if the bus factor is 1? It means that losing just one person puts the project at risk. If knowledge is concentrated in a single developer, the service could grind to a halt the moment that person suddenly quits or goes on extended leave. In the end, that person has to become a superman who can’t even take a proper vacation. 🦸‍♂️

So how can we raise this bus factor?

The Power of Knowledge Sharing

‘Pair programming,’ widely used at IT companies, can be one approach. When two people write code together, knowledge naturally gets shared. That way, even if one person ‘gets hit by a bus (!),’ the remaining person can carry the work forward. The bus factor goes from 1 to 2!

Another approach is to openly share your problems and concerns with others.

Google’s Knowledge-Sharing Culture

At Google, they make use of a system called ‘mailing lists.’ They create a Google Group around a specific topic, and anyone can post a question while people with the relevant knowledge respond.

What’s truly great about this is that the person asking isn’t the only one who gets an answer — everyone subscribed to the same mailing list gains that knowledge too! You end up acquiring new knowledge without even realizing it. As problem-solving experiences are shared, a virtuous cycle forms that naturally raises everyone’s capabilities. ✨

My Own Experience with Knowledge Sharing

Let me share one of my own experiences. It was back when I was developing a service called Gathering. At the time, it was my first experience building a service, so even Slack felt unfamiliar to me. 😅

Whenever I had a question, I reflexively asked only through private DMs. My thinking was, ‘Why bother letting other people know how little I know?’

But our PM had a different view. “Anything you’re struggling with or working on should be made visible to everyone,” they said, encouraging me to share in the group channel. At first, I didn’t really understand why that mattered.

Then I had a pivotal experience. I posted a problem I’d been agonizing over for two hours into a public channel, and it was solved in just ten minutes! After that, I made a conscious effort to build the habit of sharing.

Of course, a constant stream of messages while you’re working can break your concentration, but I realized that sharing at the right moments can dramatically boost the whole team’s productivity.

Things I Want to Apply Going Forward

If I ever get the chance, I’d love to create a dedicated Slack channel where people can freely ask and answer questions. A problem I struggled to solve is likely one other teammates will run into too. When the same issue comes up, looking up a record is far more efficient than relying on someone’s memory of the solution.

And it would be even better to collect the tough problems and their solutions and publish them as a team tech blog, right? In the end, these small efforts add up and go a long way toward raising the team’s bus factor!

---

Aside

At my current company, we share work status through daily scrums, but honestly, they often aren’t that efficient. Sharing what I did and what I plan to do is fine, but listening to everyone else’s entire work status sometimes feels like a waste of time.

I wonder if it would be better to use that time to focus only on the things that truly need sharing — especially problem-solving experiences and tips. Wouldn’t that be the kind of scrum that genuinely helps the team? 🤔