Preview Mode Links will not work in preview mode

Agile Innovation Leaders

  1. All Episodes
  2. (S2)E017: Mark Schwartz on The Delicate Art of Bureaucracy and Defining Business Value

(S2)E017: Mark Schwartz on The Delicate Art of Bureaucracy and Defining Business Value

Feb 20, 2022

Guest Bio: Mark Schwartz joined AWS as an Enterprise Strategist and Evangelist in July 2017. In this role, Mark works with enterprise technology executives to share experiences and strategies for how the cloud can help them increase speed and agility while devoting more of their resources to their customers.

Mark has extensive experience as an IT leader in the government, private sector, and the nonprofit world, and with organizations ranging from startup to large.

Prior to joining AWS, he was CIO of US Citizenship and Immigration Services (in the Department of Homeland Security), where he led a large digital transformation effort, moving the agency to the cloud, introducing and refining DevOps and Agile techniques, and adopting user-centric design approaches.

From his work at USCIS, he developed a reputation for leading transformation in organizations that are resistant to change, obsessed with security, subject to considerable regulation and oversight, and deeply bureaucratic. Before USCIS, Mark was CIO of Intrax Cultural Exchange, a leader in global youth exchange programs, and CEO of a software company.

Mark is the author of The Art of Business Value , A Seat at the Table: IT Leadership in the Age of Agility, War, Peace and IT and The Delicate Art of Bureaucracy.

Mark speaks at conferences internationally on such subjects as DevOps, Leading Change, Driving Innovation in IT, and Managing Agility in Bureaucratic Organizations.

He has been recognized as a Computerworld Premier IT Leader and received awards for Leadership in Technology Innovation, the Federal 100 IT Leaders, and a CIO Magazine 100 award. Mark has both a BS and MA degree from Yale University, and an MBA from Wharton.

 

Social Media/ Website:

Books/ Resources:

 

Interview Transcript

Ula Ojiaku: 

Mark, thank you so much for making the time for this conversation.

Mark Schwartz:

Thank you, my pleasure.

Ula Ojiaku:

Great. Now let's start with you know, the question I usually ask my guests: who’s Mark? What makes him tick?

Mark Schwartz: 

And they can answer that question. It’s not a hard one. where to start? Um, you know, I always enjoy my work. That's a thing about me. I like to think that people have fun working with me because I tend to laugh a lot. And even you know, when the work is boring, I find ways to make it interesting. I just enjoy doing things and accomplishing things.

I think if we're going to talk about my books, and some of the things I've done later, an important thing to realize is that, I started out, you know, when I went, when I was in high school, when I went to college, I was pretty sure I wanted to study computer science and get involved with these computer things. But when I was actually studying, I realized there were all these other interesting areas, I'm just, you know, endlessly curious. And so, I wound up studying all kinds of other things, in addition.

And the result was that when I finished college, I decided to go to graduate school in philosophy. And I spent a few years getting a master's degree in philosophy. And the fact that I'm curious about so many things and read so many different things, I think it enters into a lot of what I do. I like to pull analogies from non-IT related fields and, and, and I'll call upon all the things I've learned in all sorts of different areas, as I'm writing and speaking and working.

Ula Ojiaku: 

It shines through in your book, definitely.

Mark Schwartz: 

Yes, I think it does. That's partly an explanation for what you see in my books. I think, um, you know, I sometimes say that I have trouble reading business books generally. Because I kind of find them boring. They tend to make the same point over and over again, and to be very just so one directional, you know, just on the same subject, and it's a little bit odd because in every other subject, the books tend to refer to other books in other fields and there's this extra dimension and that helps you understand what the author is getting at.

But in business books, they, you know, aside from having a quote now and then from a famous leader or something, they don't tend to do that, they don't, they don't sort of call upon the whole history of literature and writing.

And so, I have a little bit of fun in writing my books in trying to see if I can add an extra dimension just by reference and by bringing in other things that are a little bit orthogonal to the subject matter.

Ula Ojiaku: 

