The IT Leader’s Place in the Business

This post was is an excerpt from the book A Seat at the Table: IT Leadership in the Age of Agility by Mark Schwartz.

In the Agile world, senior IT leadership, and the CIO in particular, must look at their jobs in a new way if they want to secure a seat at the table. A few of the critical characteristics of the new IT leadership role include:

• Driver of Outcomes
• Manager of Uncertainty
• Steward of Assets
• Contributor
• Influencer and Salesperson
• Orchestrator of Chaos
• Enabler
• Impediment Removed
• Manager of Managers

Driver of Outcomes

Business organizations achieve their desired outcomes through technology. When technology was only used to help the organization derive its outcomes, the role of IT leaders was simply . . . well, to help the organization derive its outcomes by providing whatever IT capabilities the organization said it needed. IT was responsible for delivery of capabilities—the rest of the organization for determining what capabilities were needed and for harvesting business value from them.

But now that technology is so central to the business—now that we are living in a digital world—that handoff between a business and an IT department no longer makes sense.

Instead, IT leaders must take responsibility not for delivery, but for outcomes, in the same sense that marketing and sales are not just responsible for delivering TV commercials and sales calls, but for delivering revenues, as well. IT must drive outcomes in terms of revenue, cost reduction, sustained competitive advantage, employee happiness, and innovation.

It doesn’t matter whether all of these outcomes are directly created by people who work in the IT department—in fact, that will likely never happen. The magic is in how people use technology, not in the technology itself.

Install a spreadsheet program or a business intelligence tool on the desktops of business users and it does nothing. These tools must be used creatively in order to drive value creation. IT value is not created by IT people alone, and that is precisely what IT leaders must care about—the value generated through the use of the technology.

IT cannot have an arms-length, contractor-control relationship with the rest of the business.

In an Agile and Lean world, IT is engaged in a voyage of discovery with the rest of the business, bringing its particular skills to bear as the enterprise works as a single unit to discover and implement ways of creating value. The business does not know what it needs, it does not know what the outcomes of its actions will be, and it faces risk and uncertainty.

IT plays an important part in driving the enterprise forward in the face of uncertainty.

There are good reasons to think that IT leaders might be very good at driving business outcomes. Martha Heller points out in The CIO Paradox that “CIOs have a bias for action. They respect deadlines and they want results. Their teams do too.” She also points out that the CIO is the only executive who sees business processes from beginning to end.

With this end-to-end understanding of the business, a discipline and mindset of accomplishing goals, and an inclination toward innovation and change, IT leaders bring a lot to the table when it comes to working together as a company to achieve business outcomes.

The new enterprise is a community in which IT plays an important part by enabling, guiding, and providing skills. Shadow IT is a manifestation of this community aspect of IT. That is fine; all that matters for IT leadership is IT outcomes.

Manager of Uncertainty

One reason, I would argue, that IT leaders have the skills to drive outcomes is because of their ability to deal sanely—that is, rationally and intuitively—with risk and uncertainty. While other executives might over-perceive risk in an initiative, IT can make sure that risk is managed down appropriately, and then make good decisions about when it is time to “launch.”

Companies face the uncertainties of the future—and IT leaders are experts at dealing with uncertainty.

Making good decisions under uncertainty has always been an important part of IT leadership. Should we build our systems in Java or .Net? Or perhaps in Node.js? This decision involves assessing the future of these platforms, their likely roadmaps, and whether or not there are likely to be programmers with the required skills in a few years.

Senior IT leaders have to assess the risk of deploying new systems and the extent to which these risks have been mitigated through testing. They must gauge the security risks of a system given the unknown activities of potential attackers. Risk and uncertainty are simply the day-to-day reality for IT leaders.

Agile and Lean thinking give IT powerful ways to manage uncertainty. By establishing short, robust feedback cycles and flexible decision-making processes, by creating options and grooming enterprise capabilities so that they will be responsive to change, and by demonstrating the value of information, IT can lead the organization in learning and in deriving business value from good risk management and from making the most of opportunities that present themselves.

That is good, because enterprises need not only to change quickly, but to anticipate the future and prepare themselves to participate in it, as well. Strategic planning requires skill in managing uncertainty, and IT manages the assets—EA, people, and data—that will determine how adept the company is at facing the future.

