So be cheery, my lads, let your hearts never fail, While the bold harpooneer is striking the whale!

—Nantucket Song in Herman Melville, Moby Dick

At this point the danger arises that he may first exclaim, “Is that any business of yours, sir? Who are you to me?”, and then, if you continue to pester him, he may raise his fist and land a blow on you. This is an enterprise that I too was once very keen to pursue, until I fell into such difficulties.

—Epictetus, Discourses

Job Descriptions

An interesting thing you discover when you become a government Chief Information Officer (CIO) is that your job description is a law. The Clinger-Cohen Act of 1996, Title 40, Subtitle III, Chapter 113, Subchapter II, clause 11315 establishes the role of a government agency CIO and lists the role’s duties. Here’s a piece of my job description:

(3) annually, as part of the strategic planning and performance evaluation process required (subject to section 1117 of title 31) under section 306 of title 5 and sections 1105 (a)(28), 1115–1117, and 9703 (as added by section 5(a) of the Government Performance and Results Act of 1993 (Public Law 103–62, 107 Stat. 289)) of title 31 …1

This seems a wonder of precision, given that the role of CIO in most enterprises is notoriously difficult to define. Don’t let it fool you—government CIOs struggle with ambiguity just as commercial CIOs do, but if we ever needed to establish our authority for a decision, we could refer those who questioned us to Clinger-Cohen’s impenetrable text.

My employees had helpfully sent me a copy of Clinger-Cohen and a few other important documents before I EOD’d (Entered on Duty) and was sworn in. Several of my other favorite documents were included in their email: a guide to 180 or so acronyms I’d be seeing every day, some promising-sounding laws called the Paperwork Reduction Act and the Government Paperwork Elimination Act, a thick stack of paper called MD-102, and a map of the Washington, DC, metro system. I scanned quickly through the documents, noted that they had nothing to do with the way anyone runs IT, and put them aside.

Shortly after I EOD’d, I was in a tiny meeting to discuss a tiny project. My memory’s probably a tiny bit unreliable on this, but I think it was just a tiny change to the text on a tiny web page. I asked my people how long they thought it would take.

“Eight months,” they said carefully, with a side glance at each other.

“Eight months?! How could that little change take eight months?”

“Well, actually, we were going to say something longer, but we knew you wouldn’t like it.”

“Is our contractor so slow that it will take them that long?”

“No, the contractor is pretty good.”

“Well then, why would it take eight months?”

Their enigmatic reply: “MD-102.”

Another incident, also early in my time at USCIS: I was at a meeting to discuss the fate of one of our IT systems, something called RNACS. RNACS was just what you’d expect given a name like RNACS—an old mainframe-based IT system, a piece of clunky, cave-dweller technology, expensive to maintain … and no longer used. After some discussion we were sure that no one would ever need it again. “Okay,” I said, “let’s decommission it.” Decommissioning meant we’d turn it off, archive any data it held, and stop paying for its upkeep. There was silence in the room.

“Uh, sir?” someone said.

“Yes?”

“You don’t have the authority to decommission it.”

“Why not? I’m the fu … I’m the CIO!”

“MD-102.”

Dang. Probably should’ve read that thing when they sent it to me.

MD-102 was Management Directive 102, a DHS policy used for overseeing the delivery of IT systems. It defined twenty-one distinct roles in the oversight process. In its hundreds of pages of plus thirteen appendices it listed eighty-seven documents that had to be prepared when delivering any IT system and eleven gate review meetings that had to be held to approve its various phases. Each document had to be signed by a giggle* of officials, and each gate review meeting had to be attended by a synod of prescribed voting members and a terafool of nonvoting observers.† At least one of the documents, something called an Analysis of Alternatives, routinely ran to a hundred pages or more and had never taken less than eighteen months to write. A favorite document of mine (with eighty-seven documents, one is bound to have favorites) was something called the Integrated Logistical Support Plan, which explained how we were planning to swab and pilot the new battleship—I mean, IT system. If there was a Louvre or Prado for bureaucratic art, MD-102 would have crowds lining up to view it.

Could there be some connection between MD-102 and the fact that it took years and hundreds of millions of dollars to deliver any IT capabilities?

Enter the Monkey

