What’s the Role of the CIO in a Modern Agile Organization? – InApps 2022

Only in school are we put into arbitrary blocks of time to focus on completing one task, then another block of time for another task. Well that and in IT. In both cases, innovation and creativity are starved by constraints. Also, in both situations, we still maintain a command-and-control environment that negatively impacts motivation. Yes but, but — you’ll argue — agile, Scrum and DevOps culture has released us from these top-down chains.

But has it really? Or maybe we’ve just scaled down the hierarchy, but not changed these roles within a larger organization much at all.

“What does it mean to lead IT? It bears thinking now that we’re agile and DevOps and so on.”

This is how Mark Schwartz, the chief information officer (CIO) at U.S. Citizenship and Immigration Services, began his talk on the role of IT leadership in the modern agile business, at DevOps Enterprise Summit in London this week. He made a compelling argument that we have forgotten to redefine the role of the CIO  in our eagerly agile transformations.  The talk suggests that we have forgotten the purpose of an agile business model — trust enabling speed — and how we need to reconsider the role of IT management in the modern agile enterprise.

Where the IT Role Began in Corporations

Schwartz began by telling the story of Igor, an awkward technical support worker in a company he worked for long ago. We’ve all been there, Igor was the person who got complaints from other parts of the business, and then took his good old time getting around to fixing things. That’s because we perceived that “IT used to be something that doesn’t care or know about the business.” Add to that, especially when in a technological crisis, we tend to think our problems are the only ones that matter.

On the flip side, IT thought their job was to “idiot-proof” their software from the rest of the Luddite business.

These perceptions combined to isolate IT as the department that doesn’t care about the overall business goals of a company. And the IT manager’s job was to crack the whip so they at least acted like they did and that the developers and admins produced code.

Schwartz went on to speak about how when he was younger and traveling the world, he’d barter over trinkets in local markets: “They give you a high price you don’t know and you haggle for half,” he said. Then, “you walk away feeling like you’ve been ripped off even if you don’t know” anything about the pricing and value in that country.

The same principle applied in many traditional IT departments, where the business and the IT department haggle over often arbitrary estimates of how long a job will take. As Schwartz asked: How can that be negotiable? How can a unique project that takes a unique amount of time lead to negotiating fairly unpredictable estimates and deadlines?

He said, of course, this IT outsider couldn’t have known how long it’d take to complete that project, “but he could have relied on the experts within his company. To judge how long it should take, you should call upon the person who best knows.”

But that didn’t happen. Instead, internal IT was treated like consultants, outsiders who we buy time from, that aren’t invested in the overall company objectives.

“I think the dynamic that really developed is that the IT organization is something separate from the business,” often referring to it as “IT and the business.”

Not only that, but IT in its contractor’s role becomes very transactional: “The business hands over the work, IT hands the product back.” Just think about the language used. The business gave IT requirements: “This is what I require of you.” Then, IT would be asked IT “to deliver,” being “held accountable” to meet that schedule.

“These are words we don’t use anywhere else in the company,” Schwartz said.

In this command-and-control contractor model, Schwartz argues that the CIO role will only get a seat at the table with other C-level executives if you show you deliver value on time and on budget. Only then can you show that IT is committed to good service for rest of company.

“So my role as CIO is to control,” Schwartz said.

This contractor model supports the assumption that the contractor “is going to waste our time and money unless we control him with a project-oriented structure. Waterfall and Gantt are really good at this.”

Agile says no to Gantt chart — but then how can we hold you accountable to be on time and on schedule? Has it really changed at all?

Has the CIO Role Evolved at All with Agile?

As Schwartz said, now we have autonomous empowered teams. But, besides the fact that technology fosters more and more cross-company innovation and acceleration, what has changed in how IT is treated?

“We have a PO [Product Owner] as an expert on the business and decides what is important to the business and tells the developers what it is and the developers develop. Then the PO then takes the product and uses it to deliver value to the business. And then we ask the developers to commit to certain hours at each sprint. We measure their velocity to make sure they are productive.”

With agile sprints, “we sort of took that big picture of what is IT and shrunk it down to the team size.”

So, what is different? Well, it’s certainly scaled down to the team level, but, in the enterprise environment, it still follows a very similar control model where “the PO represents the business and the business decides what they require and then waits until IT delivers it.”

“Most of what we’ve done is out of necessity for an underlying need to have control and really we’ve just shrunk the model.”

While both tout the name “agile,” large enterprises dramatically differ from how the lean startup model works.

“In lean startup, the business doesn’t really know what the requirements are and what are the outcomes,” Schwartz said.

In the agile enterprise space, he continued that “Here you have a team that’s empowered [by agile] but in many cases we aren’t letting them do that because we have these so-called product experts that review and decide what is acceptable and not acceptable.”

With Scrum sprints and other constraints, we are simply repeating the process of asking developers to predict the often unpredictable, which then has a value translated by a leader, whether it’s the PO or the CIO.

Where Does IT Go from Here to Release the Command and Control?

First, Schwartz argues that we have to regard IT as a part of the business, working together with stakeholders. It needs an automatic seat at that proverbial table.

Next developers should be empowered to create and check their own objectives, being trusted to iterate and constantly improve on their own.

Schwartz also argues that we need to change the “unit of transaction” between IT and the business: the project. We still constantly transact and govern in projects. By changing this unit, we can release from Waterfall-style control.

“Maybe the granularity of which we make investment decisions should be at the feature level [smaller] or larger budget and long-term investment planning — let them deliver when they need,” he said.

Then, we need to work on “questioning some of these assumptions where power and control are really at the core of what we do. It really takes a lot of courage to force people to think about the underlying assumptions of how IT works with the rest of the organization.”

Most of all, we need to trust that IT professionals are, just as much as any other employee, working to achieve things that help the company.