Steward of Assets

I have argued that senior IT leadership has the responsibility for stewarding three critical assets: the Enterprise Architecture (EA) asset, the IT people asset, and the data asset. These three assets represent the capabilities of the company and its ability to address the future.

EA is the collection of capabilities that lets the business do what it does; it is a map of the organization written in IT systems. The health of the EA asset determines the company’s agility and costs in the future. Because the EA is grounded in technology, only IT leadership can truly steward it; polishing and grooming this asset requires an understanding of technical debt, security risks, and architectures that will be enabling or constraining in the future.

Both the IT skills asset and the data asset are future-directed bearers of latent value that are critical to the company’s ability to earn future profits. Overseeing them falls naturally to IT leadership.

I have read that product owners or other “business folks” are capable of making decisions on things like security and technical debt—that they can prioritize stories to address these things—as long as the technical team explains them in terms of business value.

As I argued in The Art of Business Value, I do not believe that this is so; implicitly, it depends on the idea that there is a common currency of business value such that the product owner can compare the business value of the security story against the business value of a functional story and prioritize them rationally. But that common currency does not really exist, especially on the level where it can be used to compare individual features. Business value is a more nuanced topic than it first appears.

So, senior IT leaders guide the technical capabilities of the firm by overseeing the development and fine tuning of its EA, people, and data assets. Senior IT leaders must be stakeholders in generating and prioritizing investments; they should be the quickest to find the delta between the EA as it is now and the EA as it must be in the future. That delta, by definition, is the IT initiative that must be pursued.

Contributor

For decades, CIOs have been told to stop acting like technology geeks and begin acting more like business people. They have been told to speak the language of the business, to focus on profits and cost reduction.

I submit that this view is very closely tied to the idea that the CIO must control the technical geeks, and is an attitude primarily rooted in fear. Not that CIOs shouldn’t speak the language of the business—it is more that IT language has become a dialect of business language.

The non-IT parts of the business have been forced to learn about technology, about digital strategy, about the internet and its peculiarities. They are learning to speak the language of IT—which happens to be very expressive when talking about IT.

I have had no problem teaching my non-technical peers and managers to “speak geek.” They can sound convincing when relaying information about the cloud, email, servers, regression testing, automated deployments—and can ask good questions around these subjects.

So, what’s the problem? I’m not sure there is one.

The senior leadership team includes someone called the CFO, who helps lead the company from the point of view of someone who is an expert in finance; the CMO is someone who contributes expertise in marketing to running the company; the COO contributes expertise in operations as one of a group of leaders of the company. It follows that the CIO is the member of the senior leadership team—the team that oversees the entire enterprise—who contributes deep expertise in information technology.

I do mean to say deep expertise. Increasingly, everyone in the enterprise knows a lot about technology; the CIO, then, is the person who knows more than everyone else. The CIO should be more technical, not less—that is how he or she contributes to enterprise value creation; otherwise, the role would not be needed.

According to one of Martha Heller’s CIOs in The CIO Paradox, “IT is like a teenager living with his grandparents. He is changing every day, and they don’t understand him.” The CIO’s job is to bring this understanding to the organization.

Jim Highsmith makes an interesting prediction in Adaptive Leadership: “Product owners are the customers of today,” he says, “while technical and quality leaders are the customers of tomorrow.”

I wonder if he is thinking along the same lines as me. If IT strategy is really about stewarding the EA asset so that it is flexible, high-quality, and a good fit to business goals, then the stewards of that asset should be the “customers” for any work that advances the asset.

The more that we see the business as digital, the more we must acknowledge that it is technical to its core and the more the technical stewards of capability need to drive investment and capability definition.

Martha Heller’s CIOs seem to be coming around to this position, as well. “Lately, I am finding that CIOs are flexing their technologist muscles again,” she says.

If we drop the idea that the CIO’s job is to protect the organization from technology and technologists, we can instead rely on the CIO to administer doses of technology when needed, to change the business’s discourse to discussions informed by technology, and to sharpen the business’s ability to use technology to create competitive advantage.

Influencer and Salesperson

The CIO’s job is not just to manage the IT department—it is to be one of a team of senior leaders managing the entire business.