And that kind of, you know, brings home the point that life isn't black and white. It’s actually a complex or a complex kind of, you know, maze and of different disciplines, different ideologies and different viewpoints that make it what it is really.

Mark Schwartz: 

Yeah well, of course, that was part of the fun of my recent book on Bureaucracy. You know, because I know we all, we want to throw up when we encounter bureaucracy, you know, it disturbs us in so many ways.

And one of the things I wanted to say in the book is, well, actually bureaucracy is all around you all the time in unexpected places and it usually doesn't drive you crazy, actually. Yeah...

Ula Ojiaku: 

Well, I have a lot of questions for you on your book, The Delicate Art of Bureaucracy, which is a catchy, catchy title on its own, very clever.

But before we get to that, what do you do when you're not working? I know, you said you love work and you've also said that you're curious about so many things, which means that you read broadly - that's my interpretation. So, what do you do when you're not ‘working’?

Mark Schwartz: 

Yes, I read broadly, is one thing. In the past, I played the guitar a lot. And I don't quite as much lately. I don't know why, you know, I'll start doing it again. I'm sure at some point. But while I was living in San Francisco, I was actually playing in bars and coffee shops, I have a singer, who I performed with.

Ula Ojiaku:

Really? Wow!

Mark Schwartz:

And that was really fun.

And then the other thing I do is travel, I've really traveled a lot. And, yeah, there was one period in my life where for about five years, I was bumming around the world with a backpack with you know, occasional returns to the States to work a little bit and make some money and then go traveling again.

So, one of the joys of my current job is that, I get to do a lot of traveling to interesting places.

Ula Ojiaku: 

So, where would you say is your ideal getaway destination?

Mark Schwartz: 

Oh, let's see. I'm a big fan of Brazil. That, I have good friends there and it's really nice to see them and the atmosphere is always kind of fun there.

Ula Ojiaku:

Okay.

Mark Schwartz:

I don't know what I've discovered so many places around the world that I've really loved being. I lived in Japan for a year and that is a place that I love to go to, especially for the food. Yeah, I like good food.

But I don't know I’ve found so many places that made me feel like I'd like to spend more time there. And of course, you can't really spend more time everywhere.

Ula Ojiaku:  Interesting.

So, let's, let's go to your book, “The Art of Delicate Bureaucracy”. What was the inspiration behind that book?

Mark Schwartz: 

Well, for all of my books, before I wrote, before I wrote them, I was thinking, ‘why hasn't anybody else written a book on this topic?’ People don't write books on bureaucracy, at least not, you know, popular books, there are academic books on bureaucracy.

And the same thing happened to me with my first book, “The Art of Business Value”, where I said to myself, we keep talking about business value in the IT world, like, is it obvious what it means? You know, what, why isn't anybody writing a book about what business value means?

So, bureaucracy is one of those things. I have a lot of experience with it first of all, I was a CIO in a government agency. But it turns out, it's not just the government, whenever I tell people about my government experience, when I speak at a conference, people come up to me afterwards and say, ‘Oh, my company's just like that. I work for a financial services company; we have lots of bureaucracy’.

And I work with a lot of people who are trying to pull off some sort of digital transformation, which is change on a big scale, that's changing traditional organizations on a big scale. And bureaucracy is always in their way because bureaucracy tends to resist change; it strongly tends to resist change.

So, if you're doing a big change, then you're probably going to come up against it. So, I thought maybe with my experience as a bureaucrat, or at least experience in the big bureaucracy, I could give some pointers to people who are trying to cause big change, and yet are facing bureaucratic obstacles. And I can't imagine that there's any organization, at least any large organization that does not have bureaucratic obstacles to digital transformation.

So, that got me started on it. And then as I started to think about bureaucracy and research it, I realized this is actually a really interesting topic.

Ula Ojiaku: 

You had an interesting introduction to the book. You said, “we are bureaucrats all.” Why that claim, you actually were saying, everyone is a bureaucrat, and I know you made a statement that’s similar to that earlier on in this conversation - why?

Mark Schwartz: 

