Mark Schwartz dives into risk management in War and Peace and IT

The following is a Q&A with Mark Schwartz, author of the book War and Peace and IT.

Why is it important that business leaders read War and Peace and IT, especially with the role digital transformation plays today?

Mark Schwartz: For true digital transformation, enterprises need to make technology central to everything they do, including their competitive strategy and their way of serving customers. But, historically, the technology organization has been at a distance from the rest of the business -- we talk about 'IT and the business' as if these are two separate things. It's more than a linguistic issue -- enterprises work with the technology organization as if it's an outside contractor, formulating detailed requirements, tossing them over the wall to IT and then managing 'delivery' as if enforcing a contract. But this reduces innovation, adds waste and fails to take full advantage of technology as a strategic enabler.

That relationship between technology and the rest of the business just can't work in a digital world. But it's not obvious how to change it. Questions quickly arise around governance, accountability, risk management, and investment models and capital budgeting, for example. War and Peace and IT breaks down each of these questions and shows how enterprises can address them in a digital world. It is about how to use nimbleness and speed to -- perhaps surprisingly -- increase stability, compliance and controls, while also fostering innovation and growth, and to do so by changing the working relationship between IT and the rest of the business.

You mention CIOs or IT leaders needing to have a conversation about how to play a more consequential role in an organization. Can you elaborate on that for those who haven't read your previous book, A Seat at the Table?

Schwartz: I wrote A Seat at the Table primarily for IT leaders -- to show them how their role needs to change based on the needs of today's enterprises. War and Peace and IT is for CXOs and other senior leaders, generally outside of IT, who want to learn how to best manage and work with the IT organization to accomplish their goals. In a way, it's the same story told two different ways, but War and Peace also goes deeper into the business strategy and financial management questions. Or you could say that War and Peace looks at how enterprises can capture the benefits of the digital revolution that have primarily been driven by technology companies.

In Chapter 6, you dive into risk and why an enterprise shouldn't eliminate it. Can you briefly describe why you think risk management is essential, or more specifically, why CIOs and IT leaders should utilize it?

Mark Schwartz

Schwartz: There's a bit of a paradox we are seeing as companies look at becoming digital: They often perceive a lot of risk in the new, while actually the new ways of working are meant to reduce risk. Moving to the cloud, DevOps and other contemporary ways of implementing technology is not, on the whole, a risk to the company; the risk today is in not doing so. For example, compare investing in a data center to using the cloud. The data center involves an upfront commitment of cash and exposes the company to substantial risks. For example, the equipment they put in the data center might become obsolete over the five or so years they plan to use it. Or the company's needs might change in a way that requires different hardware. Or the company might be too successful and outgrow its data center infrastructure or might need to shrink and cut costs but is stuck with the costs of running its data center. On the other hand, with the cloud, a company can make these changes to its infrastructure in moments, as they become necessary. So, which is riskier: being in the cloud or outside of it?

The same applies to the kind of nimble, incremental software development we do today. The old way required planning a large project and committing funds to it. The new way is to make small, staged investments, each resulting in usable product, and being able to change course depending on whether the small investment has the desired results or as the business's needs change. Which is riskier?

So, it might seem strange to hear this, but the more risk-averse a company is, the faster it should move into the digital age, including the cloud, Agile delivery and DevOps.

The following is an excerpt from Chapter 6 in the book War and Peace and IT.

Purchase your copy of War
and Peace and IT today
by clicking on the image above.

Risk is the possible negative consequences of the uncertain future, while opportunity is the possible positive consequences of the uncertain future. Agility is the organizational characteristic that determines whether the uncertain future becomes one or the other -- or simply a benign passage of time.

For those who worry about risk, there is much to worry about. Startups arise suddenly and disrupt industries. Customers are fickle and change their tastes quickly, sometimes within the few moments it takes to read a tweet. Countries Brexit or dismiss treaties they have previously signed. Regulations are put in place and then rolled back. And technology changes in nanoseconds -- when you pause for a bio-break your programmers may begin studying a new programming language you've never heard of; when you return they've already rewritten your IT systems. Both the business and technology environments are uncertain and unstable -- risky, many would say.

Uncertainty, however, doesn't always lead to negative consequences. On the contrary, it also opens up opportunities. When an unforeseen event occurs, what determines whether it's an opportunity or a hazard? Yup -- agility. "It is possible to prepare for unknown risks," reads a Boston Consulting Group (BCG) blog post, to which I would add that it's possible to prepare for unknown opportunities as well. The post goes on: "[Our] research has demonstrated that highly adaptive companies outperform less adaptive companies in periods of economic turmoil."

Let's say you spend $10 million to build a factory to produce bobblehead dolls of Sir Isaac Newton, everyone's favorite scientist. Suddenly Albert Einstein announces some theory of relativity and the market for Isaac Newton bobbleheads immediately dries up. Has your $10 million investment been sucked into the proverbial black hole?

