The Battle of Borodino: Business as a Complex Adaptive System

Adapted from War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age by Mark Schwartz.

In War and Peace, Tolstoy writes of the battle of Borodino, in which Napoleon (sort of) defeats Russia and wins the opportunity to watch Moscow burn, though not much more. The day before the battle, he walks the battlefield and gives his commanders orders for the disposition of the troops—orders which are, for the most part, ignored. During the battle, he stands in the nearby redoubt of Shevardino—which he has unexpectedly captured the day before—observing the battle and issuing instructions. Or trying to, because he’s about a mile away and the battlefield is covered with smoke and mist and gullies which block his view.

[perfectpullquote align=”full” bordertop=”false” cite=”” link=”” color=”” class=”” size=””]While an adjutant was riding the mile or more that separated him from Napoleon, the circumstances changed, and the news he was bringing became incorrect. Thus an adjutant arrived from the viceroy with news that Borodino had been taken and the bridge over the Kolocha was in the hands of the French. The adjutant asked Napoleon if he ordered the troops to cross it. Napoleon ordered them to form ranks on the other side and wait; but not only as Napoleon was giving this order, but even as the adjutant was leaving Borodino, the bridge had already been retaken and burned by the Russians.
—Leo Tolstoy, War and Peace[/perfectpullquote]

When Napoleon is able to get orders out in time, he often issues them assuming that his previous orders have been followed, which  .  .  .  um  .  .  .  is a bad assumption.

[perfectpullquote align=”full” bordertop=”false” cite=”” link=”” color=”” class=”” size=””]The marshals and generals who were closer to the battlefield  .  .  .  gave their own instructions and orders  .  .  .  without asking Napoleon. But even their instructions were carried out as rarely and to as small a degree as Napoleon’s instructions. For the most part, what came out was the opposite of what they had ordered.
—Leo Tolstoy, War and Peace[/perfectpullquote]

This is Napoleon, famous for his skill in commanding armies! In an environment of great complexity, uncertainty, and rapid change, neither following a preset plan nor giving direct orders from a distance is effective. And the environment Napoleon is in has all three of those characteristics:

• Complex, because many people, with many different interests, are all giving orders, and the orders interact in complex ways.
• Uncertain, because the results of any order depend on what the enemy does and its intentions, with its capabilities being only partially understood.
• Rapidly changing, since, for example, by the time a messenger tells Napoleon what is happening, text messaging has practically been invented.

In On War, Carl von Clausewitz says, “War is the realm of uncertainty; three quarters of the factors on which action is based are wrapped in a fog of greater or lesser uncertainty.” Napoleon isn’t really in control, according to Tolstoy, except in his own mind and in those of historians as they retrospectively assign credit and blame. Napoleon’s problem is that his decisions during the battle have a long lead time, even though circumstances are changing with a much shorter lead time. In an environment of rapid change and uncertainty, lead time for decisions and execution must be shortened to align with the pace of change. It is the troops, those who can rapidly decide and act, who can respond at the necessary tempo.

Another example of complexity is given by Atul Gawande in The Checklist Manifesto: How to Get Things Right, in which he describes the dynamics of a hospital’s intensive care unit. Patients exhibit myriad symptoms that are constantly changing—malfunctions in one bodily system suddenly lead to malfunctions in others—and a team of doctors interferes with that progression by trying to reverse it. An average patient in an ICU requires 178 individual actions per day, “ranging from administering a drug to suctioning the lungs,” with each of those causing a variety of only somewhat predictable effects. Just lying motionless in an ICU can cause additional problems, such as muscle atrophy, blood clots, and pressure ulcers.

This is what we mean by a complex environment. It’s different from something that’s merely complicated—complexity means that the interrelationships, feedback loops, uncertainty, and lack of knowledge are so great that it’s impossible to understand the complete state of affairs and to know what will happen next. Leaders in a complex environment are mistaken if they think they’re free to give orders: when they try to, the result is that France becomes a republic once again.

It might seem like a stretch to compare the business environment to a ­battle, but a set of common characteristics seems to exist between war, ICUs, business in the digital era, and IT. Each of these, including the business enterprise, is an example of a complex adaptive system (CAS)—a self-organizing system (a concept that draws from evolutionary biology) in which individuals pursue their own objectives and interact in complex, ever-changing ways. 

John Henry Clippinger Jr., in The Biology of Business: Decoding the Natural Laws of Enterprise, lists seven characteristics of a complex adaptive system:

• aggregation; that is, that the whole is greater than the sum of its parts
• non-linearity; that a small change can have a big impact
• flows, or networks of interactions
• diversity
• tagging, or naming that gives significance to actions
• internal models, which are simplified representations that anticipate future events
• building blocks, or components that can be recombined

Businesses are filled with people who pursue their own objectives and who are then combined into teams and larger organizational groupings that also pursue their own objectives. No one has complete knowledge, and information is delayed in making its way from one employee to another. Initiatives in one part of the enterprise affect those in other parts of the enterprise. Upper management layers don’t directly know what is happening on the ground, and line employees don’t know what conversations are taking place behind closed boardroom doors. The more that companies decentralize authority into teams—the hallmark of the digital age—the less direct control they have over the teams’ actions.

As CIO at US Citizenship and Immigration Services and a member of the government’s Senior Executive Service, I was considered high up in the federal hierarchy. And as a change agent, I was frequently challenging my organization with  .  .  .  unusual requests. In an assessment of one large IT initiative, feedback from independent advisors let me know that there was often a disconnect between what I thought I was asking for and what the technologists thought I wanted. Apparently, when my requests descended through the hierarchy, each middle manager subtly altered them based on his or her own understanding and interests. By the time the message reached the technologists, it had changed significantly and was sometimes close to absurd. Fortunately, they ignored my requests, and the project was going fine. I was Napoleon, leading from Shevardino, thinking I mattered.

