Configuration Managers: Fighting the Resistance to Change
What’s the biggest problem configuration managers face? That’s the subject of a current discussion within the configuration management group on LinkedIn. There are lots of good points being made, but the one that hits me front and center is titled “Resistance to Change,” posted by contributor Joni Brown.
“If it ain’t broke, don’t fix it” goes the saying. But when it comes to CM, it seems that even if it is broke, nobody wants it fixed, except of course the CM manager. OK, perhaps that’s a bit oversimplified. I know a lot of developers, managers, and others who want their CM fixed.
So, the biggest roadblock is resistance to change. Why is that?
It’s quite simple, really. It typically takes a lot of effort to get comfortable with a new tool or process. People get comfortable doing what they have to do, even if it’s tedious. So they respond, “Don’t make me learn something new just so I can satisfy your needs.”
There are two issues here: How hard is it to learn something new? and What’s in it for you if you have already met your requirements? These are key questions. The fact is, if you want someone to change, you had better be making their lives easier, and you had better be giving them big value in return.
Too many new CM tools are command line tools (see GIT and Subversion). I get endless “free seminar” emails asking: What’s new with the diff command? How can you use the list command to get more information out? and How can you commit part of your working copy with changelists?
These “free” seminars cost a lot of money in terms of developer training time. Worse than that, dozens of such seminars combine to make the developer an expert, through a great investment in time. Why would an expert want to invest time in a different CM tool or process?
And resistance is not limited to developers. All users, including CM managers, exhibit the same behavior. I’ve met many CM managers that want to stay with ClearCase because of the company’s personal investment in becoming an expert. And seeing how much effort it was to learn all of the tricks and pitfalls, I can see why they would not want to go through it again.
But tell them that they won’t have to work long hours anymore and that they can become experts—not only in version control, but in the entire CM backbone of their company—and maybe they’ll give it a second thought.
Similarly, if you tell your developers that you’ll eliminate training time and give them some real added value (see my CM story, “Is Your Software CM a Burden on Developers”), you should see their resistance to change melt away.
It all comes down to great process and next generation tools. If you try to move sideways, expect resistance. Move well ahead, and you’ll be a champion.