Well, of course, I have to define in the book, what I mean by bureaucracy and all that.

And I follow the generally what's accepted as the academic definition. It mostly comes from the sociologist Max Vabre, who is writing around 1920. And, and he talks a lot about bureaucracy, and it's fairly complicated, but I simplify it in the book.

Basically, what it comes down to is a bureaucracy is a way of organizing socially, that has rigid formal roles for people and rigid formal rules. And that's the essence of it. You know, bureaucracy, there are rules and they have to be applied uniformly to everybody. And there's a division of labor and you know, a hierarchy. So, it has rigid roles of people who have to sign off on things and approve things.

So, with that is the definition. I think it, it connects with the very human tendency to try to structure things and constantly improve them and optimize them. So, if you find a good way of doing something, you tend to turn it into a rule, you know, this is the way it should be done from now on.

Ula Ojiaku:

Best practice!

Mark Schwartz:

It’s the best practice. Yeah, yeah, exactly. And also, we, in, social organization, we'd like people to be accountable or responsible for things. And we know that you can't hold somebody accountable unless they have authority to perform their role.

So, when you put those things together, it's very natural for us to set up these organizational systems, where we assign roles to people, and give them authority, and we make rules that encapsulate the best way to do things. And, essentially, that's bureaucracy.

So, bureaucracy, I find, is everywhere around us in one form or another. But it doesn't drive us crazy most of the time, so we don't notice it.

Ula Ojiaku: 

Maybe if it's serving us, then we wouldn't notice it. But…

Mark Schwartz: 

It does serve. And if you look at the cases where it does drive us crazy, they have certain things in common. And in the book, I say there are three characteristics that bureaucracies often take on which they don't need to, it's not part of the definition of bureaucracy, but they often take on these characteristics. And it's those three characteristics that are what drive us crazy. And so, the goal, ultimately is to eliminate those three characteristics or turn them into something else.

Ula Ojiaku:

I know that the listeners would be curious to know what the three characteristics of bureaucracy that drive us crazy are? Is that so or should I just tell them go buy the book?

Mark Schwartz:

Yeah, go buy the book! Well, let me tell you the three characteristics, and also their opposite, which is what we really want.

So, the first characteristic that drives us crazy, I think, is that bureaucracies tend to be bloated instead of lean, that would be the opposite in my view. There's no reason why a bureaucracy has to be bloated and wasteful. It could be lean, but it's one of those things that bureaucracy tends to become. So that's the first one.

The second one is that bureaucracies tend to petrify, as opposed to learning. So, when I say petrifies, I mean that the rules and the bureaucracy don't change, or don't change as often as they should, or don't change continuously, which is really what rules should do.

Now, that's not necessarily a characteristic of bureaucracy, but the definition, the definition says the rules have to be applied rigorously. You know, once you have a rule, everybody has to follow it. But it doesn't say that the rules have to stay the same forever, they can change.

The opposite of a petrified bureaucracy is a learning bureaucracy, where the rules are constantly adjusted, based on what the people in the organization learn. And there are plenty of good examples of learning bureaucracies out there. And your goal is to transform the one into the other, the petrified into the learning.

The third is, bureaucracies tend to be coercive, rather than enabling. Coercive, meaning that they're there to control employee behavior, to force employees to behave in ways that otherwise they wouldn't want to. They tend to be ‘no’ saying, they say ‘no’, a lot. Your bureaucracy for your expense reporting policy in your company probably says, ‘no that expense is no good because X Y and Z.’ There are plenty of examples of enabling bureaucracies, where the point is not to stop you from doing things or force you to do something you don't want to. But the bureaucracy provides a support structure, provide best practices, as you said, that help you do your job well. And there's no reason why bureaucracies can't do that. So, the three bad characteristics are bloat, coercion, and petrify.

Ula Ojiaku:

Okay, nice. So, it sounds like the way you've described bureaucracy, when you look at it from a positive slant, would it be the same thing as guardrails, putting guardrails in place, or giving people the right degree of freedom?

Mark Schwartz:

