Originally sourced from techbeacon.com. Expanded and rewritten for a DevOps engineering audience.
The Squeeze: Speed vs. Stability
DevOps practices and digital transformation initiatives have dramatically increased the pace and volume of change flowing through IT environments. While development and product teams celebrate faster release cycles, IT operations management faces a more uncomfortable reality: an already stretched workforce is being asked to absorb a relentless increase in both planned and unplanned work.
IT Ops sits at the intersection of two conflicting mandates. On one side: “Go faster. Deploy more. Ship now.” On the other: “Don’t be the next breach. Don’t cause the next outage. Slow down and be careful.” Caught between these pressures, operations teams face a labor capacity crunch that, left unaddressed, will undermine both service reliability and business agility.
Since neither pressure shows signs of easing, IT operations must fundamentally rethink how it handles both planned and unplanned work. One proven approach is a design pattern called self-service operations.
Unplanned Work Is the Real Capacity Killer
DevOps and agile methodologies provide strong guidance for managing an increased volume of planned work. But IT operations teams struggle most with the growing load of unplanned work: outages, performance degradations, security incidents, unexpected traffic spikes, and other interruptions that arrive without warning.
Unplanned work and planned work mix poorly. Every time an incident interrupts a planned project, engineers pay a significant context-switching cost. The project stalls, the incident consumes attention, and then the engineer must mentally rebuild the context they lost before they can resume productive work. Multiply this across a team and across dozens of incidents per week, and the impact is severe.
Unplanned work also creates cascading ripple effects:
- Escalation chains: A Level 1 team cannot resolve an issue and escalates to Level 2, who escalates to Level 3. Each handoff consumes time and pulls specialists away from other work.
- Schedule slippage compounds: Outage A delays Project A. Project B depended on a deliverable from Project A. Project C needs people from Project B. A single incident can create a chain of delays that spans weeks or months.
IT Ops cannot eliminate unplanned work entirely, but it can limit the damage that unplanned work inflicts on capacity and schedules. The first step is examining how operational support is currently structured.
Two Dominant Models for Operations Support
Most unplanned work originates from operational support tasks generated during and after application deployments. Two competing models exist for handling this support work, each with significant trade-offs.
Model 1: “You Build It, They Run It”
This is the traditional enterprise model. Development and delivery teams build software and hand it off to a separate operations team that is responsible for running, maintaining, and supporting it in production.
Advantages:
- Aligns well with project-based funding models common in large enterprises.
- Allows expensive developers to move on to new projects once delivery is complete.
- Operations specialists can develop deep expertise across the production environment.
Disadvantages:
- Handoffs between delivery and operations teams are a common source of errors and lost context.
- Developers who “handed off” a system frequently get pulled back into production incidents anyway, defeating the purpose of the separation.
- Operations teams inherit systems they did not build, leading to steep learning curves and slower incident resolution.
Model 2: “You Build It, You Run It”
This newer model, popularized by organizations like Amazon and Netflix, gives fully cross-functional product teams end-to-end ownership of a service—from development through deployment and production operations.
Advantages:
- No knowledge loss at handoff boundaries: the team that built the system is also the team that fixes it.
- Tighter feedback loops lead to higher quality and faster iteration.
- Teams operate at high velocity with minimal interruption from external escalations.
Disadvantages:
- Requires significant structural and funding changes that most large enterprises cannot easily make.
- As the number of services grows, or as legacy dependencies accumulate, dedicated teams can become overloaded and the model breaks down.
- Difficult to sustain alongside a traditional project-based funding model.
Amazon and Netflix are frequently cited as organizations that restructured their entire businesses to support “You build it, you run it.” Most enterprises are not in a position to replicate that transformation. A blended approach is more practical — and that is where self-service operations becomes essential.
The Blended Model: Self-Service Operations
Self-service operations is a design pattern that captures the labor-scaling benefits of “You build it, they run it” while preserving the responsiveness and control of “You build it, you run it.” The core idea is to divide and distribute the essential components of an automated operations procedure across the teams best suited to each role:
- Definition: Who creates and maintains the automated procedure.
- Execution: Who is authorized to run the procedure.
- Governance: Who controls the security policies, access controls, and environments in which the procedure can operate.
In practice, this split enables workflows such as the following: a development team defines a restart procedure for their application; the IT operations group reviews and vets that procedure; the security team controls which environments the procedure can target and which personnel are authorized to trigger it. Each group contributes its expertise without creating bottlenecks or bypassing controls.
Four Key Benefits of Self-Service Operations
1. Improve the Capacity of Operations Support Teams
Operations support teams can codify standard operating procedures (SOPs) for known problems and predictable events — application restarts, cache flushes, certificate rotations, log collection, and similar routine tasks. Storing these in a shared, version-controlled repository means that any authorized team member can execute a vetted procedure without needing to consult a specialist or write a new script from scratch.
This approach reduces manual effort and, crucially, reduces variability. Inconsistent manual execution of operational tasks is a leading cause of errors and rework. Automating and standardizing the procedure eliminates that variability at the source.
2. Free Specialists to Focus on High-Value Work
In most organizations, a small number of key engineers are pulled into a disproportionate share of incidents. These specialists become bottlenecks: their availability gates resolution of a wide range of issues, and their project work is constantly interrupted by escalations.
Self-service operations addresses this directly. By capturing specialist knowledge as reusable, shareable automated procedures, that knowledge can be safely delegated to a broader set of people. Level 1 and Level 2 support teams handle more incidents on their own. Escalations decrease. Specialists remain available for the complex, novel problems that genuinely require their expertise — and for the project work that moves the business forward.
3. Enable Safe, Governed Delegation of Operational Tasks
Self-service operations makes it possible to extend operational capabilities to teams that traditionally could not — or were not permitted to — perform operations work. Developers can run approved deployment procedures. QA engineers can trigger environment resets. On-call engineers can execute pre-approved incident response runbooks without waiting for an operations specialist to become available.
The critical distinction from simply giving everyone elevated access is that self-service operations maintains governance. Procedures are pre-vetted. Access controls are enforced. Audit logs are generated. Security and compliance requirements are satisfied. Teams move faster without compromising the control and reliability expected of a production environment.
4. Reduce the Cost of Knowledge Transfer Between Teams
Handoffs between delivery and operations teams are a persistent source of friction in enterprise IT. Manually documented runbooks are frequently out of date, ambiguous, or simply incomplete. The receiving team has to spend significant time deciphering and validating procedures before they can use them safely.
Self-service operations changes the nature of the handoff. Instead of transferring a document, the delivery team transfers tested, executable automation. The receiving operations team can run the procedure, observe its behavior, and validate it in a controlled environment before it is needed in production. This eliminates much of the ambiguity and error-prone interpretation associated with traditional manual handoffs, and dramatically reduces the time required to bring a new team up to speed on how to operate a service.
Tactical and Strategic Advantages
Adopting the self-service operations design pattern delivers value at two levels:
Tactical: It provides immediate relief from the capacity crunch. Fewer escalations, faster incident resolution, reduced context-switching, and more capacity for planned project work — all without adding headcount.
Strategic: Over time, self-service operations builds a more flexible and resilient organization. Teams that can act independently on a wider range of operational tasks are more responsive to business needs. Knowledge is captured in durable, reusable artifacts rather than locked in the heads of a few key individuals. The organization becomes less fragile to staff turnover, reorganizations, and growth in system complexity.
Self-service operations is not a silver bullet, and it requires investment in tooling, process design, and governance frameworks to implement well. But as a design pattern for managing the tension between speed and stability in modern IT environments, it belongs in every IT leader’s operational toolkit.
Key Takeaways
- Unplanned work — not planned work — is the primary driver of IT Ops capacity problems. Address it directly.
- Neither “You build it, they run it” nor “You build it, you run it” is sufficient on its own for most enterprises.
- Self-service operations separates the definition, execution, and governance of automated procedures, allowing each to be owned by the team best suited to it.
- The pattern reduces escalations, protects specialist capacity, enables safe delegation, and improves knowledge transfer.
- Governance and access control are built into the model — speed and safety are not mutually exclusive.