Oh, thou clear spirit, of thy fire thou madest me, and like a true child of fire, I breathe it back to thee.

—Herman Melville, Moby Dick

The commentators tell us: the correct understanding of a matter and misunderstanding the matter are not mutually exclusive.

—Franz Kafka, The Trial

Meet the Sumo Wrestler

The application of just the right amount of force in just the right place to throw a four-hundred–pound wrestler to the ground. The slow wearing away at a fault line between two geological plates that suddenly results in a vigorous shaking of the earth. The one or two harpoons that tire out a sixty-foot, forty-ton whale so that it can be killed by a precisely directed lance thrust. These are the ways of the Sumo Wrestler.

Sumo is a traditional Japanese martial art that really does resemble an earthquake. Two inconceivably massive tectonic plates in loincloths and strange hair-knobs push up against each other, the tension building until it is suddenly released and one of the wrestlers shakes the stadium by falling to the ground. (Actually, a wrestler can win either by pushing his opponent out of the ring or by making his opponent hit the ground with anything but his feet.) Here’s the subtlety: if you push too hard, your opponent might simply yield, and you’ll go flying. If you don’t push hard enough, then your opponent will push you and you’ll go flying.

A sumo match can be a delicate balancing of forces, where each wrestler is trying to find exactly the right moment to apply exactly the right amount of force to exactly the right place to get the opponent off balance.

Our ally the Sumo Wrestler meets bureaucracy head-on and pushes with the just the right strength at just the right point to win the match.

S1: Refocus on Objectives

We’ve already noted the bureaucratic dysfunction of goal displacement: focusing on the rules rather than their ends. The Sumo Wrestler remedies this by realigning bureaucratic rules and bureaucratic roles to support the real objectives. Whenever an employee is working toward the enterprise’s goals, the bureaucracy should be facilitating rather than hindering their efforts. Sometimes it’s not.

The Sumo Wrestler starts by examining a bureaucratic impediment. If the control purpose behind the impediment is valid and reasonable—for example, it will help the company comply with HIPAA—then the Sumo Wrestler tries to find an equivalent control that will accomplish the same objective but not get in the way. If he finds that the bureaucratic impediment does not serve a useful purpose, he pushes it out of the ring. He conserves his strength for stomping out the useless bureaucracy and uses leverage and balance adjustments to deal with the right-meaning bureaucracy.

A sumo wrestler doesn’t get overly attached to a single plan, but keeps his objective in mind, sometimes pulling, sometimes pushing. When we hit a bureaucratic impediment, it may be possible to take a different approach that skirts it. Since there may be many routes to accomplishing an objective, we find the one that gets us there, despite roadblocks.

For example, at USCIS we were often told that we should not use time and materials contracts because they were too risky for the government, which might have to keep spending at hourly rates until the work was finished. Instead, we were “strongly encouraged” to use firm fixed price agreements, where the vendor would agree to complete the entire scope of a project for a fixed fee, because those contracts were believed to transfer risk to the vendor. Agile IT, however, has found that by far the biggest risk in an IT project is in the requirements themselves, and the firm fixed price arrangement effectively puts all that risk on the government.

It seemed like we were stuck because we needed time and materials contracts for our Agile software practices, but the procurement authorities were adamantly opposed. In the end, though, we found that we could work within a firm fixed price structure while still leaving system requirements open, thereby mitigating the most important risks and satisfying the bureaucracy. The technique we evolved was to distinguish between contractual requirements and system requirements—holding the vendor to the former while leaving the latter flexible. In any case, the Sumo Wrestler had pulled rather than pushed—and won the match.

S2: Never Waste an Emergency

When President Obama announced that we would launch DACA in sixty days, our agency recognized that it faced an emergency. We knew that we’d find some way to get it done, and of course we did. Mission-driven people in organizations are pretty good at dealing with emergencies. The difference between what you can do in a crisis and what you can do on normal days is, more or less, your bureaucratic waste. It becomes easy to identify.

As I explained in Chapter 2, emergencies can also help you sell ideas and convince others of the need for change. When the president’s signature healthcare initiative was derailed by the failure of the Healthcare.gov site, our case suddenly became stronger: “Do you really want a repeat of Healthcare.gov?” Or, “Haven’t we learned anything from Healthcare.gov?”