In 2010, Netflix released a piece of software called the Chaos Monkey, whose purpose was to randomly assassinate‡ other bits of software that were running. This might not sound like a great idea, especially when you realize it’s meant to run in a company’s production environment—that is, among the company’s live IT systems, the ones actively serving customers and employees. The reasoning behind Chaos Monkey is that since today’s IT systems are built to be resilient, to withstand unexpected failures without any noticeable impact, the Chaos Monkey would just test to make sure they really were. Netflix made its code available as open source so that other companies could practice decimating their own systems with friendly fire, and many do. Eventually, we did too at USCIS, but that’s getting ahead of the story.

Chaos Monkey spawned a new field in Information Technology: Chaos Engineering. Software systems have become so complex and interconnected that it’s virtually impossible to know what might go wrong. Chaos Engineering is a discipline that uses controlled experiments on running IT systems to find those complex scenarios that might lead them to fail, so that the software can be fixed to handle them. Automated scripts “inject” different types of failures to see what follows—what other sorts of chaos they lead to—so that technologists can make their systems more resilient.

Since organizations themselves are complex and interconnected social environments, the consequences of organizational change sometimes must also be determined experimentally. Christopher Avery, a leadership expert and speaker, in an article on responsible cultural change in businesses, talks about using a “provoke and observe” approach:

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.3

One tries something out of the ordinary and sees whether there is resistance, and if so, where it comes from and what it consists of. Then one formulates a strategy for dealing with it.

If you look back at my Clinger-Cohen job description, you’ll no doubt agree that government IT is a complex environment, with many interacting, networked, and obscure connections to be unraveled. The only way to improve it would be to provoke it, observe the consequences, and adjust. What was needed was a chaos monkey in the government.§

Speed and Government

I should probably give you some background. My agency, US Citizenship and Immigration Service (USCIS), is the component of the Department of Homeland Security (DHS) that handles legal immigration to the US—green cards, naturalizations, refugees and asylees, foreign adoptions, and about ninety other functions (things like providing some people proof of citizenship and letting others renounce their citizenship). USCIS folks are the nice guys of immigration—they don’t arrest and deport people (that’s ICE) and they don’t sit in the airport and look grumpy (CBP and TSA).

As CIO, I wanted very much to find a way that our IT organization could respond quickly to our agency’s needs. It might not be obvious why speed is important in the government, but this was something I’d learned along the way. I’d joined the government in 2010, toward the beginning of the Obama administration. On June 15, 2012, I was at home watching the evening news on TV when the president came on and announced his new immigration initiative, Deferred Action for Childhood Arrivals (DACA). This was the first I’d heard of it. The president also announced that it would be rolled out in sixty days.

The president didn’t know, because, er, he hadn’t asked us, that our average time to release an update to an IT system was eighteen months. When we analyzed the DACA initiative, we found that it would involve making changes to more than twenty IT systems. The math wasn’t encouraging.

We did it, of course. USCIS began accepting applications on August 15, 2012. We had to waive a few requirements here and there, skip steps in our standardized processes, get our contractors on board with the emergency effort, push off other work while we focused on DACA, and … it’s probably good that I don’t know what else. I know there were individual heroics, stressful meetings, and food truck wrappers all over the office.

If it had been a one-time effort, we could have left it at that. But at the beginning of the Obama administration there was talk of comprehensively reforming the immigration system, so we expected plenty of change. We also had a very large and famously “failing” IT project in the works, something we called USCIS Transformation. It was intended to be a five-year project, and after five years it had—at least according to the official records—spent about a billion dollars and delivered nothing. Even by federal government standards, this was considered pretty bad. For a sense of scale, in five years most people could have read MD-102 two or three times, and maybe the introduction to the gargantuan FAR.

The solution to large failing projects and to slow delivery cycle times is well known in the IT community: a combination of what are called Agile techniques, DevOps, and the cloud. The idea is to work in short, fast increments, finishing and releasing pieces of IT capabilities quickly and frequently, then adjusting course based on the results and the feedback obtained from users of the software. But MD-102 prescribed exactly the opposite approach—extensive planning, monolithic deliveries, and strict adherence to plans made before the project was started. Clearly, we couldn’t work within the bounds of MD-102 and also deliver speed and agility. But MD-102 was the policy of our corporate overseers, DHS.

Barriers to agility were built explicitly into MD-102’s workflows, with steps like a Systems Definition Review (SDR), which “evaluate[s] the readiness of the project to proceed to Stage 3, Design … the SDR uses a set of exit criteria to evaluate completion of activities and products for this stage.” There are seventy-three exit criteria, including “Have the requirements collected to date been specified in clear, meaningful, and testable format using ‘shall’ statements?”4 In translation, that means, “You must slow down until the bureaucracy catches up.” It was a way to spend enough time documenting and approving the requirements that you could be sure they were no longer relevant.

