When leaders make a change, they want buy-in. But they way they present a change may prevent that.
I had a conversation with a manager who wanted to improve communication between teams in his organization. While in theory all the teams were working towards the same goal, in practice it looked different. Their efforts weren’t well coordinated—or even coherent. One team would advise their client to do X, and another would provide training for Y. One team was working on a voice of the customer effort, when the main goal for the larger tech department was reducing cycle time.
The manager was frustrated and so were the teams—he heard it in one-on-one meetings and saw it in survey numbers.
The Problem: A Polished Proposal
So the manager designed a new process for all the teams to use. He hoped the teams would offer feedback and refinements.
He did the big reveal on a Monday. Gathered all the groups, and presented the process. He’d thought it all through, and made a slideshow complete with information flows and checklists.
When he finished his presentation, he asked for input. “I want to hear your feedback,” he said. “This needs to be your process, you need to own it and make it yours.”
The response was ….. crickets…..
I know this manager had good intentions, and I’m pretty sure he had a bunch of good ideas.
However, even though he said he wanted input and shared ownership, the way he went about it said “mine, mine, mine.”
The Principle: Let People Get Their Fingerprints on It
The manager—and I see this a lot with process design groups, coaches, change management teams—didn’t really leave much room for people to participate in shaping the process. When something—a process, method, decision or idea—comes off as a finished product, all done and ready to go, it’s far less likely that people will chime in with their ideas.
The more polished the presentation, the less likely people will feel that they can make any changes—no matter what someone says about “making it your own.”
Furthermore, the fact of the manager’s positional power made it less likely people would bring up issues or flaws. In many organizations—maybe most—telling your boss his baby is ugly is a career limiting move.
And many managers are taught this is what they should do… Design processes for others to follow. Figure stuff out. Get people to follow the process. But people are much more likely to follow a process that both serves a purpose and suits them.
To accomplish this, make it easy for people to get their fingerprints on a change.
When people play a part in defining and designing or refining something, they are much more likely to feel ownership of it… And they’re much more invested in helping whatever it is to succeed.
Involve people early. From the start. Waiting until you have a finished product to ask for input is, ummm, not really asking for input. Even if you really do want input, a polished product looks finished. And many people are reluctant to comment on a finished product, because they consciously or unconsciously believe it won’t change.
Think about giving online feedback on a book, for example. You can write a book review saying you like or dislike a book, but your review will not change the book (though if enough people dislike the book, that may change how well the book does).
If you ask for feedback on a finished product in a meeting, it is an extra whammy… Little time to internalize, little time to consider deeply, and the friction of speaking up.
Now, this doesn’t mean you have to involve everyone every step of the way.
But when you do show your work, make it sketchy rather than polished. Use a sketching tool (or pencil and paper) rather than a vector graphics tool. Flip chart and markers vs. a powerpoint presentation. Sticky Notes rather than an annotated graphic. In this way, your visuals will be congruent with your request.
Leave something for people to do—add, refine, fill in, revise, fix, polish. This communicates that it really isn’t a finished product. Sometimes I will leave gaps on purpose, which can encourage people to fill things in.
So if you want people to own something, let them get their fingerprints on it:
- Don’t wait until you have a finished product to get input.
- Get input about both the problem and potential solutions.
- Leave plenty of rough edges, so people can help smooth and shape them.
- Allow for local variation if you want people to make it their own.
If you do this, you’ll get buy-in, not just compliance!
The Trade Off: It May Seem Like it Takes Longer
Now, it may seem like it would be faster to figure something out on your own and present it as a done deal. But that’s because you’re only accounting for one part of the change… the design part.
Getting people to actually follow the plan or accept the change can take a verrry loooong time—especially when it feels imposed or like there was a request for faux input.
You get to choose… You can spend time including people, or spend time persuading, pushing and prodding them.
When you involve people who are doing the work in defining the problem, you’ll gain a better understanding of the problem.
Then involve them in developing candidate actions. You’ll get a broader set of ideas.
Then involve them in choosing. You’ll get broader support.
And while you do this, you’ll be helping people see their work more broadly and more systemically. You’ll be helping people see how their work impacts and interacts with other parts of the system.
Surface compliance, dis-engagement, divorcing people from ownership of their own work and diminishing autonomy…
When you consider the other costs, it doesn’t look so good.
I know which I’d choose.
Not all stories have happy endings.
The manager felt a bit put out and insulted that people didn’t have much to say about the process he had designed to help them. He did it for them, after all. To him, it seemed the team was ungrateful, and didn’t understand how important the process was and how it would benefit them and their clients. He interpreted his team’s silence as lack of initiative and responsibility. And it showed. He became more directive. Mutual resentment grew. And client satisfaction went down.
Which is too bad, because the process could have helped… Had it been the team’s process, not the manager’s.
Basically, TDD instead of BDUF (Test Driven Design instead of Big Design Up Front)… a common shift for any agile team ;o)
great artical. Thanks
Really nice article. Thanks Esther.
Thanks a lot for this article. I am completely on your page, that it is more than important to include the people into the change, but reading your article I always thought “But it takes so much longer to do it that way.” until I finally read: It May Seem Like it Takes Longer …I really had to laugh. Like you read my mind here.