Another productive disaster for us was the theft of personnel records from OPM’s databases. While its immediate impact was to tighten controls around security, it also became useful support for our argument that we needed to rethink our security approach altogether. It opened up the possibility of change.

As I write this, COVID-19 is the emergency of the day. I’m certain that many companies will be using the crisis to advocate for loosening restrictions around telework. The need for sudden change to respond to Brexit, for many firms and government agencies, will be a good argument for increasing IT agility and disposing of old IT systems. Who knows what we’ll be able to do when comes the zombie apocalypse …

Sometimes you can create urgency through BHAGs (big hairy audacious goals). To maximize their impact, though, you need to connect them to mission outcomes. Employees will internalize the goals much better if they are not just aggressive targets someone has set to drive them to higher efforts.

S3: Call and Raise the Bureaucracy

Fight bureaucracy with bureaucracy. As Provoke and Observe is to the Monkey and Lean Technique is to the Razor, Call and Raise is the core principle of the Sumo Wrestler. If your opponent is large, be larger.

You saw this technique at work in Chapter 2, “Chaos Monkey in the Bureaucracy,” where we fought MD-102 by introducing MI-CIS-OIT-003 and 004. To prevent backsliding into MD-102, we set up a magnificent bureaucratic IV&V process that would make doubly sure that Agile practices were being followed. It even helped the auditors do their jobs, as there was now a paper trail showing that we had done exactly what we said we would—that is, be agile.

A wonderful thing about bureaucracy is that it can be turned upon itself very productively. By writing a Project Tailoring Plan that said we’d do the opposite of what MD-102 required, we made our process compliant with MD-102. It was like matter and antimatter annihilating one another in a burst of energy. What was left was a clear field where we could build freely.

In a variation on this strategy, we learned to check all the compliance boxes even before anyone told us to. We tried to be even more bureaucratic than the bureaucracy. Where there were FISMA controls that had to be implemented, we found ways to implement them so quickly and effectively that we could immediately claim to be compliant. That earned us trust from the bureaucracy and also advanced our efforts to be lean.

S4: Read the Fine Print

Myth grows up quickly around rules. People don’t like to fight, so they “play it safe” by conservatively interpreting the rules or setting even stricter rules for themselves … just to be sure. That’s why we were told that we weren’t allowed to sign time and materials contracts because “they were frowned upon,” and that there had to be parity between paper and electronic forms. Contracting authorities told us we couldn’t require bidders to submit to an in-person test of their abilities. Security people told us that we couldn’t have a datacenter that allowed non-US citizens inside. None of these was actually in the original rules, even if they later became codified in policies and memos and imagination.

We learned to ask, first, where a rule came from—“Is that your rule or is it required by some law or policy?” The answer was almost always “No, it’s not my rule, it’s the law.” The second question was: “Can you point me to exactly where it says that in the law or policy?” In many cases, we found, the law said something different, if it existed at all.

Asking “Where exactly does it say that?” graciously can help convince bureaucrats that you’re in earnest—that you respect the humongous FAR or the PRA and are eager to abide by their precise terms. If you become an expert in the rules, you’ll find ways to be creative within their constraints, and you can bond with the enforcers over a discussion of the finer points of the law.

So, the “don’t do time and materials contracts” thing was not a rule, it was just “frowned upon,” whatever that means. And actually, there was nothing in the whalelike FAR that said or even implied that we couldn’t test the contractor’s skills. The PRA doesn’t literally say that there has to be parity between electronic and written forms. And the rule around non-US-citizens in the datacenters, I think, turned out to say something more like “Each agency needs to decide whether it will allow non-US-citizens into its datacenter.” Some did, and some didn’t, have a rule that applied.

Our QA organization had encouraged project teams to write those really long answers in each section of MD-102 documents because they were afraid that the overseers would otherwise reject them. And they occasionally did. But there was nothing in the rules that said we had to—and it turned out that we didn’t.

And I’ll say it again—those conservative interpretations have a cost. The way of the Monkey is to expose the waste. The way of the Razor is to cut it away. And the way of the Sumo Wrestler is to gain and use leverage by questioning the enforcers and examining the rules more closely.

