Mark Schwartz

And I got a job working for the company that my father worked at, of course. And they had just gotten a fancy new computer. It was a Data General thing, and it had its own room. It was a computer room. And it was super-duper air-conditioned.

And the room was just off the path that you would walk to if you were going to eat lunch in the lunchroom. So all the employees of the company walked past at one time of the day or another. And if they looked into the little window in the door, they could see the big computer sitting there, and they could see these big refrigerator-sized reel-to-reel tape drives and the punch card reader and everything, and all of these IT guys walking around in white lab coats because it was pretty cold in there with all the air conditioning.

And so you have to imagine that you're one of the employees of the business. You're walking down the hall, you look in, and the lead engineer was a guy named Igor, of course.

Of course. Of course. Of course.

And Igor was a little bit unusual. He generally was looking into space sort of like this, and had the very thick glasses, sort of dreamy look. And Igor had this frown on his face all the time. And Igor was a genius, by which I mean that nobody could understand what he was saying. And he could code in machine language. He actually had read the manual. So really a character.

And so here you are, you're a business person in the business, and something goes wrong, and you run down the hall. The payroll system's not working. So you've got to go find Igor.

And so you look around, and finally you find the desk that Igor is sleeping under. And you wake him up and you say, "Igor, the payroll system is down."

And Igor says, "Hmm. Interesting."

And you say, "Igor, it's not interesting. Nobody's getting their paychecks. The payroll system is down."

"Hmm. I think it's the hyper-recursive spanning tree index hyperventilator masticator algorithm that I deployed last night. I thought it was okay. Want me to do something about it?"

And, "Yes, Igor, please do something about it."

"Oh, let me finish the quasi-reticulator manifold fumigator, and then I'll get to it."

Something like that. This was your usual conversation with Igor.

So if you are a manager in the business and you have this wonderful conversation with Igor, you walk away from the conversation, and what are you thinking? You're thinking, "IT people are strange." That's easy. You're thinking, "They can't speak English." You're thinking, "They're worried about hyper-reactive fumigators or something, when the payroll system is down. They're focused on the wrong things." And if you don't do something to focus them, then they are going to go and work on their hyperventilator manifolds instead of on what the business really cares about.

This is a sort of obvious conclusion when you're in an interaction like that. And really, if you step back and you think about the context a little bit, the business is running along fine. You're doing what you do day to day, and you have no idea that you need IT or you need computers or anything because you're just going along like everybody else. And then all of a sudden, there are these people in your organization like Igor.

And it's not just Igor, but it's all these IT people with funny titles that don't make any sense to you: your map producers and your DevOps instigators and SQL injectors or whatever it is you've got. And you now have to suddenly rely on them to actually get your job done.

This is the problem. Most of the IT systems at the time are these internal mission-critical systems. It wasn't customer-facing, of course. And slowly, you get into this position where you absolutely have to rely on what Igor is doing in order to be able to do your job.

So I think the problem then became, well, I have to control IT somehow. I have to get it to produce. I have to get Igor to focus. But I don't understand what he does, so it's a little bit of a challenge for you as a business leader. How are you going to be able to control something that you don't really understand? And it's new, and you were fine without it, and now all of a sudden it's there.

So just in case any of you ever find yourselves in that position, I have some suggestions for how you might go about controlling Igor.

First thing I would do is I would tell him he has to start speaking English instead of speaking techie, and he has to provide good customer service to the rest of the business. In fact, we're going to evaluate his performance based on whether everybody's satisfied with what he's doing. So that's number one.

Number two: "Well, I don't know what you do really, Igor, but I need you to do some things for me. So what I'm going to do is I'm going to write those things down really precisely, exactly what I want you to do, because I know if I don't do that, you're going to come back at me with all these questions that are like little nitpicky things, and then I'm going to have to answer. So I'm going to write exact requirements down, and then we're going to have a little discussion about timing, and you're going to tell me when you're going to finish it. And also, Igor, I want you to give me some milestones so I know if you're actually on schedule. So put together a plan for me, and this way, I don't really understand the milestones, but I can ask you, did you do the detailed design or something?"

