Mark Schwartz

Have any of you ever been frustrated by bureaucracy?

That's it. Go ahead and raise your hands. Nobody can see you.

All right. Looking around, I see pretty much everybody's got their hands up. For those of you who don't, you might want to broaden your definition of bureaucracy a little bit. So for example, when you were a child growing up, did your parents perhaps have some kinds of rules about how much TV you could watch each day, or what time you had to go to bed? And despite the fact that you had really good reasons why you needed an exception, why you should be staying up later, your parents just wouldn't listen to reason, right? The rules were the rules.

Okay. Well, that's pretty much what bureaucracy looks like to most of us in most cases.

My name is Mark Schwartz, and I'm an enterprise strategist at AWS, and I want to talk to you today a little bit about bureaucracy and what it is, and how we might think about overcoming it when it gets in our way.

All right. So my next question for you: I think some of you probably are involved in some kind of organizational transformation. Let's say a transformation to DevOps or digital ways of working in general, and you're probably running into some bureaucratic impediments, I think.

I know I was. I was the CIO of U.S. Citizenship and Immigration Services in the Department of Homeland Security. As you can imagine, we had some bureaucracy to contend with in the federal government. But from what I've heard, it's really not just the government that is filled with bureaucracy. I talk to executives from large corporations from around the world in different industries. From what I can see, large enterprises in general are very good at bureaucracy. Small companies sometimes also, but as a company becomes bigger, it tends to wrap itself in bureaucratic process. Also, there are some industries that are especially good at it. I would say financial services is a pretty good example.

So at Homeland Security, we had this wonderful piece of bureaucracy that was called MD 102, Management Directive 102. I've talked about it before in some of my other speeches. I love to talk about MD 102. I find it fascinating. And it kind of imposed an SDLC, a software delivery life cycle, on all IT projects that involved writing something like 87 documents, going through 11 stage gate reviews. It defined 21 oversight roles in the oversight process. It said that all requirements had to be finalized before any other work started, and in fact, it said that all the requirements had to be written as shall statements. It said that we couldn't start testing any code until all the code was finished and somebody had issued a letter saying they'd reviewed it and determined that all the code was finished and it was ready for testing.

So, it's not so surprising that government IT projects sometimes take years to complete, sometimes cost billions of dollars. We actually had one that had spent about five years, at the point that I'm going to tell you about, and it had spent about a billion dollars, and it didn't actually have any results to show for it. It had some results, but they turned out to be unusable. With a process like MD 102, you can kind of understand how things expand into monstrosities like that. We found that our average release time, our cycle time for finishing a release on most of our systems, was about 18 months. Eighteen months between releases. And we were in immigration during the Obama administration, so it was kind of a fast-changing area, and that kind of speed maybe wasn't a very good match for what we needed to do.

Nevertheless, we moved to the cloud and microservices. We rolled out DevOps across the agency. We went from that 18-month release cycle to deploying new features about three times a day on each of our major systems. And we did it still complying with MD 102, sort of.

So I'll tell you a little bit about what I learned along the way. I actually just wrote a book on the subject. My book is called The Delicate Art of Bureaucracy: Digital Transformation with a Monkey, the Razor, and a Sumo Wrestler.

You might wonder a little bit at the title. I realized as we were doing our transformation, or as I look back on it, I realized that the techniques that we had used in order to overcome our bureaucratic impediments, there were a number of them that I could identify as things that seemed to have worked for us. They fell into three categories pretty easily: the category of the kind of things a monkey would do, the kind of things a razor would do, and the kind of things a sumo wrestler would do. So in my book, I present a number of plays or actions you can take to try to overcome bureaucratic impediments, and I classify them into these three categories. You can sort of think of them as personas that we adopted in order to change bureaucracy. So that's the monkey, the razor, and the sumo wrestler.

So to illustrate for you what the monkey does, what the razor does, and what the sumo wrestler does, I'm going to tell you the story of MD 102 and our struggle against MD 102 and break it down for you a little bit.

