Oh, I half thought you were serious until this point. I still don't get the joke though.
In fact if you take any of this offhand advice as gospel, well I wouldn't.
Maybe I should have scattered "probably" and "often" about the place.
1: ------------------------------------------------------------
When you read the book, ole Fred is not a fan of large engineering units. Forget two pizzas (Bezos is from New York, two pizzas for him is ~10 people).
Fred's view is actually:
1x captain/tech lead,
1x co-pilot,
1x ops guy equivalent,
1x business analyst equivalent who can be sent to meetings (he worked for IBM).
(And then two secretaries. And an copy editor for the documentation, because no internet.
No internet! The documentation must be written!
The lead developer needs to follow my favorite advice of all time:
Can't write? Imitate Hemingway.
And a full-time librarian for the punch cards. And a full-time employee just to maintain the minicomputer that was your debugger.
Because hey, the book was written in 1975.
The internet doesn't exist, email doesn't exist, the engineers almost certainly can't touch type. And anyone without an attractive female secretary was nobody.
The pimply faced youth's job as config wunderkid and unofficial court jester fills most of those roles these days)
2: ------------------------------------------------------------
If you think of all the amazing software that has been made by one person...
How many people do you need to make amazing software?
What are you even making?
I wasn't taking it as gospel and I agree some engineering outfits are (or at least appear to be) overstaffed or inefficient, and a small number of very driven and talented people can produce some incredible things. But when it comes to making a product it can take a radically larger amount of engineering effort than it would appear.
PS Semi is an example of an ARM-beating company which was founded by a visionary engineer who almost certainly had the big ideas himself or within a small group of technical leadership. It still took a hundred engineers 4 years to bring out their first product.
That said, Palo Alto Semiconductor was hardware, which has a far higher barrier to entry than software engineering does/can.
There's more details to it, but a single person could write a very small CPU and put it on an FPGA (or ASIC if they have the tools) in a few months.
That's just one example though. There's lots of software examples. Compilers, browsers, OS kernels, database servers, hypervisors. A single person can write any of those, but to make a competitive product it's often a very different story.
I sympathize with the argument that one engineer can be sufficient but am doubtful about them being an employee as opposed to founder.
But yes, I think you can have two high quality employees make good software? I mean they're employees, you're going to give them marching orders to do something presumably.
Sure, there are exceptions who don't know their worth. In general it's hard to find mediocre technical cofounders and very very hard to find good technical cofounders.
The assistants aren't assistants - you hire them with minimum pressure, but try still to find the most talented junior you can find.
2 juniors in a startup is a bit, probably not the right thing. You'll run out of junior work surely?
The "two good ones plus exactly one junior to make them feel important, and to keep the show on the road for 2 weeks in case they both quit simultaneously" formula is pretty solid.
I would consider "junior" here not as a person in non-critical role who cannot function as an individual contributor, but as a solid candidate that lacks industry experience but can be at the moment hiring be expected to quite fast grow into the role of a solid IC. I.e to use a bit too stereotypical characterization - not a "stablehand" but a "journeyman apprentice".
At the moment of hiring you don't count on it that they can deliver (but guess and hope), whereas the seniors will have shipped products under their belt.
My brain just operates very strictly as:
Junior = apprentice, first job or similar.
Mid = journeyman, "worked another job before". Independent, trusted to be delegated to for specific things, but doesn't quite have a personal brand.
Senior = Master. Proven track record, proven reputation of delivering, capable of leadership inside a technical project. Has and maintains a reputation as someone you can trust.
Principal = Mentor to seniors.
Ofc there are shades of grey between junior and mid, because junior-ship takes like 2-3 years to grow out of.
The list of work able to be delegated to someone at the start is not all that large in many cases.
You won't need more than 2 engineers at the beginning for 99% of the startups. Almost nobody is making anything technologically significant - and if they do they raise millions and act like a disorganised mid company.
In order to do your typical backend + frontend work you won't need much more, unless your developers can't code.
