Making Bureaucracy Lean, Learning and Enabling

This post is a transcript of Mark Schwartz’s DevOps Enterprise Summit- London 2020 presentation. 

Hi everyone. My name is Mark Schwartz. I’m an enterprise strategist with Amazon Web Services. I think I’ve spoken at every one of these DevOps Enterprise Summits since 2014, so I hope you’re not getting tired of me yet. I think some of you might also have read one or more of my books. There’s The Art of Business Value, A Seat at the Table, and War and Peace and IT. 

And the exciting news, at least exciting for me, is I’m just putting the finishing touches on my latest book. And it’s a book about our favorite topic, I would say. It’s all about bureaucracy. I consider myself qualified to write a book on bureaucracy because, before I joined AWS, I was the CIO at US Citizenship and Immigration Services, part of the Department of Homeland Security. And you might say I got sort of a worm’s-eye view of your bureaucracy through that. And certainly I was stepped on by a lot of bureaucrats. 

I’ve been thinking a lot about bureaucracy. And the first thing I want to point out is that bureaucracy is not just a problem in the public sector, in government. It’s something that companies have to think about a lot. In my role at AWS I meet with about 120 senior executives from large enterprises each year, and consistently they tell me that their biggest problem or one of their biggest problems in transforming is bureaucracy. In many cases it’s bureaucracy that they’ve set up themselves. Bureaucracy is a force of inertia that’s holding them back from change. And so I think some of the lessons that I learned in government are quite applicable to corporate bureaucracy as well. So I’ve been thinking, really thinking a lot about bureaucracy, and the story I tell in my book might surprise you a little bit.

A Little Background on Bureaucracy

Here’s how it sort of goes. The first point that I try to make is that your bureaucracy is natural. It’s something we do all the time. People are really good at creating bureaucracy, and it’s around us more than we think. We just don’t necessarily notice it because it’s not getting in our way. Second point then is it actually is in our way, quite a lot. And it’s in our way in the most frustrating way possible. Right? And I don’t really have to tell you that, that’s not the surprising part of the book. Third thing, third point I like to make is that it’s not really bureaucracy itself that frustrates us. I’ve narrowed it down to three things about bureaucracy that are really troubling. And those three things don’t necessarily need to be part of bureaucracy.

So a fourth point I try to make is that we can change those things, and in fact, the best model that we have for how to do really good bureaucracy is DevOps. Now that’s a little bit uncomfortable in many ways for people who are big fans of DevOps to accept, but I’m going to try to show you that DevOps is actually a bureaucracy, and it’s good sense and a model for how we might want to structure bureaucracy in general.

[perfectpullquote align=”left” bordertop=”false” cite=”” link=”” color=”” class=”” size=””]Bureaucracy is a force of inertia that’s holding them back from change. [/perfectpullquote]

In the book I present a playbook for how you might deal with bureaucracy that gets in your way. And I present 25 plays and divided them into three different, let’s say martial arts. Three different ways: the Way of the Monkey, the Way of the Razor, and the Way of the Sumo Wrestler.

And if you learn those three ways, then I think you can bust through any bureaucracy that’s getting in your way. But as an extra bonus in the book, I also present a playbook for you to use if you happen to want to create your own bureaucracy, and do it in a way that is good not evil. So, that’s where the book concludes. 

So, the first thing we should discuss is what do we mean by bureaucracy? And it turns out, I was a little surprised to learn this, but bureaucracy has a long history in academia. Sociologists, and management theorists have been talking about it for a while, but maybe the easiest way to define it is to say that bureaucracy is a form of authority that is based on rigid rules and rigid roles or authorities. Right?

It often also includes what we call red tape. That’s something I’ll come back to in a minute and talk a little bit more about, but basically we’re talking about a system of organization or authority where there is a set of rules that has to be obeyed with no exceptions and where there’s a hierarchy of authorities that is also very rigidly defined. 

Born Bureaucratic

Now I would like to explain bureaucracy by talking a little bit about raising children. Now, of course. I consider myself an expert on this topic also, and very much qualified to talk about it because I don’t have any children and I never did. So I figure I don’t have any of that reality bias that some of you might have. I can actually just make up anything I want. So I’m imagining maybe you’re parents of young children and you tell them the rule is you have to be in bed by eight o’clock each night.

And I don’t know, is eight o’clock the right time? Let’s say it’s a seven year old and eight o’clock is your bedtime. And of course your seven year old doesn’t want to go to bed at eight o’clock. Right? So he or she makes up reasons every night for why it’s not a good idea to go to bed at eight o’clock. Why he or she has to stay up later. And of course you say, no, no, that’s not okay. You go to bed at eight o’clock. And of course I’m imagining that seven year olds these days go online to Wikipedia and do a little research and come back at you with, well, according to this scientific source I don’t have enough melatonin in my body at eight o’clock to go to sleep or whatever. And you say, too bad kid, eight o’clock. Eight o’clock is what it is. Right?

