Q&A with Mark Schwartz and Gene Kim – War & Peace & IT

Recently, Gene Kim and Mark Schwartz had a chance to discuss Mark’s upcoming book, A Seat at the Table. It was an enlightening discussion about inspiration, common misconceptions and the often bumpy journey of a CIO.

Gene Kim: Share the story of what inspired you to write A Seat at the Table, as well as the first time you realized that a) you didn’t have one, and b) when you finally got one?

Mark Schwartz: I remember a conversation I had with the CEO of a company where I was CIO. My IT organization had done a great job transforming one of the company’s business units, and had tried to do the same with a second business line. But it didn’t go as well. The CEO was not happy. But—I said—the problem was that the business unit had given us bad requirements, and then insisted on those requirements even when we pointed out the problems. My team did a good job delivering what they asked for, and that was our job. No, the CEO said, that is your mistake. I am trusting you with my IT investment to deliver me a good return on that investment. You didn’t.

Being an argumentative sort of person, I argued. I didn’t have the authority to override the head of that business unit, I said. I couldn’t control how they used the system once we delivered it. It was their budget money, so they got to decide what we would do with it. But the CEO was firm. I was supposed to deliver outcomes.

Over time, I realized that he was right. You might say that I already had the seat at the table, but wasn’t using it. My job was to use IT dollars wisely to deliver outcomes for the business. Not to provide “customer service” to the business units, and not to deliver product like a contractor would.

I also realized that DevOps and Agile approaches in general can help us take this level of responsibility for outcomes—but neither the Agile community nor the CIO community seemed to be seeing it. Or at least they weren’t talking about it. The discussion in the Agile community centers around autonomous teams with product owners—but if the teams are autonomous, then what is the CIO’s role? And the CIO community is focused on demonstrating to the enterprise that they are adding value, by trying to show that they can control IT functions, despite the obvious uncertainty and unpredictability they involve.

The answer is that DevOps allows fast learning and feedback cycles, through which the CIO can validate that he or she is achieving the business’s desired outcomes. This lets the CIO focus on outcomes rather than outputs—that is, delivery of chunks of IT capability as “required” by the business. It makes all the difference!

GK: What do you think is the biggest misconception from business stakeholders on the role of technology leaders?


MS: Don’t become self-conscious now, Gene, but I want to point out the language of your question. You are asking about “business” stakeholders and technology leaders as if they are different things. Look how deeply ingrained that distinction is: “IT and the business.” Now try it out with other CXO domains. “Finance and the business.” “Sales and the business.” “Operations and the business.” It sounds stupid, doesn’t it? To be seated at the table means to be the business, as the title of Martha Heller latest book says.

But to answer your question, the chief misconception of non-IT stakeholders is “I am the customer.” You aren’t, actually. Customers are outside of the company. Both you and I are inside the company. The internal vendor-customer model for IT is deeply flawed, because it essentially makes IT something separate from “the business”—a contractor to it, in fact. That is why the idea of outsourcing IT functions seems so natural. But what this IT-business model does is make IT, and the CIO, responsible only for delivering things, delivering product, delivering outputs. What the business really wants is for the CIO to deliver business outcomes, and the CIO cannot be accountable for doing so if he is accountable for providing service to someone else in the business.

A second misconception from business leaders is that “the business” knows what its needs are and can “specify” them to IT as requirements. This stopped making sense to me as soon as I read Lean Startup by Eric Ries. The truth is that someone in “the business” might have a hypothesis about what they need (in order to deliver value), but that hypothesis must be tested to see if it actually will deliver the desired business outcomes. And the knowledge of what will deliver outcomes does not have to come only from the business operators and then get passed to IT. Given the emerging importance of digital strategy, it might be even more likely that IT will know what delivers value.

A third misconception is that IT systems are finished “products,” which can and should be acquired off the shelf if possible. This leads to the idea that at some point an IT system is “finished” and only needs maintenance, like a car. That is another terrible analogy. Cars need maintenance to continue to function as they did when they were bought. IT systems will continue to function exactly as they were when they were bought or “finished” without any maintenance—and that is the problem, because the business continues to change.

GK: What is the number one mistake CIOs are currently making? What should they be doing to shift out of the mistake and into a better solution? How does Agile fit into the mix?


MS: The number one mistake CIOs are making is to frame their role that same IT-vs-the-business way—to hide behind requirements as I did when talking to that CEO. “My job is to provide service to the business.” It isn’t. This bad way of thinking leads the CIO to think that on-time delivery of projects is a key goal, that reducing IT costs is a key goal, and that keeping “customers” in the business happy is a key goal. None of them are. Using technology to achieve business outcomes in an increasingly technology dominated world is the key goal. By the way: you are probably wondering why I say reducing IT costs is not a goal. Reducing the company’s overall costs might be a goal, and technology investment might be the way to do it. Or growing the company’s revenues might be a goal and increasing IT spending is the best way to do it. The CIO must influence the IT budget based on overall company strategy.

But I’ll give you a second mistake, since I gave you several for the business side. Mistake number two is to allow initiatives to become large. The CIO should always be asking, “What is the smallest thing I can do that will add business value, test hypotheses, and move the company incrementally along the IT vision I have in mind.” This is hard discipline.

GK: What is your favorite innovated practice you have seen CIOs incorporate into their leadership style?


MS: I love to hear speeches from CIOs who are really passionate about the business they are part of. You hear that in the government a lot. I heard the CIO from iRobot, Mike Tirozzi, talk in a roundtable discussion yesterday. I think everyone in the room was awed by his conviction that his company was going to change the world. That is part of the CIO’s job: to inspire people. I don’t know if you’d call that an innovative practice, but how many CIOs think of this as their responsibility? But as a sitter-at-the-table, it is.

One model I am really enthusiastic about is to empower cross-functional teams with a business objective rather than handing them a set of requirements. The team can have an appropriate mix of business, technical, process, whatever skills, and simply owns an objective. They self-organize to find the best way to accomplish it. They have to win friends and influence people to make their ideas effective. If they can best accomplish the objective through a business process change, they are welcome to not write a single line of code. They self-organize around the objective rather than around how to deliver a capability that a product owner said the business “needs.”

In that kind of setup, the CIO is truly an impediment remover. And a coach. The team will not have the authority to push their ideas. The CIO can help them. The CIO is the hammer, or if necessary, the nuclear bomb. The CIO works for the team as an asset they can take advantage of.

You know, one side of me feels like people will be outraged by some of the ideas I just presented, but another part of me feels like I am just saying the obvious and everyone has figured this out already, and I’m probably just boring you.

GK: What’s your favorite lesson in SATT for technology leaders?

MS: My favorite lesson … my favorite lesson … I think it was something about pasta, wasn’t it? I’ll go back to my opening quote from Xenophanes: “Let these things be believed as resembling the truth.”

A Seat at the Table: IT Leadership in the Age of Agility by Mark Schwartz is now available for purchase at all major book retailers in print, ebook, and audiobook formats.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•