Mark Schwartz

I'm Mark Schwartz. I am an enterprise strategist with AWS, and my topic for today is, "What Does It Mean to Lead IT?"

I'm going to ask: what does it mean to be a CIO? But what I really mean by CIO is any IT leader, or even a CDO, a chief digital officer, anybody who's in sort of this general role of leading the technology organization.

It's a subject that's very important to me because before I joined AWS, I was CIO of U.S. Citizenship and Immigration Services. And before that... yes, exactly. My feeling, too. Before that, I was CIO of a company in San Francisco. I've been a CEO as well of a software company.

In these CIO roles, I felt like I had to come to grips with what it means to be a CIO now that we are agile and DevOps-y and cloudy and all these other things that we are. It's not obvious to me what it means to be a CIO given all of those changes.

And so I've thought about it a lot, and in my role at AWS, I work with customers. I'm part of a team of enterprise strategists. It's a small team of people who have been CIOs of large enterprises or CTOs and have done some sort of a digital transformation. And so we spend a lot of time with customers trying to overcome the impediments that they see in moving to the cloud or in transforming.

And the subject comes up a lot. What does it mean to be a leader of the transformation? What does it mean to lead the IT organization?

And if you think about it, the changes that we've been seeing have a lot to do with people in the IT world working very directly with people who we would've considered to be on the business side. And so where does IT leadership fit in there?

Meditating on that subject led me to write two books, The Art of Business Value and A Seat at the Table, which basically are about the struggle to understand that.

So, what does it mean to lead IT or to be a CIO?

Let me start with what I think it doesn't mean. It doesn't mean, at least not today, running an organization that is something separate from something called the business. It's not about providing customer service to customers inside something called the business. It's not about taking requirements from the business and delivering what those requirements say. And I think most of all, what it's not about is running IT like a business.

Hope I'm not shocking anybody here. Maybe you've read my books.

I think these ideas are the conventional ideas. They're the ideas that we've had with us for a while, and I think they're tied to a certain way of thinking about the IT function in a business that is becoming increasingly dysfunctional, if it was ever functional in the first place.

So I think this old model says we have the business, we have IT, and IT stands at an arm's length from the rest of the business. The business makes up a set of requirements, tosses it over the wall to an IT organization. The IT organization then makes a plan, commits to it, creates a Gantt chart, all of those sorts of things, goes away, does its thing, and then tosses a product back over the wall to a business.

And the whole thing is managed sort of like a contract. Here's the requirements. That's the terms of the contract, and you agree to do it on this time schedule. And now we have a contract, and if you don't deliver on it, IT, then you've breached the contract, essentially.

And I think the conventional model also acts as if the goal of the IT organization is to provide customer service and keep employees happy. Which, of course, is very hard to do when you're responsible for security and standardization and things like that. But when you put all that together, I think it's about this arm's-length relationship as if IT was a contractor within the company.

And so it was very logical at some point to say, "Well, why don't we just outsource this? We have outsourced it. We've outsourced it to our IT organization, and we negotiate this contract with them every time they work on a project," et cetera.

And I think this was the only way that the non-technical people, when suddenly confronted with IT entering into their organizations, this was the only way that they could really feel comfortable with it and feel like they had control over IT, is by having this relationship that is essentially arm's length.

So I think that's, let's say, the status quo up till now, and it's a pretty terrible status quo for a lot of reasons. And I think a lot of them aren't a surprise to the people here who are DevOps practitioners.

But the first dysfunction, I think, is that there's a lot of waste and a lot of overhead in this idea of negotiating a contract with IT. You've got to put all the requirements together, you have to get them approved, and then you've got to go back and forth on how long is it going to take, and then you have to put mechanisms in place, status reporting, to make sure IT is sticking to its side of the agreement.

And I'm exaggerating everything, of course, but I do think it's a mental model that applies. So there's a lot of this waste in the process.

I really liked Jonathan Smart's presentation this morning with the fuzzy front end. Because if you're going to contract with IT at some point, then you have to go through a lot of process in order to make sure you know that you're requesting the right things, and have straight in your head what you're requesting.

And then I think the fast feedback that we all value, it's very hard to collect feedback on what's being created and work that into your process and your requirements if you've already agreed these are the terms of the requirements.

Perhaps the biggest problem is when you frame it in that way, here's a requirements document and IT is going to deliver on that document, you have to make sure that the document says exactly what you want, that everything you want is included there, because it really is a contract. And in order to avoid the big fear in this model, which is scope creep, you make sure every possible feature that you could want is included in those requirements.

