I was skimming It Doesn’t Have to be Crazy at Work again, and there’s one quote from the chapter “Three’s Company” that stuck out to me:

Just like work expands to fill the time available, work expands to fill the team available. Short, small projects become big, long projects when too many people are there to work on them.

Basecamp addresses this by limiting projects to only 3 people. I don’t have any particular opinion about that number - again, it’s what works for them.

But it got me thinking of a similar concept - of keeping the product proportional to the team.

Chris Dixon wrote that software is simply the encoding of human thought, and as such has an almost unbounded design space. Building new things is relatively easy, but understanding what it takes to maintain software is difficult. It is a constant balance of new features, fixing what’s broken, providing tools for internal teams, and so on.

Knowing what your team is capable of maintaining is an important limiting factor in what new features you can build. This is an important skill of resource allocation - to factor in the second order effects of a past feature in the future capability of a team.

This doesn’t mean that small teams cannot build and maintain large pieces of software - quite the contrary. Knowing the upfront requirement of product maintenance becomes forcing function to increase a team’s capability.

Increasing that capability can happen a number of ways - either through increasing the leverage of the team, or by reducing the surface area of concern. Increasing leverage can happen through automation, testing frameworks, or training and development. Reducing the surface area of concern comes through addressing technical debts, or removing features altogether.