True, the CFO manages the finance department, but the CFO’s primary job is to steer the entire business with his skills in finance. The CMO manages the marketing organization, yes, but the C in CMO means that the CMO is really leading the entire enterprise in a way that is consistent with good marketing principles and his or her own marketing strategy. So, too, for the CIO.

The critical skill for someone who is leading an enterprise, only a portion of which is under his or her control, is the ability to manage through influence. The CIO needs to sell his or her ideas to the rest of the organization—to influence the use of technology in areas he or she does not directly control.

To do so, the CIO must build relationships with peers; understand the outcomes they desire; demonstrate how his or her ideas can help them achieve their outcomes; and explain, convince, and follow through.

This is very different from the treatment in most books about IT leadership, which often speak about how the CIO must communicate to other executive leaders how much value IT is contributing.

This, to me, is a horrible way of thinking—defensive and wasteful. The time, resources, and dollars the CIO is spending on that communication would be better spent on influencing the activities of the company.

What executive leadership wants is not fancy brochureware explaining all the good things IT is doing. What they want is for IT to be doing the good things. The CIO looks at business dynamics from the point of view of technology and contributes ideas based on this focus, negotiating, convincing, and compromising his or her way into making an impact.

Daniel Pink, whose book Drive has been very influential in the Agile community’s thought about motivating employees, has also written a book on selling called To Sell is Human. “People are now spending about 40 percent of their time at work engaged in non-sales selling—persuading, influencing, and convincing others in ways that don’t involve anyone making a purchase,” he says. This makes sense, he says, because “a world of flat organizations and tumultuous business conditions—and that’s our world—punishes fixed skills and prizes elastic ones.”

Flat organizations do not lend themselves to command-and-control, but rather to indirect influence through softer skills. Sales skills, though often unacknowledged in the technology world, are the key to managing in the community environment that has been the legacy of open source.

Orchestrator of Chaos

We have spoken of the business as a Complex Adaptive System. In a CAS, leaders lead through creating the conditions that help evolution select for the desired behaviors and outcomes. Senior IT leaders are important influencers of evolution in this sense.

The CIO has a number of tools at his or her disposal for encouraging evolution to proceed in a way consistent with the company’s desired outcomes. The CIO hires employees and trains them; organizes them into teams; and facilitates communication between those teams.

The CIO issues policies and standards where appropriate, makes governance decisions, distributes budget resources among teams, and delivers feedback.

He or she provides tools and sets up the environments in which teams work. All of these elements create a context for the teams—add the CIO’s articulation of a vision and adjustments of behavior through feedback, and we have a powerful set of mechanisms to guide the business’s evolution.

In his book Implementing Beyond Budgeting, Bjarte Bogsnes is not just concerned with the mechanics of a budgeting process, but also with the assumptions behind our approach to budgeting and its impact on the people in our organizations. The real problem Bogsnes sees in our budgeting approach is that it is used as a way of controlling people’s behavior.

But the sort of control provided by budgets is neither appropriate nor effective in the complex environment of a business organization. Instead, according to Bogsnes, “what we can do is to create the conditions needed for good performance to take place . . . . good leaders should create clarity, capability, and commitment.”

“With consumerization and cloud services, the role of IT moves from integrator to orchestrator, and orchestration is different because you no longer have direct control of all of the pieces,” says Ralph Lara, CIO of Clorox, as cited in Martha Heller’s The CIO Paradox, and he might as well have been talking about management in a CAS.

I began my book A Seat at the Table posing the question of how senior IT leadership can play a role in an environment of autonomous teams working directly with product owners from the business. The answer, I think, lies in this kind of leadership by influence.

In “The New New Product Development Game,” Takeuchi and Nonaka, the authors of the Harvard Business Review article that was an inspiration for the Agile community, say that “subtle control is also consistent with the self-organizing character of project teams.”

Craig Larman and Bas Vodde, in their book Scaling Lean and Agile Development, have this to say: “Self-organizing teams do not just happen, they need the right environment. The organization is responsible for supporting the team development by creating the conditions needed for teams to succeed. Switching to self-organizing teams means the job of the traditional project manager changes from directing the team to creating these conditions.^“

Not just the project manager, the authors might have said, but leadership in general.