And the result, predictably, is feature bloat. There's all kinds of stuff in there that's based on, maybe we'll need this. We're not going to get another chance for a few years while IT works on this contract, so we've got to make sure it goes into this set of requirements.

So from a lean perspective, looking at the entire system, looking at the high level, there's a lot of waste built into this sort of a process.

The idea of running IT as a business, I think it sounds really compelling. As a CIO, my first reaction was, "Of course I should be running IT like a business."

This, I think, is based on the same sort of optimism that results in committing to a schedule on a project that you're never actually going to be able to fulfill. I think, as a CIO, I want to think, yes, I can run IT as a business.

But the thing is, you can't run IT as a business, even if you wanted to, because you don't have control over a lot of the things that you need to in order to be a business. If you were a standalone business, let's say a contractor providing service to the organization, you would be able to hire people at will, fire people at will. You'd be able to scale up as much as you want to meet the demand of your market. You would be able to choose what customers you're going to work with and what products you're going to produce.

There are all these things that you need to be able to do in order to really run a business, if that's what you want to do in the first place.

But why would you want to do that? You're not running a business. You are a part of a business, and you're part of this organization. So the whole concept doesn't really make sense to me.

And one of the results, I think, is that we have often been in a position where there is this... somebody referred to it as a vomit of user stories. You've got these customers across the business, and they've all got demands, and all these demands are coming at you. And it becomes a question of demand management and building business cases for individual things and pleasing some people and not pleasing other people.

And none of this actually accomplishes the objectives of the organization at the high level. You're making decisions between different things that may or may not tie to the strategic objectives, and you're making decisions based on trying to run a business and please your customers and maintain relationships.

So it's dysfunctional in a lot of ways.

And what I want to point out is that nothing changed when we introduced agile approaches to IT. And what I mean by that is with Scrum, which I guess we have to deal with as sort of the default way of implementing agile practices in an organization, with Scrum, you have something called a product owner.

And the product owner represents the business, usually drawn from the business, and tells the technical people on the team what's valuable to the business, and then is responsible for making sure things get implemented.

Well, this is exactly the waterfall model, where somebody on the business side decides what's valuable, tells IT what's valuable, IT produces the product, and the business implements it.

Now we have it just on a smaller scale. We've got a product owner who decides what's valuable because they represent the business. You've got a technical team that tries to implement the solution and turn it back over, and then the product owner goes and does whatever they do to make sure it gets implemented.

All we've done is shrunk the whole model. There's still this sense of, we decide what's valuable, you do it.

Or, since in many cases, this was historically perpetuated by the IT organization, I think you have your technical people saying, "Well, we can't do anything till you give us your requirements."

And this separation, I think, has continued and is embedded in the way we speak. It's hard to not talk about IT and the business. Well, IT is the business, right?

So I think this state of affairs, though, for some reason, continued for decades, and I think it would've continued forever except that a whole bunch of things changed on us recently, and make it unpalatable, I think, to continue with this sort of a mental model.

So what's changed? Well, it's a terrible buzzword, but we're in the digital era now, right? A lot of what a company does is done digitally: interactions with customers, sources of revenue, all sorts of things like that.

So it's a little weird for this thing called the business to be giving requirements to the technologists when those requirements are about the technology, right? The model's almost backwards.

You can think of instead, maybe the IT organization should be figuring out the digital strategy and telling the rest of the business what to do, right? Requirements should almost be flowing in the other direction.

That changed. The cloud changed. And I think the importance of that is that the cloud enables companies to move at a much higher velocity, much higher, where you can provision infrastructure in no time. You can deprovision infrastructure, you can try things and make the decision not to go forward with them. You can get access to high-level services like machine learning in no time. So, the pace at which an IT organization can move is much, much greater.

DevOps, at the same time, was shrinking cycle times. So when you have an idea for a capability, you can get that capability into production really quickly. So again, speed changed a lot.

And companies realized that the best way to reduce risk in creating products, the best way to get a good fit to the users or the customers for a product, was to use this lean startup sort of approach: try things, see how the market responds, make changes to what you're doing, and pivot or persevere.

And IT has become much more about experimentation, fast feedback, and adjustment. So when you put all these changes together, it's a very different way of thinking about how IT fits into an organization.

But it was, even then, still easy for companies to resist these changes because, okay, so what? You can move faster. We can just keep plugging along at the same speed.

The real issue is that these capabilities give your competitors all sorts of opportunities, right? So you can continue to move slowly, but if somebody else uses these new tools and finds the new way to include technology into their organization, you're going to be in trouble. Or if a startup starts up and is able to compete because it's taking advantage of all of this velocity and feedback.

