I've improving quality on software teams for 20 years now. These are a few ways I approach change in the workplace. Typically this means things like agile practices or exploratory testing, but it probably works for anything.
Typically, we assume that:
The current state is completely and utterly shit. Anyone that disagrees is a clown.
The desired state is rainbows and doves. It must be true because it's my idea.
To get from current to desired, we follow the pre-ordained steps. I'll lead the way!
And that's where the trouble begins!
Start from where you are.
Instead of wishing things were different, accept reality.
This means two things need to happen:
You need to understand where you are.
The next step mustn't be huge.
For example, saying that I'll win the next London Marathon ignores both those things. Saying that I'll set a PB at the next London Marathon is better. Jogging around the block, assessing my time, physiological condition, etc. then deciding my next move is probably the best option.
On our software teams, we often try to change allTheThings at once without really knowing why understanding what problem we're trying to solve and or which direction we're heading in.
Frame what you want in terms of what they want.
Everyone has their own agenda. Not because of any nefarious plot (ok... not always because of that). People are just naturally self-interested.
Imagine a place nearby that serves the best bacon sarnies in town. You want to go but not alone, so you ask me to come.
Now, I'm a Muslim vegan (true story).
How persuasive will it be to describe how wonderful the bacon buttys are? (For those following along at home, the answer is not very!).
Likewise, in our delivery teams, imagine I want to improve testability. Should I talk about how it makes things easier for me? What about:
The developer context switching from an in-progress complex feature to difficult to investigate live production issues?
The PO trying to deliver as much value to customers but also fighting against longer than expected lead times?
The customer support engineer dealing with constantly changing features and fielding queries from confused customers all day?
Do these folks care much about your testing problems? Unlikely. Not because they're terrible people but because they're busy, stressed and have their own issues.
Look for the friction.
What factors in the system act against the stated aims or goals of the system?
What you're looking for are perverse incentives:
Salespeople close deals for features that aren't profitable to implement.
Tying performance to individual goals rather than team goals.
Batching releases together because they're difficult and take too long, so you batch releases together because they're difficult and take too long, so you...
When you're alert for unintended consequences in the system, the less chance a chaotic situation will blindside you.
The more you listen and observe, the more aware you become of the situation. The more aware you are, the easier it is to identify the next step.