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 differences1 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.
How many writers do you need to write a book?
Notes
[1] This is not to be taken literally (it's rare that 10x or 100x more software is shipped). In the real world, these differences in productivity manifest in more nuanced ways, as a combination of figuring out what to build, speed, precision, and less technical debt. For example, the goal may be building a product that is polished and high-quality (fast, reliable, robust, scalable, etc.). Consider that some teams manage to build such products in 6 months while others spend 5 years without succeeding at the original goal, and the productivity differences indeed become real.
April 18, 2023
Subscribe
I send out occasional emails about new posts, learnings, scientific discoveries, and combinations of insights that I found interesting. No promotions.