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.
[Dive deeper on DevOps leadership, culture, and metrics. See our related article, 10 DevOps must-reads.]
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.
Comments
Great article, but not far enough. Your statement, "the role of IT [is] to provide requirements to the rest of the business as it used to be the role of IT to accept requirements," sums it up. Maybe in the 19th century capitalists might have had something to offer the human race. Today's political and business leaders are engaged in a giant rent seeking circle j**k. Devops is about how humans are going to emerge from the paradigm of "it's who you know, not what you know", to the more useful model of letting smart people make decisions. Programmers must rise up and rule the world, because no one else can handle it.
In regards to "programmers ruling the world because no one else can handle it"; I worked in a greenfields product development environment that was run by very talented programmers without formal enterprise, governance, or risk mitigation plans and they built a terrific product using agile methodologies and the hottest open source products available. In less than 2 years that product had to be rewritten from scratch because the developers departed and left the business owner with a programming language that was largely abandoned by the open source community for the next hottest project, a mish mash of architectures, and no concern for other risks. Obviously, a very expensive ordeal.
We all play a valuable role and can produce kick-@ss solutions if we respect what we all bring to the table and work together for common business goals.
"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."
Well, a couple of items are implied here..."rightly understood" means across the entirety of an organization, not just IT...my guess when you mention DevOps outside of IT...read cross-functional teams...eyes still glaze over and the impression left is IT is trying another 'new' thing.
The challenge is empowering the entirety of a cross-functional team to define its strategy, objectives and execution paths...meaning the cross-functional team is a 'function' supported by all the necessary skill sets...Marketing, Sales, IT, Back-office as if it was it's own small company...think of the paradigm of a start-up...everyone is focused on one and the same mission.
Indeed, a tactical relationship is needed between business and IT. The old model of "IT as a service" does not work anymore - it is too slow, and too compartmentalized.
interesting article
I think you missed one overarching concern of the CIO and that is cost.
For example, regarding buy vs build; There is no doubt that the likelihood of meeting every requirement is greater with build vs buy but not every firms can afford perfection. Sometimes meeting~80% of the most critical business requirements, is more valuable to the bottom line than a perfect solution. I have seen analyst numbers that the TCO over the life of the custom built application is anywhere from 2 to 5+ times greater than the COTS alternative, depending on complexity, life of the application, etc, which bring the ROI into unacceptable ranges including the the negative.