I get why these "Managers are so clueless!" posts feel good and are often well received. One thing that would help is if technical talent didn't naturally position leadership as comprised of people who are totally different from them, who intentionally strive to create an unpleasant counter-productive environment that makes it hard to create and deliver software.
I get the pain expressed here, it's real, and the problems are REALLY HARD to solve. Any one of these is multifaceted and cannot be solved by "management" alone. Asking VPs to code a feature every quarter is both unrealistic and silly. Complaining about too many managers, meetings and processes is common and fair, but not to say "if you have painful process fix it with this different, equally strict and brittle process" is naive to the point of funny. Saying "estimation is hard so don't do it" an incomplete answer, and railing against smaller teams or realigning people broadcasts "I don't really think about budgets, emerging needs or things above writing code".
So much of this can be addressed within the team; you can promote streamlined process that does enough to align without prescribing, you can add some consistency in who does what work to build more durable teams and form a consistent mission, you can estimate in effort not time. The author seems to think the ideal is achieving stasis and maintaining it; to me this is impossible and actually sounds like hell.
The day that engineers accept the reality of reporting to investors who only care about cashflow and time is the day all those MBAs and managers go away. Until then, someone always needs to impedance match between the world of ROIC and the world of hackers.
Well said. Managing engineers is an incredibly difficult and multi-variable challenge - companies have been trying different approaches for nearly a century now. We like to imagine as software developers our management problems are unique and can be solved with a silver bullet blog post, but I think they’re largely the same meta-issues that Ford faced in the 30s or Boeing in the 90s.
I get the pain expressed here, it's real, and the problems are REALLY HARD to solve. Any one of these is multifaceted and cannot be solved by "management" alone. Asking VPs to code a feature every quarter is both unrealistic and silly. Complaining about too many managers, meetings and processes is common and fair, but not to say "if you have painful process fix it with this different, equally strict and brittle process" is naive to the point of funny. Saying "estimation is hard so don't do it" an incomplete answer, and railing against smaller teams or realigning people broadcasts "I don't really think about budgets, emerging needs or things above writing code".
So much of this can be addressed within the team; you can promote streamlined process that does enough to align without prescribing, you can add some consistency in who does what work to build more durable teams and form a consistent mission, you can estimate in effort not time. The author seems to think the ideal is achieving stasis and maintaining it; to me this is impossible and actually sounds like hell.