So that's another way you can try to control Igor.

Another thing that worked really well is you get one of these CIO people, because in theory, the CIO can speak geek and can also speak business, and you can have the CIO watch over the Igors and make sure that they actually get things done. And this way, because Igor has agreed to the project schedule and the milestones, you know he's not going to fool around with any manifold fumigators or whatever he's doing. He's got to spend his time working on the project. So you know that you're in control, let's say.

So it sounds familiar, right? It's kind of waterfall, isn't it? Waterfall is a beautiful model for establishing control over an IT organization that you assume is something different from the rest of the business and you don't understand.

And I think over time, these stereotypes kind of hardened. The IT people, they're strange, they're geeky, they don't really care about the business. They don't know anything about the business. And the IT people, of course, had stereotypes for the business people. They're kind of clueless. They're very demanding. We'd better idiot-proof our software because somebody's going to have to use it at some point.

So you have these hardened stereotypes on both sides, and I think the result is that we've had this distinction between the business and IT sort of thoroughly pounded into everything we do in the IT world. We're constantly talking about IT and the business. This is the way we talk, the way we frame problems.

We say things like, "IT's customers are the business." This is pretty much the way you would talk if the IT organization was actually a contractor that was independent of the business. The business, they are the customers of that contractor. The contractor should give an estimate of how much something's going to cost, and then should deliver on that estimate, should provide good customer service.

We wound up with this way of thinking about it as if IT and the business are two different things, and IT is in this contractor relationship with the business. And in a way, it had to be that way because IT was a sudden intrusion into the business that was working just fine before, and now had to be controlled despite the fact that the business didn't really understand the details. So you've got IT and the business and a contractor relationship.

Well, obviously, you can think about outsourcing IT, right? They're already a contractor pretty much. So what does it matter if they work for your company or they're a separate company? So it was very logical to start thinking in terms of outsourcing IT as well.

The CIO, and by extension IT leadership in this picture, CIO was responsible for making sure that IT stayed under control. The CIO, how do we know if the CIO is doing a good job? Is IT providing good customer service to the rest of the business? Is it treating the business like its customers? Is it delivering projects on schedule? Is it reducing costs? Never mind the impact that might have on the rest of the business. Is it reducing its costs?

The overall concept of what IT leadership was about was control over something that seems risky and scary.

So 2001 comes along. We're all Agile, and so the CIO—

Yes, exactly.

So the CIO is saying to the rest of the business, "By the way, requirements are going to keep changing, and we're not going to make a Gantt chart anymore. And in fact, we're not going to exactly promise what's going to get done."

Well, what's the first reaction of somebody who's outside of IT in the business? "Well, then how do we control it? How do we control the project if the requirements can change anytime, the schedule can change anytime? How can we control this? And, more than that, how do we know if IT is doing a good job? Because we don't know if they're delivering on time, not on time. They can just change the requirements, change the schedule anytime."

So the fundamental barrier that we hit, I think, when we started to introduce Agile approaches was, "Yes, that sounds great, but how do we control it?" Because we've always thought of IT as something that has to be controlled by the rest of the business. It's all about control.

So the thing to reflect on maybe is that things have changed pretty clearly since 1977 and the big Data General and Igor. I have worked with a lot of great IT professionals, and I have to say, I can't think of many of them who didn't care about the business and who just wanted to play with technology, honestly. It's a stereotype that we've all lived with. I don't actually see it.

Some of my USCIS people are back there. Hello. People who worked for me in my last position. And these are people who care passionately about the mission, who actually speak English, and speak it articulately. This stereotype is a little bit odd.

To tell you the truth, it was never actually a very good stereotype, because I knew this guy, Igor. And I knew that he was passionate about getting the work of the company done, even though his bearing didn't look that way. In fact, when he released that hyperreactive, hyperventilating masticator into production, he did it because he was trying to speed up the payroll system so that people would get paid quicker.

And when he was looking off into space when you asked him about the problem, he was looking off into space because he was trying to figure out what could be wrong, and he was trying to solve the problem in his head. This stereotype of IT people who don't really care about the business, it's maybe tiny sample size or something, but it's never really been a good description of the dynamics here.