So to begin with, we realized that MD 102 really was not written to support DevOps. So we knew we had to do something about that because we had to comply with MD 102. Fortunately, the first thing we noticed is that, like a lot of other pieces of bureaucracy, MD 102 had an exception process. They knew that it wasn't going to be able to cover every possible contingency, so they put an exception process into it. In this case, they said that it would be okay to tailor MD 102 whenever it was justified by the specific needs of a project. So we figured our project required some tailoring of MD 102 because MD 102 didn't make very much sense, really. That was kind of our argument, but I think we worded it a bit differently. But we started by writing a tailoring plan. And we found when we looked at our tailoring plan that we had tailored MD 102 to say exactly the opposite of MD 102.

Now, the gotcha, of course, is that you can't just write a tailoring plan. You have to get somebody to sign off on it. So that was what we had to do next. And that took a little bit of work, but we had a big advantage. Our big advantage was that our project had already wasted $1 billion in five years. So people were desperate for us to figure out a way to turn it around, and I don't think anybody had any new ideas on how to do so except what we were proposing.

So we had a discussion, a little argument around it. In the end, we agreed that our team would pilot a new approach and that we would be allowed to use this tailoring plan. All right. So that was a start.

So we went ahead. At the time, we were using Scrum. We didn't know anything about DevOps at the time, so we were using more or less a standard Scrum kind of practice. And so we had standups and we had a backlog, and it got groomed by a product owner, and we had retrospectives. In some of those retrospectives, we realized that we had a little bit of a challenge with product ownership. It's a long story, but we had a huge project ahead of us, and it was hard to have one product owner who really could own the entire thing because it crossed everything the agency did. But at the same time, when we had multiple product owners for different pieces of it, their pieces tended to expand, and we weren't able to move on to others so easily. So we figured in the spirit of continuous improvement, we would try a few experiments to see what we could do about product ownership. And we came up with something that seemed to be working for us at the moment. So we were pretty proud of ourselves, I would say.

Now, honestly, we didn't really know how this whole thing was going to work out. It seemed a little bit too easy to tailor MD 102 into saying the opposite of what it said. So we figured at some point we're going to hit bureaucratic impediments, but we didn't know what they were going to be, and we figured the best way to find out is just essentially provoke and see what happens. So that was our strategy, and that is the classic strategy of the monkey.

The monkey, as we all know, is mischievous and playful, and monkeys provoke. So by tailoring MD 102 in this way, we were issuing sort of a provocation to the bureaucracy, and we figured that when we saw its reaction, then we would learn something and we would learn about what we had to do in order to consistently be able to work around the bureaucracy. So without thinking about it at the time, we had essentially begun down the road of the monkey persona.

Well, so we waited to see what the bureaucracy would do and how it would react, and it reacted. So the first thing that happened was, you have to understand that this was a big failing government initiative. And when you have a big failing government initiative, auditors get very interested in it. So they decided to audit us. This was the GAO, the Government Accountability Office, and they audited us. They then called us in to explain their findings, and we were kind of surprised by the result because they sat us down, and strangely, they said that the problem with our project was we weren't being agile enough.

This was puzzling for a couple of reasons. The first was that as far as we knew, GAO didn't really know a lot about IT development, and they certainly didn't know a lot about agile. This was a new concept that was just being introduced to the government at that point. So we thought about it, and we realized that it was unlikely that they understood agile better than we did. After all, we had some agile thought leaders on the team. Some of us had been doing projects using agile approaches for a while outside of this project.

So we were interested in what the GAO would say, and the way they explained it was sort of like this. They said they read our documentation and they saw that we were using Scrum. And so they looked it up and they read some things about Scrum, and they found that our practices didn't exactly correspond to Scrum's practices. In particular, that continuous improvement we'd done on the product owner role didn't match what the Scrum books said. So they listed the points where we weren't doing what Scrum said. And it turned out that in some of their books and papers, Ken Schwaber and Jeff Sutherland, the creators of Scrum, said that you can't change anything in Scrum or else it's no longer Scrum. They did. They said that. And GAO pointed that out to us and they said, "You guys, you said you were doing Scrum. You're not doing what you said you were going to do, therefore you're not agile."

And we argued, we said continuous improvement is part of being agile, and we had continuously improved, we thought. But they said, "Nah, no good. We didn't do what we said we were going to do."