So in the end, I think companies, enterprises, have realized that they need to change the working model and need to change it in ways where they can speed up the entire value stream for trying things out and getting feedback.

And you can't do that if you are treating your IT organization as a contractor at arm's length, and you have to go through the whole contracting pro... all the things that Jonathan Smart put on the screen this morning, right? If you've got to go through this complex, long lead time process in order to be able to deal with your IT organization in this manner that seems to give control over it, but is really an arm's-length sort of contractor model for what the IT organization does.

So, how do we create a new model for what the CIO is responsible for and how the CIO relates to the rest of the organization?

Well, one option is just punt on it entirely. Just let things keep going. And that's the strategy that eventually leads to creating a chief digital officer position, I think, because the need doesn't go away, right? The CIO can continue to run the slow-moving stuff of IT and let somebody else deal with everything that has to be fast-moving.

I don't think ultimately that's a great model, but it's one way to look at it.

I think a better way, and what really got me thinking is, if you've got a CIO, that should be sort of parallel to what a CMO does, what a CFO does, what a COO does. There are all these other CXOs, and there's this asymmetry between what they do and what a CIO does.

What I mean is, for example, marketing doesn't say the business is my customer, right? You don't talk about marketing and the business. Finance doesn't say finance and the business. The business is our customer. It's a little weird that the CIO often thinks of it that way.

The CFO, CMO, these other CXOs, what they really do, I would say the sort of high-level way of thinking about what they do, is they bring expertise in their functional domain to company strategy.

So a bunch of people with seats at the table, and the CFO looks at the company strategy, company issues, from the point of view of somebody who's an expert in finance. And the CMO does the same thing as somebody who has expertise in marketing.

And really, the CIO role, you would think, would be the person who has the technology expertise who's helping the company formulate its strategy and providing that value of being the expert at technology.

So I sort of start from there. And when you think through the implications of trying to make all these things be analogous, CMO is responsible for the quality of marketing, primarily. The CFO is responsible for the quality of the financial statements, the use of the assets of the company. CIO, maybe similarly, is responsible for the quality of the technology and the technology products that the organization is using.

And when you put all the pieces together in the context of lean startup and DevOps and the cloud and the ability to move really fast, you could think of the IT organization not as a separate thing that the business contracts with, but instead as a part of the business that is on a learning journey together with the rest of the business.

So we agree that nobody knows what the ideal requirements are, not the business, not IT. Together, they try experiments and they put their heads together, some people from a marketing perspective, some people from a technology perspective, and they figure out good experiments to try, hypotheses to test. And they test those things and they learn, and everybody's in it together.

So I tried something like this at USCIS. I mention it in my book, but I actually know a little bit more about how things turned out now, having gone back and seen what happened after I left.

So let me describe the business situation, and I'm going to use this as sort of a model for how maybe we can think differently about the role of the CIO's organization in the enterprise.

The situation was we were responsible for E-Verify, if you're familiar with it. This is the system that's used in the United States for employers to verify that their employees are eligible to work in the United States.

Hiss? Hiss. Yeah.

So this is a system that is used by some employers, but not all of them, and we were pretty sure that there would be a lot of bargaining around immigration, and we'd wind up being told that all employers need to use the system to check the eligibility of all of their employees. It hasn't happened yet. It probably will. And if that happened, we would need to scale the thing up like crazy.

So we hate, in the government, we hate Congress giving us a hard time, and we hate newspapers writing bad stories about us, so one of the critical goals of the agency was to make sure that this E-Verify system could scale up when it suddenly had to and not be like healthcare.gov and some of the other government disasters, because we don't want to be on the front page of The Washington Post, et cetera, et cetera.

So key agency priority: make sure the thing scales.

What was interesting is scaling, in this case, was not a technical question. We could make the technology scale pretty easily. We were confident about that, but there's a human side of it.

98.6% of the cases could be handled just by technology and an automated system say, "Yes, this person's eligible to work." But in that last 1.4% of the cases, a human being had to get involved and adjudicate the case, and human beings don't scale so well, right? They scale linearly. If you suddenly are processing a much bigger volume, you're going to need a lot more people.

Other parts of what we were doing similarly wouldn't scale because of people, so our ability to detect misuse of the system and fraud, for example, we would need more people to do that.

So we started out this project by saying, what specifically are we trying to accomplish from a business objective point of view? And we agreed that there were five things.

One of them was a person could process 70 cases per day, and we said that number has to go way up in order for us to be able to scale this thing.

Second thing, we're solving 98.6% of the cases in an automated way. That number has to go up. We have to get closer to 100%.

