A Classic Response
In a product development organization, when schedules are consistently missed, costs are rising, and profits are decreasing, a classic management response is to add more “oversight” to turn things around. This sincere, but often counterproductive response to deteriorating performance, exacerbates the mess by adding more cost and further slowing progress.

The above figure graphically shows the deterioration in performance over time ignited by the “classic response” to perceived poor execution. The additions to the management team somehow magnify the illusion of control that managers think they have over the product development/maintenance process. The act of piling on more management serves as an anesthesia that temporarily relieves the pain of poor performance. When the numbers show that performance hasn’t improved, the next step is to keep the top heavy structure in place, but replace one or more members of the management team with “proven” managers. Sick city.
So what’s an alternative to the “classic response”? Take a look at the figure below. In this response, the product manager rolls up his/her sleeves and gets dirty with the product development team. She dives deep into the product infrastructure and scours the landscape for missing information, erroneous information, and “camouflage”. Armed with this realistic, unfiltered “status” data, effective decisions can be made and productive direction can be given. In addition, by visibly doing some non-status-taking and non-schedule-hawking work, credibility and trust (which are difficult to acquire but easy to lose) are gained.

Sadly, during the transition from doer to manager, an automatic mindset switch occurs. Instead of growing into a 3D status taker plus schedule jockey PLUS, most importantly, a helper, only the first two responsibilities are internalized. “I’ve arrived and I don’t have to do any hard, messy work anymore”. Even worse, upper management innocently, but surely, encourages this post-transition mindset because it’s the same mindset that guides their behavior. Bummer.
“You have to know a lot to be of help. Learning is slow and tedious. You don’t have to know much to cause harm. It’s fast and instinctive.” – Rudolph Starkermann

Good description of highly dysfunctional Mythical Man Month. Instead of overloading the people directly working on the problem/product, this describes the overloading of the management. Classic case of increasing the number communication paths without any benefit to the problem/product.
Yeah, it’s even worse than throwing more engineers at the effort. When you overload engineers, at least you’ll get some, but mot much, value-added work done. With manager overload, since they typically don’t do any productive/added value work and often prevent value-added work from being done by cracking the whip, it’s a total waste of money and time.