In an interview with the New York Times prior to SuperBowl XXXIV, St. Louis Rams running back Marshall Faulk was asked why he made it his business to learn the assignments of every player on the team for every play in the Rams' repertoire. His answer was profound, with important insights for business executives. He said, “I don't just want to know what everybody has to do; I want to know why. When you know why, you know more... You play faster.”

This exceptional athlete was not talking about his know-how. He was talking about know-why. Know-how is procedural knowledge, which is action-centered and based on practice, and Faulk has a superabundance of it. But it is know-why that distinguishes him from other talented athletes, enabling him to better anticipate what will happen next. He does this not by projecting historical trends, but by deriving meaning in real time from what is happening now. This meaning comes from an understanding of the context within which action takes place, rather than from an understanding of how to perform the action.

Know-why is systems knowledge, not process knowledge. Systems knowledge is akin to what we mean when we talk about holistic thinking and seeing the big picture. It comprehends the purpose of the system, the rules of the game, and the way in which the parts of the system relate to one another. As Faulk says, such knowledge enables him to play faster—not because it increases his speed, but because it decreases the time it takes him to adapt to developments. Here are some quotations from a New York Times article written two years later, just before SuperBowl XXXVI:¹

Faulk crouches just before the snap of the ball, hands on his thighs, and surveys the defense, his eyes shifting back and forth. In those milliseconds, teammates say, he recognizes the defense's plan of attack and anticipates uncannily where the holes will be.

He will know to intercept a blitzing linebacker on one play, and on the next play, because of a slight shift of a defender on the other side of the field, he knows to block a different player.

“He's never wrong,” said Jamie Martin, the Rams' backup quarterback. “It's incredible, really.”

They will go to him Sunday during the game to ask him what he sees, what adjustments can be made, what plays may work, long before videotape confirms what Faulk already knew.

In business terms, Marshall Faulk is an excellent sense-and-respond decision-maker. His decisions are not analytical, or “data driven,” even though he spends an extraordinary amount of time studying films to extract the tendencies of opposing teams and coaches—what they are likely to do under a variety of game situations. As he watches these films, he is looking for and internalizing patterns. When he is given the ball, it is his pattern recognition capability, not his reasoning skill, that enables him to anticipate and respond to what is happening on the field. The patterns he recognizes are systems patterns, not activity sequences. The current relationships between the players, more than the current actions of them, informs Faulk's real-time decisions.

What does Marshall Faulk know? At one level, he knows the rules of the game, the outcome he is accountable for, the assignment of every player on his team, where the defense is lined up, and how the defense shifts before the snap of the ball. He also knows, from hours and hours of watching miles of game tapes, the patterns and proclivities of defensive players.

At a higher level, because of his pattern-recognizing ability to rapidly size up the implications of a given game situation, Faulk knows something much more important: he knows earlier than anyone else on the field the meaning of what is happening now. That is what enables him to play faster, rather than run faster. Because he picks up that slight shift in a linebacker's position, and because he knows what that implies, given the current assignments of his offensive line, Faulk knows before the play starts that the off-tackle hole will not be open and that “up the middle” is a better option.

He is not the only sports great with this kind of knowledge. Knowing earlier is what hockey legend Wayne Gretzky is talking about with his famous declaration, “I skate to where the puck is going to be.” And it is what basketball Hall of Famer Bill Russell meant when he said, “I get the rebound before the shot is taken.”

These sports analogies capture an important insight for business leaders—the people who are responsible for creating the enterprise playbook and keeping everyone in the business on the same page. Having an employee like Marshall Faulk is a great advantage only if the business design leverages his skill. Knowing earlier without the ability and opportunity to act on that knowledge produces frustration, not success.

In an on demand business environment, where things change so unpredictably that few executives believe their strategic planning playbooks anymore, knowing earlier what is happening now provides a crucial competitive edge. And if executives cannot reliably predict what their customers will prefer or what they and their competitors will be capable of in the future, it no longer makes sense for them to place bets on plans and processes. “Plan your work and work your plan” was a mantra of success in more stable times. In the new economy, it all too often leads to a process orientation that makes a company better and better at doing irrelevant things. Processes and set plays are core competencies when the environment is sufficiently stable; and “six sigma” execution (that is, nearly perfect execution) of best practices is a powerful strategic advantage when the target moves slowly or predictably. But when it does not, timely one sigma execution (that is, flawed execution) of next practices wins the day, and knowing why trumps knowing how. Said another way, systems knowledge replaces process knowledge as the source of strategic advantage.

