There are some other dynamics that are worth mentioning here that can stand in the way of undertaking any of the steps the author recommends. I don't think they touched on any of these things so I'll list some of them out:
* Technical staff in an organization feel they have no authority or respect within the organization. This can happen when companies become too sales-driven.
* Senior technical staff feel they have no ability to delegate, either because of the previous point or because they don't trust the technical ability of less senior staff.
* Those in an organization who do have authority to delegate lack sufficient understanding of priorities or lack technical knowledge.
These things highlight the classic balance between technical knowledge and managerial skills. If you don't have people that bring both to the table, you're in for trouble. Not sure if I'd go so far as to say this is what it's all about. However, reading over the author's advice, I thought to myself, "None of this could have happened at some places I've worked." You can come up with a good plan, but if no one will listen to you or take your advice, it's worthless.
The author probably was that person who brought what was needed to the table. As such, perhaps the plan is not what ended up mattering so much as having someone who was willing and able to push it through. Also, having the right people from top to bottom. My feeling sometimes is that effective teams occur almost randomly. This might be because organizations rarely have the patience or the resources to assemble them deliberately.
Particularly: "perhaps the plan is not what ended up mattering so much as having someone who was willing and able to push it through.". This is very true. It was a combination of having tenacity to grind through a lot of politics and repetitive conversations and doubts that everyone had, while also addressing extremely real technical and process issues. Previous leaders often brought one or the other to the team: they either knew what needed to be done technically but couldn't push a plan through, or were politically savvy enough to get changes implemented but they just ended up moving deckchairs around. When I stepped in, I inherited a team that did this twice previously and everyone had zero trust and learned helplessness. I wrote this up and tried to emphasize the slowness of the process and the fact that it wasn't a "one simple trick" type approach because that was the case.
Or: "If no one will listen to you or take your advice, it's worthless." This is true. We had a few really brilliant developers cursed with a cassandra complex: they correctly identified the problems but given their way of communicating, they actually fostered resistance to the changes. Communication of the plan and building consensus is as important as the plan itself, if not moreso. Every plan will need to be adjusted based on reality and context, but as long as you build consensus and goodwill, you'll be able to have that flexibility.
With regards to your point about technical staff, we were an enterprise sales organization where decision making was concentrated in the finance and sales departments. It was extremely sales driven. The reason we were able to push this through was precisely because the company had lost faith in product and engineering to accomplish anything after a series of poor launches and chronically missed deadlines. I actually think the problem is that if engineering leadership did have more trust, they would have pushed back on this. It didn't look good to "give up and try to just do one thing at a time" as we did. For most organizations, that's painfully radical. But in the words of Munger/Buffet: "Don't just do something, sit there!"
* Technical staff in an organization feel they have no authority or respect within the organization. This can happen when companies become too sales-driven.
* Senior technical staff feel they have no ability to delegate, either because of the previous point or because they don't trust the technical ability of less senior staff.
* Those in an organization who do have authority to delegate lack sufficient understanding of priorities or lack technical knowledge.
These things highlight the classic balance between technical knowledge and managerial skills. If you don't have people that bring both to the table, you're in for trouble. Not sure if I'd go so far as to say this is what it's all about. However, reading over the author's advice, I thought to myself, "None of this could have happened at some places I've worked." You can come up with a good plan, but if no one will listen to you or take your advice, it's worthless.
The author probably was that person who brought what was needed to the table. As such, perhaps the plan is not what ended up mattering so much as having someone who was willing and able to push it through. Also, having the right people from top to bottom. My feeling sometimes is that effective teams occur almost randomly. This might be because organizations rarely have the patience or the resources to assemble them deliberately.