| This conflates two different concepts: division of labour and hierarchy. Whether you should have separate project managers and whether you should have a flat hierarchy shouldn't be connected. As far as PMs go: from long experience, I've yet to witness a good one. I'd say at least 80% of devs are productive assets -- i.e. their work moves the project forward. Maybe 20% of PMs are. In well over half the cases, the team would be more productive, happier, and effective if you simply fired the PM. Others might scrape by with a break even. As far as flat hierarchy goes: that's anarchy, and anarchy is conflated with chaos for a good reason. You can read a codebase and detect within 5 minutes if it was written by a flat hierarchy team. I'll take a foul mouthed Linus tyrant at the top over a flat hierarchy any day. The problem is that due to the nature of the job of PMs (supervising & giving orders & planning work etc), they're naturally superordinate in role, no matter how many times you call them a "servant" or "facilitator". But they're also the least qualified types to lead devs. They know nothing about development, and most of what they naturally tend to do to exert control and carry out their role results in purely damaging effects. As I see it, the only effective solution is: (a) train devs how to manage -- since that's much easier than teaching managers how to dev, (b) establish clear hierachy but with everyone subject to rules (basically replicating how states work). I'm never one to turn my nose up at the division of labour rule, but I don't believe PM is ever truly labour that can be divided out without interfering with another rule: the wise should lead. PM is too close to a "boss" concept to be separable labour. I.e. it's never truly horizontal, but vertical. Which is why I'll never hire or create such a role, and instead train the best devs to move beyond just typing code and move towards "conductors of the code being typed". |