Or, the definition of the integration and test phase, which is allowed to begin only after all of the development work has been completed: “The purpose of the Integration and Test Stage is to demonstrate that the solution developed satisfies all defined requirements and to complete the integration of configuration items that have been readied during the Development stage.”5

DevOps, on the other hand, requires that integration, testing, and delivery start right away, at the beginning of the project, and proceed throughout. It also has as a principle: “Maximize the amount of work not done.” That is, try to find requirements that you can avoid implementing.

Not that MD-102 was the only impediment, but it was a handy enemy. If you could make it through all the words, what it communicated was “you must move at the pace of an embarrassed glacier and spend vast amounts of money if you want to be allowed to do anything good for the American public.” Arguably there were worse impediments in government—the Paperwork Reduction Act is a good candidate (more on that later)—but MD-102 was the most immediate. It was the leviathan breathing bureaucracy down our necks,¶ so the battle with MD-102 commenced.

Robot Pranks

MD-102 was not crafted by evil bureaucratic robots playing robot pranks. It was created by dedicated civil servants who wanted to guide projects into delivering good results and effectively using the public’s resources, generally the taxes paid by citizens. It institutionalized practices that were considered by many to be best practices when it was written. But IT had changed, and new ideas such as those we planned to implement had shown themselves to be much more effective.

The writers of a document like MD-102 are also not naive. They left open a back door, as most bureaucratic artworks do—an exception process. In this case, something called a Project Tailoring Plan. So, we began there, “tailoring” the process laid out in MD-102 to be exactly the opposite of the process laid out in MD-102.

The snag with a Project Tailoring Plan is that someone has to sign off on it. This is hard because most people are too busy when you ask them to take a personal risk. But we got a signature because (1) several of our projects were frighteningly behind schedule and no one could figure out another way to fix them, and (2) everyone had heard that DHS IT needed to become agile, and this was the one way anyone had thought of to do so.

The moment was right. The DHS CIO had recently written a widely distributed email saying we should try out some new Agile ideas. That sort of email is like a banana to a chaos monkey.

We also had the advantage of the then-recent failure of Healthcare.gov, the president’s signature healthcare initiative. When the site was finally launched after extended political battles, it quickly fell apart. I taught my staff to ask “Do you really want another failure like healthcare.gov?” in answer to any questions they received.

So, we were given limited permission to try out something more agile, at least for the technical part of the work. We decided to use a process based on the Agile framework called Scrum,** organizing our work into short iterations, with working software delivered after each one.

Now, an interesting side conversation developed. I said that MD-102 was not agile. The guardians of MD-102 said that it supported agility just fine, because you could get an exception with a Project Tailoring Plan, as we did. I said that since Agile is the best-known way to get results, you shouldn’t have to get an exception to use it. MD-102’s rules saying that you have to work the old, discredited way unless you get an exception are not actually good guidance, IMHO.

So why, I asked, don’t we just make MD-102 say that you have to be agile and fast, unless you get an exception? The rulemakers laughed, because obviously they couldn’t be as irresponsible as that. A Systems Engineering Center of Excellence had been involved in formulating MD-102, and the Center of Excellence said that it’s excellent to have a lot of documents and gate reviews, and they would know, since they are the Center of Excellence.

Anyway, we proceeded with a big project that was now tailored to be agile. We rolled out Scrum,†† juggled feature backlogs, stood up for a fifteen-minute standup every day, retrospected religiously at the end of each increment, and practiced continuous improvement on our agile process to get better and better.

Agile Amateurs

Matta!‡‡ A problem arose. Because it was a huge failing project that we were trying to fix, it had the attention of the auditors—in particular, that of the Government Accountability Office (GAO) and the DHS Inspector General (IG).

There was something surreal about their audits. The GAO didn’t know that much about IT delivery, much less about Agile practices. I, on the other hand, with the appropriate nose-up arrogance of a digital technologist, considered myself an expert, having used Agile practices more or less since the Agile Manifesto was written in 2001, and I had several people working for me who were Agile coaches and thought leaders.

