Spoon-Feeding Change
When a new idea or change is not accepted, it is frequently due to a communication failure. Not informing folks is an obvious problem. However, introducing too much all at once can be equally problematic.
I have been thinking about this problem for a while. Here’s my summary of the problem, the tenets, and the recommended solution. Please provide your comments before we roll this out to the rest of the team.
That is too much information up front. You are pedaling at 30 mph, whereas the team is only gearing up to go on a bicycle ride. The result is often chaos. Some folks are disagreeing on the original problem description. Others don’t like the solution. Others may have a different vision of where we should be going and don’t even think this is a problem. You are off to series of frustrating meetings and discussions.
Instead, try spoon-feeding the change. Break it into pieces over different discussions, and get buy-in before you go to the next step.
Agree on the problem
Here’s a problem I observe. Do you agree? Did I capture the problem correctly? Do you agree with the stated assumptions (aka tenets)? Do you agree that it is important to tackle this problem now? Who should be involved in finding a solution to this problem?
At this point, you end up with a crisp description of the problem and its tenets.
When there is agreement on solving the problem, you can open the door to discussing areas that can help find the solution. We aren’t proposing a solution yet. We’re looking for ideas or degrees of freedom that will allow us to craft a solution offline.
Is it useful to talk to Phoebe’s team? What if we change the customer return policy? Do we need this process? Do we have the budget to hire a contractor?
If there is no agreement on the problem, it is possible we need to take a step back and discuss the vision and priorities.
Do you agree that the top priority is blah, and that we are willing to give up blah to achieve it? Considering the company objectives, why do you think this is a problem to tackle?
For example, if the priority is to ship a new feature fast, then hardening the code base, and solving the problem of too many false positives from static analysis, isn’t something we should be focussing on.
Now, end the discussion and go work on a proposed solution.
Agree on the solution The debate on how to solve the problem will be more focused when we are all trying to solve the same problem. You may need to remind folks from of the agreed problem and assumptions, as you are discussing solutions.
That’s nice, but that’s not the problem we are solving.
Based upon your comment, do you think assumption 2 is not longer true?
Agree on the roll out plan Now that you have allies on the change, the roll out will be easier as well.
By going slower, you will achieve change faster.