Yeah, that's exactly the idea. What I find is that guardrails and automation are ways of implementing bureaucracy, that lead to those three good characteristics rather than the bad ones.

Let's say in software development, in DevOps, for example, it's a good idea to put guardrails, security guardrails, for example, around what people can do, and automated security tests and things like that. Because then the developers or the DevOps teams, they can go charging ahead full speed, knowing that they can't do anything wrong, you know, because the guardrails are there. And they get immediate feedback, if they do something that's going to put them outside the guardrails and they can just immediately fix it.

So, it's very empowering for them, lets them move fast. And it also gets rid of that coercive element of you know, I write some code and then somebody comes in afterwards and says, ‘no, you can't deploy that’. That's annoying.

Instead, I can run the security tests myself, as a developer, see if there's anything that's problematic, fix it right away if I want to, so it's all under my control. But the end result is still the same. The bureaucracy is still there. It's just automated and implemented as guardrails.

Ula Ojiaku: 

It's enabling, like you said before, instead of hindering.

Mark Schwartz: 

And it's lean, because it's very inefficient and wasteful, if you write some code, and then at the very end of the development process, somebody finds a security flaw. And now you have to remember what you were doing.

And, you know, go back and relearn your code and make changes then, so that's wasteful, as opposed to lean. It's coercive, as opposed to enabling. And if you're good at doing these things, then you keep updating your guardrails and your security tests based on new security threats you learn about or new policies or whatever. So, you make a learning bureaucracy as well.

Ula Ojiaku: 

Interesting. In the book as well, you said you want us to be calm, chaos monkeys, knights of Ockham, lean sumo wrestlers, very interesting oxymoron there. And you know, black belt experts, could you tell us more about those terms? Why did you use those terms?

Mark Schwartz: 

Because they made me laugh of course.

Ula Ojiaku:

Well, they made me laugh too.

Mark Schwartz:

So, I thought about what I learned about coping with bureaucracy, especially in my government job, but also from reading and from talking to other people. And I realized I had about, you know, 30 techniques for coping with bureaucracy, I call them plays. And I just grabbed those 30 techniques, but I thought about it, and I realized they divided into three. And the three, I could sort of associate with a personality, almost. You know, that these 10 plays are associated with this personality, these 10 plays are associated with this one. And I came up with these three personalities that I thought describe those plays. And the three personalities are the monkey, and the razor, and the sumo wrestler.

And, you know, I think, I could stop right there, because it's probably obvious why I associate those with these plays, but I will go a little further.

Ula Ojiaku:

Please…

Mark Schwartz:

So, I realized that some of the things we did, the ones that I call the plays of the monkey, the way of the monkey, those things had to do with provoking. You know, monkeys are mischievous, provocative, and sometimes annoying. And a bunch of the techniques had to do with trying to be provocative.

And the razor and I'll give you some examples in a minute. The razor, to me is all about being lean. It's about trimming away waste. And it also refers to the philosophical principle of Ockham's razor. Ockham was a medieval philosopher, right, William of Ockham. And he's generally credited with an idea that something like if you have a choice between a simple explanation, and a complicated explanation, you should prefer the simple one. That's not really what he said. But that's, that's what most people associated with him. That's the principle of Ockham’s razor.

And, and so it's called a principle of ontological parsimony, meaning, you shouldn't presuppose the existence of more things than you need to, in order to explain something. So, you know, don't make up nymphs. And you know, I don't know, water dryads and whatever's to explain something that you can equally just explain through simple physical laws.

Ula Ojiaku: 

Just saying, 'keep it simple...'

Mark Schwartz: 

Yeah, keep it simple, in a way, right? So that's called the principle of ontological parsimony.

And I said, there's a similar principle of bureaucratic parsimony, which says that if you're trying to implement a control, and you can do it in a simple way, or you could do it in a really complicated way, do it a simple way.

And so, it's a principle of leanness because I find that bureaucracies, when they get bloated, they have these really complicated wasteful ways of doing something that they could they could accomplish exactly the same thing, but in a simpler way. So that's the razor.