So, it surprised us when we went to a meeting where the GAO presented their findings and told us … we were not agile enough. Seeing that we were using Scrum, they had done some research, and they compared our practices to those of the official Scrum framework. It turned out that in our continuous improvement retrospectives we’d decided on a few departures from the rules of Scrum. For example, we’d experimented a bit with Scrum’s product owner role. Our challenge was that the tremendous scope of our project made it difficult to have a single product owner from the very siloed business operation, and when we had several product owners each was incentivized to maintain a never-ending list of requirements (feature backlog) so that they kept the teams working on their part of the project forever. We tried some experiments to see if we could overcome the problem. We’d also made a few other changes here and there, based on what we’d learned as the project proceeded.

GAO hit us with a fact-based analysis. They listed the points where Scrum practice said one thing and our practice was different. Then, for a kicker, they pointed out that the creators of Scrum, Ken Schwaber and Jeff Sutherland, had said that you can’t change anything in Scrum, or it’s not Scrum.6 Ergo, we were not agile.

I explained that the idea of Agile is to inspect and adapt, and that a good Agile practice was to hold retrospectives for continuous improvement. Once again, I was laughed at.

Prosecutorial voice: “So you admit you made changes. According to Jeff Sutherland, then, are you doing Scrum?”

I had to admit that we weren’t. Then I thought I had them with a brilliant closing argument that “Scrum is not the same as Agile.” Nice try, but I was dealing with bureaucracy professionals. They just drummed their fingers on our Project Tailoring Plan where it said we were going to use Scrum. We were not doing what we said we were going to do.

Fastest-Ever Digital Transformation

What had defeated us? Think about it for a second. It wasn’t really government bureaucracy. It was Scrum bureaucracy. Scrum had a bunch of rules, and Jeff Sutherland had said you must follow the rules. Scrum—please don’t hit me, Agile IT folks—Scrum is a bureaucratic way of performing IT delivery. It has defined roles—scrum masters, product owners, team members—and it has defined rules—fifteen-minute standups, backlogs, grooming, story points, and something about pigs and chickens that even its adherents are embarrassed to talk about.§§ I don’t mean that it’s necessarily bad,¶¶ just bureaucratic.

This led to an epiphany. I realized—I had been told this before, but I had never seen such a clear example—that the auditors’ real job was to compare what we said we would do with what we actually did. How to overcome the system then was obvious.

You know the idea of aikido and other Japanese martial arts? You try to use your opponent’s strength against them. In a sumo match, the wrestlers push against each other. But if your opponent pushes too hard and you respond by pulling, you can throw them off balance and win the match. A chaos monkey, it turns out, can sow chaos better by mastering sumo.

What if I flexed my own underdeveloped bureaucratic muscle and wrote a policy that said we had to be agile? I could define agility in my own way … exactly the way we wanted to run our projects. Then if GAO audited us in the future, they’d be reading my policy and checking to see that everyone was following it! They’d be on our side. A virtuous circle. An inashi,*** a deashi,††† a true sumo solution.‡‡‡

So, I looked into how I’d go about writing a policy. Unfortunately, I found out that I didn’t have the authority to do so, and in any case, it was a long and complicated process. Nor did I have the authority to write a Management Directive, like MD-102. But—I was told by my best bureaucracy savants—I could sign a Management Instruction, composed by them in fluent Orwellian, as long as it wasn’t a policy, and the people who worked for me would still have to follow it. This was becoming fun.

MD-102 had an official-sounding name, so I knew our instruction had to have one too. Not having any examples to draw on, I decided to name it MI-CIS-OIT-001, or Management Instruction, Citizenship and Immigration Services, Office of Information Technology, Number 1. It doesn’t roll off the tongue … so it seemed perfect.

Our non-policy carefully defined what we meant by agile. It prescribed eight practices for every IT initiative, and it described five more that were optional. For example, it mandated frequent delivery of code, time-boxed iterations, retrospectives, and continuous testing. There (finger snap)—we had a lack of “policy” that said everyone had to be agile. Fastest Agile transformation ever! We were provably agile the day I signed the non-policy.

Later, when we learned about DevOps, my experts wrote me a new MI with the equally catchy name MI-CIS-OIT-003.7 On the day I signed that one we’d transformed all of our IT activities to DevOps. This is why bureaucracy is wonderful.

(If you want to transform your organization in just two days, you’ll find MI-CIS-OIT-003 in Appendix A to this book.)

Be Right a Lot

