DevOps requires dumping old IT leadership ideas

Source – enterprisersproject.com

Some IT leaders see DevOps and agile practices simply as a way to run their software projects. If you look at DevOps in this narrow way, you miss the deep implications for the way IT should be managed and led. Make no mistake: DevOps represents a different way of thinking about IT – and requires a different leadership model.

As noted in my new book A Seat at the Table: IT Leadership in the Age of Agility, four big concerns of the CIO—governance, risk management, build versus buy decisions, and enterprise architecture, get turned upside down in the DevOps and agile world. While the waterfall development world was about IT control of project delivery, the DevOps world is about collaboration across the business organization to achieve business objectives, using cross-functional teams with both business and technology skills.

Rather than passing requirements and product back and forth between IT and the rest of the business, these teams can take ownership of strategic goals and work together to accomplish them, sharing accountability for outcomes. They can try out different approaches, test hypotheses, and innovate new ways of doing things. DevOps makes it possible for teams to try experiments and quickly receive feedback, and to mold their plans based on actual results. The team can be charged with an outcome rather than given a set of requirements and a deadline.

When you look at typical CIO concerns through an DevOps lens, you find that many of them appear upside down – and require new thinking. Consider these four examples:

• Build versus buy: The conventional wisdom says that buying off the shelf is preferred when possible. But in many cases, building will allow for a more user-centric, fast-feedback, incremental delivery process.
• Enterprise architecture: The traditional role of Enterprise Architecture is to standardize and constrain. But in an agile world, where architectures evolve through the work of empowered teams, EA should play a hands-on role, facilitating reuse and guiding the enterprise to a flexible, agile architecture.
• Governance: Companies often make governance decisions at the granularity of projects or programs. But now that we can execute at the level of single piece flow – essentially fulfilling one requirement at a time – are programs and projects still the right granularity for governance decisions? And when development and maintenance can no longer be clearly distinguished, what does it mean to “complete” an initiative?
• Risk: We have always thought of risk as something to be eliminated, or at least mitigated. Is it perhaps more productive to think of it as something that is to be accepted and acknowledged, with an eye toward earning a risk-based return?

The consequences of agile and DevOps thinking for IT leadership are significant. IT leaders can no longer be passive recipients of business requirements, but instead must take responsibility for business outcomes.

Governance is no longer just a formal process of approving or prioritizing project proposals, but an active process of generating initiatives to accomplish specific business goals. Providing customer service to the business is no longer the CIO’s goal, but rather working with other parts of the business to accomplish objectives. Instead of focusing on reducing risk of project delivery and production outages, the CIO should actively determine the appropriate level of risk and boldly target that level. It is not farfetched to think that in a digital world, it is as much the role of IT to provide requirements to the rest of the business as it used to be the role of IT to accept requirements.

DevOps, rightly understood, is an approach where cross-functional teams use a process that harnesses fast-feedback loops and constant adjustment to accomplish the company’s goals. For IT leadership, this means that the technical folks are part of a business team, a team that is together on a journey of discovery, trying to find the best ways to meet business needs. The idea that IT is merely responsible for “delivering” what the business says it wants or needs is an outdated one. Instead, the CIO must step up, and courageously take responsibility for driving corporate outcomes.