How many writers do you need to write a book?

It's a tricky question. The right answer is usually one, or in some cases, a few. Writing a book is such a subjective and personal endeavor that the question almost doesn't even make sense. It depends on the author's mindstate, their perspective, their way of thinking and approaching problems. If another author wants to contribute, they have to understand the full context of what has been written before, match the style, match the storyline, logic, and so on. Multiple people can't work on the same section at the same time, or risk duplicate work.

The same concept, while admittedly to a lesser degree, also applies to creating innovative software and design. You can't just add more software engineers to a project to make it faster (doing so often backfires). The mythical 10x and 100x differences¹ in engineering productivity are very real. And not having a few key people on a project initiative (a given senior engineer, the right architect, etc.) can result in the project being delivered late, or never delivered at all in line with the original vision.

Some readers will observe that this is nothing new, and yet as of 2023, many (most?) organizations outside of Silicon Valley still don't seem to understand the essence of this. There's a tendency to view software and design as industrial-style work where more input equals more output – and correspondingly, a good number of those projects get canceled, fail, or properly launch only after extensive reparations and team changes (ultimately costing a lot more in money or technical debt).

Applying this in practice is tricky because it's a multi-faceted issue that includes, among others, the difficulty to assess competence, building teams that work well together, and the intricacies of navigating complex situations and getting buy-in from stakeholders. However, I believe that just focusing on understanding, reflecting on, and applying the concept itself is the best first step.
‍