Ask HN: Patterns or anti-patterns for driving technical change within an org?

I'm currently a senior software engineer at my company, and my medium-term career goal is to be promoted to staff engineer (and eventually, principal). I'm aware that one marker of staff-plus engineers is the ability to drive technical change within the organization, and part of doing this is building organizational alignment around such a change. There is a specific, major technical change that I'd love to see implemented in our org. The details of the change aren't relevant here, but I am interested in hearing about specific patterns or anti-patterns around proposing such a change and building alignment around it. I look at this process as very sales-like in nature, so things like: -how to identify the key decision-makers (people who need to say yes, as well as people who get to say no). -where in the org to start building support for the idea (i.e. top-down vs. bottom-up). -how to frame the value proposition in order to maximize its appeal to my audience. Side note- as I'm writing this, I'm realizing that this process is quite similar to enterprise sales, but from within the org as opposed to outside of it. So anyone with enterprise sales experience, please share your hard-won lessons here.