Marshall Faulk understands this principle, as his differentiation between playing faster and getting results faster demonstrates. Getting the ball down the field faster is what is important, not running faster. Moreover, agility—the ability to change directions rapidly—is not enough. The change must be appropriate to the situation, which is why an ability to size up the current situation earlier is fundamental to adaptiveness. How many managerial proponents of velocity, agility, and speed to market understand this distinction?

One way of finding out is to ask how many of them understand what it means to design a business as a system, as opposed to designing it as a set of enterprise processes that link hierarchies of authority. Another test is to ask them to represent their business as a system and look at what they produce.

Applying systems design principles to business

Many principles of systems design deserve to be adopted as management principles by leaders of on demand businesses—businesses that must sense and respond in a profitable and timely way to what is actually happening now, rather than make and sell efficiently what they planned to produce. The five principles discussed below have particular salience to issues that managers of on demand businesses must address because, for these companies at least, concepts such as synergy by corporate acquisition, post-merger integration projects, designing processes to cope with the unexpected, best practice adoption, and matrix management, are often bad ideas. Managers with an understanding of how systems are created and managed would never contemplate most of them—especially in on demand environments where rapid and discontinuous change is the norm.

Four of the recommended design principles are inherent in the properties of any system:

1. Design top-down.
2. Design for synergy.
3. Design relationships.
4. Identify the higher-level systems of which our system is a part.

The fifth is a sense-and-respond principle for adaptiveness:

5. Dispatch capabilities from the external “event back.”

The following sections explore some of the far-reaching implications of applying the principles of adaptive systems design to management.

Designing a business as a system: Synergy and alignment

“System” is a word that everyone uses but defines differently. For purposes of this discussion, I use a definition familiar to those acquainted with a discipline called general system theory:

A system is a collection of elements that interact to produce an effect that cannot be produced by any subset of the elements.²

Two important insights emerge directly from this definition. First, if a business is designed as a system, it will automatically create synergy. Second, the key design choices specify how the pieces interact, not how they act. These insights are significant, given the current widespread focus on process design and management and the spotty track record of synergy-seeking executives over the past two decades. What does the word really mean, and what is required to make it a reality?

Synergy. Synergy is not the result of putting companies in a pot and stirring vigorously, as some seemed to expect when AT&T absorbed McCaw Cellular Communication, Inc., Tele-Communication, Inc. (TCI), and NCR Company. Synergy does not mean cross-marketing, either, as when it was used, for example, to justify the merger of AOL and Time-Warner.

Defining synergy as a result that is “more than the sum of the parts” is closer to the mark. This definition, for example, is what the corporate office of the General Electric Company (GE) achieves by lowering the cost of doing business for its subsidiaries. Because they are part of GE's portfolio, the subsidiaries benefit from the economies of scope that come from sharing the GE logo: GE's AAA investment rating, GE's worldwide telecommunications network, and GE's “boundaryless” knowledge, to name some of the assets that are shared across units. The result is that the units are more profitable as a part of GE than they would be as separate entities, which means that GE's revenue and profit are more than the sum its parts would produce as separate companies.

But the real meaning of synergy is something very different from “more of the same.” Because synergy is a system-level result, it differs qualitatively from the outcomes contributed by any of the parts. It is what occurs when, for example, hydrogen and oxygen interact to create water. Neither hydrogen nor oxygen is wet or drinkable. But they interact in a way that creates something that has both attributes. A favorite restaurant that keeps people coming back—even though they know other restaurants with better food, or better service, or better interior decorating—is producing synergy. It does this by the way it manages food, service, and ambience to provide customers and their tablemates with a unique feeling of well-being. The result is a preference-creating experience, a system-level effect produced by the way products, services, and ambience interact with one another and with the customer.

Similarly, in providing insurance for its clients, the Progressive Casualty Insurance Corporation delivers “peace of mind” as a synergetic value proposition. Their experiential value proposition results from the way Progressive manages the interaction of insurance products, the empathy and competence of its employees, its claims management processes, its network of affiliates, and its emergency services. Some or all of these elements come together spontaneously but seamlessly—in a manner dictated by the specific nature of each incident—within two hours of an accident involving one of its insured vehicles. As a result, clients feel reassured that their financial, auto repair, medical, and interim transportation needs are being handled quickly, professionally, and with an absolute minimum of hassle. The fact that this peace of mind is delivered in a systematic way at a very stressful time further enhances its worth. Not surprisingly, the value that clients attribute to their relationships with Progressive is significantly greater than the sum of the values they assign to the individual product and service components of the company. The business impact of this synergy result is reflected, year after year, in Progressive's industry-leading financial results.

