Bureaucracy and DevOps

Join Mark as he shares learnings from his new book: "The (Delicate) Art of Bureaucracy."

MS

Mark Schwartz

Author, The (Delicate) Art of Bureaucracy

Transcript

00:00:07

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 summit since 2014. So, uh, I hope you're not getting tired of me yet. I, uh, I think some of you might also have read one or more of my books. There's, uh, the art of business value, a seat at the table and Warren piece in it. And, uh, 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, uh, 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 a, you might say I got sort of a worm's eye view of your courtesy through that.

00:01:09

Um, I'm certainly I was stepped on by a lot of bureaucrats. Um, so a book is just about ready. I've been thinking a lot about bureaucracy and, uh, the first thing I want to point out is that bureaucracy is not just a problem in public sector in government. It's something that companies have to think about a lot. Um, in my role at AWS, I meet with, uh, about 120 senior executives from large enterprises each year. And, uh, consistently they tell me that their biggest problem or one of their biggest problems in transforming is your ocracy in many cases of bureaucracy that they've set up themselves. But in any case, a bureaucracy, as a force of inertia, that's holding them back from change. And so I think the, some of the lessons that I learned in the government, uh, are quite applicable to corporate bureaucracy as well.

00:02:10

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. Um, here's how, how it sort of goes. Uh, the first point that I try to make is that your accuracy is it's natural. It's something we do all the time. People are really good at creating bureaucracy, uh, and it's around us more than we think. We just don't necessarily notice it because it's not getting in our way. Um, second point then is, uh, it actually is in our way quite a lot. And, uh, uh, it's in our, it's in our way, in the most frustrating way possible. Right. Uh, and, uh, I don't really have to tell you that that's not the surprising part of the book. Um, third thing, third point I like to make is that it's not really bureaucracy itself.

00:03:06

That frustrates us. It's really, um, I I've sort of narrowed it down to three things about bureaucracy that are the really troubling things and those three things don't necessarily need to be part of bureaucracy. Um, so a fourth point I try to make is that, uh, we can change those things. And in fact, the best model that we have for how to do really good bureaucracy is DevOps. Now, uh, that's a little bit uncomfortable in many ways for people who are big fans of, of DevOps to, uh, to accept, but I'm going to try to, uh, show you that actually dev ops is you're obviously, and it's good sense, and actually a model for how we might want to structure your ocracy in general. So, uh, then the book goes on, uh, in the book, I present a playbook for how you might deal with bureaucracy that gets in your way.

00:04:05

And I present altogether 25 plays as I call them from the playbook and I divide them into three different. Um, uh, let's say martial arts, you know, are 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, 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, uh, that's where the book concludes. So, um, first thing we should discuss is what, what do we mean by bureaucracy? And it turns out, uh, I was a little surprised to learn this, but we refer say has a long history in academia, sociologists and management theorists have been talking about it for awhile.

00:05:03

But, um, maybe the easiest way to, to define it is to say that bureaucracy is a form of authenticity that is based on rigid rules and rigid roles or authorities, right. It often also includes what we call red tape. Um, 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, uh, with no exceptions and where there's a hierarchy of all authority is that is also very rigidly defined. So, um, now I would like to explain bureaucracy by talking a little bit about raising children. Now, of course, I, I consider myself an expert on this topic also in 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, that reality bias that some of you might, might have a, I can actually just make up anything I want.

00:06:17

So I'm, I'm imagining, you know, maybe you're your parents of young children and, um, you, you tell them the rule is you have to, you have to be in bed by eight o'clock each night. And, uh, I don't know, it was eight o'clock the right time. Let's say it's a seven-year-old and eight o'clock is your, your bedtime. Um, and of course the, your seven-year-old doesn't want to go to bed at eight o'clock. Right? So, uh, he or she makes up reasons every night. Why it's not a good idea to go to bed at eight o'clock. Why, why, uh, why he, or she has to stay up later? And of course you say, no, no, that's, that's not okay. You go to bed at eight o'clock. Uh, and of course, uh, uh, I'm imagining that seven year olds these days, they then go online to Wikipedia and do a little research and come back at you as like, 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.

00:07:16

Uh, and, and you say to bad kid, eight o'clock, eight o'clock is what it is, right. Uh, now, um, when the kid asks you a Y, uh, which I'm sure they do your answer has to be because I said so, right. Whether you, you know, you might know that that's not really the right answer, but at some point that's what it comes down to. Am I right? I hope I'm right about all of this. Um, so the thing is, this is a perfect example of bureaucracy and teaching children, how to be rock bureaucrats. Um, it's a fixed rule that they have to follow, and it's a fixed set of authorities. I'm the mommy or the daddy. And I'm telling you that this is the rule, right? That's exactly the characteristics of bureaucracy and children learn those pretty well because, um, I don't know if you've noticed.

