The potential of one person

The potential energy of one person is great. A single brilliant person can generate a good idea, break it down into its components and execute.

Language developers Booth, Hamilton, Hopper, Guido, Stroustrup, Ritchie, Matz, and Eich initially designed and developed their programming languages entirely by themselves.

With one person, you have ultimate consensus. There is no communication impedance, communication complexity, miscommunication, competing biases, or competing egos.

If one person does not have great potential, in my experience the reason why usually comes down to only a lack of skill or motivation holding them back.

Teams of course can have more potential than one person but the chance for failure increases. It is this failure that can kill companies and projects.

The reason why teams are more susceptible to failure is each person you add to a team has diminishing returns. One reason why is the increase of communication channels. A team of four has 6 communication channels while a team of 5 has 10 communication channels.

If a team of four has 6 communication channels in their network and they use JIRA, Slack, Zoom, and Email that is a total of 6 channels across 24 mediums. Add Google Docs and now we’re up to 30. At some point, balls are always being dropped. Nobody can keep up and they are doing more work communicating than doing what we need them to do - build great software products.

As teams grow, not only do communication channels increase quadratically, individual contribution decreases overall and there is less ownership and responsibility so people care less. For example, a team of 15 has 14 other people to pick up the slack and so a person can easily rationalize themselves into mediocrity whereas a team of 1 has no one else and a team of 3 only has 2 people and so they very quickly will let the third know of any of his or her shortcomings and slacking, where a team of 15 may never be able to notice it let alone apply pressure.

This is why it is important to reduce complexity where possible at every level of your organization possible and to have a well-defined working agreement at your company and for your teams. This applies to all complexity: Communication Tools, Development Tools, Technical stack, and Corporate Culture.

Many companies like Gitlab choose a limited set of tools and asynchronous work.

Small and lean teams get more done.

Small teams that work with constraints in a lean and agile fashion get more work done. Whether it’s deadlines, money, people, or technology, embracing constraints fuels creative solutions. Constraints breed resourcefulness, self-sufficiency, and invention.

A team’s ability to deliver software correctly and efficiently can be a differentiating factor for your organization against your competition. The smaller the team the easier the collaboration. Too small though and you don’t have all of the skills necessary to iterate and ship. Too large and it’s impossible to get anything done because we’re spending all of our time organizing, debating, project managing, or just rationalizing our way into slacking.

“We try to create teams that are no larger than can be fed by two pizzas,” said Bezos. “We call that the two-pizza team rule.”

My personal preference based on anecdotal data only is:

Team of 5-6 > Team of 3 > Person of 1 > Team of 2 > Team of 10