Now, when the kid asks you, why, which I’m sure they do, your answer has to be because I said. Whether you might know that’s not really the right answer, but at some point that’s what it comes down to. 

[perfectpullquote align=”right” bordertop=”false” cite=”” link=”” color=”” class=”” size=””]we learn bureaucracy kind of from an early age and we’re pretty good at it.[/perfectpullquote]

This is a perfect example of bureaucracy and teaching children how to be bureaucrats. It’s a fixed rule that they have to follow, and it’s a fixed set of authorities. I’m the mummy or the daddy, and I’m telling you that this is the rule, right? That’s exactly the characteristics of bureaucracy. And children learn this pretty well, because I don’t know if you’ve noticed that sometimes when you watch kids playing, they make up a new game and they spend more time discussing and arguing about what the rules of the game are going to be than they spend actually playing the game, right?

My point is we learn bureaucracy kind of from an early age and we’re pretty good at it. So I don’t mean to ask you to change your parenting techniques, despite my expertise in this field. Really it raises the question of is bureaucracy good or bad? And some of you might be surprised that I would even raise that question. Obviously, bureaucracy is bad, we know it. 

Surprise, Bureaucracy is Good!

But it turns out there are some reasons why bureaucracy can sometimes be a good thing or a helpful thing. First of all, the central idea of bureaucracy has to do with fairness. Rules are rules, and they’re applied fairly equally to everybody. So exceptions are not made because you’re especially rich or you’re an aristocrat or whatever, no exceptions. Right? The rule is kind of fair. It is what it is.

Second thing is the rules in bureaucracy provide some predictability, you might say. So if you are going to, let’s say, apply for a permit for something from the government, you know that if you fill out the application and you meet the requirements you’re going to get the permit, or at least you’re reasonably confident. You’re confident because that’s the way it works. The bureaucracy is set up that way and it has sort of predictable results. 

Today in the business world, there’s a good reason for bureaucracy, which is that we’re subject to all over these compliance regimes. In the government, it was FISMA, maybe it’s HIPAA or Sarbanes-Oxley, or any of these other many, many compliance regimes, and you have to get a good audit every year. It’s very hard to do those things unless you have a set of rules that you know, that everybody in the organization is going to follow and therefore it’s auditable. Bureaucracy is a tool that can help you be compliant. 

[perfectpullquote align=”left” bordertop=”false” cite=”” link=”” color=”” class=”” size=””]But it turns out there are some reasons why bureaucracy can sometimes be a good thing or a helpful thing.[/perfectpullquote]

And then one more thing I’ll mention, because this is one of those things you never think of in connection with bureaucracy, but imagine a brand, a very valuable brand, let’s say, Coca-Cola or McDonald’s or something like that. These are brands that are worth many billions of dollars. The only way you can maintain a brand is to maintain consistency. So McDonald’s, for example, has an operations manual that all its employees or all of its stores have to follow, essentially to make it clear that they’re part of the McDonald’s brand. You can imagine, let’s say at Coca-Cola, the way the logo is used. They’re very particular about that, right? There are rules around it, I’m sure, and if you want to use the logo in unusual ways you probably have to get approvals and all sorts of things. Bureaucracy can help in building a brand or anything else where consistency is an absolute requirement. 

That’s enough on why bureaucracy might be okay or helpful in some cases, we know that usually it’s not, it’s a pain in the neck. It’s really…you’re trying to make a transformation. You’re trying to change things and bureaucracy gets in your way. It really sucks. Why is bureaucracy so bad? 

The Three Big Bads of Bureaucracy  

And when you really think about it, or at least when I really thought about it, it came down to three things. I think the first problem with bureaucracy as we typically experience it is that it’s often coercive. The basic idea of bureaucracy is to force people to do things a certain way. It often involves people in authority who are happily exercising their authority over you. It involves these gatekeeping trolls of administrators who kind of show up now and then, pop out of the shadows, and say, “No, you can’t do that,” until you fill out a bunch of forms for them. Bureaucracy has a sort of coercive side to it often, and that makes it unpleasant. 

The second thing about bureaucracy as it’s typically practiced is that it tends to petrify. It tends to resist change. You have the rules and those rules stay the rules for a long time. And when you’re trying to do a digital transformation, let’s say that’s a problem. You’re looking for change. 

