Change: Incrementally Making Things Better (Part 2)

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/change_incrementally_making_things_better_part_2.htm]

Part 1 (Intro)

Part 2

Part 3

Part 4

Part 5

Part 6

 

What encourages people to change?

 Ultimately all change starts with people. Even if you buy a new tool or framework, you need to convince people to use that new thing (or at least cooperate with it). And remember, "A man convinced against his will is of the same opinion still." You cannot effectively force knowledge workers to change, you must make it a "pit of success" - where it's easy to do what's right and hard to do what's wrong.

If it all comes down to people, then what causes people to change? Two things: the avoidance of their pain, and the pursuit of their pleasure. For example perhaps a developer is receptive to code generating the data access layer because they're sick of writing thousands of lines of brittle ADO.Net plumbing. Or, perhaps they want to start unit testing and refactoring because they get an intrinsic joy in seeing beautiful, automatically tested, code.

 The flipside is "what causes people not to change?" Assuming the change itself is a good and profitable idea, there could be as many answers as there are people:

• They're content now, and the change doesn't benefit them ("if it ain't broke, don't fix it").
• The change isn't worth the cost (let's force everyone to rewrite legacy code to adhere to the new naming convention).
• Their nature is to resist new ideas - some people are just naturally stuck in their ways.
• They don't want to change too quickly - people need some stability to cling too.
• The person proposing the change has a bad track-record, so people don't want the risk.
• They're too busy to even think about it (this plays into the "downward" spiral").
• Ego - it wasn't their idea.
• They have some hidden agenda that they're not explicitly telling you. For example, the change may be good for the company as a whole, but it will personally cost them (such as longer hours, or putting them out of a job)
• FUD (Fear, Uncertainty, and Doubt) - hey, people are still people.

You likely can't change the fundamental nature of the team. A startup will be different than a huge bureaucracy, a private company different than a government agency, an industry IT department different than a consulting group. Think of it like sports teams: you can help an average football team be great, but you can't make it a baseball team. If you want to switch baseball, you'll need to join a baseball team.

 So, any attempt to instigate a cultural or infrastructure change is going to need to address it from both sides: encourage people to change and removing the obstacles that block change.It will also need both top-down and bottom up support. With only top support, it becomes an "ivory tower". With only bottom support, it becomes a "misguided effort" or "postponed project until the schedule opens up". To make things happen, you must work at both ends. Getting into the right mindset

This is one of the many lessons I've learned the hard way. If you want to help change the department, you must put yourself in the right mindset. You're absolutely not going to simply strut into a demo room, show a flashy prototype with a buzzword-filled PowerPoint slide, and then have everyone ooh and ah at your brilliance and "see the light". Even if you have the best idea in the world, you're going to need patience (it will take time), perseverance (9-to-5ers don't change departments), and empathy (you're dealing with people).

 In the hopes that you can learn from my painful mistakes, these types of things will not work:

• Complaining - It may feel good to tell your desk buddy how crappy the whole thing is, but negative venting will not bring positive results.
• Telling how wonderful your perfect past project was - People will think "If your last place was so good, then why don't you go back there?"
• Muttering "I told you so" after a failure - This is what you expect in junior high. People will just resent you or say you're a Monday-morning quarterback.
• Trying to boil the ocean - Sure, "if we just completely wrote all 5 million lines of code by October..." Stop it. This will never happen. Stop even thinking it.
• Pulling rank - You may be able to temporarily use your job title to force people to change, but if they don't buy into it, they'll just game the system. So you set up a required "root-cause-analysis" text box on the issue change form so you can better track what's going on - busy people will just type "aaa" into it.
• Sending one-line emails saying "this looks good" - change needs to be like a hungry dog that attacks the problem and won't let go until it's digested. Tossing some links around will just bounce off people's busy schedules. Anyone can send out email links.

As Paul Glen explains in Leading Geeks, while you can control behavior (think supervisor in a factory), knowledge work isn't based on behavior - it's based on someone's thoughts. And you can no more control someone's thoughts than you can tell the sun to stop shining. Therefore changing people is impossible. All you can do is create an environment that encourages people to change, and this will take every good character trait you can muster.

NEXT:  Part 3