On the other hand, this IT and the business contractor relationship is odd, and we've come to accept it. But if you think about it, this is a really odd relationship. Somebody in the business, IT is not the business, somebody in the business writes down a bunch of stuff and goes to IT and says, "These are my requirements of you."

Well, who else do you do that to in your organization? Do you go to marketing and say, "Here are my requirements"? The whole idea that you're going to tell the IT people what to do is a little bit odd. The idea that you're going to have to oversee what they do and make sure they focus on the right things, who else do you do that to in your organization? Maybe when you have a management problem here and there you do, right?

The business is IT's customers. Is the business marketing's customers? Is it finance's customers? Any other part of the business, anybody else represented by a CXO, we don't think in those same terms about.

But for some reason, we've gotten comfortable with this idea that the business is IT's customers, that IT has to align with the business, whatever that means. That there's this kind of arm's-length relationship of control between the two. And when it comes down to it, the CIO role and the role of IT leaders has been defined in terms of this dynamic, I think.

So okay. Actually, let me point out something else, just a little item of interest. Of course, with Agile approaches, we've fixed this, right? Instead of having the business figure out all of its requirements, make a requirements document, and give it to the IT organization, we got rid of that. Now we have a product owner from the business who figures out what the requirements are and tells the technical people on the team, right? Whole different thing.

Instead of having a Gantt chart with milestones and telling the technical people, "You better deliver on these milestones," instead, at the beginning of a sprint, we have the technical people commit to doing a certain bunch of work, and then we make sure they have it done at the end of the sprint, right? Whole different thing.

Instead of measuring their performance based on did they hit their schedule objectives, we now measure performance by their velocity. Do we like their velocity? Should it be higher?

I think the truth is that even as we've moved towards Agile and DevOps, we've kept a lot of the ideas about IT leadership and about how we need to control what the technical people are doing. It's very insidious, right? It seeps into everything that we're doing.

So what's the alternative? What does IT leadership need to look like in the age of DevOps? And how can we avoid getting ourselves back into this paradigm where it's all about control and it's all about trying to find a way to enforce visibility on what the IT people are doing?

I have a different way of thinking about it, let's say, that I'd like to propose. This is something that we've tried out. We tried it at USCIS, and I think it was working, but it's still kind of an early experiment. So I'm going to throw it out there as something that everybody can try fooling around with.

We said the purpose of what the technical teams are doing is to meet strategic objectives. Let's just start from there. A company has objectives based on what they're trying to do, and those objectives, we want a team to somehow fulfill, and we suspect that it has something to do with technology.

So what we did was we started from a business case for those objectives, and we got rid of the idea of requirements entirely. Here's the set of objectives. Is it worth spending X amount of money to accomplish these objectives?

I'll draw an example from USCIS. We were responsible for the E-Verify system, which some of you are probably familiar with. This is the system that tells us whether a person is eligible to work in the United States. And we knew that we were probably going to have to scale it up quite a lot, probably very quickly.

And so in order to make it scale up, we had to figure out what the critical points were in scaling. Part of it was the infrastructure itself. Was it going to be able to scale up? But part of it was the human part, because when the system couldn't decide if somebody was eligible to work in the United States, a human being had to review the case, and a human being could review about 70 cases a day or so.

And so if we had to scale up dramatically, which is what it looked like we were going to have to do, there's no way that the human being would scale. This was our business problem.

So there's an example. Business problem. Goal is, right now, the person can do 70 cases a day. We want them to be able to do a lot more than that. Second goal is, right now, the automated system can handle 98.6% of the cases. We want it to handle more than 98.6%. That will help us scale. So those are two goals.

And instead of first writing up a bunch of requirements documents about what the system was going to do exactly in order to accomplish all that, we just took the objective. We said, 70 cases, we want it higher. 98.6%, we want it higher. And let's not pretend that we know what system requirements are going to accomplish those things. Let's just take the objectives themselves and pass them on to a team.