And then a sumo wrestler. Well, Sumo is the sport where, you know, two massive people sort of bang into each other, right? And the goal is you want to push your opponent out of the ring, or you want to make them fall and touch the ground with something other than their feet. And if you can do either of those things, you win.

So, if you're a big massive person and you're trying to accomplish those things, you might think that the best thing to do is charge your opponent and push really hard. But if your opponent then just either dodges or just is soft and lets you push, well, you're probably going to go flying out of the ring, right?

So, one of the principles in Sumo is you want to use your opponent's strength against them. And if they push hard, now, go ahead, give them a little pull. And, you know, let them push even harder.

And I realized that some of these techniques for overcoming bureaucracy have to do with using bureaucracy actually, on your side, you know, the using the strength of bureaucracy against it. So that's why the sumo wrestler.

So, I'll give you examples now on each one, now that I've described my three personalities. So, the monkey does what is sometimes referred to as provoking and inspecting or provoking and observing, in parallel with the Agile principle of inspect and adapt.

So, provoke and observe, what the monkey does is try something that's probably outside the rules, or at least is, you know, a borderline and watches what happens.

So, an example where we use this is that we have these rules in Homeland Security that essentially said, if you were going to do an IT project, you have to produce 87 documents. And each document had a template, and you have to fill in each section of the template. And these documents would run to hundreds of pages.

And so, using the persona of the monkey, let's say, we started to turn in these documents. But in each section of the template, we just wrote a one sentence, one sentence answer, you know, we're very short answer instead of writing pages and pages. And we wanted to see what would happen if we did that, because there was no rule that said, it had to be a really long answer.

And eventually, we started to provoke even more, we just left out sections that we thought didn't make any sense for what we were doing. And all of this was unprecedented, you know, it caused a lot of fear.

It turned out, and this sometimes happens, that the enforcers of this policy, they were happy when they said, “We've never wanted anybody to write these really long answers to these things, we have to read them. And you know, the intention wasn't to slow people down. As long as you're giving us the right information. That's all we need.”

So, in this case, provoking just it turned out that we could defeat a bunch of bureaucracy there, we could, we could make things a lot leaner because nobody objected. But sometimes people do object. And if they do, then you learn exactly what the resistance is, who it is, is resisting, and that gives you valuable information, when you're trying to figure out how to overcome it. So that's the monkey. You know, let's try something a little playful and mischievous, and see what happens.

The razor, well, that one follows also on my 87 documents, because we then set up an alternative way of doing things that had only 15 documents. And where there had been 13 gate reviews required for each project. We reduced it to two.

And so, all we did, you know, we just used our little razor to trim away all the excess stuff that was in the bureaucratic requirements. And then we showed people that those 15 documents and those two gate reviews accomplished exactly the same thing as the 87 documents and the 13 gate reviews. That's the principle of the razor, that's how the razor works.

The sumo wrestler, also a favorite of mine. So, we were trying to convince the bureaucracy to let us do DevOps and to be agile, and it was resisting. And people kept pointing to a policy that said, you can't do these things. And so, we wrote our own policy. And it was a very good bureaucratic policy looked exactly like every bureaucratic document out there. But it essentially said you must use DevOps and you must be agile on it, you know, it set up a perfect bureaucracy around that it's set up ways of checking to make sure everybody was using DevOps.

And the theory behind it was the auditors when they came to audit us and said we were being naughty because we were doing DevOps. Their argument was we looked at the policy and we looked at what you're doing, and they were different. And that's the way auditing works. That was the, you know, GAO, the Government Accountability Office, and the Inspector General and all that.

So, we figured if we had a policy that said you must do DevOps, and they audited us, well, they would actually be enforcing the policy, you know, they'd be criticizing any part of the organization that was not using DevOps and I thought that's great.

So, this is how you use the strength of the bureaucracy against the bureaucracy or not really, against even, you know, it's perfectly good, perfect…

Ula Ojiaku: 