Yes, if your factory can only produce Queen Anne-era Cantabrigian scientist dolls. But if it's agile enough to quickly retool to produce Einstein dolls, then your investment becomes worth even more: you'll be first to enter the relativity market and have a first-accelerator advantage. In other words, designing the factory to be agile from the start lowers your risk -- you are able to deal with changes that take place in the uncertain future.

Given an uncertain future, anything that increases your cost of change also increases your risk. Anything that decreases the former also decreases the latter. Reducing the cost of change is the definition of agility. To put it bluntly: risk is lack of agility.

Another equation: "Risk management is strategy," BCG says, "and strategy is risk management." In some cases, they can barely be distinguished. Let's say you choose to cross over from the bobbling head market to that of those cats waving their paws up and down -- the ones you see in many Japanese restaurants. Is your decision to build a bobblepaw cat a strategic product extension? Or is it mitigating the risk of the bobblehead market drying up? Or of competitors moving more quickly into the bobblepaw market? There really is no distinction. Risk management is just a different way of looking at strategy.

There is risk in both stasis and change; risk in competitive actions and in passively responding to competitors' actions. An analysis of the one hundred companies having the largest stock price drops from 1995-2004 showed that only thirty-seven were hurt by financial risks, while sixty-six were hurt by strategic risks -- including competitors' actions, for example.

An enterprise's goal is not to eliminate risk, but to use it for competitive advantage. If the enterprise could, say, put in place robust automated controls to reduce risk -- seizing opportunities more aggressively as a result -- then it could also seize market share. If it could eliminate controls that slow it down without effectively mitigating risk, it could achieve a speed and cost advantage. And if it could assess risk better than its competitors, making better bets as a result, it would wind up ahead.

The cloud, DevOps, digital transformation -- all of these come with techniques for increasing business agility, thereby reducing risk. Yet enterprises sometimes hesitate to adopt them because their leaders perceive risk in the unknown. It's an interesting kind of risk: one where we don't really know what the risk is. Our fear is of a second order: the risk that there might be a risk.

In another USCIS incident, a number of us met to discuss the severe problems we were having with the performance of a large contractor. At one point, someone suggested we start a new request for proposal (RFP) to replace the contractor. "Too risky," said one of the more senior executives. "We don't know what kind of a contractor we'll wind up with or how good they'll be."

I've heard many variations of this line of thought. In this case, we had a contractor who had a 100% chance of performing poorly (since it was already doing so), yet the perceived risk of working with an unknown one somehow seemed to be higher. It's equally strange that some organizations are afraid of Agile and DevOps practices, as these were invented as a way to reduce risk. Ditto for the cloud, which eliminates the risks of managing onsite infrastructure.

I've had conversations with security experts in the government and at large commercial enterprises where someone will ask, "Is the cloud secure enough?" It is, but this is the wrong question. What they should be asking is, "Where will my security posture be better -- in the cloud or in my on-site datacenter?" The framing of this question reveals a lot about fear of the new. In my role at DHS I found the decision easy, by the way. The cloud clearly enabled us to build a much more robust security architecture.

Ask any information security specialist if they're happy with their security posture in their datacenter:

"No way. Too many people have privileged access; we have too many insecure legacy platforms; we don't patch often enough; our firewall rules are too complex; production systems aren't reviewed often enough . . ." and on and on.

"How about moving to the cloud, then?"

"Well, that would be risky . . ."

There's a pattern here: we tend to attach too much weight to the risk of the new and too little weight to that of the status quo.

In fact, this is an instance of a common cognitive bias, described in a 1988 article by William Samuelson and Richard Zeckhauser, "Status Quo Bias in Decision Making." The authors' experiments showed that people disproportionately decide to stick with the status quo when presented with alternatives. And in a 2016 Psychology Today blog, Rob Henderson wrote, "Status quo bias is a cognitive bias that explains our preference for familiarity. Many of us tend to resist change and prefer the current state of affairs."

Status quo bias was further explored by Daniel Kahneman, Jack L. Knetsch, and Richard H. Thaler in their paper, "Anomalies: The Endowment Effect, Loss Aversion, and Status Quo Bias." They relate status quo bias to a phenomenon called the endowment effect -- the tendency of people to give a higher weighting to things they already have when making decisions.

What at first seems like fear of the new is perhaps better thought of as an emotional preference for what we already have. The effect is stronger the more choices we're confronted with (think of all the options available in the cloud!), and is stronger the longer we've held the object we may be giving up. It reminds me of those groovy old COBOL mainframe systems that have been around since hippies occupied Golden Gate Park during the Summer of Love. Hard to give up, right?

