Chapter Two

A Test Case

We think in generalities, but we live in detail.

$$Alfred NorTH WHITeHeAd, BrITIsH PHIlosoPHer

Chapter $1$ was fairly theoretical. Unless you understand the basic transition model, you won$$t be able to use it$.$ But only in actual situations can you use it$,$ so let$$s look at a situation that I encountered in a software company. I was brought in because the service manager wanted to make some changes, and his staff was telling him it wasn$$t going to be as easy as he thought.

He told me that he didn$$t see why that should be so$.$ The change made perfect sense, and it was also necessary for the firm$$s continued leadership in the field of business software for banks. $$Besides$,$ he said, $$no one$$s going to lose a job or anything like that.$$

Bearing in mind what you read in chapter $1,$ see what you think.

The company$$s service unit did most of its business over the telephone. Indi$-$ vidual 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 evalua$-$ tion 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 re$-$ port 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 avail$-$ ability 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

$11$

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 perfor$-$ mance 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 re$-$ membered to ask. Worse yet, there was poor coordination among the three levels. A level$-$one technician never knew to whom he was referring a cus$-$ tomer$$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 frus$-$ trated 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 cus$-$ tomer$$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 unitwide 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 im$-$ portant their part was in making it work.

Although there