Is Outsourced Operations a DevOps Anti-Pattern?

In theory, outsourcing offers many benefits, from labor elasticity to economies of scale. It has the potential to release more management time and mindshare for the things that matter — things that contribute to customer value or competitive advantage.

Yet the large scale functional outsourcing of IT services in previous decades often failed to deliver ROI. And for some, the reputation of any IT outsourcing remains tarnished by association.

Conversely, few modern businesses would question the benefits of using cloud computing. Letting a hyper-scale cloud provider handle the heavy lifting associated with traditional IT infrastructure and operations is standard practice these days.

So, why are some technology leaders reluctant to work with third parties for the remaining management overhead, even when using a cloud-based infrastructure? Is all outsourcing inherently flawed, or can outsourced operations management be effective when combined with modern ways of working? In short, is it possible for a business to embrace DevOps principles to unlock those theoretical benefits of outsourcing without creating additional problems?

To answer these questions, it’s worth clarifying what we mean by DevOps and looking more closely at the challenges associated with outsourcing.

DevOps defined

DevOps is a response to the weaknesses of traditional operational models optimized according to the role and characterized by technological silos. It draws on Agile, Lean, and systems thinking to create a new model optimizing the flow of value to customers. Some people have the misconception that DevOps inherently requires Dev and Ops people to work on the same team. This is a very effective way of bringing together the two factions from a traditional IT organization. But ‘you build it, you run it’ teams come with their own challenges and it’s certainly not the only organizational topology that can support effective DevOps. See Matthew Skelton’s DevOps Topologies for more insights.

It is also possible to implement highly effective DevOps practices while running separate infrastructure and operations teams. This is clearly evident in Site Reliability Engineering (SRE) where software engineering principles are applied to IT operations in a forward-thinking operating model. You don’t need to be the size of Google to make it work either.

Challenges with outsourcing

Accelerate: the State of DevOps links functional outsourcing with what the report’s authors consider to be ‘low performance’. This is critical because the low performers are negatively correlated with factors related to organizational success, such as growth, profitability, and market share. However, the report highlights that these findings relate specifically to functional outsourcing. And that other forms of outsourcing don’t show the same low-performance correlation. So where exactly does traditional functional outsourcing fall down?

Seven sins of functional outsourcing:

1. Functional outsourcing creates silos (and, to quote Rundeck co-founder Damon Edwards, silos ruin everything).
2. Handoffs — every time we hand over from one group to another, we lose information and context. That’s an inescapable fact of human communication. Lost information leads to defects, lower quality, and waste.
3. Handoffs also result in queues, which mean more waiting and more waste.
4. Batching of work — handoffs and queues result in larger batches of work, which means longer lead times and increased cost of delay. This is compounded by the high transactional cost of taking work from one silo to another: people are incentivized to batch work to reduce costs. So high-value and low-value features get lumped together, and all work — whether high or low value — is delivered at the same (sluggish) pace.
5. Silos optimize locally, focussing on the goal of the silo (like ‘100% uptime’, or ‘ship more features faster’, to choose extreme examples). This can ignore the goal of the system (happy customers who spend more money).
6. Friction and blame — local optimization for local goals, the inevitable defects arising from handoffs, and delays caused by queues and large batch sizes reduce trust between functional groups. Low trust environments tend to give rise to more rigid contract structures and greater scrutiny. This adds further overhead and contributes to spiraling costs, delays, and inflexibility.
7. Lack of contractual flexibility — the functional division of responsibilities can also inhibit agility. Once contracts have been signed, changes to specifications are difficult to manage across external silos.

Functional alignment vs product alignment

Many of the above issues aren’t a direct result of outsourcing; they’re related to functional alignment. Aligning IT by function — Dev, Test, QA, Infrastructure and Ops — inevitably brings challenges like these, whether the work is handled internally or externally. Outsourcing just exacerbates the problems with this operating model.

Today, progressive organizations generally opt for cross-functional, multiskilled, product-centric teams. Each team is as self-sufficient and autonomous as possible. Dependencies on other teams are kept to a minimum and they pretty much handle the entire product lifecycle. By reducing handoffs and keeping work in one place, the negative impact of silos is greatly reduced: everyone is focused on the same objectives and target outcomes.

If you can maintain all the capabilities needed to build and run everything customers demand within a sustainable team of seven plus or minus two people, then this is probably the way to go.

But this is rarely possible.

Smaller businesses often need specialist skills beyond those that can feasibly be maintained in-house. In fact, hiring specialists too early is a sign of premature scaling, which results in business failure for 70 percent of scale-ups. What’s more, many businesses need flexible capacity and don’t have a permanent requirement for Kubernetes architects, for example.

Larger businesses will inevitably need more than nine people, which means multiple teams. With teams aligned to products, rather than functions or projects, handoffs can be minimized to improve effectiveness. But once you move beyond a handful of product teams, the dynamics change, and new challenges emerge. This is the time to think about introducing advanced capabilities such as self-service platforms (to avoid repetition between teams) and SRE (to protect teams from unplanned work). We cover these areas in more detail in a separate blog about cloud operating models.

So, is outsourced operations a DevOps anti-pattern?

This is a good question, that any rational technology leader should ask before taking the plunge. But it’s worth remembering that partnering with a third-party specialist is not synonymous with functional outsourcing. Especially when the partner is a digital-native organization that understands modern operations and DevOps principles. You also need to consider the damaging repercussions of inexpert operations management, such as development teams having to handle unplanned work.

Sophisticated, modern operations management that’s fit to support the business-critical applications of technology companies demands a specialist skillset. And if you can’t hire it, or don’t want to hire it yet, partnering with a digital-native operations expert is the best way forward.