Now there were a few problems with this approach. The first was that my policy conflicted with MD-102, which had been signed by someone much higher in the organization. The second was that when my employees saw my policy, they whispered to each other, “What is the CIO talking about?” They had no idea how they were going to do what I said they had to do, and besides, they said, it was impossible because of MD-102. But I was still congratulating myself on my bureaucratic sumo move, so I figured we’d deal with those things later.

In my mind the conflict with MD-102 was just a small impediment—yes, my employees still had to comply with it while they also complied with my policy, but since it was an impediment and I was a servant leader, I could just tell them not to worry because I would deal with it.

“Go ahead and follow my policy, and I’ll deal with MD-102,” I said. See? That fixed it with one sentence. How did I deal with the impediment? Mostly I asked the DHS CIO for help. I had his banana memo to refer to.

This put all the risk on me, and that was okay. We have a leadership principle at Amazon that goes like this: Be Right a Lot.§§§ That helps when you’re taking risk in a bureaucracy as well: it’s less risky when you do the right things.

I knew that our agile approach at UCIS was going to lead to great results. All we needed was a bit of time to prove it. Good news—big bureaucracies move slowly enough that we had plenty of time to show results before anyone got around to questioning us. Again, bureaucracy made things easy for us.

The second problem, as I said, was that my IT employees had no idea how to be agile. Here again bureaucracy came to the rescue. I have to be a bit immodest again to explain this. The government bureaucracy is extremely hierarchical. And I was rather high in the bureaucracy. As a member of the Senior Executive Service, I was technically the equivalent rank of a two-star general or admiral in the military.8 Now, I had no military experience and would never have made it to that sort of rank if I did. I’m about as fit as you’d expect someone to be whose chief forms of exercise are giggling and lifting a Starbucks venti to my lips. But in the federal bureaucracy, people—largely—treated me as if I were worthy of respect. So, when I puffed my chest, summoned all of my command-and-control authority, and nicely asked everyone to be agile, they said, “Yes, sir!” Of course, that’s also what they said when I told them that they should read my favorite short story by Herman Melville. Side note: read “Bartleby the Scrivener.”¶¶¶ What a great story.

But they were motivated to figure it out, after they got tired of telling each other that I was as crazy as a sumo-wrestling monkey. I arranged training for them and paired them with technologists who already knew what they were doing, and the transformation proceeded.

Another technique I used to great effect: I met with our contractors (we used a lot of contractors), and put on my serious face and said to them something like this: “I expect your people to know more about DevOps than I do, and that’s a high bar. If you have talented people working on other government projects, take them off those projects and put them on mine.” Then I would scowl and walk out of the office like I imagined a two-star general might.

By the time we got to writing MI-003, we’d learned a lot. Instead of defining what good practices were, we defined ten outcomes that we wanted. They were things like “Frequent delivery of valuable product” and “Work that flows in small batches and is validated.” Then we wrote an addendum in which we listed what we considered today to be good practices but noted that the addendum would change often. So, we essentially wrote a policy that said “this policy will change often, and that is a good thing.”

Wrong Again

As you can tell, I was proud of my newfound bureaucratic savvy. But GAO and the IG raised the bureaucratic stakes. When they heard about my new policy, they dinged it again. The problem, they said, was that I hadn’t set up any mechanism to make sure my people were doing what my policy said they should do.

That was a pretty clever maneuver, because, you see, MD-102 had such a mechanism. It was called independent verification and validation (IV&V). The idea was that an objective, independent outside party would come in at the end of each project and check against the initial requirements to make sure every feature in it had actually been delivered, whether it turned out to be necessary or not. It was a check to make sure that the project had not done anything that risked flexibility or agility, and that every unnecessary bell and whistle**** in the requirements document had been rung and blown so that the government had wasted as much money as possible.

Well, they had me again. No matter: we now knew enough to release MI-CIS-OIT-004, our non-policy on Independent Verification and Validation. We mandated a role for IV&V that was exactly like MD-102’s, with a few exceptions. While MD-102’s IV&V made sure the full, or maximum, amount of IT work had been done, MI-004’s made sure that the minimum had been done, that teams were finding as many things as they could not to do from the original requirements while still getting the same business outcomes. IV&V would also do as little auditing as possible given the project’s risk, and it would make sure that the teams were doing DevOps well and were happy and motivated.

Enter the Razor