Relationships. From the discussion above, it follows that if a business wants to produce synergy with its employees, products, and places, it must understand and design the interactions among them, rather than the actions of them. And, as will be emphasized below, it should do this before a merger or acquisition. Too many companies, however, defer this critical exercise until after the merger takes place. They use the oxymoron “post-merger integration” to describe a set of projects whose objective is to determine, post merger, how the pieces of two or more companies fit together. In doing so, they are using language that suggests their corporate marriage is already in deep trouble. Post-merger integration is about as good as “post-meal menu planning” as a managerial concept.

Synergetic results can provide durable competitive advantage for companies that produce them. Executives should understand that operating as a system is prerequisite to achieving it.

Alignment. I have already mentioned the advantages of knowing earlier and synergy for businesses that must sense and respond to unpredicted events. An equally important benefit is that organizational alignment is an automatic byproduct of a systems design. Alignment of the parts to the whole is an intrinsic feature of systems. No more task forces are needed to align information technology (IT), or marketing, or development, or geographies, or the human resources operation with the business strategy. The reason for this is that, in a system, every element (capability) exists only because the outcomes it delivers to other elements are essential to the system's ability to produce its function. Alignment of the parts to the whole is an intrinsic feature of systems.

A major and directly related benefit of this feature is the prospect of significantly reducing the enormous internal transaction costs associated with matrix management. The lines connecting roles in an organizational matrix are not informed by a systems design. Instead, they are lines of communication connecting people in different silos of authority. These lines almost always increase ambiguity about who is responsible for what.

The negative attributes of matrix management include suboptimization, fragmentation, redundant accountability for the same outcomes, and ambiguity about authority and accountability. The cost of these negative attributes can be significant. A 1998 study of multidivisional teams in a large multiproduct company quantified the opportunity cost of matrix conflict in terms of deals lost, not pursued, or not closed because of noncompetitive bids at more than $10 million, and the company had dozens of these teams in operation at any given time. The root cause was identified as “lack of clarity about roles, accountabilities, and authorities.”³

Matrix management recognizes the existence of interdependencies between organizational functions, but does not address them systematically. For example, seen through the lens of a systems designer, having multiple roles accountable for producing the same result is ludicrous. Yet it is common practice to make customer, product, and geographic organizations accountable for the same revenue and profit, which leads to endless nonproductive meetings about who receives credit, what transfer price should be used, and so on. Ambiguity about “who owes what to whom” is more than expensive and annoying; it can be crippling, as the following example illustrates.

A state-of-the-art command center in the Persian Gulf is beset by “significant confusion” and not ready to conduct an air war against Iraq, a confidential Air Force report said over the summer [of 2002]. “There is significant confusion about roles, responsibilities and chain of command throughout key areas within the [Combined Air Operation Center],” the report said of the one-year-old center. “It is difficult for the operators to know who to take direction from and who they talk to to get things done.” The report added, “The organization is not currently poised to smoothly transition to a MTW [Major Theater War].”⁴

In the sense-and-respond model of adaptive business designs (see sidebar for overview), clarity about accountability is achieved by defining the work of persons exclusively in terms of the roles they play. Roles, in turn, are defined exclusively by the outcomes that relate them to other roles.⁵ Nothing need be prespecified about how the outcomes are produced, that is, about processes or activities.

Sidebar

Managers concerned with improving the performance of teams will recognize that this discussion has important implications for them. In fact, certain attributes of a good systems design are identical to the attributes of a good team: common purpose, common boundaries, and an understanding of individual roles and how they should interact to produce the common purpose.

Top-down design

Designing an organization as a system provides a perspective that casts serious doubt on other commonly accepted business practices and models. None is more illuminating than what goes on in many companies under the rubric of “process integration,” or even, perversely enough, “systems integration.” This phrasing suggests that the design challenge is one of rationalizing components that currently exist. But that would constitute a flagrant violation of a fourth fundamental principle of systems design: that it begin with an identification of the larger systems of which the system in question is a part, not with an analysis of the parts that happen to exist at present. No system of any complexity is designed from the parts up. And no system is ever improved by applying best practices to each of its components. These suboptimizing behaviors are counterproductive, but they are common and very expensive practices in many businesses.⁶

