“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) 2766 C.E.
This apocryphal quotation 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 structure of companies. I have also seen reorgs that shuffle a few people, responsibilities, and titles, but leave most of the business practices the same. The word most commonly associated with reorganizations is “alignment.” The company is restructured to align some internal function with some external constraint 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 reorganization in four years hits, and each one has been touted as “aligning 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 skepticism. 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 manager, “for the life of me I can’t see 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.”
Given the rather obvious costs, disruption, and resistance, why do companies reach for the reorg approach so readily and so often?
This scene, played out just over a year ago at a major U.S. company, was typical. A recently appointed general manager, imported from another company, conducted a study of the alignment of his new organization’s structure to their recently adopted strategic 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 customers. 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 actually 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 general manager’s words “…we’re losing out on technology springboards, each group is developing unique solutions to the same problems.” The general manager’s solution, apart from bringing in a number of senior managers from his previous company, was to align the business 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 abdication of project management and resource prioritization on the part of the host company. Meanwhile, some obvious synergies were missed: there was duplication of function, lack of architectural solutions to similar problems, and a lack of focus on next-generation products. Although seemingly a good candidate for reorganization, a review of the recent past showed the group had been organized by technology function just 18 months before the arrival of the new boss. They had been intentionally reorganized into the customer orientation under intense pressure from the key customers.
Dimensions of Organizations
If we imagine the major attributes of a team, project, 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 dimension. 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. Were this the case, one could reasonably 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 radiating along closely aligned axes: similar product technologies require the use of similar 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 hierarchical synchronizing and controlling system, whereas what it is attempting to control is predominantly 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 systems. Basically, management can exert optimal control over only one of the dimensions. The control 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 company has the same type of customers, in the same business, located in the same geographical area, using the same technologies, 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 correlation 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 organizations, there are clusters of dimensions. Typical clusters include: technology based (both product and development technologies), business based, geographically 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 structure the way it does—to allow management intervention and control over the dimension that needs it most. This application of management attention to problems makes them go away: the customers are screaming at us over the phone, so we reorganize to be optimally sensitive to their needs. However, the focusing of management attention tends to be less than optimal for other dimensions. But management 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 reorganization, and we have the approximate timetable for the Reorg Cycle (see Figure 3).
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.
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 environment and society, compound into the Reorg Cycle as we know it.
What To Do?
Some of the issues driving this cycle are intrinsic 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 companies try to stick to core competencies in product, others in skills or technology. For each filter 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 complex management as a core competency 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 processing paradigms since the days of tape sorts.
The bottom line seems to be that while 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.
The etymology of “reorganize” 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 technology-focus as mentioned here, serious consideration is being given to changing the company’s organization to be “more customer responsive.” As Gaius Petronius might have commented: sic.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment