Q&A on the Book "A Seat at the Table"

In the book A Seat at the Table Mark Schwartz explains how the traditional role of the CIO conflicts with an agile approach for software development. He explores what IT leadership looks like in an agile environment, advising CIOs to set a vision for IT and take accountability for business outcomes.

InfoQ readers can download an excerpt from A Seat at the Table.

InfoQ interviewed Schwartz about the way that business and IT interact and how to change it, how enterprise architecture can enable delivery of business value, how an agile governance model can look, the IT leadership role and what IT leaders can do to remove impediments, and his advice for the CIO of the future.

InfoQ: What made you decide to write this book?

Mark Schwartz: When I was working on my first book, The Art of Business Value, I realized that one of the topics I was writing about was worth a lot more attention. That book was about the term “business value” - what it really means, how it is often abused in the IT context, and how it should guide our IT practices. One chapter in the book was about the role of the CIO in defining and interpreting business value for IT projects. And as I was writing, I realized that there were some fundamental conflicts in the CIO’s role.

Think about it this way: Agile practices have development teams working directly with business representatives - product owners or onsite customers - to deliver value. The teams are autonomous and empowered, focused only on meeting the business need. Well, if that is the case, who needs IT management and leadership? The business stakeholders define the need, and the team is on its own to fulfill the need.

Something was wrong with the picture, and I figured that by writing a book about it, I would learn what. And as I probed the implications became more and more interesting. The result was A Seat at the Table: IT Leadership in the Age of Agility.

InfoQ: For whom is this book intended?

Schwartz: I think that IT leaders need to redefine their relationship with the rest of the enterprise, so the book is intended for them - CIOs and their leadership teams. The book provides practical guidance on improving this relationship, and on adopting agile and DevOps concepts in IT strategy formulation.

A secondary audience is the broad agile and DevOps community. Agilists don’t talk much about the CIO and senior IT leaders - they tend to focus on the teams. When they do mention IT leaders, it is generally in the context of driving the transformation that will lead to agile adoption in their organizations. But what then?

And since this is ultimately a book about the relationship between IT and the rest of the enterprise, I think it will be interesting to non-IT leaders and managers who want to better understand how to work with IT to accomplish their business objectives.

InfoQ: In the book you stated that IT is often seen as a contractor held at arm's length by the business. How did we get in this situation?

Schwartz: When information technology first entered the consciousness of the business community, it was frightening and seemingly unpredictable. The people who could manage the technology were - let’s face it - a bit strange. Because the business folks had little understanding of cause and effect in the IT world, they came to think that the IT folks were tinkering with things that had no business value, playing with IT toys. When they saw that IT projects were always late and over budget, it reinforced this line of thought - clearly the projects were late because the geeks were doing things that didn’t contribute to the project’s success. Actually, the real reason was probably just that IT work is done in an environment of high uncertainty, but that wasn’t clear.

So the non-IT business folks felt like they needed some way to get “control” over IT projects, and developed ways of trying to do so. The business would prepare a set of “requirements” for IT, ask IT to price it, and then demand that it be delivered at that price. That is just the way you work with a contractor, right? And IT should deliver services with good customer service - of course the customer being the non-IT people in the enterprise. And the business would establish a governance process to make sure IT worked on the right things. We came to speak of “IT and the business,” as if these were two separate things. All of this is consistent with a contractor model. Step back and think about it - who else in the enterprise is told to fawn on their colleagues as if they were customers? Who else is given “requirements” and told to deliver them?

InfoQ: What makes it so difficult to change the way that IT and business interact?

Schwartz: There are a number of things that get in the way of change.

First of all, notice that this contractor model is perfectly aligned with the waterfall approach. The business tosses its requirements over the wall to IT, who makes a plan and sticks to it. So when we try to transition to agile, we are in a way undermining the whole structure that has been set up to gain control over IT functions. The obvious questions on the minds of non-IT folks are: how can we control IT projects if there is no gantt chart and the requirements keep changing? How do we know whether IT is doing a good job if we can’t measure its adherence to schedule and budget? But are these really the right questions, or the legacy of a model where control is all-important?

A second problem is that we haven’t quite dropped the stereotypes yet. IT people are geeks who don’t know how to explain things in non-technical terms, and are liable to go and play with the technology instead of of focusing on the business. And business people are clueless folk who must be talked down to, who ask for impossible things, and who are likely to try to get around IT policies. In my experience, most IT folk are actually very interested in supporting the business, and though they love to play with the technology, they do it to find better ways of meeting the business need. And the business folk are plenty tech-savvy.

A third problem is that we have set up unyielding processes and oversight mechanisms based on these old models. You can see it wherever organizations are trying to transform. There are organizational politics, compliance regimes, constraining policies, IT standards, approval routings, and rigid budgeting practices. There’s lots of organizational sludge that was put there thinking that managing IT meant putting controls in place.

InfoQ: How can we change enterprise architecture from something that constrains development, to something that enables the delivery of business value?

Schwartz: My point is that the CIO needs to set a vision for IT and how it will support the enterprise in accomplishing business outcomes. This vision will be different for each enterprise. It is what we should truly call the “enterprise architecture (EA),”  although the term has come to mean something different in the past. When I use it in this sense, today’s EA is the set of technology capabilities the enterprise has in place now, including its latent capabilities - the things that will make it agile in meeting future needs. At any given time there is also a desired future state for the EA, based on the CIO’s understanding of the enterprise’s strategic goals.