To help the bureaucracy yeah, to help them to improve, improve the organization. But thinking about the monkey though, being provocative and mischievous, do you think that there has to be an element of you know, relationship and trust in place first, before… you can’t just you know… you're new, and you've just gotten through the door and you start being a monkey… you probably will be taken back to wherever you came from! What do you think?

Mark Schwartz: 

Well, it helps if you're giggling while you do it. But you know, I think the goal here is to figure out the right levers that are going to move things. And sometimes you do have to push a little bit hard, you know, you do need to take people out of their comfort zone.

Usually, you want to do these things in a way that takes into account people's feelings, and you know, is likely to move them in the right direction, rather than making them dig in their heels. But I'll give you a couple of examples of Monkey tactics that are less comfortable for people.

One is simply, you know, there's a status quo bias. It’s a known, well-known cognitive bias; people tend to prefer the status quo or look the other way about it’s failings and stuff. So often, when you're trying to make a change, people say, we're fine the way we are, you know, everything's okay.

So, one of the things the monkey tries to do is, is to make it clear that the status quo is not acceptable, you know, to show people that it actually if they think about it, it's no good. And so, for example, when we decided to move to the cloud, instead of working in our DHS data center, people said - of course at the time it was a big concern, ‘was the cloud secure enough?’ And in the persona of the monkey, the right response is, ‘are we secure enough now?’ You know, ‘don't you realize that we're not happy with our security posture today?’ ‘It's not like, the cloud has proved itself. I mean, we have to compare our security in the cloud versus our security in the data center. And yes, I'm very sure it'll be better in the cloud and here's why…’

But you can't start from the assumption that you are fine right now. In general, when we're talking about the cloud, that's the situation. Companies are using their own data centers. And it's like, you know, we have to teach them that they can do better in the cloud.

But the truth is that they're not happy in their own data centers, if they think about it, right? There are security issues, there are performance issues, there are cost issues. And they're aware of those issues, right, they just look the other way. And because they're comfortable with the status quo, so the monkey has to sort of shake people up and say, ‘It's not okay, what you're doing now!’

Another example, and this is really harsh, and I wouldn't use it in most cases. But let's say that this was in Homeland Security. Let's say that Homeland Security is enforcing a very bureaucratic process that results in IT projects, taking five years instead of six months. And let's say, you know, the process is there on paper, the rules say, ‘Do this’, the people are interpreting the rules in a way that makes things take five years. Sometimes, the monkey has to go to somebody who's in their way and say, ‘We are in the Department of Homeland Security, this IT project is going to make people more secure in the homeland. Are you comfortable with the fact that you are preventing people from being more secure for the next four and a half years, when we could…’ You know, it's a matter of personalizing it. And that sometimes is what's necessary to get people to start thinking creatively about how they can change the bureaucracy.

You know, ‘I hate to say it, but you're a murderer’, you know, essentially is the message. It's a monkey message. And like I said, you know, it's not the preferred way to go about doing things. But if you have to, I mean, the lives of people are at stake, and you've got to find a way to get there.

Ula Ojiaku: 

So how can leaders because your book, The Art of Business Value, in your book, you said that “leaders create the language of the organization, and they set up incentives and define value in a way that elicits desired outcomes.” So, in essence, I understand that statement to mean that leaders set the tone, and you know, kind of create the environment for things to happen.

So, how can leaders implement or apply bureaucracy in a way that enables an organization where, before it was seen as a hindrance, how can they do this?

Mark Schwartz: 

My thought process was, if we all agree, we're gonna try to maximize business value? How do we know what we mean by it?

And I realized, a lot of Agile people, you know, people in our Agile and DevOps community, were being a little bit lazy. You know, they were thinking, ‘Oh, business value, you know, it's returns on investment, or, you know, it's up to the business (to define) what's business value.’ The tech people just, you know, do the work of providing a solution. And to me, that's too lazy. If you're going to be agile, be it you have to be more proactive about making sure you're delivering business value. So, you have to understand what it means. You have to actually do the work of, you know, figuring out what it means. And what it means is not at all obvious. And, you know, you might think it has something to do with return on investment or shareholder value or something like that.