The third thing that we often see with bureaucracy is maybe what it’s most famous for bloat, that red tape. I think that’s really what we mean by red tape. It is the opposite of lean. It is wasteful in the sense that it requires filling out lots of paperwork and going through lots of processes that don’t necessarily add value. So to me, those are the frustrating things about bureaucracy.

• First of all, it involves somebody exercising authority over you from somewhere else in an organization. It’s coercive.
• Second, it petrifies, it doesn’t change when it should.
• And third, it involves lots of waste and frustrating, extra red tape that you don’t really want to go through. 

A Lean, Learning, Enabling Bureaucracy 

So are those three characteristics necessarily part of bureaucracy or is it possible that you can change bureaucracy such that it doesn’t have those characteristics? To me, the answer is very much yes. In fact, it’s what we tried to do when I was at USCIS, and I think we tried pretty successfully in many cases. And it turns out that DevOps actually is the model that we learned from in order to be able to do it. So let’s just agree right now that DevOps is a kind of bureaucracy.

For example, DevOps has lots of rules, and in some cases, those rules are automated, but they are still rules. They’re still enforced on you. In a traditional security model, for example, you develop a bunch of code and then at the end, the security people come in, they assess the code, and they say, “Oh, no, that you didn’t follow the rules. You’re not applying that right.” That’s good bureaucracy. That’s kind of classic. 

In DevOps we don’t have that. We have automated security tests instead. So those automated security tests are doing the same thing as the security people in a traditional bureaucracy. They’re doing it in a different way, but they’re still enforcing rules that constrain what you can do. I think from that perspective, DevOps is very much a bureaucratically oriented way of doing things. 

[perfectpullquote align=”right” bordertop=”false” cite=”” link=”” color=”” class=”” size=””]DevOps has the structure of bureaucracy, but it’s implemented in a very different way. [/perfectpullquote]

I think from the cultural perspective, too, for example. Do you know any DevOps teams that are deliberately doing blameful retrospectives? Blameful retrospectives? No, of course not. We all know that you do blameless retrospectives in DevOps. We also know, for example, that you need to check in all your code into the version control system and your infrastructure as well. 

We have all sorts of rules around DevOps, and they’re enforced pretty seriously the way that a lot of bureaucratic rules are. So I think in a way…I know I’m pushing things a little bit, but in a way, DevOps has the structure of bureaucracy, but it’s implemented in a very different way. And if we look at those three characteristics I talked about before and think about them in a DevOps context, I think you’ll see what I mean. 

So the first thing I mentioned before was the coercive nature of bureaucracy. It turns out, and a lot of sociologists have pointed this out, that a bureaucracy does not need to be coercive, it can be enabling. An enabling bureaucracy is a bureaucracy that has standard procedures and rules that are followed but in a way that helps you do your work. For example, it automates a way—or, I shouldn’t say automates—tt standardizes how you do boring, repetitive tasks in an efficient way. It’s the thing we call in DevOps toil: repetitive work that doesn’t add a lot of value. 

Bureaucracy standard procedures can help automate that toil so that you don’t have to think about it as much. I keep saying automate, I don’t really mean automate. In DevOps, we do it through automation, but the concept of an enabling bureaucracy is that it becomes a tool for people to use in doing their jobs better. And in an enabling bureaucracy, the employees have the ability to influence what those rules are going to be. 

A classic example of this was the NUMMI Joint Venture Factory between GM and Toyota, where it was an extreme bureaucracy in many ways. It had a lot of formal process standardization. It had a lot of layers of management, but employees were encouraged to suggest process improvements, in the spirit of continuous improvement, and they did. They did it a lot. And once they did, once their process improvement was tested, it became part of the bureaucracy. It became a rule that everybody else had to follow. 

[perfectpullquote align=”left” bordertop=”false” cite=”” link=”” color=”” class=”” size=””] a bureaucracy does not need to be coercive, it can be enabling   [/perfectpullquote]

In order to stop the bureaucracy from being coercive, we need to make it enabling. In DevOps the example I gave before of security is a great example of how you can do that. Instead of the security people coming in at the end and saying, “Oh no, you can’t deploy that.” The automated test suite that the security people can provide to the developers becomes a tool that the developers can then use to test the security of their code. It reports back to the developers whether their code is secure or not. So all of a sudden, what was sort of a coercive “no saying” thing before becomes a tool for the people who are doing the work, and in that sense it becomes a piece of enabling rather than coercive bureaucracy.

All right. Onto the second one, bureaucracies petrify. Well, a number of sociologists have suggested  that this petrification doesn’t actually need to happen, that the bureaucracy can be continually learning and changing. 

