William Bridges, an expert on helping organizations and businesses make transitions and shifts says that, “what most people resist is not change, but transition.” And yet those words are used almost interchangeable when they do not mean the same thing.
“Change is a situational shift. Getting a new job is a change, getting a promotion, losing your job, moving to a different home, going to a different school, losing a loved one (which is a huge one.)
Transition on the other hand, is the process of letting go of the way things used to be and then taking hold of the way they will become. In between letting go and the taking hold again there is a chaotic but potentially creative period where things aren’t the old way, but aren’t really a new way yet either. Transition is the way that we all come to terms with change. Without transition, a change is mechanical, superficial and empty.
I found the following case study from William Bridges book entitled, Managing Transitions: Making the Most of Change to be a great example of how to integrate transition management to your company.
Case Study
The software company’s service unit did most of its business over the telephone. Individual technicians located in separate cubicles fielded callers’ questions. The company culture was very individualistic. Not only were employees referred to as “individual contributors,” but each was evaluated based on the number of calls he or she disposed of in a week. At the start of each year a career evaluation plan was put together for each employee in which a target (a little higher than the total of the previous year’s weekly numbers) was set. To hit the target brought you a bonus. To miss it cost you that bonus.
Purchasers of the company’s big, custom software packages called to report various kinds of operating difficulties, and the calls were handled by people in three different levels. First the calls went to relatively inexperienced individuals, who could answer basic questions. They took the calls on an availability basis. If the problem was too difficult for the first level, it went to the second tier. Technicians at that level had more training and experience and could field most of the calls, but if they couldn’t take care of a problem, they passed it on to someone on the third level. The “thirds” were programmers who knew the system from the ground up and could, if necessary, tell the client how to reprogram the software to deal with the problem.
Each tier of the service unit was a skill-based group with its own manager, who was responsible for managing the workload and evaluating the performance of the individual contributors. Not surprisingly, there was some rivalry and mistrust among the different levels, as each felt that its task was the pivotal one and that the others didn’t pull their weight.
As you may have surmised, there were several inherent difficulties with this system. First, customers never got the same person twice unless they remembered to ask. Worse yet, there was poor coordination among the three levels. A level-one technician never knew to whom he was referring a customer—or sometimes even whether anyone at the next level actually took over the customers when he passed them on. Customers were often angry at being passed around rather than being helped.
Managers were very turf-conscious, and this didn’t improve coordination. Sometimes the second-tier manager announced that all the “seconds” were busy—although this was hard to ascertain because each technician was hidden in a cubicle—and then the service would go on hold for a day (or even a week) while the seconds caught up with their workload. In the meantime, the frustrated customer might have called back and found that he had to start over again and explain the problem to a different first-tier worker.
Not only were customers passed along from one part of the service unit to another, but sometimes they were “mislaid” entirely. The mediocre (at best) level of customer satisfaction hadn’t been as damaging when the company had no real competition, but when another company launched an excellent new product earlier that year, it spelled trouble.
The general manager of the service unit brought in a service consultant, who studied the situation and recommended that the unit be reorganized into teams of people drawn from all three of the levels. (This reorganization is what in the last chapter I called the change.) A customer would be assigned to a team, and the team would have the collective responsibility of solving the customer’s problem. Each team would have a coordinator responsible for steering the customer through the system of resources. Everyone agreed: the change ought to solve the problem.
The change was explained at a unit wide meeting, where large organization charts and team diagrams lined the walls. Policy manuals were rewritten, and the team coordinators—some of whom had been level managers and some of whom were former programmers—went through a two-day training seminar. The date for the reorganization was announced, and each team met with the general manager, who told them how important the change was and how important their part was in making it work.
Although there were problems when the reorganization occurred, no one worried too much, because there are always problems with change. But a month or so later it became clear that the new system not only wasn’t working but didn’t even exist except on paper. The old levels were still entrenched in everyone’s mind, and customers were still being tossed back and forth (and often dropped) without any system of coordination. The coordinators maintained their old ties with people from their former groups and tended to try to get things done with the help of their old people (even when those people belonged to another team) rather than by their team as a whole.
Imagine that you’re brought in to help them straighten out this tangle. What would you do? My next blog post will include a series of questions to ask yourself to test how best to resolve the issue.