William of Occam†††† was a medieval Christian philosopher. Like many philosophers, he’s most famous for saying something that he never said. In a principle called Occam’s Razor, he proposed (he didn’t) that simpler explanations are better than more complicated ones, other things being equal. Or he said that explanations that posit fewer entities are better than explanations that posit more. He might have not said either one. In any case, Occam is given credit for a principle of “ontological parsimony” that said you shouldn’t add extra stuff you don’t need. Newton’s Law of Gravitation, Occam’s rule would say, is to be preferred over a law that says apples fall because massive objects like the Earth cause a chorus of invisible bureaucrats to write a policy instructing apples to fall or else, and apples, being law-abiding, follow the rules.

My bureaucratic variant on Occam’s Razor says “Don’t add extra work that doesn’t add value” or “Choose the process that is leanest, given an equal amount of value delivered” or, in the case where the value to the business is risk reduction, “Don’t do extra risk-reduction work that doesn’t reduce risk.” It’s a principle of bureaucratic parsimony.

Applying the razor, we devised a new tailoring plan to accompany MI-003 that shaved MD-102’s eleven gate reviews to two, and the number of documents from eighty-seven to fifteen. We continued looking for ways to get an even closer shave. We also trimmed our procurement times from six or more months—sometimes as long as three years—to thirty days in some cases. We whittled down our up-front business case-building to as little as a month, and pared the time it took us to procure computing infrastructure from nine months to just a moment in the cloud.

By mastering the ways of the Monkey, the Sumo Wrestler, and the Razor we’d not only transformed IT, but we’d also set up checks and balances to make sure it stayed transformed. We’d gone from releasing new IT capabilities once every eighteen months to three times a day for some of our IT systems. We’d taken a project that had been “underway”—writing documents but not doing anything—for four years, and in just six weeks begun deploying new IT capabilities that had measurable, meaningful business impact.

Now, that’s what bureaucracy can do!

A Brief Moment of Reflection and Self-Awareness

All right, it wasn’t all as smooth as that might sound. It was more a matter of stumbling around in bureaucracy-land until we found some tricks that worked. We inspected and adapted, and in the end had some good successes and also some notable failures. We never did get MD-102 to mandate agile practices, though it was changed to explicitly say that sane practices were acceptable.

Checking back in with USCIS a few years after I left, it appears that many of our changes have stuck, especially the cultural change that left employees willing to try new things and advocate strongly for them. Other areas that were important to me have seen some backsliding, as later management considered them less important. And I’m not sure anyone actually read “Bartleby.” But USCIS stands as a strong example of how change is possible in a resistant bureaucracy.

Though I tell the story with some snark—meant in fun—the most important thing I learned was that virtually everyone involved cared deeply about the agency’s mission and wanted desperately to do the right thing. We succeeded best when we unlocked that motivation. Bureaucracy is the mechanism for accomplishing mission outcomes in the government. It won’t go away. But it can’t remain an impediment to accomplishing that mission once the passion of employees is stirred and directed to the right ends.

Estimating Costs

There was another complication I should tell you about. MD-102 required that we calculate Life Cycle Cost Estimates (LCCEs) for our planned projects. The very reasonable idea of the LCCE was that project teams should disclose not just the cost of building or acquiring a new technology, but also the cost of maintaining it over time. According to the scholars charged with interpreting MD-102, our LCCE should assume that our new immigration software system, ELIS, would be in operation for twenty years once it was completed. So, calculating our cost estimate would involve estimating IT costs for the next twenty years.

That’s difficult, since a twenty-year estimate would include, ahem, a bit of uncertainty. Like how much prices might change for our cloud infrastructure, how much labor costs might increase, what new technologies we’d need to incorporate into it, how many immigration applications we might need to process in the future. (We could perhaps hedge a bit by buying Red Bull futures.) And a big uncertainty—how much immigration laws might change over the next twenty years. The guardians of MD-102 insisted that an estimate could be prepared with good statistical rigor by paying contractors a whaleboat of money to use simulation techniques. We were pretty sure that no simulation could give an accurate estimate with that kind of uncertainty and wanted to keep our whaleboat of money. But we complied and paid contractors to do the calculation, which came to $2.1 billion as the twenty-year cost.

A year or two later, the scholars of MD-102 told us that their interpretation had changed and that now our estimate should project costs for thirty years in the future. There’s a good amount of uncertainty about what IT costs might look like thirty years into the future—after all, thirty years in the past almost no one had a PC, let alone a notebook, a tablet, or a smart phone. But we changed the cell in our spreadsheet model from twenty to thirty, and dutifully reported a new estimate of $3.1 billion for the thirty-year LCCE.