An executive familiar with the principle that systems are designed from the purpose down, not from the components up, would not think that “business process integration” is a good way to improve performance. Starting with existing processes and determining how to integrate them into a system is almost certainly a waste of time. One might suppose that such a bottom-up approach is nonsensical on the face of it. After all, who would think of creating an IT architectural design by trying to bolt together whatever application code happens to be on hand? Yet, in the 1980s, IBM itself violated the principle of top-down design when it introduced a new higher-level architectural framework, called Systems Application Architecture, that was intended to allow applications on several incompatable computer architectures to run consistently. Unsurprisingly, the results were disappointing.

The top-down design principle does more than identify poor practice. It provides guidance for good practice. It is clarifying, for example, to realize explicitly that one's own company is a subsystem of its constituents' value-producing systems, for example, those of its customers, shareholders, and distributors. Accordingly, a systems design effort should start by identifying the constituents for which the organization must produce outcomes, and what those outcomes are. It is from this work that the purpose, or design point, of the organization should be determined, not from an analysis of the company's existing capabilities. As a result, the design is “purpose down” rather than “capabilities up.”⁷

An analog to business systems designs: IT architectures. The systems perspective is not something foreign or esoteric to all members of the business community. IT professionals will recognize the distinction between systems and processes as that which exists between architectures and procedures. An IT architecture shows how system components relate to one another. It does not define tasks, and it has no temporal dimension. Rather, it relates the components of an IT system in terms of their functionality, or outcomes. Because it depicts the outcomes that relate the components, that is, their interactions, it explains why each component exists.

Procedures, in contrast, codify know-how. Their design necessarily entails predictions about inputs, contingencies, and the best way of doing something. Their ability to deal with the unexpected is limited by the imagination of the designer, rather than by an on-the-spot interpretation of current reality. When something unanticipated does arise, the best a procedure can do is deliver an exception report—the designer's way of saying, “I hope there is a Marshall Faulk out there to deal with this.”

Alas, most managers think about plans of action, rather than organizational designs for action. As a result, no business of more than 50 people that I know of is designed or managed as a system. One consequence is that the IT architects in such companies have no business architect counterpart (and therefore no business architecture) to mirror. Thus, to provide a coherent framework for integrating multiple subsystems, they must invent a business architecture. It is often called an enterprise model, and although most enterprise models are created with the involvement of business people, they are basically figments of IT imagination rather than enterprise-level expressions of executive intent.

The fact is that the vast majority of business people do not think like systems designers. But this does not mean that they cannot or should not. After all, they did not think like process designers either, until IT dragged them into it.⁸ Teaching business people how to design processes was sold on the basis of greater efficiency and lower cost. But the underlying IT imperative was to have a reliable business process specification from which to create IT procedures. Many IT executives learned the hard way that the best way to guarantee a lousy reputation with business people is to program applications based on business process designs that are figments of IT imagination.

We should be encouraged by past successes in making managers aware that process design is an important business competence. And we should learn from our experience that superior business performance is the correct way to sell business people on becoming competent systems designers.

A mergers and acquisitions recipe for disaster: Bolting business models together. Business leaders trying to cope with the rapid, unpredictable change that characterizes the information economy can gain other valuable lessons by looking at their business through the lens of a systems designer. Most managers think about plans of action rather than organization designs for action. For example, from the perspective of a knowledgeable business architect, what has been called the clicks-and-mortar issue (how to integrate real and virtual assets) quite often is actually a problem of integrating intrinsically incompatible business models.

Business models are what people use to make business sense out of opportunities and threats—to know why an investment makes sense or does not. So when Jerry Levin and Steve Case got together, post-merger, to decide on the merits of, say, a $500 million investment proposal to leverage the capabilities of AOL Time-Warner, how were they supposed to make sense out of it? If they came together with Time-Warner's business model and AOL's business model, respectively, in their heads, they could instantly afflict the combined business with multiple personality disorder. Even if they were able to agree on the wisdom of a given course of action, how would they propagate that intuition through their respective organizations, where people were operating with different, incompatible understandings and measurements about what value is and how it should be created? Unless leaders are good architects—which means they can be clear about organizational purpose and how the parts of the business relate to the purpose and to each other—how could anyone else in the organization know these things? Integrating two separately conceived business models requires the development of a new and different business model, with a newly defined purpose. That purpose, once defined, enables the top-down systems design logic that makes clear which capabilities in the former companies are needed, which are not, and what capability gaps need to be plugged by development or acquisition. As suggested earlier, only after the design is complete can the why of the merger be truly understood and evaluated, because the design necessarily shows how the capabilities of both organizations will interact to produce the synergies that motivated the merger.

