Good theory, but I think the numbers are a bit unrealistic. I would hope that a manager with a team of five coders would be able to create the output of about three coders working independently. Okay, maybe four, but that'll be tough.

The trick is that if you actually have three or four coders working within the same group without a manager or other organizational scheme, it'll be a complete mess. They will be doing redundant work, then spending time integrating their work and eliminating redundancy, then deciding how to interface their pieces together, and so forth. The point is that unless you have truly independent projects, there's no way for your coders to work completely independently. (And if you do have several truly independent projects, your company probably ain't gonna make it. It's spread too thin. Focus on what you do differently, and beg/buy/borrow/steal the rest.)

Ok, so maybe the numbers aren't quite right, but you get the idea. Think of it as parallel processing, which it is. The ideal would be linear scaling, but dependencies between processors (coders) always drop the speedup below that. One job of a manager is to eliminate as many dependencies as possible, and minimize the disruption of the rest. That may mean scheduling first the pieces that need to be resolved to avoid blocking others, or it may mean setting some things in stone to make sure the parts work together while leaving other things loose and flexible so they can adapt to their circumstances.