The Inspector General then wrote a report saying that our project was doing so badly, that our costs were planned to jump from $2.1 billion to $3.1 billion—we were going to overspend by $1 billion! We protested that nothing had changed. The difference between the two numbers was just that it was a thirty-year estimate instead of a twenty-year estimate. The IG put that into a footnote in their report.9 The press apparently doesn’t read footnotes, because the articles they wrote said that our project was going over budget by $1 billion.

Score one for the bureaucracy.

The Paperwork Reduction Act (PRA)

I mentioned that one piece of bureaucratic art that slowed us down was the Paperwork Reduction Act (PRA) of 1995, 44 U.S.C. 3501 et seq. The “Act” in its name tells you that this was a law, passed by Congress. A bureaucracy-busting law! It was intended to reduce the amount of time the public had to spend filling out forms for the government. That’s a brilliant idea. I’ve recently filled out applications for visas to other countries that ask for information like my father’s cousin’s children’s names and occupations and my favorite brand of chewing gum. Even better, Congress set up a concrete metric to measure the PRA’s success—multiply the time it takes to fill out a form by the number of people who fill it out, and that gives you the total burden on the public. The PRA’s goal was straightforward—to minimize burden.

I know this sounds like a good thing for those of us trying to modernize government IT by making application forms electronic. The first sign of trouble is that there is also another act called the Government Paperwork Elimination Act (GPEA). The Knight of Occam asks: “Why would we need both a Paperwork Reduction Act and a Paperwork Elimination Act, and why is there still so much paperwork?” All will become clear.

Congress made the mistake of specifying the precise process that would be used to implement the PRA, and Congress, for the most part, is not filled with experienced process managers. The PRA was to be overseen by a small team of bureaucrats in the White House called OIRA (Office of Information and Regulatory Affairs), and any new form a government agency wanted to release to the public would first have to be approved by them and given a control number. You’ve seen these on the bottom of government forms. To get approval from OIRA, you had to send them a mock-up of the form, along with an explanation of each data field and why it was needed, and an estimate of the burden. Then, after OIRA’s critique, you would improve the form, publish it for sixty days to gather the public’s comments, work with OIRA to improve it again based on the feedback, and then republish it for another thirty days for more public comments. And then OIRA would decide whether to approve it.

Now, this process probably makes sense if you’re Congress. But given that OIRA is chronically understaffed, it sometimes took as long as eighteen months for a form to be approved. And OIRA later determined that the process would apply not just to newly created forms, but to any change to an existing form. That’s any change—including changes whose purpose was to reduce the paperwork burden. So it might now take eighteen months to reduce public burden, and more effort and cost than most agencies wanted to spend. You had to think carefully before doing anything of the sort.

Furthermore, OIRA decided that electronic forms were also subject to the process. If we at USCIS wanted to offer an online version of one of our ninety or so paper forms, we’d have to go through the entire approval process again, even though the paper version had already been approved. If we later decided to change it based on applicant feedback, we’d have to do it yet again. And our plan was to make all ninety forms electronic.

They added a bonus rule that there had to be “parity” between the electronic form and the paper one—we couldn’t do anything that gave an advantage to people who chose to use the electronic form. Now, it’s common in electronic forms for the software to fill “default” values into some of the fields based on what it already knows about an applicant, and to validate what an applicant types to make sure they haven’t accidentally listed their age as negative ten or their favorite TV show as Real Housewives of New Jersey. But, of course, paper doesn’t do that, so it was (in theory, at least) prohibited.

One more thing. It’s an IT best practice to do A/B testing when designing a form. That means that for each design decision that has to be made, several versions of the form are created to see which option works best when people use it. With the PRA we obviously couldn’t do that, because the form had to be fully approved before we let people use it.

Ah, you’re wondering what the Government Paperwork Elimination Act is for. The GPEA of 1998 (1998!) required federal agencies, by 2003, to provide electronic rather than—or in addition to—paper options for the submitting of information where practicable, and to accept electronic signatures rather than paper ones, where practicable (my italics).10 Although we wanted to accept electronic signatures on our forms, the Justice Department apparently thought that in our case it wasn’t practicable, so we set up a process where our digital applicants signed a paper form when they came to our offices to give us their fingerprints.

