Small is Good
That's right. Only relatively small projects can get along with such a light amount of administrative work. Small projects with a single person who both knows the details of the problem and implementation is the ideal situation. That's basically what happens in a one man project. If only all projects could be as efficient!
Some problems are just too massive to work that way. It is usually most efficient to either hire someone a little more experienced who can keep it in one-man-land, oradd a second or third senior engineer. What if that's not enough? Then it's often best to have a clear teachnical lead who can specialize in decision-making. This kind of thing usually holds up to about 7 or 8 people. Beyond that there's a HUGE dropoff in productivity. Growing a project team beyond that size is just asking for trouble and should only be done when there's no other choice.
Larger teams often bring serious practical and political hazards. One is that management often thinks that it is OK to insert people who have no idea what is going on. Often this person is called a "project manager". Worse, they often insert such people into a diffuse decision-making process.
If non-technical people are involved in a projct it is best that they be "doing" and not "supervising". There are things that non-technical people can do under the direction of technical leadership: user docs, artwork, testing, and some kinds of documentation. That can help take the load off the technical staff and speed things up. Putting them in charge has in every case I have seen been a wet blanket on the project. Worse, as soon as non-technical people get in charge of things, they usually bring in more non-technical managers to "help". In one case I know of, two technical managers were replaced by 90 non-technical managers to manage a smaller number of engineers and development has all but ground to a halt.
