You’ve probably heard of You Build It You Run It before. It’s an operating model that empowers product teams to own every aspect of digital service management.

When done well, it accelerates your time to market, increases your service reliability, and grows a learning culture. There are also some pitfalls, which can drain the confidence of your senior leadership, and ultimately put the success of You Build It You Run It at risk.

Today I would like to focus on one of the pitfalls that often stops projects from getting off the ground. The run cost pitfall. This is part of our recent You Build It You Run It playbook, we take a deeper look at the risk of on-call costs becoming uncontrollable, and how you can guard against it, and even escape it.

If you’re in a hurry, our ways to minimise run costs are:

1. Understand an operating model is multi-cost insurance for business outcomes
2. Make product team budget holders accountable for business outcomes
3. Fund on-call costs from product team budgets
4. Select availability targets on financial exposure
5. Select out of hours schedules on financial exposure

The run cost pitfall

If you work in a large enterprise organisation, you’re probably familiar with the traditional IT operating model. You’ll have a multi-level support hierarchy, with an L1 operations bridge team for monitoring, and an L2 application support team for incident response. Each day, an application support analyst is on-call out of hours.  

The names of these teams change, but the operating model doesn’t. It’s so ubiquitous, it doesn’t really have a name of its own! In our playbook, we call it Ops Run It. 

This operating model has a clear benefit in run cost management, due to:

• Low on-call standby costs. You can have one application support analyst on-call for all your software services.
• Low team costs. You can outsource your operations bridge and application support teams to a third-party managed service.
• Predictable forecasting. You can confidently estimate on-call costs a year in advance. 

I’ll bet your Head of Operations likes this benefit, as they’ll be responsible for run costs in a strained opex budget. Bethan and I believe it justifies this operating model for foundational systems such as self-hosted COTS and back-office applications. 

You can see from this diagram, You Build It You Run It is a superior choice for digital services. It can achieve the throughput, reliability, and learning outcomes you need to sustain innovation.

However, your senior leadership may have a perception that You Build It You Run It is too expensive. It’s understandable. Four developers on L1 on-call for four services doesn’t seem to make financial sense, does it? Especially not when compared with one L2 on-call application support analyst for four services. And what if you have 10 teams and 20 digital services? 

Bethan and I call this the run cost pitfall – allowing run cost to increase every time you have a new product team on-call for a new digital service. Now, it’s important to pay developers for L1 on-call in You Build It You Run It, to recognise the inconvenience of out-of-hours support, and we’ve got some advice on transparent, fair remuneration but that doesn’t mean a high run cost is inevitable at scale. 

Here are five ways to mitigate run costs, without sacrificing on-call compensation or operability incentives for your product teams. 

1 – Understand an operating model is multi-cost insurance for business outcomes

Ensure there’s a broad understanding across your organisation that an operating model is an insurance policy. One which protects your business outcomes in exchange for a multi-cost premium. 

Different insurance policies offer different levels of protection, at different premiums. And we all understand that the more valuable the contents of your home, the higher the premium you pay for your house insurance. See operating models are insurance for business outcomes.

The multi-cost premium for an operating model is:

You Build It You Run It produces a similar run cost to an application support team. Setup cost is still a concern, but that’s offset by lower transition, incident, and opportunity costs. Here’s a diagram of our relative cost estimates.

2 – Make product team budget holders accountable for business outcomes

Make the budget holder for a digital service accountable for deployment throughput, service reliability, and learning culture. That’ll be your Head of Product if team funding comes from a product budget, or your Head of Delivery if funding is from an IT budget. This encourages product teams to find the right balance between product features, operational features, and engineering effort. 

Your Head of Operations has to transfer accountability for the reliability of all digital services onto product team budget holders. In my experience, operability incentives are maximised for a product team when they are held to account for reliability. For more on this, see make product team budget holders accountable for business outcomes.

3 – Fund on-call costs from product team budgets

Pay on-call costs from product team budgets. This incentivises product team budget holders to choose availability targets that balance business outcomes insurance with run costs. It also allows them to prioritise the protection of live product functionality alongside the delivery of new product features. And, it ensures that graceful degradation and adaptability are part of the customer experience. 

Your Head of Operations transfers on-call funding for digital services from their opex budget into the distinct capex budgets owned by product team budget holders. This won’t be easy, it won’t be popular, and you need to do it. Good things happen when you empower product teams to incorporate funding choices into their decision making. For more detail, see fund on-call costs from product team budgets. 

4 – Select an availability target on financial exposure

Ensure a product team budget holder selects an availability target for their digital service, based on its financial exposure. That’s the maximum revenue loss and operational costs per hour that could be incurred upon failure. This encourages a product team budget holder to translate business goals into operability objectives, and build operability in from the outset.

Selecting availability targets and deployment targets for different software services is often a dark art. It doesn’t have to be that way. See How to decide when to use You Build It You Run It – and when not to use it for a step-by-step guide on how to estimate financial exposure, and consequently select a matching availability target. 

5 – Select out of hours schedules on financial exposure

Our fifth and final way to minimise your run costs is to link availability targets to different types of on-call schedules out of hours, based on financial exposure. This achieves a balance between the cost of failure, on-call costs, and remuneration for on-call developers without weakening operability incentives.

You Build It You Run It protects business outcomes. It doesn’t mean every digital service needs 24×7 on-call support. During working hours, every product team has its own on-call schedule. Out of hours, it’s a different story. 

Here’s what You Build It You Run It might look like in your organisation, if you’ve got multiple product teams owning digital services with varying levels of financial exposure. 

To find out more, you can continue our You Build It You Run It pitfalls series:

1. 1. 7 pitfalls to avoid with You Build It You Run It
   2. 5 ways to minimise your run costs with You Build It You Run It – you are here!
   3. Why your operations manager shouldn’t be accountable for digital reliability 
   4. How to manage BAU in product teams 
   5. 4 ways to remove the treacle in change management 
   6. Why product teams still need major incident management
   7. Stop trying to embed specialists in every product team 
   8. How to avoid developer burnout on call

Our You Build It You Run It page has loads of resources on on-call product teams – case studies, conference talks, in-depth articles, and more. Plus our You Build It You Run It playbook gives you a deep dive into how to make it happen! Get in touch, and let us know what you think.