Decision Making

COMMUNICATIONS OF THE ACM February 2003/Vol. 46, No. 2 19

“We trained hard ... but it seemed that every time we were beginning to form up into teams we would be reorganized. I was to learn later in life that we tend to meet any new situation by reorganizing; and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency, and demoralization.”

Gaius Petronius (called

Arbiter) 27–66 C.E.

T his apocryphal quo- tation is ascribed either to a Roman satirist who lived

some 2,000 years ago, or to a member of the Greek Navy who lived a couple of hundred years before that. It adorns cubicle walls in organizations big and small and is a wry reminder that empires may come and empires may go, but reorgs are with us always. Few phrases today are greeted with less enthusiasm than “impending reorganization.” I have personally seen and participated in reorgs that completely rearranged the entire business model and struc- ture of companies. I have also seen reorgs that shuffle a few people, responsibilities, and

titles, but leave most of the busi- ness practices the same. The word most commonly associated with reorganizations is “align- ment.” The company is restruc- tured to align some internal function with some external con- straint or requirement.

Software businesses and IT organizations seem more prone to reorganization than most, and certainly there are many rapidly changing factors present in the business of software: changing market expectations, technology, the availability of tools, libraries, development environments. Even

the sometimes faddish nature of processes, methodologies, and languages seem to require changes of business practice that might warrant a supporting change in the business structure.

But when the fifth reorganiza- tion in four years hits, and each

one has been touted as “align- ing the business structure to better serve our customers” or to “remove obstacles and speed time to market,” the average developer might be permitted a certain skepti- cism. If this reorganization is concerned with removing the obstacles, what happened to the previous four obstacle- removing rearrangements?

From personal experience, typical recovery times for groups subject to significant reorgs can be on the order of nine months. If companies are reorganizing on the same

timetable, the groups never get to settle to a basis of consistent productivity. Given the rather obvious costs, disruption, and resistance, why do companies reach for the reorg approach so readily and so often?

“The structure is to blame,” asserted the new general man- ager, “for the life of me I can’t see

The Reorg Cycle

O R

ES TE

Z EV

O LA

Phillip Armour

A natural hierarchical management response to a rapidly changing environment.

The Business of Software

20 February 2003/Vol. 46, No. 2 COMMUNICATIONS OF THE ACM

why my predecessor organized the groups this way. Customer focus is all very well, but we are customer aligned to a degree that we might as well be working for the customer, at the customer, being managed by the customer.”

This scene, played out just over a year ago at a major U.S. company, was typical. A recently appointed gen- eral manager, imported from another company, conducted a study of the alignment of his new organization’s structure to their recently adopted strate- gic measures (also imported). The study showed a section of his new company was “incorrectly” aligned, predominantly focusing on serving the needs of a small set of very important cus- tomers. The customer focus was taken to the extent that several of the groups in the organization were named after the customers they served. In fact, in one (quite successful) release, key roles in project management were actu- ally provided by the customer’s staff.

This alignment, while greatly favored by those customers who were being so well served, was disliked by the smaller customers who did not have the luxury of dedicated project resources. A

bigger problem was, in the gen- eral manager’s words “...we’re losing out on technology spring- boards, each group is developing unique solutions to the same problems.” The general man- ager’s solution, apart from bring- ing in a number of senior managers from his previous

company, was to align the busi- ness by technological function— to reorganize.

This seems like a reasonable change: the big customers were, on the whole, quite happy with the service and perhaps did not need such close hand-holding. While the customer-managed project was quite successful, it did require considerable abdica- tion of project management and resource prioritization on the part of the host company. Mean-

while, some obvious synergies were missed: there was duplica- tion of function, lack of architec- tural solutions to similar problems, and a lack of focus on next-generation products. Although seemingly a good can- didate for reorganization, a review of the recent past showed

the group had been orga- nized by technology func- tion just 18 months before the arrival of the new boss. They had been intention- ally reorganized into the customer orientation under intense pressure from the key customers.

Dimensions of Organizations If we imagine the major attributes of a team, proj- ect, or organization as lines radiating from the center

(see Figure 1), the orientation of each line represents how many sub-attributes or variables they share). The length of each line represents the degree of effort or expertise required in each dimen- sion. It is theoretically possible, though unlikely, that each dimension could be orthogonal to all other dimensions. In such a situation, each customer would purchase completely different products requiring a completely different set of skills and resources and would operate on radically different technology.

The Business of Software

Given the rather obvious costs, disruption, and resistance, why do companies reach for the reorg approach so readily and so often?

Geography

Support

Development Dependencies

Development Tools

Development Processes

Development Technology

Skills

Resources

Product Technology

Products

Features Customers

Figure 1. Dimensions of teams.

Were this the case, one could rea- sonably ask: “Why is this one company trying to provide all these services that share nothing in common?” Significant overlap of dimensions is more common. While they may be of different lengths, we would expect to find many of the dimensions radiat- ing along closely aligned axes: similar product technolo- gies require the use of sim- ilar development technologies that employ identical development tools, among others.

