In my last blog, I presented some thoughts about looking at change differently.  While we typically refer to change management as the needs in a company, what most people have difficulty with is not the actual change, but rather, the transitional requirements that a change presents, for example if a company can’t afford taxes when closing you could learn if you Can’t Pay Corporation Tax and how to act in these case.  I also mentioned that I would provide you with a series of questioning techniques to use in discerning how best to handle the situation presented in the last blog.

Case Study:  Please read my previous blog:

Here some questions to ask yourself.
Fill in those numbers before you read further, and take your time. This is not a simple situation, and solving it is a complicated undertaking.

Possible Actions to Take
1 = Very important. Do this at once.
2 = Worth doing but takes more time. Start planning it.
3 = Yes and no. Depends on how it’s done.
4 = Not very important. May even be a waste of effort.
5 = No! Don’t do this.
Fill in those numbers before you read further, and take your time. This is not a simple situation, and solving it is a complicated undertaking.
Possible Actions to Take:
____ Explain the changes again in a carefully written memo.
____ Figure out exactly how individuals’ behavior and attitudes will have to change to make teams work.
____ Analyze who stands to lose something under the new system.
____ Redo the compensation system to reward compliance with the changes.
____ “Sell” the problem that is the reason for the change.
____ Bring in a motivational speaker to give employees a powerful talk about teamwork.
____ Design temporary systems to contain the confusion during the cut-over from the old way to the new.
____ Use the interim between the old system and the new to improve the way in which services are delivered by the unit—and, where appropriate, create new services.
____ Change the spatial arrangements so that the cubicles are separated only by glass or low partitions.
____ Put team members in contact with disgruntled clients, either by phone or in person. Let them see the problem firsthand.
____ Appoint a “change manager” to be responsible for seeing that the changes go smoothly.
____ Give everyone a badge with a new “teamwork” logo on it.
____ Break the change into smaller stages. Combine the firsts and seconds, then add the thirds later.
Change the managers into coordinators last.
____ Talk to individuals. Ask what kinds of problems they have with “teaming.”
____ Change the spatial arrangements from individual cubicles to group spaces.
____ Pull the best people in the unit together as a model team to show everyone else how to do it.
____ Give everyone a training seminar on how to work as a team.
____ Reorganize the general manager’s staff as a team and re conceive the GM’s job as that of a coordinator.
____ Send team representatives to visit other organizations where service teams operate successfully.
____ Turn the whole thing over to the individual contributors as a group and ask them to come up with a plan to change over to teams.
____ Scrap the plan and find one that is less disruptive. If that one doesn’t work, try another. Even if it takes a dozen plans, don’t give up.
____ Tell them to stop dragging their feet or they’ll face disciplinary action.
____ Give bonuses to the first team to process 100 client calls in the new way.
____ Give everyone a copy of the new organization chart.
____ Start holding regular team meetings.
____ Change the annual individual targets to team targets, and adjust bonuses to reward team performance.
____ Talk about transition and what it does to people. Give coordinators a seminar on how to manage people in transition.
There are no correct answers in this list, but over time come to trust some interventions more than others. If you are interested in learning more about transition management I would urge you to pick up a copy of William Bridges book.  He makes valid points that are critically important in today’s rapidly changing work worlds.

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.