But when you really closely examine it, that is not the right way to define it, when it comes to deciding what its efforts to prioritize and all that that's, you know, the case that the book makes, and I explain why that's true.

Instead, I say you have to think of business value within the context of the business's strategy and its objectives as a business. There's no like, abstract, this has more business value than this because we calculated an ROI or something like that, that doesn't work reprioritizing. It's always asked within the context of a particular business strategy. And the business strategy is a direction from leadership. There might be input from everybody else, but ultimately, you have leaders in the organization who are deciding what the strategic objectives are.

So, for example, if you are a traditional bank, or traditional financial services company, and you look around you and you see there are all these new FinTech companies that are disrupting the industry, and you're worried, well there are a lot of different ways you can respond to those disruptive FinTechs. And how you're going to choose to respond depends on your preferences, it depends on the situation of your company, in the industry, the history of your company, all of those things. But of the many ways you can respond to that disruption, you're going to choose one as the leader of your enterprise.

Well, what adds business value is whatever supports that direction you choose to go. You can't think of business value outside of that direction, you know. That's the case that I make.

So, leaders don't just set the tone and the culture there, they're actually setting strategic direction that determines what has business value. And then the people who are executing the agile teams have to take it upon themselves to make sure that whatever they're doing is going to add business value in that sense.  

So, the role of leadership then becomes direction setting and visioning for the future and communicating the vision to the people who are working and providing feedback, you know, on whether things are actually adding business value or not . And that's the key responsibility.

Now, in order to do that, in order to motivate people to deliver according to that idea of business value, there are certain techniques as a leader that you have to keep in mind, there are ways that you get people, you get a big organization to sort of follow you. And one of the ones that's become most important to me to think about after talking to a lot of leaders about how they're running their organizations, and what's working, is using middle management as a lever for accomplishing those things.

So often, I'll talk to leaders of a business, and they'll say, our problem is the frozen middle, middle management is, you know, they're just not changing the way we want, we want to, we want to cause a big transformation, but middle management is getting in the way. And I tell them, ‘that's pretty much a myth.’ You know, ‘that's not actually what's happening, let's look more closely at your organization.’

Almost always, middle management is still trying to do the best they can, given the situation that they're in. And the way that you get them to align themselves behind the change is, you change their incentives or their role definition, or how you tell them what you're expecting from them, you don't say “change”, you know, and start doing X and Y, you change what success looks like for their position. And then they adapt to it by becoming engaged and finding ways to get there.

So, there's almost always a leadership problem when you have that frozen middle effect. And, and I've seen it work really well that, you know, all of a sudden, you get this big leverage, because you just do a little bit of tweaking of role definitions, and bring everybody into solving the problem.

And actually, there's an example, I love to talk about a history book, like I said before, I like to bring in other things, right? It's called the Engineers of Victory. And it's about World War Two, the Allies realized that they had to solve a set of problems, I think there was six or so problems.

One of them was how do you land troops on a beach that's heavily defended? They realize they were just not going to be able to win the war until they could do that. But nobody knew how to do it. Because, you know, obviously, the bad guys are there on the beach, they're dug in, they put barbed wire everywhere, and mines, and you know, all this stuff. And it's just going to be a slaughter if you try to land on the beach.

So, this book, Engineers of Victory, makes the case that what really won the war, was figuring out those solutions. And who was responsible for figuring out those solutions? It was middle management, basically. It was the, you know, within the structure of the army, it was the people not at the top who had big authority, you know, the generals, and it was not the troops themselves, because they weren't in a position to figure out these things. It was middle management that could see across different parts of the organization that could try things and see whether they worked or not, that, you know, essentially could run their own mini skunkworks projects. And eventually, they came up with the solutions to these problems.

So, I think that's very encouraging for the role of middle management, you know, that a lot of problems have to be solved at that layer in order to pull off a transformation. And it really can be done. And this is a beautiful example of it.

Ula Ojiaku: 