So, the bureaucracy kind of won round one, you might say. And part of why it was so difficult for us at that point is that we were not only fighting the government bureaucracy, we were fighting Scrum bureaucracy as well. Scrum is a bunch of formalized artifacts and practices and has a number of formalized roles, like product owner, and there are rules more or less about how they operate. And Schwaber and Sutherland had said you can't change anything. So, two enemies to fight against was a little bit too much.

We backed up a little bit and we thought about it, and we thought about how we could get out of this little bind. Well, it was kind of obvious when you think about it. We realized that what GAO really cared about is that we did whatever we said we were going to do. They read our plans, and they compared what we did against the plans. So it's obvious, I think, how you deal with it.

Let me introduce the sumo wrestler.

So sumo, if you're not familiar with it, is a kind of a wrestling match where you have two very large men, typically. I mean, typically large. I think they're always men. And they're in a small ring, and they crash into each other, and the object is to push your opponent out of the ring. Or actually, you can win by pushing your opponent out of the ring or by making them touch the ground with anything besides their feet. So the two of them, the two sumo wrestlers, sort of crash into each other, and there's a bunch of pushing, and often it seems like nothing's happening for a couple of minutes. And it doesn't really sound like a very subtle art form here, but it actually is. If you think about it, if your opponent pushes really hard against you, let's say, and you don't push as hard, they might push you out of the ring. Then again, if they push really hard and you just completely yield, they might go flying out of the ring, right? So in a way, the game here is to carefully sense what's going on with your opponent and then try to use their own strength against them.

So, that's what we did with the bureaucracy. The bureaucracy is also a big object, and we figured if we can be even bigger and if we can use the bureaucracy's strength against itself, then maybe we can win. So what we tried to do is to create our own bureaucracy that was, let's say, even more powerful than the government bureaucracy. We figured we'll write a policy that says we're going to be agile, and then we'll tell everybody in our organization that they have to follow this policy.

Okay. Good idea. Turned out we couldn't do that because policy is very formally defined in the government. There are certain ways to create policy, and number one, we didn't have the authority. And number two, it's a lengthy, involved process, and we didn't really want to go through all that. So we couldn't write a policy. We also couldn't write a management directive, which is what MD 102 was, Management Directive 102. We couldn't create a rival management directive because we didn't have the authority for that either. But I did have some really good bureaucracy experts on the team, and they thought about it and came back to me and said, "You know what? We can actually write a management instruction, not a management directive, but a management instruction saying that everybody had to be agile and everybody in the organization would have to follow it." So that's what we decided to do.

We created MICISO-IT-001, our first policy. Not a policy, our first management instruction. Sometimes people ask me how long our transformation at USCIS took, and I love to tell them it took an entire morning, which was pretty much how long it took for me to read the last draft of the policy and sign it. After that, we were provably agile.

We released our MICISO-IT-003 later on that essentially said everybody should use DevOps practices. It explained in more detail what we meant by those practices, and it had an appendix that we said was going to change often as good practices changed, but we mandated being agile and later using DevOps. So we could prove we're agile now.

And that seemed really good. The sumo wrestler had come through for us, but we kind of suspected that this was not going to solve all our problems either. So we went on with this for a little while, and then GAO decided to audit us again. And when they did, they came up with another interesting finding. They said the problem with what we're doing is that we don't have a good way to make sure that everybody's following our policy. So great, you've got this management instruction, and great, people are doing what it says, but you don't have a control mechanism to make sure they do.

Now, MD 102 did actually have such a control mechanism. It was something called IV&V, or independent verification and validation. And the way they had set it up, it essentially involved a third party, an impartial, objective party coming in and checking to make sure that the project team had actually met all of the requirements of the original requirements document. So they went requirement by requirement and made sure each of them had been implemented, whether it made sense or anything. And so we didn't have such a thing, and we had to admit that GAO was right about that. We didn't have a good way to force people to follow the policy.

So we wrote another management instruction defining, describing what IV&V should look like in our environment. And the IV&V instruction said that IV&V should check to make sure that all of the teams were using good DevOps practices. And it also had a couple of other interesting things to it. If you think about MD 102, essentially, its IV&V checked to make sure that the maximum amount of work had been done, that every requirement had been implemented. So we decided that our instruction would take a different approach. Our IV&V instruction essentially said the outside observers should make sure that the maximum amount of work had not been done. In other words, the minimum amount had been done. They were to enforce the principle of maximizing the amount of work not done. And they also were to enforce the idea of doing as little documentation as necessary. So part of their job was to review any documents that had been written, make sure that they were as short as possible, and make sure that they actually served a purpose. So our IV&V process was a little different from the MD 102 one, but it made a lot of sense given the direction that we were trying to go.

