Agreed, except a slight visual-tweak I'm seeing on the tough guy manager is the 'servant-leader'. Somehow these 'servant-leader' action-item lists never spur any introspection within the manager-deity themselves. The servant-leader sounds like a great idea to managers who have enough self-awareness to have an inkling that they have no idea what they're doing aside from following "industry trends".

They read from the Book of Jobs every monday morning. "If thee bees have passion, they never work a day in their life. And we hiredest thee smartest to tell us what to do, not to tell them what to do." But the freedom and passion they're talking about is in deciding how many story points to attach to the minute tasks that have been pre-ordained for you to be passionate about. This is because we would have never hired you if you would not be passionate about the roadmap at all times. Leaders don't admit mistakes in the Book of Jobs, they first travel through the bloggosphere on their quest for validation that it's someone else's fault. If that does not work, they check if the naysayer can be replaced, preferably at a cheaper rate. If so, the naysayer will be sacrificed to the land of better opportunities to boost team morale.

This article is telling the story of an engineer who tried to collaborate and voice their concerns constructively to start, but found out it was all the meetings and listening was just an empty act on the part of their managers. Their managers kept cramming so much work into the release that quality suffered under the unrealistic expectations. Those same unrealistic expectations that were previously carefully regarded by the subordinate engineer as risks and concerns.

So the engineer realizes that to get something done, they have to do it themselves. They work longer hours to rearchitect and/or introduce some new tools to improve the pipeline, but the manager was unable to understand how this related to this sprint's burndown chart or the pre-ordained roadmap. And the only conclusion the manager is capable of, even after reading all the blogs they could find on the subject is: When there's a misunderstanding with "their" engineer, it was either a bad hire or even though "their" engineer speaks fluent C,C++,Go,Haskell and Scala, they just do not seem to understand pie-charts and maybe they need a 1v1 to talk about it. Yes, more meetings is what they need to get their work done. The engineer stopped trying to waste their time voicing anything in meetings.

Their rate of commits dropped because they were working on design work, aka thinking. But their manager literally treats the github commit graph as an indicator of the engineer's health vital signs. The manager believes themself very technologically advanced by not resorting to that barbaric practice of correlating LOC with an engineer's vital signs. Throughout the whole story, the manager never actually learned or changed one damn thing.
*In the article, this same story is told through the perspective of a manager with their head quite far up their ass.

Anyways, what a bunch of back-patting patronizing bullshit. I feel truly sorry for anyone who has to work under this guy or anyone influenced by him.