It reminds me of, you know, my experience in a few transformation initiatives. So, the middle, the people who are termed to be in the frozen middle, are, like you said, they want to do what's best for the company, and they show up wanting to do their best work, but it's really about finding out, ‘Where do I fit in, (with) all this change that's happening?’ You know, ‘if my role is going away, if the teams are going to be more empowered, that means I'm not telling them what to do, but then what do I do now?’

So, the clarity of what the ‘New World’ means for them, and what's in it for them, would help, you know, make them more effective.

Mark Schwartz:

And the mistake that's often made is to say to them, ‘start doing DevOps’ or, you know, ‘start doing agile or something.’

Because if you don't change the definition of success, or you don't change the incentives that, you know, then it's just, make work and they're going to resist it. You know, if you say your incentive is to get really fast feedback or you know, one of the other goals of DevOps, because of the following reasons, it helps the business this way, so let's try to reduce cycle time as much as possible for producing software.

Okay, that's a change in the incentive, or the, you know, the definition of success, rather than just telling somebody you have to do DevOps, you know, read a book and figure it out.

Ula Ojiaku: 

So, what other books because you mentioned the Engineers of Victory, are there any other books you would recommend for the listener to go check out if they wanted to learn more about what we've talked about today?

Mark Schwartz: 

Well, I think, you know, obviously, my books referred to War and Peace by Tolstoy, Moby Dick, another great one. You know, you probably need to read my books to figure out why those are the right books to read and Engineers of Victory. As I said, I think that one's a great one.

Within the field, there are some DevOps books that that I like a lot, of course, Gene Kim's books, The Phoenix Project, and now The Unicorn Project, the sequel to that. Because those are books that give you a feel for the motivation behind all the things that we do. The Mechanics of Things, there are plenty of books out there that help you learn the mechanics of how to do continuous integration and continuous delivery.

And then the cloud is I think it's really transformative. You know, it's the cloud itself is a tremendous enabler. I work at AWS, of course but I'm not saying this because I work at AWS, it's more than I work at AWS because I believe these things. And my teammates have written some good books on the cloud. Reaching Cloud Velocity, for example, by Jonathan Allen and Thomas Blood is a great one for reading up on how the cloud can be transformative. But my other teammates, Gregor Hope, has written a number of books that are really good, Stephen Orban did A Head in the Cloud.

So, I think those are all… should be at the top of people's reading lists. And then, of course, I recommend my books, because they make me laugh, and they might make you laugh, too.

Ula Ojiaku: 

Definitely made me laugh, but they've also given me things to think about from a new perspective. So, I totally agree. And so, where can people find you if they want to reach out to you?

Mark Schwartz: 

Yeah, LinkedIn is a great place to find me. If you're with a company that is an AWS customer, feel free to talk to your account manager, the sales team from AWS and ask them to put you in touch with me, is another easy way. LinkedIn is kind of where I organize my world from so find me there.

Ula Ojiaku: 

Okay. Sounds great. And any final words for the audience or for the listeners.

Mark Schwartz: 

Um, I, I have found that these things that you want to do to take advantage of the digital world, and I think we're all sort of pointing ourselves in that direction, there are these amazing things you can do in the digital world. They're sometimes challenging to get there, but it's very possible to get there.

And one thing I've learned a lot at Amazon is the idea of working backwards, you know, you get that picture in your head for where you want to be and then you say to yourself, ‘I can get there. Let me work backwards and figure out what I have to do in order to get there.’ And you might be wrong, you know, you should test hypotheses, you start moving in the right direction, and of course, correct as you need to.

But you can do it with confidence that others are doing it and you can too no matter what your organization is, no matter how much you think you're a snowflake and you know different from every other organization. You can still do it. And with just some good intention and good thinking you can figure out how to how to get there.

Ula Ojiaku: 

Thank you so much, Mark. That was a great close for this conversation and again, I really appreciate your making the time for this interview. Thank you.

Mark Schwartz:

Thanks for having me.

Ula Ojiaku:

You’re welcome.