Pseudo-rules proliferate when there’s gatekeeping late in a workflow. Because everyone is afraid that the overseers might reject something at the last minute, they’re more conservative early on. It’s a little like superstition—you don’t really know what the bureaucrat’s going to do, so you think “Once we tried this and the overseers rejected it, so we won’t do it again.” I remember a psychology professor telling our class of an experiment where researchers gave lab rats food pellets at random times. The rats developed strange, quirky behaviors—running in circles, dancing the Macarena, rebooting their computers—believing that doing so might trigger the reward.

The Sumo Wrestler wisely refuses to dance the Macarena and suggests that bureaucrats stop as well—the costs of watching are just too high.

S5: Redefine Quality

What you’re allowed to do is often determined by whether or not what you do is challenged. When you understand auditors’ objectives, you can work backward to what you can do without their objecting. A Sumo Wrestler technique is to create your own definition of quality that you can map to any framework you must comply with—then enforce your definition rather than theirs.

It’s useful to think of quality as encompassing a broad range of attributes. In IT, for example, quality might include not just passing tests, but also accomplishing business objectives, being usable and accessible, and being secure. High-quality code is readable and maintainable, scalable and reliable. It is simple and straightforward. And it complies with any frameworks the company is subject to.

When an organization defines these attributes precisely, it can automate the process of testing for them. The definition of secure code (more or less)* is code that passes the automated security tests. Accessibility, scalability, and framework compliance may also be defined by the set of tests the code must pass. These objective ways of judging quality can replace quality assurance by trolls and arbitrary “conservatism” applied “just to be sure.”

If you’re making your bureaucratic controls lean and enabling, then you have as much interest as the auditors in making sure they’re enforced—your incentives are aligned. You don’t want to wait until an annual audit finds problems. Instead, you can define quality in a way that will satisfy auditors, then “shift left” and enforce it throughout the delivery process, avoiding the waste that would otherwise come with bad audit findings and rework. Yet you don’t add superstitious effort based on fear of the bad audit.

Another place where you fight bureaucracy by creating more of it!

S6: Show Success

When things are going poorly, the bureaucratic trolls come out of their caves and compete with each other to demonstrate their commitment to fixing your problems. When things are going well, they just stay home and barbecue spherical cows. A good way to escape costly scrutiny is to be successful.

Since the purpose of much oversight is to mitigate risk, it often has triggers that force attention on something that is not going well. A typical scenario we faced was that a project would be ignored by the overseers until it suddenly found itself “in breach” of a schedule or cost milestone. Then the bureaucracy would come crashing down hard on it.

Fortunately, today’s techniques are troll repellent—they make it easier to stay in success mode. With DevOps and the cloud, we can release IT capabilities quickly and begin to accomplish business objectives, then build on them incrementally. That means we can demonstrate success consistently throughout a project. Agile techniques are designed to show business outcomes (rather than to hit cost and schedule milestones), really, so we should have confidence that that’s exactly what we’ll do. And if you demonstrate success quickly, before you’re tied up in red tape, then no one will remember which form you “forgot” to fill out. It’s rare for bureaucracy to descend on a project that’s popular and successful, especially one that returns money it was budgeted.

Agile projects are designed to correct their own course, quickly, and without the interference of authorities. They’re constantly and rapidly knocked back on track before administrative interference is launched. In the new oversight process that we piloted, the overseers were involved every step of the way, so a “breach” was no longer a breach of an implicit contract—it was simply a measurement of how far away from hoped-for results a project was. It was not a question of blame or poor execution, just a reason to reevaluate and redirect the investment.

S7: Listen to the Bureaucracy

We asked our bureaucratic overseers: What would make your job easier? We treated them as the customer of our new and improved oversight process. We took in their feedback frequently and adjusted our process. They hadn’t fully realized how much of a burden the old oversight process was on them, with its long and wordy documents and its drawn-out review meetings. Since our MD-102 documents were so long-winded, they didn’t actually have time to read them—so they delegated the review to others. But that meant that they didn’t really have a handle on important information and sometimes missed problems that were brewing. If we could reduce the noise and the blubber, then they could focus on the important stuff and oversee better.

