Overcoming Resistance
Esther Derby posted an excerpt of a Management Consulting News interview with Jerry Weinberg where he answers the question of how to overcome resistance, “Yes. Don’t.” Oh, he says more there, and he can say a lot more on the topic, but that’s enough for the intro to this article.
You see, I wanted to write an article with a shining example of a time when I didn’t try to overcome resistance, but used it to advantage, instead. The problem was that I found myself in the trap that Don Gray frequently mentions, that when someone tells you not to think about something, you can’t help but immediately think about it. So what filled my memory was a time when I had tried, eloquently and earnestly, to overcome resistance on the part of my client.
The system being developed was a Java J2EE system that had been in production for a number of years. It was the system that the development team had built as they first learned Java. It worked well–a real testament to the skill and care the developers had applied. It was, however, rather difficult to extend and small changes tended to make odd bugs pop up in other places. The short description is that the code was very procedural in nature, rather than object-oriented. There was duplication where blocks of code were copied and modified for new features. There was temporal coupling where dissimilar things were being done in the same place because they needed to be done in the same HTTP transaction. There were code objects that extracted values from data objects, operated on them, and put them back.
I could clearly see that refactoring this code into good object-oriented practice would reduce the complexity, reduce the unwanted coupling that caused unexpected bugs, and reduce the time it took to add new features. I wrote up a description of the types of changes I was proposing and made my pitch to the team. As I talked about making these changes (and making them incrementally, as we added newly requested features), I could tell that they weren’t really enthused by the idea. I poured on the heat of persuasion, describing the benefits in the short term of the immediate features we were developing. The less progress I made, the more enthusiastic I became, scribbling UML diagrams on the whiteboard and building castles in the air as I pointed out the advantages in the long term of making some significant changes we knew were coming down the pike.
I got nowhere but exhausted. I stopped, wondering how I could get these procedural programmers to understand the benefits of object-orientation. I was trying to figure out what to say next when a senior member of the team said, “I don’t think there’s anyone in this room who doesn’t believe you when you say this is a good thing to do. We just don’t know how to get from where we are to what you describe.”
Oh.
I guess I should have asked more questions.
How did I get over this “resistance” to my suggestions? I can think of three distinct ways, demonstration, discussion, and retrospection. The demonstration is focused around what I did, as I provided examples of what I intended and described how I got from the current code to the new code. The discussion is balanced between us, with questions and suppositions and assertions flowing freely in both directions, between peers. The retrospection lay on their shoulders, where I facilitated the discussion while remaining outside of it. They owned what they had learned, where they wanted to go, and what still puzzled them.
What techniques have you used to get across ideas that don’t seem easily accepted?
I have found that groups contain people who have ideas that are better than mine, the same as mine, or compatible with mine. I use the knowledge and wisdom dormant in work groups by advocating the use of BRAINSTORMING to solve problems. When the top ideas (solutions) emerge, I SUPPORT those ideas. I have experienced that when everyone has an opportunity to share their ideas, resistance becomes a resource for solving problems rather than an impediment.
I got the advice early on that “people are not obstacles.” That’s been most useful to me.
My extension of that is not as good: Often people are overloaded, or have rightfully surmised that the change will not allowed to bloom in their culture or under their leaders (ie the department wants to *seem* progressive). Sometimes they’re so beaten down that they’ve given up hoping. Sometimes they’re afraid. Sometimes they’re exhausted. Sometimes they are straining at the limits of their ability to absorb change.
Sometimes the critic is just acting as the gauge that tells you what the rest of the group are thinking but not saying. But people aren’t obstacles.
An extended version of this post is available as an article on the AYE Conference website: http://www.ayeconference.com/overcoming-resistance/ (now on the Wayback Machine)