Change should be a friend. It should happen by plan, not by accident.
– Philip Crosby Reflections on Quality
Users will change their habits when the pain of their current situation is greater than their perceived pain of adopting a possible solution.
– Pip Coburn The Change Function
When our daughter was a toddler, she suffered from repeated ear infections. The standard treatment at that time was Amoxicillin, an antibiotic dispensed as a thick, pink liquid that tasted awful. Our daughter hated the stuff and resisted taking the medicine, even though we told her it would make her feel better, which it did.
When her ear infections continued to recur, her doctor suggested putting tubes in her ear drums, a procedure that allows the ears to drain, making them less susceptible to infection. We chose to do this, and it solved the problem. Because our daughter was too young to understand what was happening, and because the doctor used an anesthetic, the procedure was at worst a bit uncomfortable for her, and unlike her parents, she suffered no anxiety about the procedure in advance.
However, consider if it was you, rather than your toddler. You probably wouldn’t think twice about taking a nasty tasting medicine if it would help. And, you’d probably accept an injection in your arm, though maybe with a little anxiety. But, I suspect that you’d react much more strongly to the prospect of putting a tube through your ear drum. You’d probably question the doctor about the efficacy of the procedure and look for a way to get relief without enduring the perceived pain of putting a tube through your ear drum. Your perception of the procedure and that of the toddler are almost completely reversed, even though we’re talking about exactly the same condition and treatment.
Technology changes in the work environment are a lot like ear infections. You complain about the pain, maybe impaired productivity, and when someone suggests a way to fix the pain, maybe a new technology, you weigh the potential benefits versus the perceived pain of adopting the fix. If it’s the equivalent of taking medicine or getting an injection, you go forward; if it’s the equivalent of punching a hole in your ear drum, you probably resist. The problem, of course, is that some of the people affected by the change see it as taking medicine and others see it as the hole in their ear drum.
In this chapter, I’ll look at how you as a manager can facilitate change and make productive change a part of your environment. This is a tough one; the most critical mistakes I’ve made as a manager have occurred when I was unable to bring about a needed change or sustain that change until it became ingrained in the organization. Regardless of how brilliant your proposed change is or how important a particular change may be to the success of your organization, if you can’t gain acceptance of the change or can’t sustain it, you will fail.
Common wisdom is that you need a “Burning Platform” to cause change. A burning platform describes a crisis so painful that you are forced to act. The classic image is that of an offshore oil rig on fire. The prospect of jumping into the ocean is so perilous that the workers won’t jump until it’s clear that remaining on the rig means certain death. Jack Welch, former CEO of General Electric, is famous for using the burning platform as part of his transformation of GE. While he saw clearly the problems he needed to address, he needed the rest of GE to see the same things he saw. His ability to communicate that perception was part of what made him successful in transforming GE.
While the burning platform is effective, using it is an admission of failure. There are situations, and the GE that existed when Jack Welch became CEO is arguably one of them, where you have no choice; you need to point out the flames, maybe fan them a little, and move ahead with radical change. But, if your team won’t make a change unless the flames are licking their feet, then you’ve got two crises on your hands; the flames and a team that hasn’t embraced change as part of their normal day to day work.
I’m suspicious of the burning platform. I’ve seen managers try to generate a burning platform out of whole cloth. As you might guess, this is pretty much guaranteed to backfire. People may disagree about the severity of a problem, but they will usually agree as to whether the problem exists. If you try to manufacture a problem, your team will know, and in addition to deciding you’re a moron, they will resist change.
The other place where a burning platform will backfire is when you’re standing on the burning platform, but your team is happily treading water near shore. Unless the people who need to change feel the flames licking at their feet, they won’t be inclined to move.
If you do have a true burning platform, it can be a catalyst for change, but only if it really is a legitimate burning platform, and only if the crisis affects the people who need to change.
A more nuanced, and to me more compelling, view of change is described in Pip Coburn’s book, The Change Function[Coburn06]. Coburn argues that change is a function of “perceived crisis,” how bad you think things are, and “total perceived pain of adoption (TPPA),” how hard you think it will be to change. Regardless of how compelling a technology may be on the surface, it will not be adopted unless people believe that the “pain” of changing is less than the “pain” of remaining in their current situation.
This explains why some technologies, as cool as they may be on the surface, are never widely adopted. The classic example is Picturephone, which doesn’t address a compelling “crisis” for most people, and which has a very high perceived pain of adoption. Another example is the Segway, a very cool technology that doesn’t address a strong enough crisis to overcome its TPPA.
An important aspect of the “change function” is that it is a function of the potential user’s perception. For example, consider RFID (Radio Frequency Identification). RFID is a technology that performs the functions of bar codes without the need to directly scan information. Instead of a bar code reader, which needs to be positioned where it can visually read the tag, you can read an RFID tag at a distance using a specialized radio receiver.
If you live in or near a big city, you’ve probably seen toll roads or bridges that use RFID technology with names like EZPass, Fast Lane, and Smart Tag. If you have the right device, you can drive through an RFID equipped toll booth without stopping; the system registers your passing by reading the RFID device and debits your account for the toll. RFID has been a big success in this application. It provides a clear benefit to the user (speed and in some places a discounted toll), and a clear benefit to the vendor (fewer delays, fewer toll booth attendants, and often a chunk of pre-paid cash).
RFID is also used to tag merchandise. Big retailers like WalMart like RFID because it speeds up the handling of merchandise and gives them more control over inventory. However, to do this, their suppliers need to also adopt RFID, at considerable cost. Since few of the benefits accrue to these suppliers, there has been at best lukewarm adoption of RFID, much of which can be attributed to arm twisting by retailers who have the clout to force their suppliers to use it. These users don’t perceive a benefit that is worth the pain of adoption, so they resist the change.
Many of the highly touted documentation technologies, such as content re-use, XML, and Content Management Systems, promise to relieve one or more aspects of a corporation’s perceived crisis. Given that these documentation technologies provide significant benefit to the corporation—an assumption that can and should be challenged before adoption—they also need to provide significant benefit to the actual users or their adoption will be troubled.
I have spent years trying to move organizations towards better structured and more productive environments. Some of those efforts have been successful, others have failed. Along the way I’ve picked up some hard lessons that may be useful.
Probably most important is that people respond best to concrete, personal and urgent challenges. If your house is burning, you will act and act quickly. If it’s not burning right now, you’re less likely to promptly fix wiring problems, replace batteries in smoke detectors, buy a fire extinguisher, or take other simple preventative actions. This is one reason why the burning platform is effective; it is concrete, personal, and urgent. As you look at the suggestions below, consider that any of them will only be effective to the extent that they address concrete, personal, and urgent concerns.
Let’s look at the four critical things you need to consider as you face change. Most of what follows is written in the context of technological change, especially the adoption of new technologies. However, the concepts apply to other kinds of change, too.
As manager, you must have a clear understanding of the reasons for change. If you don’t, stop right here and make sure you understand and can articulate why it’s necessary to change.
Your job in communicating the perceived crisis is to make the the current situation and the reasons for change concrete, personal, and urgent to everyone who’s affected. In addition to your team, this includes your management team and any other team that’s affected.
Here is where the notion of a Burning Platform may be useful, especially if you have a true crisis on your hands. Don’t be shy about outlining the dangers in your current situation and the importance of changing, but at the same time stay real; your motivation for change needs to withstand scrutiny and make sense to those who you’re trying to convince. If you misrepresent the situation or artificially inflate things into a crisis, they will figure it out sooner or later.
Make sure as well that you portray the current situation in ways that apply directly to everyone you need to persuade. I have been in situations where I made a compelling argument to writers for a change, but neglected to make an equally compelling argument to management, with the result that management saw no reason to support the change. Everyone with a stake in a change needs to have a reason for supporting it.
The perceived crisis is half of Coburn’s “Change Function,” and therefore is critical to leading change. But, it is very easy to forget about the perceived crisis and skip to the perceived benefit, especially with new technology. You need to separate real need for change from the “Gee whiz, wouldn’t it be nice” glow you get from cool technology and the salespeople who push it. If you can’t identify a real need for change, you’re in trouble.
The desired future state defines the point you’re aiming for. As with perceived crisis, you need to be able to articulate the desired future state clearly and specifically for each constituency. If you can agree on the perceived crisis and the desired future state, you’re halfway to making change happen.
However, it is very easy to get off track. The most common, and very dangerous, mistake is to confuse defining the desired future state with defining a specific means for reaching that state. If you start discussing the future state in terms of specific technologies or methodologies, the chances are that you’re making this mistake. The danger here is that humans love to solve problems and will happily dive into proposing solutions before they even know for sure what the problem is. Therefore, make sure you define the desired future state, in terms that pose as few constraints as possible on the solution, before you dive into problem solving.
Once you have a common understanding of where you are and where you need to go, your job leading change becomes easier because you now have a framework for engaging your team and other affected parties in defining the details of a solution.
In many ways, the most important detail in planning a solution is deployment. Paradoxically, the deployment of a solution can be more important to adoption than the solution itself, and is often more difficult to pull off. A good deployment is one that minimizes the Total Perceived Pain of Adoption for your solution. No matter how good your solution is, if the TPPA is too high, it will not be adopted except by sheer force.
The question of how to pick a good technical solution is discussed elsewhere. For this section, let’s take a look at some of the factors that affect TPPA.
- Phasing: A solution that requires a major one-time shift in process or tools will usually have a higher perceived pain of adoption than a solution that can be phased in over a period of time in smaller steps.There are dangers in phasing. It’s easy to lose momentum, either with your team or with management. The latter is especially dangerous because corporations live in the short term, and it’s distressingly common for new management to torpedo the projects of their predecessors. At the same time, trying to make too big a change at one time can stop you dead in your tracks before the project has gone anywhere.
Here are some of the keys to keeping momentum going:
- Make sure each phase delivers benefits to both your team and management.
- Front load expenses as much as possible so that you don’t need to ask for money separately for each phase. If you can’t do that, try to make each phase cheaper than the previous one.
- Front load the user benefits, too. Once users see the benefits to them, they will become advocates for subsequent changes. This also gives you good news to communicate to management.
- Make sure each phase stands on its own. That way, if you’re cut off in mid-stream, you will have a workable environment.
- Communicate progress widely and frequently. Make sure users and management are frequently reminded about the great things you’ve already accomplished, the greater things about to happen, and the amazingly wonderful future that’s just around the corner.
- Participation: Part of keeping momentum going is keeping participation active and positive. On one project, where I managed both the engineers developing the tools and the people using the tools, I let users attend the developer’s meetings. While there were some topics that didn’t interest users, having them there kept their issues in front of the developers. The result was that the development was in many ways led by the users, who then became committed to the project and later on helped recruit and train other users.The other critical part of participation is keeping management informed with frequent updates. This is a case where “out of sight” really means “out of mind.” If you don’t keep your managers informed, they will get their information from other sources, most of who won’t have the same investment in success that you do. If you’re unlucky, they may get information from sources that would be happy to see you fail. While it may be hard to keep naysayers away from your managers, you can make sure that both good and bad news comes to your managers from you first. Also, make sure they see demos frequently, so they can get a tangible sense of what you’re doing.
- Training: Every time I’ve ever proposed a change to a new technology, one of the first questions is always, “how are you going to train us?” I’ve found that resistance to change is inversely related to the amount and quality of training available to users. Don’t ignore training or offer it half-heartedly. Instead, plan for it from the beginning and factor in the cost, both the cost in dollars and the cost in the time your users will need to learn the system.On the project mentioned in the previous section, the developers trained the first users, who then trained later users. In the right situation this will build a strong, committed set of users. However, most of the time you need to get people working quickly and can’t afford to have them spending time training other users. Therefore it’s probably best to plan for formal training from the vendor or a skilled third party. This will be especially true if you’re moving to a widely used technology.
Most of what I’ve discussed in the previous sections has to do with managing the introduction of new technology. Of course, as a manager, you need to deal with many other kinds of change as well, some of it planned and some of it unplanned. I’ve found that the best strategy for dealing with change in this general sense is to follow the advice of Philip Crosby in the epigraph to this chapter, “Change should be a friend. It should happen by plan, not by accident.”
The best way to do this is to make change part of your environment. You need to be constantly looking for ways to improve your product and your productivity, and you need to be constantly implementing those improvements as you see them. A team that is continuously looking for and implementing improvements will see potential problems and avert them long before they become burning platforms. They will also learn to embrace change as normal, rather than seeing it as an aberration.
I use several techniques to keep change “in the air.” One of my favorite techniques is to regularly float crazy, and sometimes not so crazy, visions of the future. The Release Note project discussed in ??? is an example of this. I probably drove the Release Note author crazy dropping by and brainstorming about a future where the release notes were kept in a database as modules and assembled automatically for publication. At the time, we didn’t have any particular problem, but we did have room, as you always do, for improvement. I didn’t force a change, I just painted a picture of the future. The writer grabbed this vague idea and ran with it, coming up with a structure that took the first step towards the change discussed in that section.
Another way to keep change in the air is to constantly question what you’re doing. Is your current structure the best it can be? Are your interactions with engineering as smooth as they should be? Is there a more effective or efficient way to create deliverables? What would your documentation look like if you weren’t limited by tools, techniques, or schedules? If you find limitations, how can you remove them? By regularly asking these kinds of questions, you engage your team in a constant dialogue focused on continuous improvement and change.
Your own attitude towards change is critical. Keep your mind open when members of your team or management propose change. If you don’t take them seriously, they won’t take you seriously. If you have concerns about a proposed change, use the suggestions in this section to help clarify everyone’s understanding of the current situation, proposed future state, and the means for getting from the former to the latter. Even if the proposed changed is mandated by management, and you have no choice but to implement it, you can still take the time to understand the motivation and communicate it in the best possible light to your team.
In the end, not matter what you do, you will constantly face change, some welcome, some not. Having both a good attitude and a strategy for dealing with change will put you ahead of the curve. You will see the need for change and take action before change gets forced on you, you will have the tools needed to make the best of unwelcome change, and you will keep your organization happier and more productive.
Copyright © 2007 Richard L. Hamilton