It will be easier and less expensive to move to that future state if today’s EA is supple and has latent capabilities that support agile change. When you think of it this way, the practice of the EA function cannot be about constraining - it must be about enabling that future state.

How can we move to that kind of EA practice? One way is by having EA become a hands-on, creative discipline. EA practitioners can actually be practicing software and infrastructure engineers, who contribute just like other engineers. Perhaps they develop reference architectures, perhaps reusable components. Perhaps they help refactor other developers’ work to make it more reusable. One thing I’d like to try is having EA shepherd internal “open source” communities, where they could establish an objective and have other developers contribute to it.

InfoQ: How does an agile governance model look?

Schwartz: Since agile approaches are empirical and based on inspecting and adapting, agile governance must be as well. It no longer makes sense to plan a large project, making lots of assumptions, give it a green light, and then wait until it finishes or needs to be canceled. Instead, we have to learn as we go, and treat all project plans, investment commitments,  and requirements as provisional, to be adjusted as the initiative proceeds. For example, if we create a feature on the assumption that it will be valuable to users and find that it is not, we should re-examine our plans to see if there are other features that shouldn’t be built, or perhaps use what we have learned to dream up other features that will be valuable.

If you think about it, governance has always been tied to the waterfall approach. We build a plan for a project, make an investment decision based on the plan, and then try to execute the plan as is because that’s what the investment decision was based on. But there is now a disconnect, because the way we are actually executing the project is agile and frequently changing. Also, with DevOps we can release product very frequently and gain information from how it is used. With traditional governance, that information cannot be used to improve the investment decision, because the plan has already been made.

InfoQ: You mentioned in the book that "failure is considered acceptable for IT systems”. What's your view on this?

Schwartz: What triggered that comment was something that I heard from business unit leaders, something along the lines of “Why is it acceptable for IT to introduce these bugs that are damaging to the business? Anyone else would be fired for making such a mess.” The question made me realize that we do insist that the rest of the business accept a lot of - what to them are mistakes - from us. Systems go down; hardware fails; patches are installed that make things stop working. An IT person believes that they are doing their job well because they respond quickly to these problems and demonstrate good debugging skills. But that’s not the way it looks to the rest of the business.

I am not saying that we can completely change this - uncertainty is a huge factor in what we do, and unexpected things will go wrong. But I think we can up our game by building with quality and ruggedness in mind from the start, by writing good tests and immediately fixing issues, by building in redundancy - by adopting good hygiene, you might say.

InfoQ: How does the IT leadership role look in the agile and lean world?

Schwartz: IT leadership is about business outcomes. We’ve always said that, but at the same time thought of IT as a contractor who delivers products and services to “the business,” which then obtains the business outcomes. IT could always hide behind “First tell me your requirements before I do anything”, or “We delivered what we were asked for, so it’s not our fault if it doesn’t work.” That is not really an outcome focus.

What’s changed is that with DevOps, cloud, and so on, IT leaders can more easily participate in a learning journey with the rest of the business, trying out hypotheses, refining ideas, measuring value delivered, and contributing innovative business ideas. IT can now really be about outcomes.

But that doesn’t mean that IT plays some sort of generic role in fostering outcomes. Just as CFOs bring financial expertise to the table, and CMOs bring a marketing perspective to the table, CIOs must bring technology expertise and perspectives to the table. They view business strategic decisions through the lens of deep technical expertise. And they are especially focused on the longer-term implications of the technology architectures being built today - will the technical architecture foster agility and innovation in the future?

InfoQ: What can IT leaders do to remove impediments?

Schwartz: An interesting thing I’ve noticed is that while command-and-control leadership doesn’t work so well in an agile environment, it can often be excellent for removing impediments. I’m joking somewhat, but the truth is that impediments just need to be cleared, and sometimes we need to seize on whatever works. Impediments are usually there for a reason - when they were put in place, they fulfilled some need. To remove an impediment, an IT leader has to first try to figure out what the intent was, then decide whether that intent is still valid, and, if so, what better, leaner way there is to fulfill that intent.

I’ve seen all kinds of impediments - constraining rules, company politics, cash flow limitations, network problems, critical approvers being out of the office, lost paperwork - you name it. A leader has to use his or her creativity to figure out how to sweep those obstacles aside so that the team can keep working without frustration.

InfoQ: Which advice do you have for the CIO of the future?

Schwartz: The most important piece of advice is to be courageous. That might sound a little sappy, but what I mean is this: an IT leader must realize that there is a great deal of uncertainty in what we do, and that making the right decision can still lead to the wrong results. But you have to make the right decision anyway. And to free up your employees to use their skills to the fullest, you have to shoulder risk for them. That takes courage as well. And, finally, my suggestion is that rather than waiting for a seat at the table, IT leaders just go ahead and take it, by going ahead and taking accountability for business outcomes, not just for providing good customer service to the rest of the business and delivering what someone in the business says is a business “need.” Just smile and pull up another chair to the table, if necessary.

About the Book Author

Mark Schwartz is currently an enterprise strategist with Amazon Web Services, where he works with large enterprises to help them get the most from their cloud adoption. In his last CIO role, as the CIO of US Citizenship and Immigration Services, he led a large scale transformation to DevOps practices, the Cloud, and a more customer-centric approach to design. Schwartz has a BS in computer science from Yale, a master's in philosophy from Yale, and an MBA from Wharton, and is the author of  The Art of Business Value, and  A Seat at the Table: IT Leadership in the Age of Agility.