There are all sorts of risks in today's business technology environment— things for managers and leaders to worry about. There is risk that a large IT investment won't return its intended business benefits. There is risk that a disruptive startup will shake up the industry. Or that a hacker will steal sensitive customer data. What about a competitor thinking of a brilliant idea first? Then there's risk that costs will spiral out of control. Or that a new technology will make the current infrastructure obsolete.

I could go on and on. There are so many risks it's a wonder that an enterprise can do anything at all. But that's exactly the point -- the biggest risk is not change, but stasis. Or as the Marine Corps doctrine dryly puts it, "Risk is equally common to action and inaction." Unless you're sure that your enterprise is already prepared to meet all of the aforementioned risks, the status quo is a terrible place for you to be, and the risk of the new should seem negligible compared to the urgency of change.

To be very clear, I'm not suggesting that companies change their risk tolerance -- if anything, I think they should be more risk averse. There has been persistent confusion in the literature of digital transformation, with writers suggesting that companies need to become more comfortable with taking risk, that they should consider failure to be a good thing . . . just another learning opportunity. I'm talking about comments such as, "We need to encourage risk taking and quirkiness" in Jim Highsmith's book Adaptive Leadership. Yes, I'm all for quirkiness. But do we really want to encourage risk-taking? I think Highsmith doesn't really mean what he means. He is perhaps thinking of Xerxes, poised to invade Greece at the Hellespont:

If you were to take account of everything . . ., you would never do anything. It is better to have a brave heart and endure one half of the terrors we dread than to [calculate] all of the terrors and suffer nothing at all . . . Big things are won by big dangers."

But business leaders have a fiduciary duty not to take on big dangers, though there is a lot to be said for proceeding with confidence once a decision has been made (it didn't work out too well for Xerxes, by the way). The miscommunication, I think, comes from using old terminology and mental models to describe the new ideas. When a digital transformation writer says that it's important to "fail fast" and encourage failure, what they mean is that it's a good thing to try experiments and abandon them if the results aren't the desired ones, or to change direction frequently if change is warranted.

Experimentation and changes of direction, however, are tactics to reduce risk. Instead of committing to an investment such as building a product, choosing a technology, or launching a change to a digital service (all risky), a more Agile approach is to make a smaller commitment to an experiment first, then gauge whether the larger investment will be effective. It's a case of buying information to reduce risk. If it turns out that the larger investment isn't a good idea, then the experiment was not a failure but a success; it gave us critical information that let us avoid making a bad investment.

So please do not fail. And if not failing works out well as a strategy for you, please tell people you read about it here.

The experimental approach can also reduce the risk of fixating too early on one idea when better ideas might be available. Experiments can be rigged to try a few different innovative solutions, then compare the results. If one idea turns out to be better than the others, then testing alternatives wasn't a failure -- it was a success at inexpensively buying information to reduce risk and make a good decision. As Yogi Berra said when giving directions to his house: "When you come to a fork in the road, take it." Experimentation encourages innovation by allowing ideas to be tried out, then vetted by finding Yogi's house.

Experimentation is a powerful way to avoid analysis paralysis. Since there is a cost of delay, it's often better to proceed on a small scale with a reversible decision, then quickly pivot if it doesn't work out. The cost of the effort spent going down the unsuccessful path is likely to be less than the cost of a long analysis, and the conclusion is more certain. Proceeding quickly with reversible decisions reduces the risk of being late to market. That's success, not failure.

You can also think of the experimental approach as a strategy of doubling down on winners. Experimentation allows us to place small bets on a portfolio of possible winners. When we find the odds on one particular idea increase, then we raise that bet.

Doubling down, by the way, is much more than a cliché -- it's the actual strategy in blackjack. If you're dealt cards that add up to ten or eleven, then the only correct strategy is to double your bet. This is hard for many people to get used to -- they view doubling down as optional. But in fact, over the long run, if you want your odds to come close to being even with the house, you must take advantage of the opportunity to double down when the cards look good. In other words, doubling down on likely winners in your "portfolio" of blackjack hands is a way of playing your cards to reduce risk.

The experimental, tentative decision technique is neither about failing fast nor taking more risks. As Highsmith says, "Traditional teams attempt to drive out uncertainty by planning and analysis. Agile teams tend to drive out uncertainty by developing working software in small increments and then adjusting." Why then does he advise taking risks?

In a predictable world, perhaps it's right to consider anything new and unknown to be risky. In a world of uncertainty and change, however, anything old and known is risky. It's risky as well to blindly follow a plan, because we know that the world is changing and our plan is based on what we knew yesterday. This is difficult to accept, because plans have always been our way of reducing risk. Today, though, the unexpected remains unexpected even for careful planners.

The more risk-averse you are, the more excited you should be about digital transformation, even if it's frightening because it's new. Frightening isn't the same as risky.