The answer to my question is simply that IT leaders do not need direct “control” of the teams’ activities, because they lead indirectly—as do all of the executives with seats at the table.

Enabler

The control metaphor has extended to the way that IT systems interact with other human beings; or perhaps it is a reaction to the control dynamic imposed on IT.

Systems are built to compel behavior, and users are trained on how to use systems as directed. IT personnel channel users into particular ways of doing things; saying “no” is normal. Our systems give error messages when the users misbehave.

Of course, this makes a lot of work for IT folks—every time there is a new special case, we have to change the rules to allow it. Every time there is an exception to standards, there is paperwork involved in granting the exception.

Perhaps it is time for a new way of thinking about this reverse-­control dynamic.

What if the job of IT is to enable activities rather than to discourage them? If users are becoming more sophisticated consumers of IT, perhaps we should be putting the burden on them to do what is right with the tools we give them.

Business intelligence systems have been created on the basis of trying to enforce a single version of the truth—one set of reports that everyone can agree on. But today, that approach is fraying at the edges: in the days of data science and big data, it is important to let the people with real data skills explore freely; constraining them is value-destroying.

Yes, I know that we have constrained the use of our systems in order to preserve data integrity—we don’t want users to make mistakes that puts our data into a non-logical state. And so what? Is that really what matters most to us?

Perhaps, in many cases, we can allow more freedom because the price of non-logical data is low; or perhaps, in other cases, we can automatically correct errors. Remember that data is used mostly for analysis—transactions that create or update data are a smaller and smaller fraction of our database use. Freedom is powerful and motivating.

We have been afraid of “rogue” application development, or shadow IT. There has been good reason for that. Rogue applications are often unreliable and insecure; IT winds up having to fix them when they become mission critical. But are they always insecure and unreliable? Do they have to be?

If everyone is really becoming more tech savvy, might it not be a better idea to support and encourage rogue development?

I have tried giving sophisticated folks outside of IT programming environments with controls built in, and shared source code repositories. We have held hackathons where anyone can participate using those tools.

If a user wants to check out a piece of code, make changes to it, and then contribute those changes back to the IT team, who am I to tell them they can’t? Or, to put it another way, why would I accept that behavior if they report to me and not accept that behavior if they do not report to me?

If we treat IT and the business as a whole as a community, we can focus on enablement; it is the control paradigm that puts boundaries around what people can do. Those boundaries are wasteful, and we must drop them wherever they are not necessary. Risk there may be, but big is the benefit, as well.

Impediment Remover

The leadership model that seems to work best with Agile approaches is servant-leadership. The Agile team is committed and hands-on; they will tend to know best how to accomplish the objectives they are given. The best thing that a manager can do is to help the team do what it knows how to do by removing impediments. Tell the team what you need, let them do their work, and ask them how you can help.

There are many things that a senior manager can do more efficiently than the Agile team because of his or her organizational power; those things should quickly be brought to the manager’s attention, and the manager should deal with them immediately.

Autonomous teams need to interact, and senior leadership sets the context in which that interaction takes place. Is it encouraged? Do teams feel comfortable asking one another for help? Are direct interactions allowed, or must communication go through a Scrum Master or a bug-tracking system? Senior leadership can reduce the friction that causes wasted energy and that slows the release train.

Commitment to reducing cycle time means that everyone—teams and leaders alike—are engaged in reducing it by doing whatever is necessary. Leaders have powers that the teams lack—often the impediments slowing cycle time can only be removed by those in power.

Leadership influence, you might say, is an important asset the team has in doing its job. The leader’s contribution to the IT community is his or her use of power for the common good.

Manager of Managers

The old span-of-control model for middle management makes less sense in an Agile world of empowered teams. But what of command and control? Does it disappear entirely in the Agile world?

I’m not sure, to be honest.

While the Agile community speaks of the need for cultural change across the enterprise, I’m not sure that it recognizes its own cultural biases and the impact they have on the success of Agile transformations.

Even just the words “command and control” bring on a strong negative reaction in many. In my experience, this dislike lasts right up until the moment that the team faces a tough impediment—then they would like management to order the impediment to go away—or until some of the developers are not following good technical practices. Perhaps they are breaking the build and not fixing it immediately, or perhaps they aren’t writing enough unit tests. At some point, the team relies on management to fix the problem.

