Making Change Happen


Many good books are available on how to make change happen in an organization. For reference, I've included some of my favorites in Appendix 4.

I wish it were possible to provide a template for making change happen. Something along the lines of: If you're a programmer and want to change your organization to sustainable development, do this, then that, say this, etc. My personal experience with leading change has been that every organization is different, that this is particularly true of software organizations, and that software organizations are especially difficult to change. The problem I think stems from many factors, including:

  • Software people come from many backgrounds. I've worked with people who have degrees in engineering, physics, mathematics, astrophysics, computer science, psychology, sociology, English, music, business, and accounting. Many of my co-workers have had multiple degrees; some have even had no degrees.

  • In many organizations people who understand amazingly little about software development, sometimes appallingly so, wind up managing the organization. Note: I'm not necessarily saying this is a problem. I have worked for some managers who are excellent at knowing what they don't know and who to askalthough I've also worked for managers who don't, which is a problem. It's difficult to find good managers who love both business and software development. Usually, people with a sales or financial background and/or people who have written a few lines of code sometime in the past are the ones who wind up in control because they tend to be more extroverted and/or charismatic than most technical people. Management is only a problem when it is bad or incompetent.

  • Many organizations do not discuss or try to consciously foster their culture and development practices or pay attention to key people issues such as professional development and leadership. Instead, they focus on projects, schedules, and results. While there is no question that results are important, if the bottom line is the main focus then there is a problem.

  • There are a lot of incredibly bright people in software organizations. On just about any topic of importance there will be no shortage of opinions. This can be both good and bad depending on the topic at hand, and it can lead to situations where creating consensus is difficult or even impossible. However, being bright in a problem-solving sense doesn't necessarily translate into being a good communicator. Many people in software organizations are good talkers but not listeners, and some are not very good at expressing their opinions in a respectful way. Hence, while having a group of bright people may seem like a good thing, when it comes to making change happen, sometimes the fact that everyone has an opinion and that some people are poor at expressing their opinions means that resistance to change can be quite high. Or, resistance might just seem high because people are usually very good at expressing displeasure but not as proactive as they should be at providing positive feedback.

  • Software education lacks standards and a poor understanding of what the basics are. Most people learn more about software development on the job than they do in school because only in the workplace are they confronted with the task of maintaining a million lines of code for ten years or joining projects where a large amount of code already exists and the people who wrote it are no longer available. I also know people who have graduated from top universities in computer science who have been well schooled in theory such as NP complete problems but haven't taken a course in compilers or computer construction!

  • People don't like being told how to work. They want to be able to choose the best approach based on learning. Hence, the challenge with achieving culture change is finding ways to achieve complete buy-in and then helping and providing advice as required.

  • People are different. Consider this basic list of character traits: introvert, extravert, opinionated, stubborn, consensus-builder, excitable, emotional, and restrained. Software developers tend to be introverts. Sales and marketing people tend to be extraverts. Add age as a factor as well: Older and more experienced workers tend to be more jaded by past experiences (or perhaps they are just more relaxed).

  • Organizations are complex simply because of the mix of different people, for better and worse. What will work in one organization likely will not work in another.

  • Complacency. We almost always underestimate the effort required to introduce change into an organization. Complacency is often at the heart of failed change efforts because if your co-workers don't understand the need for change they won't actively participate.

  • It's hard to admit that you have to change, too. We tend to generalize when things get uncomfortable. Driving a car is a perfect example. When asked, we consistently say that there are too many jerks on the road and that other drivers cause the problems. And yet that clearly can't be the case because someone has to be the other driver. Few people admit that they need to improve their driving skills when actually we should all be continually striving to get better.

  • Try this experiment with your co-workers. Have all of them cover their eyes and ask people to raise their hands if they believe they are open to change. Then, with eyes still covered, ask people to raise their hands if they believe other people are unwilling to change. What you will invariably see is that virtually every hand will be raised in response to both questions! The implication should be obvious: that while you may think you are open to change, the impression you give to other people may be different. Change has to start with you and it is your responsibility to find ways to engage others.

None of these factors is catastrophic. They're really just the people factors you need to keep in mind when considering how to introduce change into your organization. People, and the culture they have built for themselves, are probably the largest variable between organizations. People and culture are also the largest potential barriers to change. You have to recognize that any change challenges the comforts that have been built up over time.




Sustainable Software Development. An Agile Perspective
Sustainable Software Development: An Agile Perspective
ISBN: 0321286081
EAN: 2147483647
Year: 2005
Pages: 125
Authors: Kevin Tate

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net