OP here. I think those are good points. Particularly: "perhaps the plan is not what ended up mattering so much as having someone who was willing and able to pu

OP here. I think those are good points. 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!"