Management is Hierarchical; the World is Network The managerial problem arises from the fact that management control structures (reporting channels, accountabilities, chain-of-command) are predominantly a semirigid hier- archical synchronizing and con- trolling system, whereas what it is attempting to control is pre- dominantly a network of fluid, event-driven, interdependencies. This is a classical problem that has system analogies and system solutions dating back to the 1950s design of tape-driven sys- tems. Basically, management can exert optimal control over only one of the dimensions. The con- trol over all other dimensions must, almost by definition, be suboptimal.

The congruence of the dimensions largely determines the effectiveness of any one management structure. If a com-

pany has the same type of cus- tomers, in the same business, located in the same geographical area, using the same technolo- gies, requiring the same skills and resources, then the same management structure will work well across all these dimensions. The width or spread of these axes is the management extent or

area of effective point control. A narrow extent implies close cor- relation between dimensions in both focus (direction) and degree (axis length).

The wider and deeper the extent, the more management will tend to be spread thin and experience conflicting priorities (see Figure 2). In most organiza- tions, there are clusters of dimensions. Typical clusters include: technology based (both product and development tech- nologies), business based, geo- graphically based, resource management based, and feature or product based.

Why Management Looks the Way It Does There is one simple reason for management to define its struc- ture the way it does—to allow management intervention and control over the dimension that needs it most. This application of management attention to prob- lems makes them go away: the

customers are screaming at us over the phone, so we reorganize to be opti- mally sensitive to their needs. However, the focusing of management attention tends to be less than optimal for other dimensions. But man- agement is doing its job, which is taking care of business and fighting the hottest fires.

The Reorg Cycle The net effect of this

entirely appropriate management consideration is that, after a few months, the customer fires are put out. But what is happening to the technology fires? Or the resource-balancing fires? Or the geography fires? The relative inattention to these dimensions means these start to flare, or at least start to stand out more against the reduced glare of the primary blaze. Given it might take a few months to contain the customer fires, a few months for (say) the technology fires to build, a few months to recognize and process the need, and a month or so to plan the reorga- nization, and we have the approximate timetable for the

COMMUNICATIONS OF THE ACM February 2003/Vol. 46, No. 2 21

Geography

Support

Development Dependencies

Development Tools

Development Processes

Development Technology

Features Customers

Skills

Management extent

Management Axes

Products

Product Technology

Resources

Figure 2. Management extent.

Reorg Cycle (see Figure 3). In some companies this may

match the turnover cycle for senior management. When new managers come in, they can readily see the flames, but don’t recognize the embers of the previous conflagrations.

These cycles, reinforced by equivalent and larger cycles in the business envi- ronment and society, com- pound into the Reorg Cycle as we know it.

What To Do? Some of the issues dri- ving this cycle are intrin- sic to the software environment—these multiple dimensions simply exist and must be addressed. Typical responses from organizations include divesting orthogonal businesses, product lines, and even customers to focus the management extent. Some com- panies try to stick to core compe- tencies in product, others in skills or technology. For each fil- ter level, of course, opportunities are missed. Other companies attempt network management by having multiple reporting and directive channels operating at the same time. While laudable in that this approach is attempting to address the real issue, which is

the concurrent management of multiple different dimensions, the track record of this kind of network management is not

good. Some companies pride themselves on this kind of com- plex management as a core com- petency and adopt a structure that aligns along this axis. Some companies simply get proficient at the activity of reorganizing.

There are systems analogies from which we can learn. A reorg is the equivalent of resorting data prior to processing. It is a very old method of processing data. We have created many new pro- cessing paradigms since the days of tape sorts.

The bottom line seems to be that while we have mostly single-

dimensional management struc- tures managing and multidimen- sional environments being managed, reorgs will be as much

a part of the business of software as the seasons are part of the year.

The etymology of “reor- ganize” is a mixture of Latin and Greek. It comes from the Latin prefix “re-” meaning “again” and the Greek “organon” meaning “tool” or “instrument”—retooling. Fair enough. However, “re-” can also mean “against” and the word “organize” is also derived partly from the Greek

root “ergon” meaning “work.”

Reorg Postscriptum Midway through the settling-in period for the reorganization from customer-focus to technol- ogy-focus as mentioned here, serious consideration is being given to changing the company’s organization to be “more cus- tomer responsive.” As Gaius Petronius might have com- mented: sic.

Phillip Armour (armour@corvusintl. com) is a vice president and senior consultant at Corvus International Inc., Deer Park, IL.

©2003 ACM 0002-0782/03/0200

c

22 February 2003/Vol. 46, No. 2 COMMUNICATIONS OF THE ACM

Geography

Support

Development Dependencies

Development Tools

Development Processes

Development Technology

Resources

ReorganizationProduct Technology

Features

Customers

Skills

Products

Figure 3. Reorganization.

The Business of Software

As long as we have mostly single-dimensional management structures managing and multidimensional environments being managed, reorgs will be as much a part of the business of software as the seasons are part of the year.