Summer Read Along: A Seat At The Table | Chapter 9 – Governance and Oversight

In this series of blog posts, follow along as we revisit Mark Schwartz’s book A Seat at the Table: IT Leadership in the Age of Agility. Five years after its publication, it’s still highly relevant and chock full of tips, tactics, and learnings. Join us as we follow along with Online Marketing Assistant Lucy Softich as she reads through the book for the first time. Make sure you start with the introduction post!

We’ve been touching on it in other chapters, but Chapter 9: Governance and Oversight really gets at the heart of the division between IT and “the business.”

Not having a software background, it’s always a little hard for me to wrap my head around the fact that IT has been traditionally treated like a contractor instead of a vital part of the overall business. I know, we’ve talked about this before, but still, it boggles the mind sometimes. And this chapter really makes it clear how damaging this relationship is. In many ways, it’s the heart of the problem.

The Star Chamber

In a traditional Waterfall structure, Governance and Oversight are the business’ attempts to control IT. Governance is the front end, where executives lay out expectations and goals for IT, and Oversight (and Management) is the back end, ensuring that only “successful” projects move forward. However, as we’ve discussed before, this structure means that the ones making decisions—the ones setting goals and determining which projects can continue and which are on the chopping block—have the least knowledge and experience about the project. Mark refers to this group as the “Star Chamber,” a group of executives mostly separate from the teams and decisions they oversee.

The most well-intentioned executive board cannot know everything about every department, nor should they; that’s why they hire competent professionals to work under them. The role of a leader is to focus on the big picture; to keep multiple contexts and goals in mind; to help clear the way for their trained and talented staff to do what they were hired to do.

At least in an ideal world. But in a world where the CIO barely has a seat at that table, let alone a voice, is anyone really capable of determining what IT should and should not be focusing on?

Agile Governance

But there’s got to be a better way! And, of course, there is. In an Agile context, Governance focuses on outcomes and coming up with flexible, agile ways of satisfying the Star Chamber’s needs. Traditionally, a board would demand plans and requirements, but those documents were not what they really needed; they were just an attempted means to an end.

Their decisions were not really based on the planning documents—they wanted to see those details only so that they could have confidence that the team knew what it was doing and was putting appropriate thought into the project.

As Mark has outlined here, planning documents don’t go deep enough; they don’t address the root of the problem (especially if no one has time to read them all). If we apply some Agile thinking, we look for the desired outcomes and work back from there.

The Real Goal of Governance

Mark was able to restructure his team to meet the board’s needs while still delivering value in a flexible, Agile way. When outlining goals, they acknowledged uncertainty; they opened things up for discussion and created a culture of frequent check-ins to reassure the board and give them a chance to voice concerns; they frequently met within their teams, as well, to make sure everyone was on the same page.

This process will be unique in every instance, but it’s essential to come to the process with that outcome mindset. Ideally, IT would also be consulted in the planning stages, before those broad outcomes were even defined.

IT investments are so central to corporate initiatives that is is hard to make any other investment decisions without first making IT decisions… In our digital world—if we are truly committed to the idea that that’s the world we live in—IT should not follow business decisions but drive them.

IT can’t be the last step in the governance process. We must resist this tendency to think of IT as just a tool for the business’ goals because it has so much more value than that. Mark says this about budgeting, but it holds for other facets of an Agile structure as well:

Because an Agile project begins delivering valuable capabilities long before the budget is exhausted and delivers them in prioritized order, we can stop work when the budget runs out and know that the money was well spent.

When you focus on continuous delivery, you see results very quickly, and it’s easy to change a process or pivot to a different priority if we aren’t seeing the results we wanted–or if we meet them sooner than expected. But, we’ll talk about that more in Chapter 10: Risk!

—

Jump to a Chapter

Introduction & Chapter 1
Chapter 2: Kept from the Table
Chapter 3: A Nimble Approach to the Table
Chapter 4: Planning
Chapter 5: Requirements
Chapter 6: Transformation
Chapter 7: Enterprise Architecture
Chapter 8: Build Versus Buy
Chapter 9: Governance and Oversight
Chapter 10: Risk
Chapter 11: Quality
Chapter 12: Shadow IT
Chapter 13: The CIO’s Place at the Table & Chapter 14: Exhortation and Table Manners 

- About The Authors

Lucy Softich

Lucy is the Marketing & Social Media Coordinator at IT Revolution. She has a background in writing, marketing, and business.