00:08:12

So 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. Then they spend they're actually playing the game. Right. Um, my point is we learn bureaucracy kind of from an early age and, uh, we're pretty good at it. So, um, I don't mean to ask you to change your parenting techniques in, despite my expertise in this field, um, really it raises the question of is bureaucracy good or bad. And, um, some of you might be surprised that I would even raise that question. Obviously, bureaucracy is bad, we know it. Um, but it turns out there, 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.

00:09:14

So exceptions are not made because you're a specially rich or you're an aristocrat or whatever. Um, no San Francisco, right? The rule, the rule is kind of fair. It is what it is. Um, second thing is, um, the rules and bureaucracy, uh, provide some predictability. You might say. So if you are going to, let's say, apply for a, I dunno, a permit for something from the government, you know, that if you fill out the application, right, and you meet the requirements, you're going to get the permit. Um, or at least you're, you're reasonably confident. You're confident because that's the way it works, right? 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, uh, we're subject to all of these compliance regimes, right? Uh, in the government, it was FISMA, maybe it's HIPAA or Sarbanes-Oxley, or I don't know any of these many, many compliance regimes, and you have to get a good audit every year.

00:10:26

It's very hard to do those things, unless you have a set of rules that, you know, everybody in the organization is going to follow and therefore it's auditable. So your accuracy is a tool perhaps that can help you be compliant. Um, and then one more, one more thing I'll mention, cause this is, this is one of those things you never think of in connection with bureaucracy, but, um, imagine a, a brand, a very valuable brand, let's say, you know, Coca-Cola or McDonald's or something like that. These are brands that are worth many billions of dollars. The only way you can, uh, maintain a brand really 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, um, to make it clear that they're, they're part of the McDonald's brand. Uh, you can imagine, let's say a Coca-Cola the way the logo is used.

00:11:23

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. So bureaucracy can help in, um, building a brand or anything else where consistency is an absolute requirement. So, all right. That's you fun? Unwind 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 know, you're trying to make a transformation. You're trying to change things and bureaucracy gets in your way. It really sucks. Um, why, why, why is bureaucracy so bad? And, uh, when you really think about it, uh, or at least when I really thought about it, uh, it came down to three things for me. I think, uh, the first problem with bureaucracy as we typically experience it, is that it's often coercive.

00:12:22

The basic idea of bureaucracy is to force people, to do things a certain way. It often involves people in all authority who are happily exercising their authority over you. It involves these gatekeeping trolls of administrators who kind of show up now and then, you know, pop out of the shadows and say, no, you can't do that. Uh, until you fill out a bunch of forms for them or whatever, right? So, um, your aunt Chrissy has a sort of coercive side to it often, uh, and that makes it unpleasant. Right? Uh, second thing about your opportunity as it's typically a practice is that it tends to petrify, right? 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, you're looking for change.

00:13:19

Um, the third thing that we often see with bureaucracy is maybe what it's most famous for that loop, uh, 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, uh, to me, those are the frustrating things about bureaucracy. First of all, it involves somebody exercising or authority over you from somewhere else in an organization. Um, it's coercive. Secondly, it petrifies, it doesn't change when it should. And thirdly, it involves lots of waste and frustrating, extra red tape that you don't really want to go through. All right. So are those three characteristics necessarily part of bureaucracy or is it possible that you can, uh, change bureaucracy such that it doesn't have those characteristics?

00:14:28

And to me, the answer is very much yes. In fact, it's what we tried to do when I was at USC. I S and I think tried pretty successfully in many cases. And it turns out that DevOps actually is, is the model that we learned from, in order to be able to do it. Um, so let's just agree right now that dev ops is a kind of bureaucracy. Uh, for example, you have ops has lots of rules and, uh, in some cases, those rules are automated, but there are still rules they're still enforced on you. So 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, huh, oh, no, you didn't follow the rules. You're not applying that. Right. Um, that's good bureaucracy, right? That's, that's kind of classic in dev ops.

00:15:23

We don't have that. We have automated security tests instead. So those automated security tests, um, they're giving the same thing as, as the people bureaucracy, or they're doing it in a different way, but they're still, uh, enforcing rules that constrain what you can do. So I think from that perspective, dev ops is very much a bureaucratic oriented way of doing things. I think from the cultural perspective to, for example, do you know any dev ops teams that are deliberately doing blameful rep retrospectives blameful retrospectives? No, of course not. We all know that you do blameless retrospectives in dev ops. We also know, for example, 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 dev ops and, uh, they're enforced pretty, you know, pretty seriously the way that a lot of bureaucratic rules are.

00:16:30

