Fixing a Bus Factor of One

Please note that all opinions are that of the author.

Last Updated On: 2025-10-13 07:27:39 -0400

I am currently Founder and CTO of a new company, Pollitify, where we have a bus factor of 1. This is a dangerous thing for any company but particularly for a company doing the technical side of progressive politics in 2025 in America.

Let’s start with the bus factor concept and what it means. The idea of bus factor for a technical firm is simple – how many people at the company need to get hit by a bus for everything to fall apart. When you have a single engineer, that means you have a bus factor of 1 by definition. So let’s say that you add a second engineer – does that mean your bus factor goes up? The answer is, unfortunately, it depends. The question becomes two fold:

1. Can your second engineer truly replace the first engineer (if the first engineer is the one who gets hit by the proverbial bus) ?
2. Can your second engineer scale up, over time, to replace your first engineer (again same assumptions about 1st engineer being hit by the proverbial bus)?

Strategically we need to fix this and that raises a number of questions:

1. Do you hire small and smart or large and less smart?
2. How do you find people you can trust?
3. How do you get maximum effectiveness while still spending minimal dollars?

Small and Smart versus Large and Less Smart

Tech startups tend to either be staffed by two types of tech teams:

• Small and Smart
• Large and Less Smart

My bias is always for small and smart. With this approach you hire the smartest folks you can find and then you trust in them to do the right thing, counting on their brains, their judgement and their choice of technologies. You tend to avoid explicit technology standards at the organization level in favor of core team knowledge.

Here are examples of the Small and Smart approach:

• Viaweb by Paul Graham
• Reddit in the early, early days

Viaweb was successful largely due to Paul’s choice of Lisp as a development tool. Lisp is an iconoclastic language that in the right hands is game changing. Similarly the database schema used by Reddit in the early days was very much NOT a standard approach but a brilliant choice for early stage startup development.

The Large and Less Smart approach is often the model you find in a consulting company. With this approach, you have a large team and they are mostly junior staffers, often coordinated by a senior engineer. With this approach you focus on documented procedures, standard languages and standard tools.

It is important to note that you can reach your goals with either staffing approach. Personally I would rather have a small, brilliant, productive team but that’s my personal choice. The downside to the Small and Smart approach often is that the lack of standardization can lead to, ahem, weirdness in a code base. It should be noted that after Yahoo acquired Viaweb, their first task was to literally throw away the codebase and replace it in full. Why? Because it is essentially impossible to hire Lisp developers in the large.

Finding Trusted Folks

Here’s the simple answer on this oh so complex issue (trust is one of those human problems that we just haven’t solved yet and, ultimately, will never solve):

• Start with people you have worked with extensively over the years
• Keep going with people you know on a personal basis

Any technical lead worth their salt usually has a handful of good contacts that they can always turn to. These are the people that you want to recruit.

Maximum Effectiveness with Minimum Dollars

Achieving maximum effectiveness with minimum dollars basically boils down to a few things:

1. Good engineering practices such as full test coverage
2. Solid documentation at the repo level like a well written, tested readme that explains how to get started.
3. Supporting documentation where the project level conventions differ from the environment standard. For this I tend to use blog posts. As an example, I have my own approach to data seeding where I don’t believe in the standard Rails way. Here’s a blog post on my approach.

All too often, in a startup context, the argument is made that you can’t afford the time to write documentation or implement test coverage. That is penny wise and pound foolish thinking; documentation and test coverage always pay for themselves.