Gee, look at all those fancy, multidividual contributor titles. And then there is the development team, a.k.a the title-less induhvidual contributors.
Umm, let’s see. Customers interact with features. Features are implemented across components. Components are designed/coded/tested/integrated by developers. Well, duh!
On the left side of the following figure, we have a typical mega-project structure with a minimal Overhead-to-Production personnel ratio (O/P). If all goes well, the O/P ratio stays the same throughout the execution phase. However, if the originally planned schedule starts slipping, there’s a tendency of some orgs to unconsciously exacerbate the slippage. In order to reign in the slippage via exercising tighter control, the org “promotes” one or more senior personnel out of the realm of production and into the ranks of overhead to help things along.
By executing the “promotion strategy“, the O/P ratio increases – which is never a good thing for profit margins. In addition, the remaining “unpromoted” senior + junior analysts and developers are left to pick up the work left behind by the newly minted overhead landlords.
So, if you’re in the uncomfortable position of being pressured to increase execution efficiency in order to pull in a slipping schedule, you might want to think twice about employing the “promotion strategy” to get things back on track.
The brilliant Fred Brooks famously stated something akin to “Adding people to a late project only makes it later“. In this infamous post, dimwit BD00 states that “Promoting personnel from production to overhead on a late project only makes it later“.