A third thing was we have sort of a shopping cart abandonment rate problem when companies sign up to use the system. A very large number, like 60% of them, didn't make it through the sign-up process.

So there were two other goals that I won't talk about, but we said at the sort of high-level managerial level, those are the five goals of what we're doing, and if we accomplish those five goals, it will be a success, and it's worth spending X amount of money on doing that.

And then what we did, I think, is kind of unique. Instead of having somebody write up requirements for how we were going to accomplish those goals, we just gave those goals to teams directly.

And so we created a team that was a combination of technical people, business people, had all the skills. This is sort of the concept of DevOps, is you put together on the same team the skills of development and operations and testing and security.

We extended that one further and said also the business application skills should be on that team. And the team as a whole should have the power or the ability or all the skills necessary to make whatever changes are actually going to accomplish that objective.

So objective number one, get more than 70 cases per day per person. Well, we gave that to a team and we said, "Get us more than 70 cases per day per person. We trust you. You have the skills. We know you have the skills, so just do it.

"And we're going to measure your progress. You have a DevOps pipeline already set up. You have a cloud infrastructure already set up, so you can start deploying today, and two weeks from now, you can show us what you've changed in the business, how many cases per day are people able to do."

It would've been weird in the old days to say, "In two weeks, show us your actual results," but there was no reason why they couldn't do it in this case.

So we agreed that every two weeks we would have a check-in, and we would discuss what the number now was, and what they were working on, and how it was going.

And in the meantime, they were free to do anything they wanted to get that number up. So if they didn't want to write any code, they just wanted to change a business process, fine, do that. Or if they wanted to write some code, what that code would be, up to them.

We actually started the process, to get a little bit of alignment, we had a brainstorming session and we used impact mapping. I don't know if you guys are familiar with it, Gojko Adzic's framework, which I think is great, where you essentially draw a mind map of hypotheses about what capabilities might result in the business goal.

So we did that as a brainstorming session between management and the implementers of the project. But we told the project team, "You can just ignore everything we just did. This was just to get us a start and get some good ideas on the table. Try these different hypotheses or try other hypotheses. Just tell us how you're doing on the 70 cases per day."

I had people overseeing me as well, and that was a DHS oversight group, and I had to report back to them. And they were used to these complicated 104 forms, if you've seen me talk about this before, 104 different documents we had to write, whatever.

And I said to them, taking my chances, because for me, this government job was all about risk and taking personal risks. I said, "We're not going to write those documents, sorry.

"Instead, every month, much more often than you're used to, we're going to come back to you and tell you what these metrics are and how we're doing. We're going to tell you what we spent and what we accomplished and what we're planning to do, and that's the only information we're going to give you. And you get to decide each month if we're going to continue, if you're going to keep funding us, essentially. And you have the power every month to say, 'That's it,'" which typically they didn't have in the past.

In fact, we got so much of the waste out of the process, we wound up working out with this oversight body that every time we came back to them, we were going to give them four pieces of information and four pieces of information only.

That was: how many cases per day are we now doing? How much have we spent? What are we planning to do, high-level terms, in the next month? And how much are we planning to spend? And that's it.

There was actually a fifth thing, which is how they could help us remove impediments.

So the way I figured it, the first two of those things, what have we accomplished? What's the number up to now? How much have we spent? If you compare those two, that tells you how well the program is running.

And what are we planning to do, more or less, and how much are we planning to spend? That's the business case right there. Because it's all framed in terms of this 70 cases per day. We don't have to make a return on investment business case or anything else complicated like that. We have already agreed that the goal is raise the 70 cases a day. So what are we planning to do? How much are we planning to spend?

Getting the overseers used to that fifth question, how can they help us, that took a long time. That was the hard one. But essentially, we said, "This gives you all the information you need. Decide whether to continue funding us."

And we actually, in many cases, we could recommend to them not to continue funding us. For example, on that shopping cart abandonment rate project, we showed them that we had increased the percentage of completed transactions. This was after a few months of working on this. Increase, increase, increase, plateau.

And we described the hypotheses we were testing about how to continue the increase. We had tested all of them, and so we said to the overseers, "Look, we've tried everything we can think of. We don't think we can budge the thing any higher, so stop giving us money for it. Let's put the money against a different goal."

So everybody could be on the same page with respect to whether things were succeeding or whether the investment should continue. And it wasn't this arm's-length sort of thing, which is what I'm getting at.

The oversight for this project on a day-to-day basis, or every two-week basis, was me and the head of the business unit that was responsible for this. We were the ones who met with the team, and we were on the same page because we were sitting there together reviewing what the team was doing.