If you think about it, bureaucracy means you have a set of rules that are applied without exception. They are rigid rules in that sense. However, that doesn’t say anything about how the rules are created in the first place and whether they can change over time. For it to be bureaucracy, well, the rules have to be enforced on everybody, but still the rules can be changed periodically. Changed based on input from the workers, for example, as in that NUMMI example. There’s no reason why it can’t work that way. And it’s possible to set up a feedback loop where rules get improved constantly. That is, in a sense, what we do in the DevOps world through continuous improvement, for example. And in DevOps, that’s one reason why we check everything into version control, so that it can be changed later on. And we can keep control over the changes. So bureaucracy doesn’t need to be petrified. It can be learning as well. 

Onto the third one, the red tape. So bureaucracy often is bloated in the sense that it’s not lean. It involves a lot of extra work, paperwork, filled out in triplicate, sign-offs, etc. We have one process at USCIS called the Balanced Workforce Assessment. After you prepared it, it had to be signed by seven different people. Each of them had a one week SLA for doing their signing. And these things just sort of add up and add up and you wind up with this big bloated process, but in a way, bureaucracy is a value stream. It’s a value stream that produces a product. That product is compliance. And that value stream, like any other value stream, can be made lean by removing waste.

You can look at the steps in the value stream and say, how can we streamline this step? How can we remove this step? How can we have only six approvals instead of seven approvals? How can we have only one approval instead of six approvals? Each step can be optimized. You can work toward what you might call minimum viable bureaucracy or minimum viable compliance. You can use all of the principles of Lean, Lean Manufacturing, Lean production systems to remove waste out of the process. 

[perfectpullquote align=”right” bordertop=”false” cite=”” link=”” color=”” class=”” size=””] in a way, bureaucracy is a value stream. It’s a value stream that produces a product   [/perfectpullquote]

And what you wind up with is still bureaucracy. It’s still formal processes that have to be followed, but they can be much leaner processes.

You Don’t Really Hate Bureaucracy, Do You?

So what I’m getting at is the painful parts of bureaucracy, the things that really drive us crazy, are these three things: coerciveness, petrification, and bloat. But those three things can each be addressed, and they can often be addressed by techniques that are analogous to the ones that we use in DevOps. 

We can take our bureaucracy, automate it, and make it enabling for the people who are using it. We can set ourselves up for continuous improvement, even though after we improve a process we then apply it in a rigid sort of a way. We can do continuous improvement. We can use version control of rules as a way to A/B test. Let’s try this set of rules versus this one and see which one works better. 

We can remove bloat, the third thing, for example, by automating parts of our process, which we do a lot in DevOps. We can have the automated process produce some of the artifacts that otherwise we would have to produce manually. 

So in a funny way, it seems to me that DevOps implements a lot of the ideas of classic bureaucracy, but does it in a way that’s not painful. And what we found at USCIS is that a lot of the bureaucratic impediments that we were faced with could be treated in similar ways. Those bureaucratic impediments, instead of being impediments, could be made enabling. We could make them lean, and we could make them learning in the sense of being adjustable over time. 

So that’s my train of thought. And in the book I present the different ways that you can cope with the bureaucracy that you face. Pass through it is maybe a less delicate way of saying it, by forcing it to become those three things: enabling, learning, and lean. And the techniques for doing so obviously are the techniques of The Monkey, The Razor, and The Sumo Wrestler. 

And in the book, I explain what I mean by each of those and why those are the right ways to think about defeating bureaucracy, and give a list of suggestions on how exactly you might implement the Way of the Monkey, the Way of the Razor and the Way of the Sumo Wrestler in order to try them over whatever bureaucracy is standing in your way. So good luck with your digital transformations. And I hope this is useful to you when you happen to come across some bureaucracy in your way. 

Read more in Mark’s upcoming book The (Delicate) Art of Bureaucracy.

- About The Authors

Mark Schwartz

Mark Schwartz is an iconoclastic CIO and a playful crafter of ideas, an inveterate purveyor of lucubratory prose. He has been an IT leader in organizations small and large, public, private, and nonprofit. As an Enterprise Strategist for Amazon Web Services, he uses his CIO experience to bring strategies to enterprises or enterprises to strategies, and bring both to the cloud. As the CIO of US Citizenship and Immigration Services, he provoked the federal government into adopting Agile and DevOps practices. He is pretty sure that when he was the CIO of Intrax Cultural Exchange he was the first person ever to use business intelligence and supply chain analytics to place au pairs with the right host families. Mark speaks frequently on innovation, bureaucratic implications of DevOps, and using Agile processes in low-trust environments. With a BS in computer science from Yale, a master’s in philosophy from Yale, and an MBA from Wharton, Mark is either an expert on the business value of IT or else he just thinks about it a lot.

Follow Mark on Social Media

• 
•