Um, so I think, uh, in a way I know, I know I'm pushing things a little bit, but in a way, dev ops 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 dev ops context, I think you'll see what I mean. So, uh, the first thing I mentioned before, it was the coercive nature of bureaucracy. Um, it turns out a lot of sociologists have pointed this out that a bureaucracy does not need to be coercive. It can be enabling. That would be the opposite. Uh, enabling bureaucracy is bureaucracy that has, um, standard procedures and rules that are followed, but in a way that helps you do your work. For example, it automates a way, um, or I shouldn't say automates it, it, um, uh, standardizes how you do boring, repetitive tasks, and I make efficient way, for example, right?

00:17:35

Um, maybe, uh, it, it, uh, it's what we call in dev ops. The, the thing we call them, dev ops toil, repetitive work that doesn't add a lot of value. Well, uh, bureaucracy standard procedures can help automate that toil so that you don't have to think about it as much. Or I keep saying automate, I don't really mean automate. Um, in dev ops, we do it through automation, but, uh, 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, uh, the employees have the ability to influence what those rules are going to be. A classic example of this was the Numi joint venture factory between GM and Toyota, where, um, it was an extreme bureaucracy in many ways. It had a lot of formal process standardization and had a lot of layers of management, but employees were encouraged to suggest process improvements in the spirit of continuous improvement.

00:18:44

And they did, they did it a lot. And once they did, once their process improvement was tested, it became part of the bureaucracy. Essentially it became a rule that everybody else had to follow. So in order to stop the bureaucracy from being coercive, we need to make it enabling in dev ops. The example I gave before of security, 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 is a, 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, you know, no sayings hanging before now, it becomes a tool for the people who are doing the work.

00:19:40

And in that sense becomes a piece of enabling rather than coercive. You're obviously all right on to the second one and bureaucracies petrify, well, a number of sociologists have suggested actually that this Petrofac location doesn't need to happen, uh, 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 con for it to be bureaucracy. Well, the rules have to be enforced re uh, on everybody, but still the rules can be changed. Periodically changed based on input from the workers. For example, as in that new may example, um, there's no reason why it can't work that way, right? And, uh, if possible, to set up a feedback loop where rules get improved constantly, and that's in a sense, again, that's what we do in the dev ops world through continuous improvement, for example, and in dev ops, that's one reason why we check everything in diversion control so that it can be changed later on, right?

00:21:10

And we can, we can keep control over the changes. So your opera say, doesn't need to be petrified. It can be learning as well onto the third one, the red tape. So your ocracy often is bloated in the sense that it's not lean. It involves a lot of extra work paperwork, you know, filled out in triplicate and extra. I don't know, sign-offs we have one process in a U S C I S, where it was called the balanced workforce assessment after you prepared it and 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, uh, like any other value stream can be made lean by removing waste.

00:22:18

You can look at the steps in the value stream and say, how can we streamline this, this step? How can we remove this step? How can we, uh, have, you know, only six approvals instead of seven approvals? How can we have only one approval instead of six approvals? Um, each step, it can be optimized. You can work towards what you might call minimum viable bureaucracy or minimum viable compliance. You can, uh, you can use all of the principles of lean, lean, manufacturing, lean production systems to, uh, remove waste out of the process. And you, what you wind up with is still bureaucracy, right? It's still formal processes that have to be followed, but they can be much leaner processes. So, uh, what I'm getting at is the painful parts of your ocracy. The, the things that really drive us crazy are these three things. Coerciveness, uh, Petrofac location 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 dev ops.

00:23:37

So we can take our bureaucracy, automate it and make it enabling for the people who are using it. We can, um, 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, so we can do continuous improvement. We can, um, uh, use version control of rules as a way to, let's say, a B test. You know, let's try this set of rules versus this one and see which one works better. Um, we can remove bloat the third thing, um, for example, by automating automating parts of our process, which we do a lot in dev ops, we can have the automated process produce some of the artifacts that otherwise we would have to produce manually. So, uh, in a funny way, it seems to me that dev ops implements a lot of the ideas of classic bureaucracy, but does it in a way that's not painful.

00:24:40

And what we found at USC, I S is that a lot of the bureaucratic impediments that we were faced with could be treated in similar ways. We could make, make them those bureaucratic impediments instead of being impediments, we could make them enabling, we could make them lean and we could make them learning in the sense of being adjustable over time. So, uh, that's my train of thought. And in the book, I, uh, present the different ways that you can, um, cope with the bureaucracy that you face through. It maybe is a less delicate way of saying it, uh, by forcing it to become those three things, enabling learning and lean, and, uh, the techniques we're doing. So obviously, um, are the techniques of the monkey, the razor and the Sumo wrestler. And, uh, in the book, I, I explain what I mean by each of those and why those are the right ways to think about defeating bureaucracy and, uh, 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.

00:26:05

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. Thank you.