So this is the technique of the razor. That's the third persona that I wanted to introduce. The razor is named after the principle of Occam's razor, which essentially, there's some debate in philosophy about what exactly it says. But let's say it says that if you have a complicated explanation and a simple explanation of something, you should generally prefer the simple explanation. So we created essentially a bureaucratic version of Occam's razor, and it said, given the control that you want to have, if there's an easy way to do it and a harder way to do it, prefer the easier way, or more exactly, prefer the process that is shorter and faster.

So IV&V, in our definition, was there to apply the razor to everything we did to make sure that anything we did was the shortest path, the fastest path, and the simplest way to get things done, given the level of control that we had specified in our other instruction. We also applied the razor in the way that we tailored MD 102, or the way that our instructions set up the processes. Where MD 102 had 87 documents, our management instruction specified 15 or so, and we were working to get the number down from there. Where MD 102 had 11 stage gate reviews, ours had two. And again, we figured maybe we can even improve on that. But these are examples of how the razor can take bureaucracy and, without eliminating the bureaucracy, make it leaner.

So putting these techniques together, you've got the monkey who provokes and observes and tries things and learns. You've got the razor that makes things lean, even within the bureaucratic context. And you've got the sumo wrestler who tries to use the weight of the bureaucracy against it and to pull off a reversal, you might say.

So by combining these three approaches, these three personas, we had managed to create this process within the bureaucracy and fully acceptable to the bureaucracy that still supported our approach, which we knew to be the best approach, of doing frequent releases with cross-functional teams that let us do three deployments a day of new capabilities and let us do all of that within the context of the bureaucratic rules, even, you might say, within the context of MD 102.

So when I thought about it and thought about why all of this worked, I realized that there are three characteristics that bureaucracies tend to take on, but that are not really essential to bureaucracy. And those three things are: they become coercive, they become bloated, and they become petrified. They don't change. Now, bureaucracies don't have to be those three things. What you're really trying to do in a bureaucratic transformation, which is going to accompany your digital transformation, you're trying to turn those three characteristics of bureaucracy into their opposites, yet maintain the needed controls that might be embedded in the bureaucracy already.

Why do you need controls? Well, you need controls, in some cases, because you have compliance requirements, for example, because you have security to think about, and you need to put some limitations on what people do. There are a number of reasons why you might need the structure of a bureaucracy. But what you don't want is for it to be coercive, petrified, and bloated.

So the idea of a bureaucratic transformation is to turn what is a coercive bureaucracy into an enabling bureaucracy. You want to turn what is a petrified bureaucracy into a learning bureaucracy that's constantly able to improve itself, and you want to turn a bloated bureaucracy into a lean bureaucracy. Now, that might sound impossible, but as we showed with the technique of the razor, we could still work within that framework and just look at the value stream, cut out the pieces that were adding waste, and make the processes that were important to the overseers much leaner and still have them fulfill the same needs.

So that's what we try to do when we're transforming bureaucracy with the help of the monkey, the razor, and the sumo wrestler. And when you do it successfully, then the bureaucracy is actually on your side and helping you to enforce the good practices that you are trying to spread across the organization. So bureaucracy is quite wonderful in that way.

So what I really want to-- let me put it this way. Our digital transformations are really important, and it's crazy to let them get stopped by ineffective bureaucracy. It's important to learn these techniques of, instead of panicking in the face of bureaucracy or getting upset by it, instead to see a way to working with that bureaucracy and succeeding in the transformation, even while the bureaucracy is there and watching in a way.

And this is so important because the potential of our digital world, the potential of DevOps and the cloud and user-centric design is enormous, and there's no reason why it has to be held back by bureaucracy. So I'd ask you to take a look at the plays that I suggest in the book, and I think there are about 30 of them altogether, and see if maybe some of them will actually help you dealing with the things that are frustrating you in an organization.

I hope you will. Thank you for listening.