We showed them that some of the information they were collecting was just a proxy for information they really wanted—and that we could cut right to what was important. For example, instead of telling them that a particular piece of work was 42% done (but hadn’t produced results yet), we could show them that we had finished and deployed about 42% of the functionality they expected, that employees or customers were using it, and that it was accomplishing the business results we wanted. That was much more valuable information for them.

We arranged frequent meetings with the overseers. Instead of giving them a stack of paper that didn’t have any actionable information, we agreed that there were really only two important questions they had, and that there were four key pieces of information that would answer those two questions: (1) Is the project healthy? and (2) What is the project planning to spend money on next?

To answer question (1), the two key pieces of information were: (a) how much we had spent so far, and (b) what business results we had accomplished so far? Comparing those two, the overseers would know whether the project was healthy. To answer question (2), the key pieces of information were (a) what we were planning to do next, and (b) how much we were planning to spend. We did this at a relatively fine-grained level for the upcoming month and at a coarse-grained level for the next few years. Comparing the plan and the cost, the overseers would have a sense of the business case for the future work—very approximate, but they would be revisiting the investment decision every month, so they were risking only one month of investment.

We were pretty sure that when the oversight group got used to this, they would find that it gave them exactly the information they needed in the most concise way. We were available to answer any remaining questions and we proposed a formal one-hour presentation and discussion every quarter. This pilot approach would be extremely lean but give the overseers more real control than they had had before.

But that was only a hypothesis on our part. Just as with any new product design, we needed to get feedback from our “customers” on how well it was working for them, and adjust based on what they told us. We set up a feedback loop with the bureaucracy and listened as the oversight committee reviewed our presentation and discussed it among themselves. We evolved the new technique over the course of several months based on what we learned.

S8: Reduce Risk and Increase Controls!

Like a bureaucracy, I’m pretty risk averse. That’s why I think we should make bureaucracy lean, learning, and enabling: doing so greatly reduces risk. The Sumo Wrestler outbids the bureaucracy by substituting lean controls that are even more risk mitigating than the old ones. We loved to take a “more risk-averse than thou” posture when needling the bureaucracy.

With the cloud and DevOps, we mitigate risk with speed. For example, DevOps automates testing and deployment so that completely regression-testing an IT system can take minutes to hours, where traditional manual testing took weeks to months. As a result, we can run our tests, including security tests, every time any change is made to the code or the infrastructure. That’s every time. Imagine how much more risk that mitigates. Our mean time to repair (MTTR) is also vastly shortened through automation, which means that when we discover a security vulnerability (which happens as hackers learn new tricks), we can fix it much faster, again lowering risk. Though new techniques can appear risky just because they are new, digital transformation in fact reduces risk.

It follows that the traditional bureaucratic controls, though put in place to reduce risk, actually increase it when compared to new alternatives. The Sumo Wrestler is not shy about pointing this out. “J’accuse! You, you supposedly risk averse fiduciary, you are holding onto old bureaucratic constraints that prevent us from responding to competitors and adapting to changes in the market. You are risking the entire company! That’s risk aversion?” My monkey side always wants to jump in and say “How can you keep those wasteful bureaucratic processes in place when they make it harder for us to respond to competitors and changes in the markets, and therefore threaten our entire company?” But this chapter is about the Sumo Wrestler, who turns any questions about the risk of the new around, using the force of the bureaucracy against itself. How can you, of all risk-hating bureaucracies, not change to a safer way?

A bureaucracy that fails to learn despite living in a fast-changing environment—one that petrifies—adds risk to its organization. That risk might be an “opportunity risk” (a parallel to “opportunity cost”) where new, risk-reducing practices have been invented but the organization is not taking advantage of them, or a more direct risk, where slowness to act threatens revenue streams. The Sumo Wrestler takes the power of risk aversion and turns it back on the bureaucracy to cause change.

User’s Guide to the Sumo Wrestler

A bureaucracy is a huge immovable object—a leviathan, a tectonic plate, a four-hundred-pound guy in a loincloth. The Sumo Wrestler uses bureaucracy’s force against it; he finds a small leverage point and applies force right there. Where does the bureaucracy have weaknesses?

*

I say “more or less” because we also do manual penetration testing and put guardrails in production environments. -au.