Of course, coercive behavior by management feels wrong on many levels, and is not a good cultural fit with Agile processes, which bring their own value system. Orthodox Agile practice, I think, would advocate working with those who are “disobeying” the “rules” of good technical practice; perhaps helping them to conduct experiments that will show them why writing more unit tests is a better idea, and maybe incentivizing the impediment-inserters to stop inserting those impediments.

These approaches have value, but they also might work against the effort to be Lean. On one hand, we want to encourage self-organization and self-governance; on the other, we want to forcefully and quickly remove impediments.

Perhaps removal of impediments is so important—really, it is a key to the empowerment of the team—that the faster it happens the better, and the fastest way is often through a touch of command and control.

In a sense, it doesn’t matter whether impediments are removed through management’s coercive authority—its ability to compel behaviors—or through gentler means. What matters, arguably, in an Agile process is that the team is not commanded and controlled in its ability to find a solution to the business problem at hand.

Underlying the Agile way of thinking is a vision of what it looks like when a development project is running perfectly. You have a small team of high-energy, smart software engineers who respect each other and enjoy each other’s company. They bounce ideas around and help each other find solutions. Each comes up with great ideas that make the others think of more great ideas. Before someone can finish stating a challenge they are having, someone else has already come up with—and coded—a solution to it. Stuff keeps getting done, and users keep smiling and telling the developers how brilliant they are.

Then come the template zombies. Progress halts while somebody fills out the paperwork that will allow the system to go to production. Management has brilliant ideas based on what a salesman told them and wants the team to explain why it hasn’t created the shmurf feature and why they haven’t dealt with the scary security issue that the security company told them about. Let’s face it: management is waste. They don’t code.

When a team is really working, all management can do is get in the way and reduce business value.

Agile concepts were created by working developers who know what real productivity looks like, and they rightly want to set up a way of working that leads to that state. Agile approaches are a brilliant way to work toward what the developers know actually works. But when things aren’t working so perfectly, management needs to use its powers to clear away all of the impediments that prevent the team from getting into that productive flow.

As long as a team has boundaries, there will be decisions that need to be made from outside its boundaries, and people who need to be—er, um, “influenced”—on the outside.

The team should have the primary responsibility for exercising that influence and for framing those decisions. And the team requires empowerment—that is, freedom from command and control—within its solutioning boundaries, but the effort of coordinating the activities of different teams, other actors, and other parts of the business still requires some sort of management.

IT Leaders Drive Outcomes for the Business

In an Agile world, IT leaders are not leading a customer service organization or a contractor that delivers product in response to requirements. Rather, IT leaders are driving outcomes for the business through the enterprise’s digital way of being in the world.* That way of being is based on harnessing the power of bits—their infinite flexibility, their ability to create options and to drive and encapsulate learning, the fact that changing some ones to zeros can make a Google out of an AltaVista.

Software is thought recorded in ones and zeros, and thought is as flexible as human creativity.

IT leadership is about participating in the decision of what sequence of ones and zeros is the business’s strategy, and then arranging the ones and zeros in that order. Richard Hunter and George Westerman say: “We can sum up this paradigm change as rule number 1: it’s not about IT. It’s all about business.”

Indeed it is—and the business is all about IT now.

- About The Authors

Mark Schwartz

Mark Schwartz is an iconoclastic CIO and a playful crafter of ideas, an inveterate purveyor of lucubratory prose. He has been an IT leader in organizations small and large, public, private, and nonprofit. As an Enterprise Strategist for Amazon Web Services, he uses his CIO experience to bring strategies to enterprises or enterprises to strategies, and bring both to the cloud. As the CIO of US Citizenship and Immigration Services, he provoked the federal government into adopting Agile and DevOps practices. He is pretty sure that when he was the CIO of Intrax Cultural Exchange he was the first person ever to use business intelligence and supply chain analytics to place au pairs with the right host families. Mark speaks frequently on innovation, bureaucratic implications of DevOps, and using Agile processes in low-trust environments. With a BS in computer science from Yale, a master’s in philosophy from Yale, and an MBA from Wharton, Mark is either an expert on the business value of IT or else he just thinks about it a lot.

Follow Mark on Social Media

• 
•