This article is based on ideas originally published by enterprisersproject.com, drawing on themes from the book A Seat at the Table: IT Leadership in the Age of Agility.
DevOps Is a Leadership Challenge, Not Just a Delivery Model
Many IT leaders treat DevOps and agile practices as a better way to run software projects — faster sprints, shorter release cycles, automated pipelines. While all of that is true, viewing DevOps through this narrow lens misses the point. DevOps represents a fundamentally different way of thinking about IT, and it demands a fundamentally different leadership model.
The traditional IT organization was built around control: controlling project delivery, managing handoffs between IT and the business, and enforcing gates at every stage of development. DevOps replaces that model with cross-functional collaboration, shared accountability, and continuous feedback. For IT leaders — particularly CIOs — the implications go well beyond tooling or process. Four of the most entrenched concerns in IT leadership get turned upside down.
Four Core IT Concerns Through a DevOps Lens
1. Build vs. Buy
Conventional IT wisdom says: buy off the shelf whenever possible, build only when no suitable product exists. This logic made sense in a world of long procurement cycles and even longer development timelines. In a DevOps context, the calculation changes. Building a capability in-house can enable a user-centric, fast-feedback, incremental delivery process — one that continuously adapts to real user behavior rather than locking in assumptions made during a requirements phase. The right answer is not always “buy”; the right question is which approach best enables continuous learning and rapid iteration.
2. Enterprise Architecture
Traditional Enterprise Architecture (EA) functions as a standards body: defining approved technologies, constraining team choices, and enforcing consistency across the organization. In an agile, DevOps organization, architecture is no longer handed down from above — it evolves through the work of empowered teams. This does not mean EA becomes irrelevant. It means EA must shift from a policing role to an enabling one: facilitating reuse, identifying patterns that emerge from team work, and guiding the organization toward a flexible, evolvable architecture rather than a rigid blueprint.
3. Governance
Most IT governance frameworks operate at the granularity of projects or programs: approve a project, fund it, track it to completion, close it. But DevOps enables teams to work in single-piece flow — essentially delivering and learning one increment at a time. At that level of granularity, the project construct starts to break down. When development and ongoing maintenance become indistinguishable, what does it mean to “complete” an initiative? Governance must evolve from a formal approval process into an active, ongoing discipline — one focused on generating and steering initiatives toward specific business outcomes rather than simply approving or prioritizing proposals.
4. Risk Management
IT has historically treated risk as something to be eliminated or, at minimum, mitigated. DevOps does not eliminate risk — it makes risk visible and manageable through fast feedback loops and small, reversible changes. The more productive framing is to treat risk as something to be deliberately accepted and acknowledged, with the goal of earning a risk-based return. This is how product organizations and startups think about risk. It should be how technology leaders think about it too. The CIO’s job is not to avoid risk but to actively determine the appropriate level of risk and pursue it with confidence.
What This Means for IT Leadership
Each of these four shifts points to the same underlying change: IT leaders can no longer be passive recipients of business requirements. They must take active responsibility for business outcomes.
- From order-taker to co-owner: Rather than accepting requirements from the business and delivering against them, IT leaders must participate in defining what the business should be trying to achieve in the first place.
- From service provider to strategic partner: The CIO’s goal is no longer to provide excellent customer service to internal stakeholders. It is to work alongside other parts of the business to accomplish shared objectives.
- From risk avoider to risk manager: Instead of minimizing all risk, the CIO should determine what level of risk is appropriate given the organization’s strategic goals and actively target that level.
- From project governor to outcome driver: Governance becomes a proactive, generative process — identifying and launching initiatives that advance business goals — rather than a reactive approval gate.
Cross-Functional Teams and the Journey of Discovery
DevOps, understood properly, is an approach in which cross-functional teams use fast-feedback loops and continuous adjustment to accomplish organizational goals. Technical staff are not a separate function that receives specifications and produces output — they are members of a business team engaged in a shared journey of discovery, testing hypotheses and adapting based on what they learn.
This changes the nature of accountability. Teams can be given ownership of an outcome — improve customer retention, reduce onboarding friction, increase transaction throughput — rather than a fixed set of requirements and a hard deadline. They can experiment, measure, and iterate. They share accountability for results, not just delivery.
The Outdated IT Mental Model
The idea that IT is merely responsible for delivering what the business says it wants is increasingly outdated. In a digital-first organization, technology is not a support function — it is a primary means of creating and delivering value. That repositioning has real consequences for how IT leadership must think and behave.
It is not far-fetched to suggest that in a mature DevOps organization, IT should be as likely to generate requirements for the rest of the business — surfacing data insights, identifying technical opportunities, proposing product changes — as it is to receive requirements from it. That is a significant shift in posture, and it requires CIOs who are willing to step up, engage at a strategic level, and take genuine accountability for driving corporate outcomes.
Key Takeaways
- DevOps is not just a delivery methodology — it requires a new leadership model for CIOs and IT leaders.
- Build-vs-buy, enterprise architecture, governance, and risk management all need to be rethought in a DevOps context.
- Cross-functional teams with shared accountability for outcomes replace siloed handoffs between IT and the business.
- IT leaders must shift from passive service providers to active drivers of business outcomes.
- Risk should be managed deliberately to earn a return, not simply minimized.
- Governance should generate and steer business initiatives, not just approve project proposals.