The practice of expressing the rationale for any merger or acquisition as a new business systems design should be a required element in the due diligence phase of decisions on mergers and acquisitions (M&A): Unless it is known from the start how the capabilities of the organizations in question will interact with one another, the expected benefits of lower cost and greater revenue will be at best short-lived, and the acquired capabilities will rapidly become under-performing assets.⁹ The fate of AT&T's strategic acquisitions over the past decade provides a dramatic illustration of what can happen. NCR, McCaw Cellular, MediaOne, and TCI were acquired because they were successful companies in fast-growing parts of the telecommunications industry. The relationships of these companies to the rest of AT&T and to each other were apparently thought to be something that could be managed as post-acquisition integration projects. An executive familiar with the principles of systems design would have known that integration “from the parts up” was a recipe for trouble. In any event, no synergies were realized, and the acquired companies were subsequently sold off at half the value they had when acquired.

Designing businesses for adaptiveness vs efficiency

Success in adapting to unpredictable change stems from good systems design, not from good process design. As mentioned earlier, process design requires predicting in advance the inputs, desired output, and best way of producing the output. Good process design, whose holy grail is “six-sigma” execution, increases the speed, accuracy, and efficiency of business operations when the inputs and best ways of doing things are known and sufficiently stable. But when there is rapid and dynamic change in customer preferences and a high degree of innovation in available capabilities, success and even survival depend increasingly on improvisational, ad hoc procedures, which cannot be designed in advance. Moreover, redesigning core business processes every time there is significant change is a dubious way of trying to keep up. Firms that spent billions of dollars re-engineering their core processes in the early 1990s subsequently found that they had to spend additional hundreds of millions of dollars a few years later to re-engineer them again so that they were “Webenabled.” They have to re-engineer them again every time they change their business model to accommodate reverse auctions, free software, syndication, or other abrupt, unexpected developments in the market milieu. But changing core process designs in large organizations takes time, and the half-life of a successful business model is shrinking rapidly. More and more companies are finding they simply cannot re-engineer fast enough.

Designing a business as an adaptive system of roles and accountabilities makes it possible to change business models much more rapidly. Those parts of an enterprise that can and should be designed for efficiency can be dispatched as easily as can the capabilities designed for adaptiveness. This is because roles are linked in terms of outcomes, not in terms of the way in which the outcomes are achieved. How a given role should be designed depends on the degree of predictability in the requests made of it and is a decision to be made by the accountable individual occupying that role. Because a business architect need not specify how things are to be done, he or she can incorporate roles that vary widely in terms of their internal processes and even management systems. This feature makes the incorporation of external capabilities a natural part of any business design.

Customer-back designs: Embedding customer-centric behavior

Operating a business as an adaptive system entails decomposing the enterprise into modular capabilities, and dispatching those capabilities in response to current customer requests. Operations are driven from the current customer request back, and the organization is potentially reconfigured by every new request, producing on demand business strategies that leverage on demand computing capabilities. These ideas are elaborated in the sense-and-respond model for adaptive enterprises, a brief description of which is given in the sidebar, “Overview of the Sense and Respond Model.”

The need for good process design and execution will not go away, because the demands placed on some capabilities will remain sufficiently stable, or change in predictable ways. Even Marshall Faulk and Wayne Gretzky rely on playbooks and a lot of practice time. But people innovating and improvising in on demand businesses need something more than talent, a game plan, and a practice field. They need a business model that provides a systems context within which to improvise. This context is what conveys “know-why” throughout the organization, enabling anticipation, coordination, and adaptive coherent responses in unpredictable environments.

Knowing why makes it possible to know earlier and respond faster. When everyone knows why, it is because leaders have become good architects who articulate and propagate their intent as a system context, rather than as an action plan. It is because leaders have declared a context that makes unambiguous to everyone the raison d'etre of the organization, what roles they play in achieving it, and the boundaries of acceptable behavior in it. It is also because individuals are supported by role-specific technology solutions that help them know earlier the meaning of what is happening now.

Then speed and agility can be exploited to produce coherent and profitable bottom-up responses to the opportunities and threats of the present. Then an organization can systematically exhibit the sense-and-respond behavior that is a survival competence for on demand businesses.

That is why, in the unpredictable world of on demand business, it takes a business architect to realize the potential of a company's Marshall Faulks.

Cited references and notes