Some IT complexity follows from the complexity in the business, for, after all, the company’s IT systems mirror the company’s operations. But to this IT adds the complexity of technology systems and technical practices.

Let me take you inside that black box of IT for a quick look.

You’ve probably already realized that IT is complex: entry to the profession is only available to certified propeller-heads. But I’m not referring to that kind of complexity; I’m referring to organizational complexity, administrative complexity, and gajillion-factors-to-consider-in-making-a-decision complexity. IT history has largely been about finding ways of dealing with such complexity. Each time an advance is made that reduces complexity, IT practitioners simply add another layer.

Imagine that your software application has millions of lines of code. Code is generally retained as a set of computer files, so think of it as any number of ­Microsoft Word documents totaling millions of lines of text. Now imagine you have many developers working on that codebase at the same time—anywhere from a handful to dozens, hundreds, or even thousands. At any moment they have hundreds of work items—creating new features, changing existing ones, fixing bugs. A single change made to any of the millions of lines of code can have unpredictable—or let’s say surprising—impacts on any of the other millions of lines of code. The developers are bouncing from one part of the codebase to another to make changes, depending on which tasks they’re assigned. They are under time pressure.

Now mix in the technical complexity. Perhaps a developer adds a new feature, but—OOPS!—it suddenly slows down a function that was working speedily before. Now the developer has to dig through code that perhaps was written by another coder, attempting to ascertain all of the interrelationships between it and the millions of other lines in the codebase, all to create a new design that will fix the speed problem. The changes are made and—YIKES!—suddenly another feature stops working! Meanwhile, another developer has made changes that accidentally overwrote the changes the first person made. Then someone calls a meeting and all developers drop what they’re doing. When they return they’ve forgotten where they were in the codebase. By this time the code may as well be in one of Atul Gawande’s ICUs.

Technologists deal with complexity by layering their solutions. A solved problem becomes a layer on top of which future problems can be solved. When you’re working on a particular layer, you don’t have to worry about the complexity of all the layers underneath: someone has already solved them. There is sort of a leveling effect—technologists keep the complexity of their jobs more or less constant, at the limit of the complexity they’re able to handle, by ignoring the complexity below and above the layer they’re working on.

Electricity makes its way to each of your AC outlets at home only because scientists figured out you can power appliances by making electrons flow through a set of wires. They had to discover the relationship between moving magnetic fields and electricity, then devise practical devices that could generate electricity by moving magnetic fields around. And they had to invent transformers that could step voltage up and down so as to move electricity over long distances.

But you don’t have to worry about any of that—you just plug in your toaster. So it is with the layers of computing. Someone has already figured out how to encrypt data, and they in turn relied on mathematical principles that had been developed by those who came before. We don’t have to deal with getting all computers to communicate with one another—the internet and its protocols already exist. We can focus our energies on building upon what already exists.

But things can go wrong in any of those layers. Of course, the lower the layer, the harder it is to find and fix the problem. IT people can wrap their heads around complexity because of layering and the tools they’ve developed. But the complexity remains.

Today, technology departments break down software systems into small components, each responsible for a small segment of functionality. The components communicate with one another, delegating and coordinating each piece of work. For example, when an online shopper clicks a buy button, one component locates the shopper’s account information, another obtains their credit card data, yet another sends the transaction to the credit card processor, the next receives the authorization response, still another deducts the item from inventory, and the last one notifies the warehouse to pull and ship the product. Each of these may be further divided into more granular subcomponents. Individual components may run on disparate hardware and they might access multiple databases.

The resultant complexity makes it hard to even imagine what kinds of things might go wrong. As a result, a new discipline called chaos engineering is emerging, pioneered by the Netflix engineers. Their idea was to simulate major failures in live systems to make certain such failures are gracefully handled. They started by randomly turning off servers, as if someone had stumbled over a power cord and accidentally unplugged it. Later they moved to more sophisticated failure modes. They wanted to learn what would happen. Would one failure cascade into another?

Once you make a computer system available over the internet, you take on an enormous amount of additional uncertainty. Web applications can be accessed by anyone, anywhere, at any time, and are consequently subject to vast, instantaneous swings in their scale of usage. Hackers will try to find their way into any system as soon as it’s connected. And picky users are no longer willing to accept a website that apologizes that it’s “Down for Maintenance” or “Under Construction.”

Handling such uncertainty requires true artistry. The most difficult aspect of creating applications for internet scale is the need to manage concurrency. Because IT systems are simultaneously handling the activities of many customers, unexpected coordination problems arise that can’t be easily reproduced or diagnosed. What if two shoppers buy the same unique artisan bobblehead at the same moment? As the number of system users increases, the likelihood of timing-related problems arise. If you find Gerald in a bad mood, it’s probably because he’s trying to diagnose a concurrency problem.

As enterprise change agents, we must understand that we’re dealing with a complex system, where changes in one location might have unpredictable effects in another. In his article “Responsible Change,” Christopher Avery talks about “provoking and observing” as the way to cause change within a complex adaptive system:

We can never direct a living system, only disturb it and wait to see the response.  .  .  .  We can’t know all the forces shaping an organization we wish to change, so all we can do is provoke the system in some way by experimenting with a force we think might have some impact, then watch to see what happens.¹⁶

To work effectively in the digital world, you must first accept complexity and uncertainty, for they demand a very different approach to carrying out initiatives. A predictable world rewards advance planning and rigid plan execution. But a complex and uncertain world rewards an empirical cycle of trying, observing, and correcting. 

Continue reading in Mark Schwartz’s War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•