Moreover, the communication overhead will eat up a much larger percentage of working time, since the person is only working half time. But you can't just communicate half as much. Any fixed overhead, such as status meetings, breaks, etc will suffer from the same effect.

Then there's the concept of flow. It's hard to get into a high productive state doing something like programming if you are working 4 hours a day, and 1 hour a day is overhead. Even if you get into that zone, you will benefit from it for a short period of time. For me, it can easily take half an hour to get my mind back to where I was on the previous day.

Ramping up and learning a codebase is also an overhead, and will take longer in terms of days (since you aren't working as long), take communication time, and then once you are an expert, you'll bring a smaller amount of time to bear against the problem.

In terms of teams, having a larger team (2x as large, let's say) means that you will get more good hires and more bad hires. But bad hires are far more of a problem than good hires, especially if they spend all the time communicating, asking questions, and making work for others. One bad hire can ruin a team. One good hire really cannot make a bad team into a good team.

All of this assumes also that all the part time people are working at the same time and able to communicate, which almost certainly won't be the case. Part time workers will not always be able to communicate, and may have to wait a while for an answer, further reducing productivity.

It's not only not negligible, but I worry it's not scalable.

Obviously there is benefit to adding more people, it's just that that benefit takes time to offset the cost of onboarding.

Communication does place an upper limit on the number of people who can work on a specific project, and later the total number of projects that can interact.

Something exploratory like what what the GP was suggesting doesn't require huge teams or a lot of interaction between teams, at least until the problems are identified and need to actually be resolved.

Data that you can find in Software Estimation: Demystifying The Black Art quantifies this. The overall productivity of a team increases until it has 5-8 people. Then it goes down. A team of 12 actually accomplishes LESS per month than it would if you fired half the people. However once you get to 20-25 people, productivity is back. And then increases fairly close to linearly.

Going from 5-8 people all the way to 20+ with no increase in throughput is really, really painful. And those aren't cheap people. This provides companies with a huge incentive to figure out how to get a small team to be as productive as possible. And you don't get the most out of a small team by filling it up with junior to mid-level devs.

(This does match my experience. 40+ teams simply accomplishing less and less than a very small, co-located or constantly in contact team).

The solution to that is to structure the project into independent parts that can be done in parallel by smaller amount of people, thus vastly reducing communication waste. But whether or not you can divide your project in such a way is a question of its scope, and of design decisions you make.

You get both steep diminishing returns from adding more devs, you also get additional overhead from needing more management.

The amount of code you can write grows linearly with number of engineers, but communication costs grow quadratically. Therefore, the speed at which you can execute is inversely proportional to the size of the team, unless you can cut communication costs. Established projects can do this with architectural decisions that prevent one engineer from needing to know about or communicate with other engineers working on unrelated parts of the product. New projects cannot, because the architecture hasn't been established yet. That's why every innovative product grows out of a small team.

That's why it's a platitude. It gets bantered about by developers as an explanation about why we just can't go any faster (hiring people is a lot of work after all), but in reality they CAN go faster with more people working on the various problems that make up the system.

Of course there is a point of diminishing return. The management costs come into play. The communication inefficiencies. The process issues. Those can be largely solved with good leadership, however.

It's a rule that is only true when it's true, which doesn't make it that useful to me. I've grown teams on multiple occasions from one or two developers to much larger numbers. While productivity may not have increased linearly, it sure made the projects go much faster. Hell I'd argue that doubling a two person team more than doubled productivity just because the external drags tends to be more distributed which reduces the context switching developers are having to do.

I think there are many more shades of grey that inexperienced founders just don't recognize when they're bound to that idea.

I believe Peopleware covers this pretty well.

Maybe I'm getting old and cranky, but lately 7 is becoming my limit for people on a team, with team size as low as 3 looking pretty damned good.

If the goal is to grow a piece of software over time (as in many startups), any architecture that relies on "better communication" is doomed to fail, simply because it limits the size of the team that can handle it (and thus growth).