Mark Schwartz Author of "The (Delicate) Art of Bureaucracy" As an Enterprise Strategist for Amazon Web Services, Mark Schwartz uses his extensive CIO wisdom to advise the world’s largest companies on the obvious: time to move to the cloud, guys. As the CIO of US Citizenship and Immigration Services, he provoked the federal government into adopting Agile and DevOps practices. Mark speaks frequently on innovation, change leadership, bureaucratic implications of DevOps, and using Agile practices 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 just confused and much poorer. Mark is the author of the upcoming "The (Delicate) Art of Bureaucracy", "The Art of Business Value", "A Seat at the Table", and "War and Peace and IT" and the winner of a Computerworld Premier 100 award, an Amazon Elite 100 award, a Federal Computer Week Fed 100 award, and a CIO Magazine CIO 100 award. He lives in Boston, Massachusetts. Shaaron A. Alvares works as an Agile and DevOps Transformation Coach at T-Mobile. She has a global work experience leading product, organizational agility and cultural transformation across technology, aerospace, automotive, finance and telecom industries within various global Fortune 500 companies in Europe and the US. She introduced lean product and software development practices and has led significant lean and DevOps practices adoption at Amazon.com, Expedia, Microsoft and T-Mobile. Speaker, trainer and writer, she is a news reporter and editor at InfoQ for Agile, Culture and DevOps, and Ambassador at the DevOps Institute. Shaaron published her M.Phil. and Ph.D. theses with the French National Center for Scientific Research (CNRS).
Shaaron A Alvares
Sr. Agile DevOps Transformation Coach, T-Mobile
Author, The (Delicate) Art of Bureaucracy
Uh, my name is Sharon Alvarez. I work as an agile and DevOps transformation coach and I presented last year. And this year at the dev op center price 78. And as you may know, we are approaching from the dev ops center by semi, uh, uh, in October on October 10 to 13 to 15. And, uh, so we will host a weekly session of roughly 30 minutes with experts as speakers and authors to discuss their talk and their experience leading DevOps and agile transformations in their organizations. So today I have Mark Schwartz. Um, I don't think we need to introduce mark. Um, but for those who haven't read his book, mark was CIU at the U S CIS for seven years, from 2000 to 2000, 2010 to 2017. And then there is influence, uh, the immigration services that became a model for the us government, for DevOps cloud architecture, microservices, and at GDT.
And since 2017 market works as an enterprise as strategies that Amazon, AWS, your advisees CEOs of the largest global organizations on how to address a scaling organizational and technology challenge. So mark published several books and must read the books. One of them was one of the latest that came out is a Warren piece in it. And in fact, I have it in my back and he's publishing a new book that's coming out on October 10th. Um, the day he came out of bureaucracies and he will also be speaking at the DevOps enterprise semi conference coming up in October. And so you, if you want to hear Marcus speak, you should definitely register. So thank you mark, for being here today and doing this Q and a discussion with me today. Would you like to introduce yourself at anything?
Yeah. Well, thank you for having me. This is, this is a pleasure, uh, and I think we're going to have some fun because your ocracy is really a fun topic and people don't realize that.
Yeah, it is absolutely. Um, it's, uh, I read the book and, um, uh, like I mentioned, I couldn't put it down, actually. I finished it in three days and it's an amazing book. It's very entertaining and, you know, I never thought I would enjoy actually reading a book about bureaucracy, but it's a really just fantastic it's, um, it's very insightful and it's also very pragmatic. So it's full of, uh, advice for anybody in an organization that face, uh, uh, bureaucracy. And it's also very interesting because you have people understand what broke CES, right? We talk about that. We don't always know what we mean by bureaucracy and everybody has a different definition about, so the book is divided. I want to cover the book really quickly. Before we jump into the questions. The book is divided into three main tasks. So talk to one digital transformation and grow Chrisy is dedicated to defining, clarifying and understanding the meaning of the request. And back to, uh, the Dean, a better dural Chrisy in talk to you propose a new model for a better bureaucracy. We have a lot of, uh, pragmatic T very insightful and in part three, but three is the playbook and it contains a four place to tackle. So the way of the monkey, the way of the razor and the way of the Sumo and the way of the black belt bureaucracy, if you work for an organization plagued with a .
So, um, what is bureaucracy, mark? How do you define it?
Uh, yeah. Um, well, there's a, there's sort of a standard definition of bureaucracy that comes from the German sociologist, max WebVR, who was writing at the beginning of the 20th century, uh, and what it comes down to in my way of interpreting WebVR is it's, uh, it's an organization or a way of using authoritarians that's based on rigid rules and rigid lines of authority. Um, that's kind of exactly how he says it. He, he, uh, gives a little more detail on it, but basically a bureaucracy is a system where you have a division of labor, very precisely divided. Um, you have a management hierarchy, a clear hierarchy, and you have a set of rules that are applied impartially. And the thing is because, uh, because the rules are imply applied, impartially, the bureaucracy, a typical bureaucracy can seem very impersonal and distant, and even in human, you know, the rules of the rules and you've got to follow them. Um, so those are the, those are the characteristics of a bureaucracy in at least in Weber's view. And that's the view that's usually used in any writings about sociology or management theory. And that's my starting point.
Yeah, that's really, that's really interesting. And could you tell us more about who the books or the onset is? Who's your intended audience?
Uh, well, you know, I think people who read romance novels would be interested. No, I'm only kidding. Um, I really, the audience is anybody who, um, experiences bureaucracy in their work settings. Um, which means everybody, I think. Um, but specifically I talk that I use as an example of digital transformation since that's usually who I'm writing for is people who are trying to do some sort of digital transformation. Uh, and, uh, very often they face impediments coming from bureaucracy and they need to, they need to deal with them, cope with them, get around them, whatever it is. Um, so I, I use examples drawn from that situation throughout the book, but I think the principles are pretty widely applicable to anybody who is facing a bureaucracy and needs to figure out how to deal with it or anybody who needs to act like a bureaucrat. And I, I argue that sometimes people do, uh, to tell them how to do it well, so that it doesn't drive other people crazy.
Right. Yeah. Um, yeah, I very much agree with you. Uh, I think we all in any roles we are, we all face bureaucracy and it's part of, especially when you work for really old organizations, right? 15, 20, 30 years old organizations, because they built, uh, their organization, uh, on top of they build their structure on top of each others, right? So we accumulate a lot of legacy systems, legacy, um, structure, I guess, your organization and legacy, uh, uh, channels of communications, right. And these are very difficult to, um, not remove, but address. And, uh, so it's really difficult to make, to, to drive a more leaner organization. So, and for every role, not just at the, you know, at the, on the ground or the executive level, so, um, can we delegate tackling bureaucracy and, um, how can leaders and executive leverage the book and the playbooks, uh, to, um, transform bureaucracy into, um, something valuable into a valuable capability?
Yeah. It's kind of funny that the book raises that question, right? People, people, people don't think about your ocracy as being a valuable capability. Um, but it is, and maybe we'll talk a little bit about why that is. Um, but, uh, I think they, that bureaucracy is that we encounter every day are your, your opportunities that suffer from certain problems. In other words, bureaucracy itself, isn't the problem. It's the way we've set up bureaucracies. And so typically we find that a bureaucracy, um, number one, it's wasteful or bloated, um, number two, it, it petrifies, it never changes. Right. Um, and, uh, number three, it's coercive. The, the idea of bureaucracy is to tell people what to do or force them to do the right things. Um, really those three things. Uh, let's see if I can remember them now that I've said them petrifying a wasteful and, um, coercive.
Well, those three characteristics of bureaucracy are not essential to it. And in fact, I talk about how you can make a bureaucracy, the opposite of those things. So, uh, enabling instead of coercive lean, instead of bloated and learning, instead of petrified, uh, and you can actually set up a learning cycle within a bureaucracy to constantly improve the rules, you can set up your bureaucracy so that, uh, it's not, you know, telling people no and, and, uh, criticizing them, but it's actually enabling them to do a better job. And you can, um, you can set up a bureaucracy without a lot of the waste that we typically have in bureaucracies. And I think that's the job of management to do. Uh, but the book is really about how everybody else can, who's, who's suffering from the bureaucracy, how they might take action to improve the bureaucracy as well.
Yeah. So it's very interesting. Um, you know, when we do, uh, when we develop a transformation roadmap, we have a backlog of transformation items and capabilities. We want to tackle, for example, product management. So, and we lead a continuous improvement to address all of these aspects as we want to transform. Right. And so what you said just made me think we should almost add growth arise in our transformation backlog and work on the tech and continuously improve to make it better. And it's actually a part, it should be part of a transformation, right? Because we are trying to become lean. We're not just trying to deliver, but we're trying to deliver value to our customers and faster, but to do that, we can't just address the technology and the product. We also have to address the entire organization's structure line of communication hierarchy and so on.
So, yeah. So in fact, one of the book, and you, you touched on that actually the characteristic. So you, you shared some, uh, positive characteristic of a bureaucracy and you share also some negative, uh, either impeding characteristics, or can you just touch on the three of them actually? So you just, you actually identify 10 of them. They are really fantastic. I love reading that part of the book. So I want to, uh, highlight two of them. Uh, it's, it's differs innovation and it's risky by being rescheduled. Uh, I liked those two and actually related, I think, could you elaborate on,
Uh, sure. Um, so, uh, what I say later on in the book is that, um, even though people think it stifles innovation, actually, there's some evidence that the opposite is true, but, uh, apparently it does, right? You want to try something new, but the rules are set up for the old way of doing things. I mean, that's, that's usually the characteristic of bureaucracy, is it, it encodes the way of doing things that you're doing now and turns that way of doing things into rules that you have to follow. So if you're trying to do something new and innovative, it's almost always going to conflict with, with those rules. You know, that really describe how you did things before. Um, it turns out that actually, uh, if you examine what is necessary to stimulate innovation in an organization, uh, some of those characteristics and I, I I'm quoting from, uh, management theorists, Paul Adler, um, some of those characteristics actually are characteristics that are consistent with bureaucracy. So that's why I say sometimes it doesn't really stifled innovation. Um, and then, uh, uh, what was the other one that you mentioned?
I, so it's, um, it's, it's risky by being,
Yeah. Um, so, uh, what often happens is, um, because the organization is risk averse. Every time something goes wrong, it makes up a new rule to make sure that thing doesn't go wrong again. And the result is that you wind up with a lot of rules and a lot of bureaucracy, a heavyweight bureaucracy to, uh, but the thing is in a, in a time of fast change, the digital world, these heavyweight bureaucratic rules often slow you down and moving slowly in a time of fast change is very risky. Um, so in that sense, it's risky. Also people often don't realize how much cost is being added to what they're doing because of bureaucratic requirements. Uh, and the more expensive your, your initiative is, the more risky it is. So for an example, I love to give the example from my government time of this MD 1 0 2 policy, which essentially said for releasing any it system, we had to write 87 documents and go through 13 gate reviews and so on. Um, the intention of course, is to reduce risk. You know, they want to have lots of gatekeeping and, and, you know, get everything documented. So the goal is reduced risk, but if you actually add up the cost of producing those 87 documents and going through the 13 gate reviews, it, it increases the cost of the initiative by a lot, which of course just makes it a riskier initiative. So that's what I meant when I said, you know, being risk averse in this case makes things more risky.
Yeah. Thank you very much. Um, you mentioned, um, that ProQuest is necessary in various areas. So, and I liked that it's not all bad, right? It's not a bad world and it's not all negative. And one of them, uh, the positive areas is it in organizations brands. So I want to read the code from the book. One of the most compelling uses of bureaucracy in today's economy is to support the company's branding. So how can we better our democracy to support our brand and culture?
Yeah, let me, um, let me start by telling you another reason why bureaucracy is important. Then I'll come back to branding in a second. Um, cause I, I want to make this point. So organizations increasingly have compliance springboards that they need to deal with. So for example, GDPR or HIPAA or Sarbanes-Oxley or whatever, um, those compliance frameworks require that the company have people who are accountable and signing off on certain things, it requires a processes be audit-able and followed, and that there be controls to make sure processes are followed. In other words, they require bureaucracy. Those are exactly the characteristics of your office. So I think it would be hard to actually comply with those things without having some element of bureaucracy in your organization. Now, here, when I say bureaucracy, I mean the way I defined it before, I don't mean that it has to be annoying and, you know, drive you crazy.
It just needs to have rigid rules and rigid authorities. So when it comes to branding, um, this is another area where bureaucracy is pretty much essential in my mind, um, to support a brand, you need consistency in how the brand is presented. Uh, and so for example, at, uh, to take my company, for example, Amazon, uh, we always write using a certain font for a selection of a couple of fonts and always certain colors. And we have a logo and the logo has to be presented the same way every time. And it needs to integrate with the text in certain ways, all of those things provide the consistency that lets customers associate our brand with a set of attributes that we want them to associate with it. Uh, if you think about other companies Coca-Cola and their famous logo, you know, the sort of scripted, uh, version of their name or McDonald's where they're golden arches, um, you can't have one McDonald's location that uses, uh, smaller arches or arches in a different color. You know, it wouldn't be McDonald's. So in order to keep that consistency, you have to have rules around how the Brownville expressed. And sometimes you have to have people authorized to make decisions. Like, is it okay if I use, um, this color for, for, uh, the, the company's name or something, somebody has to be authorized to make those decisions. That's your ocracy again.
And brands can be extremely valuable, you know, worth many tens of billions of dollars and they can't have that value unless you have that consistency that bureaucracy helps provide.
Right. So we've what you just said. And, uh, what you said before, it made me think that, um, you know, we talk about minimum viable processes. It's almost like we need to understand what, uh, what are, what, what could be a minimum viable bureaucracy, right. But what is it that's valuable and that we need and what can work as a safeguard and what, what is not valuable and what's can be considered as a waste. So I'll get that. I think we get back to that. I have a question on that. So the, the playbook can talk to me. You, uh, you actually offer a very pragmatic playbook and it's, uh, broken down in four plays, a very insightful, pragmatic I can mention and applicable by anyone in any organization. So the four plays are the way of the monkey, the way of the razor and the way of the Sumo restaurant. And then the fourth is very interesting. It's the way of the black belt rule, which applies to the most tenacious bureaucracies. So how do you recommend we use these clays? Can we, uh, uh, do they do, do we need to apply them based on the level of maturity or the level of bureaucracy we have in our organizations? Or can we do this five different patterns practices? How can we mix and match them?
The I, my intention in writing the book and I think everybody should use it, however, is best for them. But, um, I found that you run into different Euro cratic, impediments at different stages in what you're doing and different organizations, it's a different set of impediments. So this is meant to be a playbook or a toolkit of ideas for overcoming the specific kinds of bureaucracy you find in the specific impediments. Um, so, uh, I mean, it, that way, it's not a question of maturity, it's more a question of what, what issue are you facing and what might you try to overcome that issue? Um, the first three are ways of busting the bureaucracy or, you know, getting around it or, or fixing it. The fourth one, the, the black belt bureaucrat is really meant for a leader who has to impose bureaucracy, maybe because of those compliance frameworks or because of branding or whatever it is.
And, uh, as I said, bureaucracies can be bad or they can be good. And, uh, so that is my playbook for those leaders who are establishing a bureaucracy, how they can do so without driving everybody crazy. Uh, but the first three, um, each of those three, uh, characters let's say is broken down into about 10 plays, specific things that you might do when you're, uh, in the role of that character, let's say. So, um, the monkey is my favorite. Of course, the monkey is, you know, mischievous and a big disruptor. So, uh, the main role of the monkey is to provoke the enterprise and learn about it that way and, uh, see what can be changed or what the obstacles will be to change. So, um, the monkey sort of provokes and sees, uh, and learns and, and, uh, restrategize those based on what he learns, uh, or she learns their razor is the character that turns away the facts.
Um, it's, uh, it's the, the, a character who is looking to make the bureaucracy lean is finding different sources of waste and is getting rid of them. So there are about 10 plays, uh, that I associate with that. And then, uh, the Sumo wrestler, um, this was maybe one of my biggest learnings when I was in the bureaucracy. This Sumo wrestler uses the strength of the bureaucracy against it itself. And, uh, it's actually, uh, very possible to do we, we fought bureaucracy with bureaucracy and, uh, and improve it a lot that way, uh, which is kind of, uh, uh, what Sumo wrestlers do. If you ever watch a Sumo match and you say, you know, you've got these two big heavy guys and they crashed into each other and then like push against each other. And, um, if your opponent weekends or lets up, then you push harder and you've pushed them over. If your opponent is pushing too hard, though, you just let go. And then they, they go flying because you're not pushing anymore. So, uh, Sumo is all about using these opposing forces and taking advantage of what your opponent is doing to, um, uh, to win the match. So, um, that's, that's the three general characters, but then I break each of those into about 10 ways. You could use that character,
Right. For the way of the monkey. I really like provoke and observe, advertise the cost, the cost of delay, which is a really good one and conductor pirates. Yeah. So now really great. Um, uh, with, uh, uh, practices, you, you wrote a, I'm quoting the book. One reason why bureaucracy, besting initiatives have beaten chance of success is that they're centrally managed and centralization tend to require more bureaucracy. So, which means we, even when we try to tackle bureaucracy and we generally do it in a centralized manner, right. And that's why I was asking you, who would be the audience of this book, who, who should use the book. And, um, again, it's you, I don't think it should be only the executives. It has to be across the organization, right. Because if it's centralized, like you mentioned here, we risk it. Do we wish to add bureaucracy, additional processes, additional comment and control practices. So how can we use the place or to develop a decentralized approach to making a bureaucracy more efficient?
Yeah. I come across this a lot when, uh, in my role at AWS, when I meet with the executives of large enterprises and, uh, especially, uh, it organizations often say that they're going to get rid of waste by centralizing things, right? It's, it's quite common or a lot of the time, there's just the dynamic between a central shared services organization and independent business units or something like that. So centralization versus decentralization, and there's a pretty active issue for, for a lot of organizations. Um, but I also had in mind, the, a new CEO who comes to a company and says, I'm going to get rid of all the bureaucracy, you know, that's my priority. And they make a bunch of rules to try to get rid of your ocracy. And, uh, of course when you're making rules to get rid of bureaucracy, you're making rules and you're just changing the face of the bureaucracy.
And it also happens with governments. We, you know, we've had a number of initiatives in the United States where a new president comes in and says, they're going to make everything lean. You know, they're going to get rid of waste in the government. And then they establish policies that are supposed to get rid of waste. Um, so, uh, I see it a lot. Um, what I, what I think is, um, first of all, the problem with that is when you centralize a function and I'm not saying you never should, uh, I'm gonna come back to that in a second, but when you centralize something like, uh, I don't know, enterprise architecture standards, and you're going to do, you're going to set those centrally. And then all of the independent, uh, teams are going to have to conform to those standards. Well, that's, that's a beautiful example of your operators that you write.
The rules are, you use this enterprise architecture and, uh, the enterprise architects are the ones who make those decisions. So they have a very defined accountabilities. Um, and again, I'm not, I'm not saying it's bad. Um, what I'm saying is that if you are going to centralize, you can do it in a way that actually empowers the teams. Like I said, there there's good bureaucracy and bad bureaucracy and a good bureaucracy. Uh, it really has these three characteristics that I talked about. It's lean, it's enabling, and it's learning. And if you take this example, let's say you have a centralized enterprise architecture function. Well, how can it be lean? It can be lean by, uh, not doing gatekeeping at the end or lead in a process and saying, oh, no, you didn't follow the architectural standards. Instead. It can be involved early in the process and help guide and, and help, um, help engine, uh, help software developers, engineer their systems.
So, uh, and, and also referring back to my days in DHS, um, we had to file all these papers for our enterprise architecture, describing it and describing why it fits with the standards and all that. Well, get rid of that, right. That's how you make it lean. How do you make it enabling? Well, you set up an architecture, that's actually going to speed up the teams and doing their work and, uh, be a tool that they can use and maybe have options as well, but a tool that works really well and that, that, you know, does. And then how can you be learning? Well, you can make sure that your architectural standards change and change as often as necessary, and that there is an easy way to change them. One better ways of setting up the architecture are available. So all I'm saying is that when you centralize, you necessarily are creating bureaucracy, but you can do it in a way that can make a lot of sense, actually. Uh, you just have to decide whether it's worth centralizing and having the bureaucracy, and then you have to figure out how to make it good bureaucracy.
Yeah. Thank you very much. And, um, so we talked to Leslie about, uh, uh, internal processes and bureaucracy, but we also deal with, um, and I think you talked a little bit about that in your book about what we call customer facing bureaucracy, which impacts the customer services, customer relationship, and eventually the business. So how can organizations reduce their customer facing bureaucracy as well?
We all, we all hate it when we call a company and we get their IVR system and you get a bunch of robot people, you know, maybe it's automated or maybe it's people, but they're acting like robots and very bureaucratic, bureaucratic, right? I think in many cases that happens because they're replicating the bureaucracy inside their organization. So for example, they transfer you from one person to another, um, because their org chart separates between the two roles. So the internal bureaucracy is affecting the way they treat customers. And I think, uh, there are a lot of examples of that, um, where the internal bureaucracy sort of bleeds over into the customer experience, this, this, um, it can be improved obviously by improving the internal bureaucracy. So maybe you can empower that representative on the phone to do the functions of multiple departments. You can, you can have more autonomy and enablement, but also some studies have found that a certain amount of bureaucracy can actually lead to better customer service. And the mechanism there seems to be that bureaucracy can give the, uh, representative that you're talking to on the phone. It can give them this well established well routined solutions to problems that they can then just execute as, as written because it's a, it's a known solution. And so in a way that can have sort of a tool bag of ways of solving your problems, each of which is a bureaucratic solution, but known to be effective, and then they can choose the appropriate tools, for example. So it's a surprising conclusion.
Yeah. But it's also a really important to tackle as well, right? It's not just internet, it's also the impact of our internal group, the real crusty impact that it has on a customer facing, uh, you know, relationship communication. And so on. It's really important. It could almost incentivize organization to actually address their eternal. So as more and more, uh, you, you covered a little bit of that actually, but as more and more organizations are adopting development platform, it's really becoming, not mainstream yet, but, and coming tools and value stream management platforms. You think that this change in technology investments and adoption, that we create more common processes and standards and more bureaucracy or the opposite.
Um, I think in, in many ways more effective bureaucracy. So I often talk about DevOps as a kind of bureaucracy. And in fact, DevOps to me is an excellent bureaucracy. It has all the characteristics of good bureaucracy, and it has those characteristics because it's highly automated. The, uh, the three characteristics that I named for good bureaucracy, all of those are facilitated by automating things. So, um, while I could, I could give lots of examples of how it works, but, uh, essentially what you're doing is you're taking a rule that in the past would have been applied by a human being in a coercive way. You know, you gotta do this, you gotta do that. And instead of making an automated process that, um, that already implements those. And so there's no need for coercion. It's something that helps everybody do their jobs better. So, um, for example, to get a little bit technical for a second in the cloud, it's really important for anyone who spins up a virtual machine or an instance that they tag it with accounting categories and things like that for transparency.
So you could have a rule that says every new resource you spin up has to have a tab. And in the old way of doing bureaucracy, you might have somebody who checks to make sure every resource has a tag. And if it doesn't, then they, you know, call the person who spun up the resource and complain and whine and tell their manager or whatever. That's kind of the old way of doing your ocracy. But instead, what we can do for example, is automate the process of spinning up resources and automate policies that say, if somebody tries to spin up a resource without a tag, just don't let them do it well, that that enforces the rule. And it does it in a way that gives immediate feedback to the person. And it takes out this emotional coercive aspect to it. But you can do even better.
You can automate the process of standing up the resource in a way that just inserts the right tag automatically. And if you do that, then nobody has to worry about the bureaucracy. Nobody has to worry about whether they're compliant. In other words, they are compliant. Uh, and it is lean because they don't have to do any work it's enabling because it's doing something that they otherwise would have had to do themselves. Um, so it's, it's the, uh, it's the ideal sort of bureaucracy in my, in my way of looking at it. And, um, it comes with doing things like dev ops. So it's one of the learnings in fact of, uh, the last 10 years of dev ops.
Yeah. So, um, you know, I'm hearing, um, um, we can, we can, um, actually realize we can make a bureaucracy lean and agile, in fact, so it's, um, and we, we should, we should, uh, tackle a bureaucracy to make it more lean and agile. So in the black belt, bureaucracy, clay, you mentioned the minimum viable bureaucracy. And so how can we, uh, how do you recommend us to use the, the playbook to assess our bureaucracy, to understand what's wasteful and what's valuable.
Yeah. You said before, really part of transformation is looking at bureaucracy. Uh, you don't have to, uh, if you, if you're okay with long lead times and wasted money, but if you're, if you want to save, if you want to reduce your costs, well, one area where you probably have a lot of costs is bureaucratic waste. And if you have to cut your budget by a dollar, you take it from productive work, or should you take it from bureaucratic waste? Uh, I suggest you take it from bureaucratic waste, or at least you look carefully at your bureaucracy and see whether there are opportunities for removing waste, because if you do so, it's going to make you faster and it's going to reduce your costs. So I guarantee that in your organization, you have bureaucracy. Uh, I explained some of the reason for it before, but your bureaucracy might be good bureaucracy. You might be bad bureaucracy. It's probably somewhere in between, or maybe all the way on the bedside. And there are plenty of opportunities for improving it by making it leaner and reducing your costs,
Right? Yeah. We just need to want to attack your lead, recognize it, identify
He wants to write. That's why I wrote the book to make them, make them enjoy tackling bureaucracy,
Right. And any works. It's a very enjoyable book to read. Well, it takes you very much math. I really enjoyed this conversation with you. And I highly recommend anyone to buy the book and read it. Like I mentioned, it's a very entertaining, it's really funny. It has a lot of great practice and it's very eye opening actually, because we think we know bureaucracy. It's generally not a positive world, but you explain that, like you mentioned that it's actually sometimes media and we just need to understand how we can make it better leaner and more agile. So the book is coming out on October 10th, and you'll be speaking about data at the dev center by semi October, between October 10, October 13 and 15. So I highly encourage anyone of you to register. You can register to the Everett. It's an online event. So thank you very much, mark.
Yeah. Thanks. Buh-bye.
Unlimited users from organization
Jason Cox's SRE Playlist
Service Level Objectivity: Improving Mutual Understanding Through the Language of SRE Accepted (MediaMath and Google)
Adam Shake, MediaMath Source; David Stanke, Google