Why We Do This to Ourselves

MD-102, the LCCE, and the PRA (and GPEA) exist for very good reasons. You could say the same for most bureaucratic processes in the federal government. The federal hiring process, for example, is highly formalized because it must make sure that hiring is done fairly and without bias, and because it implements a policy that favors military veterans for government jobs, which is a policy goal. The procurement process takes six thousand pages to describe in the massive FAR because it’s carefully designed to make government procurement fair—to avoid bribery or even unconscious biases on the part of the procurers. In a way, the government is striving for perfection in how it serves its citizens, and the bureaucracy I’ve made fun of in this chapter is their well-meaning, passionate attempt to do so.

In the business world, formal rules and accountabilities also exist for good reasons. One can always ask, “What is the control objective of this rule?” There invariably is, or once was, such an objective. Sometimes a rule serves to reassure investors that the company has control over its reporting (an explicit goal of Sarbanes-Oxley, for example) or control over its spending. Sometimes the rules and authorities are put in place to mitigate risks or perceived risks. Sometimes they’re there to prevent problems from recurring, as in the case of the missing corkboard diagram. Sometimes they’re intended to promote consistency within a brand. All these rules must be applied universally, or they lose their meaning. You can’t convince investors you have control over spending if employees are sometimes allowed to bypass the spending rules.

In any social organization, there’s tension between freedom and constraint, and a bleeding edge where the two rub up against each other. That’s the territory where the bureaucratic Chaos Monkey, Razor, and Sumo Wrestler operate, probing the frontier, investigating where freedoms may lie and readjusting the guardrails to achieve both control and creativity.

*	Gaggle? -ed.
†	Apparently, a brilliant meme that a collection of baboons is “a congress of baboons”2 turned out to be a hoax. But in looking it up I discovered the (apparently legitimate) collective nouns: a shrewdness of apes, obstinacy of buffalo, coalition of cheetahs, business of ferrets, bloat of hippopotamuses, conspiracy of lemurs, unkindness of ravens, and wisdom of wombats. Monkeys, as we know, come in barrels. -au.
‡	Have you noticed that the word “execute,” which should mean the same as kill, actually means the opposite in the technology world? Just saying. -au.
§	In Chapter 12 you’ll learn the Way of the Monkey, the first force for transforming bureaucracy. For now, just watch the Monkey in operation. -au.
¶	Actually, whales can’t do this. They don’t even have noses. -au.
**	Note that I am no longer a big fan of Scrum. Some of my reasons will become evident later in the book. -au.
††	A popular Agile Software Development framework, which Mr. Schwartz discusses in greater detail later. As he says, it calls for fifteen-minute daily standups and frequent retrospectives. -ed.
‡‡	“False start.” See the sumo references below. Schwartz is thinking of his struggle against MD-102 as a comical clash between lumbering players, like a sumo bout. -ed.
§§	Pigs and chickens: In Scrum, the project team members are “pigs” and everyone else is a “chicken.” The idea is that team members are fully committed, like pigs who provide bacon, and everyone else is only “involved,” like the chickens that provide eggs. Scrum says chickens should defer to pigs, as in George Orwell’s Animal Farm. Knowing Mr. Schwartz, he is probably also thinking of the fact that the pig-leader in Animal Farm is named Napoleon, one of Mr. Schwartz’s favorite historical figures. -ed.
¶¶	It is, actually. -au.
***	Sidestepping or dodging move. -ed.
†††	Constant forward motion. -ed.
‡‡‡	A classic paragraph from Mr. Schwartz. He is weaving together threads: bureaucracy, bloated, whale, sumo wrestler. -ed.
§§§	This principle is more nuanced than it would appear. It also means that the leader should seek out other opinions and data and be willing to change views if warranted. -au.
¶¶¶	In Melville’s short story of bureaucratic rebellion, Bartleby is a clerk in a legal office. Any time his boss asks him to do something, he replies, “I’d prefer not to.” -ed.
****	According to https://www.phrases.org.uk/meanings/bells-and-whistles.html, the expression “bells and whistles” originally did refer to things that made a lot of noise, as you’d think. Today it refers to what government contractors often deliver instead of useful software for the billions of dollars they’re paid. -au.
††††	So that there shall be no confusion, know that our preferred spelling for this name at Exothermic Press is “Okham” but we have made an exception for Mr. Schwartz. -ed.