So I cite this all as an example of how you can put IT together with the rest of the business to work together on achieving objectives while maintaining the agility and the flexibility and the ability to try and test hypotheses, et cetera. All the things that we talk about. It's not the only way, but it's just one example of how it might work.

So, generalizing from there or going up a level from there, what is a CIO responsible for?

And I think it starts to sort itself out when you think of an example like that for overseeing things, and you think about this comparison to CMOs, CFOs, whatever.

What I would say that a CIO is responsible for going forward is, first of all, having technical expertise to contribute to the company in strategy setting and goal formation and things like that. Just like a CMO provides marketing expertise, a CFO provides finance expertise, a CIO should be a technical person.

This is a little bit different, I think, from what people have said over the last few decades. You could have somebody who's just a good business leader leading IT because IT is a business, et cetera.

When it comes down to it, you wouldn't have a CFO who doesn't know a lot about finance or a CMO who doesn't know a lot about marketing, right? So maybe the first role is provide that expertise to the rest of the enterprise at the strategic level.

The second thing is, as the company decides on its objectives, as I say in my first book, as the senior leadership team turns the ultimate objectives of the company into a definition of business value for the company, that has to get connected to teams.

So second role of the CIO is to take that overall vision and work with teams to implement those objectives. So that's what I was doing with Tammy, the head of that business unit. We were connecting the team to the goal and giving them constant feedback on how they were doing against the goal.

The third thing, which I surprised myself with, is I think the CIO in a way is the enterprise architect in the sense that it's almost, I said before, the CMO is responsible for quality of marketing, the CFO is responsible for quality of the financial statements.

CIO, I think, is responsible for the quality of the IT systems in the sense that they promote agility in the future. So the systems that you have, they could be filled with technical debt, and that technical debt might reduce your opportunity in the future to earn revenue or to lower costs. It reduces your agility and flexibility.

So at any given moment, the sum of all the IT systems that the company has, that is an asset, and it has value to the extent that it lets the company do the things it's going to want to do in the future, lets it move quickly, lets it generate revenues, et cetera.

It's not just the architecture, it's also the people and the processes. So the CIO is responsible for making sure that there are talented people in the IT organization, that they have the right skills to be able to do the things the organization needs, that processes have been set up, that DevOps has been implemented, all of those things.

And the way I think about it is all of that comes together into an asset that the company has. It's an off-the-books asset. It's intangible, but it determines the company's future revenues and costs because if it's a bad asset, if it's bad quality, then it's going to be very hard to move quickly in the future. It's going to be hard to obtain new digital revenue streams, et cetera.

So responsible for making sure that that asset is going to be productive in the future.

The fourth thing is that impediment removal thing. So I knew what would happen when we started meeting with the team every two weeks. They would say, "Ah, we have this great hypothesis. We've tried it out. It's not working for us because somebody is stopping the change that we need from happening."

So very easy. I loved it when teams said that because then I could take all my command-and-control authority and say, "You, stop getting in the way." Take advantage of the authority that a CXO-level person has.

So that was number four.

And then number five for me is this constant tweaking. We call it continuous improvement, but it's even more concrete than that, I think. As the team reported in every couple of weeks, I could say, "All right, that sounds good. How about if we tweak the goal a little bit this way? How about if you try this and this? And maybe your team doesn't have all the skills that you need, so I need to add somebody else to your team," or whatever it takes.

It's constant review and improvement of what's going on, both in the project sense and in the big capability sense.

So I think when you start to think about the CIO role in terms of its impact on the business as a whole, as opposed to its ability to deliver product to the business as a separate contractor, it leads to a very different way of thinking about what a CIO actually does.

Where before it was about running projects and making sure they delivered on time and met their contract, the way I put it before, it is now about... partnering is kind of too weak a word. I think partnering still implies that there are two separate entities.

It's about participating and having everybody in the IT organization participating as just a part of the business. Working with other people in the business, coming to work every day and trying to figure out how best to meet the company's objectives.

Where before it was about running a standalone business within the enterprise, now it's about taking advantage of the fact that you're not a standalone business, that you're actually part of an enterprise motivated by the same goals and being creative and innovative in order to help accomplish the objectives of the company as a whole.

And when you add it all up, it makes the CIO the equivalent or the parallel of CMO, CFO, the other CXOs in the organization.

So that is my proposal for what we are looking at today when it comes to the leader of an IT organization.

I don't know how I'm doing on time. I would love to hear your questions. I'm late, right? There's nobody flagging me down. Sorry about that.

All right. Happy to talk on the side, lunch, whatever. Thank you all.