Juice. Brady G. Wilson

Push Nearly Stalls an Implementation

      Steve and some of his key leaders are about to meet with their management team. Steve is the leader of a chemical plant and he wants to implement SAP, a technology solution that promises to integrate a broad range of organizational processes and make his people more efficient. Steve and his leadership cadre feel passionate about their point of view. It’s critical to them that the managers understand it. With so much at stake, Steve believes that the best approach is to present the merits of his ideas to others with strength, to passionately push his point of view on the others until they “get it.”

      So, rallying all of his enthusiasm, he lays it out to his management team. He outlines all the facts and stats of why SAP is the best way to go. At the end of his presentation, he asks a perfunctory, “Any questions, concerns, or ideas?” However, every manager knows that Steve isn’t interested in feedback; that he just wants to get this thing implemented, now.

      Sixteen weeks later, SAP is mired in employee-relations problems. Despite the leadership team’s encouragements, ultimatums, and even threats, people seem unclear about the process and hand-offs are not happening effectively. It seems there is not enough group will to get the project over the inevitable bumps. Worst of all, the employees who are supposed to be benefiting from SAP are overtly or covertly finding ways to sabotage the new system. Spotty compliance has created a mess: an ugly hybrid of reports, processes, and systems that are practically useless because they offer neither the comfort of the old system nor the ease and accuracy of the new.

      At this point, Steve calls for help. Group dialogues are facilitated between him, his managers, and his employees. Steve and his leaders receive coaching on a few critical skills:

      • How to set aside their own agenda and inquire into the concerns and goals of their managers and employees without judgment or defensiveness.

      • How to step into their managers’ and employees’ worlds to see their reality.

      • How to reflect back, in their own words, the essence of what their managers and employees are saying so they feel completely understood and respected.

       “People almost never change without feeling understood first.”

      As Steve begins to pull, he discovers some concerns and objections that have some serious validity – concerns and objections that left unaddressed will sink the entire process. For example, he discovers that he had failed to understand the needs and the fears of his end users. He had mistakenly assumed that operators would immediately see the benefit of the new system and wholeheartedly embrace the change. He did not realize that “people almost never change without feeling understood first,” as Stone, Patton, and Heen put it in Difficult Conversations.

      Steve had completely underestimated their paranoia about touching a computer. Seeing this reality helps him understand that the training process for the operators not only was too short, it was rolled out in a way that was guaranteed to turn them off.

      As Steve begins to make his employees feel understood, they admit their own part in the failure – that they had not really done an honest job of understanding the leadership team’s desire to make their jobs easier.

      Steve had believed that there was no time to pull and so defaulted to push. Pushing cost him dearly. Much of the energy expended in the first sixteen weeks was wasted. In the end, although Steve resorted to the pull-first approach, it took him months to overcome the cynicism, lack of trust, and reluctance that he had created by pushing first.

      Let me ask you, do your implementations grind to a halt because the ideas aren’t smart enough or because they run out of energy? Most organizations don’t lack for good ideas, they lack the intelligent energy to implement those ideas. Is the push-first approach sucking intelligent energy away from your implementations?

       Putting the Trust = Speed Equation to Work

      Understanding produces the one feeling that is most crucial to the success of any organization: the feeling of trust. Here’s another statement you can take to the bank. It’s from the book Values-Based Selling, by Bill Bachrach and Karen Risch: “People don’t trust you because they understand you ... they trust you because you understand them.”

      Think about it. The people on your “most trusted” list probably understand you. They don’t misread your motives or misinterpret your intentions. But it’s probably difficult for you to trust someone who misunderstands you. There is an integral relationship between understanding and trust. The deeper the understanding, the more trust is created. Why? Because feeling understood is one of our primal needs. Swiss psychiatrist Paul Tournier puts it this way in his book To Understand Each Other: “It is impossible to overemphasize the immense need we have to be really listened to, to be taken seriously, to be understood ... No one can develop freely in this world and find a full life without feeling understood by at least one person.”

       The deeper the understanding, the more trust is created.

      When someone meets a need as primal as the need to feel understood, we tend to feel that we can trust that person. And trust is invaluable to productivity. As W. Edward Deming used to say, “Trust = Speed.” When trust is in place, decisions can be made quickly and executed without friction. When trust is absent, people sit across the table from you, recognize your idea as a great one, but say, “We better think about it for a while. We’re not sure it will work as well as you say.” When trust is absent, it can take people days of persuading and fourteen pages of justification just to get permission to buy a photocopier.

      Steve’s idea was great. If he had taken the time to understand his employees’ concerns, he could have created trust and trust would have created speed. Luckily, in Steve’s case, all that was lost was money, time, and energy. In some situations, like the one below, the cost of push and acquiesce can be fatal.

       A Big Problem with Push

      In January 1986, Roger Boisjoly and Arnie Thompson, two Morton Thiokol (MTI) engineers, strongly and passionately advocated to MTI and NASA management not to launch the Challenger space shuttle. They had significant scientific and engineering concerns about the effect that cold temperatures would have on the solid rocket booster seals.

      But management would not listen. They marched forward and gave the thumbs up: “It’s a beautiful day, go ahead and launch.” Seventy-three seconds into the launch, the Challenger was destroyed. An O-ring seal in the right solid rocket booster failed, sending seven crew members to their deaths.

      How did this disastrous miscommunication happen?

      • Were the leaders operating from deeply ingrained assumptions? “Engineers are always perfectionists – they can’t see the big picture. All they can see are the picky little things that could go wrong.”

      • Did time pressures win the day with management? “We’ve had too many delays already. If we delay again, we’ll look incompetent.”

      • Was management cocky? “Blow-by is not a serious issue. It hasn’t burned us before.”

      • Were political pressures driving their decision? “We can’t disappoint the White House or we’ll lose funding.”

      • Was it a “sales decision”? Did MTI fear upsetting NASA and losing out on upcoming rocket contracts?

      To add insult (and further injury) to injury, despite the sheer magnitude of this tragedy, NASA still did not adopt a pull-first approach. NASA managers hit the replay button in 2003, seven years later, resulting in the Columbia disaster. Once again, the concern of mid-level engineers – in this case about a possible hole blown in the wing by foam – was squelched. And once again the engineers’ concerns were validated. The shuttle blew up upon reentry, and seven crew members were killed.

      The final report on this disaster contains this harsh assessment: “NASA’s organizational culture had as much to do with this accident as foam did.”

      Wherever