{"id":711,"date":"2026-05-02T16:58:12","date_gmt":"2026-05-02T23:58:12","guid":{"rendered":"https:\/\/hitchhikersguidetodesign.com\/book\/?p=711"},"modified":"2026-09-09T18:55:00","modified_gmt":"2026-09-10T01:55:00","slug":"bus-factor","status":"publish","type":"post","link":"https:\/\/hitchhikersguidetodesign.com\/book\/bus-factor\/","title":{"rendered":"47 \u2022 Bus Factor"},"content":{"rendered":"\n

The Bus Factor<\/strong> measures how many people would need to suddenly become unavailable before a project could no longer continue because critical knowledge disappeared with them. If the answer is one, you don\u2019t have a team – you have a single point of failure.<\/p>\n\n\n\n

In software, UX, and product development, the Bus Factor exposes how much knowledge, context, and responsibility are concentrated in particular individuals. It’s a measurement of risk; the lower the number, the more fragile the team.<\/p>\n\n\n\n

ORIGIN<\/h2>\n\n\n\n
\n

The Bus Factor<\/strong> comes from a deliberately grim thought experiment: How many people could be hit by a bus before the project was in serious trouble?<\/em><\/p>\n\n\n\n

An early example of the idea appeared in the Python community. In 1994, Michael McLay raised the question of what would happen to Python if its creator, Guido van Rossum, were suddenly \u201chit by a bus.\u201d<\/p>\n\n\n\n

The hypothetical bus isn’t particularly important. Nobody needs to be run over. Someone can change jobs, take parental leave, become ill, miss a flight, win the lottery, or simply go on vacation somewhere with enthusiastically poor Wi-Fi.<\/p>\n<\/blockquote>\n\n\n\n

WHEN<\/h2>\n\n\n\n

You\u2019ve encountered a low Bus Factor when:<\/p>\n\n\n\n

    \n
  • \u201cOnly they know how this works.\u201d<\/strong>
    A remarkably concise description of organizational risk.<\/li>\n<\/ul>\n\n\n\n
      \n
    • Work stops when someone is away<\/strong>
      The project is apparently compatible with business hours but not vacations.<\/li>\n<\/ul>\n\n\n\n
        \n
      • One person attends every important meeting<\/strong>
        Not because they enjoy meetings. Because nobody else has the context.<\/li>\n<\/ul>\n\n\n\n
          \n
        • Documentation exists mostly in people’s heads<\/strong>
          Fast, flexible, and unfortunately difficult to search after they leave.<\/li>\n<\/ul>\n\n\n\n
            \n
          • The same expert becomes the bottleneck for everything<\/strong>
            Every question, review, approval, and decision eventually finds its way to them.<\/li>\n<\/ul>\n\n\n\n
              \n
            • Onboarding requires oral history<\/strong>
              Understanding the product involves several hours with someone saying, \u201cOkay, there’s a reason we did this\u2026\u201d<\/em><\/li>\n<\/ul>\n\n\n\n

              WHY<\/h2>\n\n\n\n

              A low Bus Factor develops when knowledge and responsibility become concentrated instead of distributed or include any combination of the following:<\/p>\n\n\n\n

                \n
              • Knowledge gets trapped<\/strong>
                Important context lives in someone’s memory rather than somewhere the team can access it.<\/li>\n<\/ul>\n\n\n\n
                  \n
                • Doing is faster than teaching<\/strong>
                  Under deadline pressure, \u201cI’ll just do it\u201d<\/em> is considerably quicker than explaining it. Repeat for three years.<\/li>\n<\/ul>\n\n\n\n
                    \n
                  • Ownership becomes dependency<\/strong>
                    Clear ownership is useful. Exclusive understanding is not.<\/li>\n<\/ul>\n\n\n\n
                      \n
                    • Decisions lose their history<\/strong>
                      Teams document what <\/em>was built but forget why <\/em>it was built that way. The only person that knew left.<\/li>\n<\/ul>\n\n\n\n
                        \n
                      • Systems accumulate complexity<\/strong>
                        As products grow, undocumented exceptions, dependencies, and historical decisions turn expertise into archaeology.<\/li>\n<\/ul>\n\n\n\n

                        HOW<\/h2>\n\n\n\n

                        The Bus Factor can be reduced by making knowledge shared, visible, and replaceable. In UX and in product teams, this means moving from individual ownership to collective understanding. To prevent this, organize teams and processes by applying the following advice:<\/p>\n\n\n\n

                          \n
                        • Document decisions, not just deliverables<\/strong>
                          Capture why something exists, which alternatives were considered, and what constraints shaped the decision.<\/li>\n<\/ul>\n\n\n\n
                            \n
                          • Work in the open<\/strong>
                            Make designs, research, technical context, decisions, and work-in-progress accessible instead of keeping them in personal files and private conversations.<\/li>\n<\/ul>\n\n\n\n
                              \n
                            • Cross-train intentionally<\/strong>
                              Make sure at least one other person understands every critical area well enough to step in.<\/li>\n<\/ul>\n\n\n\n
                                \n
                              • Rotate ownership occasionally<\/strong>
                                Let different people work with important systems rather than permanently assigning one expert to each kingdom.<\/li>\n<\/ul>\n\n\n\n
                                  \n
                                • Share research context<\/strong>
                                  Insights shouldn’t disappear because the researcher who conducted the study changed teams.<\/li>\n<\/ul>\n\n\n\n
                                    \n
                                  • Make systems understandable<\/strong>
                                    Clear naming, consistent patterns, sensible organization, and good documentation reduce the amount of tribal knowledge required to work safely.<\/li>\n<\/ul>\n\n\n\n

                                    PRO TIP<\/h2>\n\n\n\n
                                    \n

                                    Strong teams don\u2019t rely on heroes. They rely on shared context. Vacations can be surprisingly useful resilience tests. If everything collapses while someone is away for two weeks, you’ve discovered a dependency without even requiring the actual bus.<\/p>\n<\/blockquote>\n\n\n\n

                                    EXAMPLES<\/h2>\n\n\n\n
                                      \n
                                    • Only one designer understands the complete logic behind a critical workflow. <\/li>\n\n\n\n
                                    • A feature can’t ship because the only engineer familiar with it is unavailable. <\/li>\n\n\n\n
                                    • A design system is extensively documented, but only one person understands when and why to use its patterns. <\/li>\n\n\n\n
                                    • Years of research exist, but the historical context lives primarily in one researcher’s memory. <\/li>\n\n\n\n
                                    • A PM is the only person who remembers why major product decisions were made. <\/li>\n\n\n\n
                                    • A new team member discovers that onboarding consists mostly of finding the right people to ask.<\/li>\n<\/ul>\n\n\n\n

                                      CONCLUSION<\/h2>\n\n\n\n

                                      The Bus Factor reveals hidden fragility in systems or processes. Dependencies on certain individuals should be minimized<\/strong> to avoid failure when people leave and their knowledge leaves with them.<\/p>\n\n\n\n

                                      A strong product must not be defined by how well one person understands it but rather by how easily others can step in. Distribute context, document decisions, cross-train people, and create systems that others can understand without summoning the original creator. In other words, get everyone on the bus instead of being hit by it.<\/p>\n","protected":false},"excerpt":{"rendered":"

                                      The Bus Factor measures how many people would need to suddenly become unavailable before a project could no longer continue because critical knowledge disappeared with them. If the answer is one, you don\u2019t have a team – you have a single point of failure.<\/p>\n

                                      In software, UX, and product development, the Bus Factor exposes how much knowledge, context, and responsibility are concentrated in particular individuals. It’s a measurement of risk; the lower the number, the more fragile the team.<\/p>\n","protected":false},"author":1,"featured_media":943,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_hide_featured_image":false,"_jetpack_featured_image_duplicate_dismissed":0,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[23],"tags":[133,135,53,134],"class_list":["post-711","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-the-productivity-mirage","tag-bus-factor","tag-processes","tag-productivity","tag-risk","entry","has-media","owp-thumbs-layout-horizontal","owp-btn-big","owp-tabs-layout-horizontal","has-no-thumbnails","has-product-nav"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-content\/uploads\/2026\/09\/47.jpg","_links":{"self":[{"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/posts\/711","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/comments?post=711"}],"version-history":[{"count":3,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/posts\/711\/revisions"}],"predecessor-version":[{"id":994,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/posts\/711\/revisions\/994"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/media\/943"}],"wp:attachment":[{"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/media?parent=711"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/categories?post=711"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/tags?post=711"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}