And now the team, well, we have DevOps, so we can combine developers and operations people on a team or have a single team that has both development and operation skills. And sometimes we say DevOps Sec or DevSecOps. We also include security skills. Why don't we include other kinds of business skills on the team?

So here's a true cross-functional team that understands the actual operations and understands the technology, and then charge the team with make that number higher. That's it. I don't care how you do it.

So if you, team, figure out that not writing a line of code and just changing the business process is going to do the best job of increasing that number from 70, do that. If you think writing some code is going to do it, do that. Whatever you think is going to get the result. You are empowered, team, because I know you have the skills to do it.

And let's have a little discussion about hypotheses about what might do it. And you go ahead and explore those hypotheses, and every two weeks, you tell me what the number is. It was 70 before, now it's 75, now it's 80, whatever.

But the point is that the IT approach in this case is not we're going to sit back and wait for the business to give us requirements. It's we're going to participate with the business in a journey of discovery, let's say. We're going to try out hypotheses together. We're going to put all our brains together, and the one thing that we're going to guide ourselves by is we want results. We're just going to keep making sure that we increase that number from 70 to higher.

And if you think about what it looks like from my point of view, the CIO in this case, what it looks like is blessing the team. Basically, here's your objective, and now I want to work with you to remove the impediments so that you can try out different things and try to deliver the results. And I don't care if the good ideas come from the technical people. I don't care if the good ideas come from the people who were doing the operations before. What I care about is, do you as a team achieve the business outcome that I'm looking for?

And it's not even a fail-fast kind of approach, which we talk a lot about in the Agile world. Failure is almost hidden. I just want to see that number go up every couple of weeks when we talk. So if in between those checkpoints, you're trying this, this, this, and this, and then you decide that one of those things is the best, great.

But my role as an IT leader in this scenario is clear the way so that the team can try things out and figure out the results. It's give them feedback to try to help them in what they're doing, and it is take all the risk and all of the responsibility for producing business outcomes, instead of saying, "Oh, the business figures out the requirements and actually implements the thing. I'm just responsible for delivering the IT system," which is what was encouraged, I think, by the control paradigm that we started with.

So I don't say this is the only way to do it, the only way to look at a different way of thinking about IT leadership. But what I do say is that if you're trying to do a DevOps transformation, you're probably hitting the wall when it comes to, how do we oversee projects to make sure that they're being delivered? And how do we govern things and make sure IT is aligned? All of these things, they're old ways of thinking about it, and they're not really consistent with an approach where we have responsibility for business objectives, where we have IT and the business working together, where requirements don't necessarily come from the non-technical people because we're now in a digital world, and a lot of our interactions with customers are digital. Makes sense that some of the technical people are going to have good ideas about what the requirements are going to be, right?

So increasingly, we have this lack of fit between the way that we're governing, the way that we're leading IT, and the actual role of IT in the business. And the danger is that because of this history of this arm's-length relationship, the need to control IT, and the need to verify that IT is doing its job well, those things are stopping us from arriving at the full solution to the problem, even though we have these wonderful techniques of DevOps and the various Agile frameworks.

They're all great and we can get a lot of work done, but we can't get the full benefit of these things until we're willing to give up the assumption about Igor, and you've got to control Igor, which I argue underlies quite a lot of the way that we're thinking about things, even product ownership and relationships between business and technical people on our Agile teams.

So what I am asking you all for is, as you are thinking through your DevOps transformations, as you're communicating with the rest of your organizations, think about whether you're actually reaffirming this bad way of thinking about things that's holding us back, right?

Are you saying, "Well, business, you've got to give us the requirements. We can't do anything till you give us the requirements"? Or, "I don't know, this team is committing to stuff and they're not getting it done. There must be a big problem here because we have to be able to rely on their commitments."

I think all of these things are patterns of communication and patterns of thinking that we've learned since Igor. And I think everybody needs to look for it in their own way they articulate things, the way that they think about IT problems, because we in the DevOps community are perpetuating something that is really a barrier for us and that we really need to be thinking differently about.

So everybody think about that, and as you spot it in your own communication, see what you can do about it.

So thank you.