How to decide when to use You Build It You Run It (and when not to use it)

You Build It You Run It is an operating model that empowers product teams to manage every aspect of digital services. It accelerates time to market, increases service reliability, and grows a learning culture.

But it’s not universally applicable, and there’s still an important role for your operations teams. This is why it’s important to understand whether You Build It You Run It is right for your team, and your business outcomes, before you make any major operational decisions.

In our recent You Build It You Run It playbook, Bethan Timmins and I provide an in-depth description of how to make this decision. We look at whether you should use You Build It You Run It, or have a separate operations team for your software services. We’ve evaluated this for our clients many times.

We think of You Build It You Run It as a hybrid operating model. We agree with Martin Fowler that a software service is a strategic differentiator or a utility, based on its business function. We distinguish between digital services (customer-facing microservices or applications), and foundational systems (self-hosted COTS and custom back office applications).

Our criteria for selecting You Build It You Run It or an operations team are:

• Financial exposure on failure. How much money could you lose if the service was unavailable? You can express this as an availability target e.g. 99.9%.
  
• Product feature demand. How often do users want new features from the service? You can express this as deployment frequency e.g. weekly deploys. 

That’s easy enough. The trick is how to calculate those variables, and who makes the selection. We provide step-by-step guidance on this in our playbook. 

When to select You Build It You Run It

We recommend You Build It You Run It in two scenarios. The first is common, the second is rare. 

Scenario 1

You have one or more digital services with both of these outcomes:

• Financial exposure on failure corresponds to an availability target between 95.0% and 99.9% availability.
• Product feature demand can only be satisfied by weekly, daily, or more frequent deployments.

You Build It You Run It is a good idea for digital services, as they’re strategic differentiators directly tied to your business outcomes. There’s a high level of demand for new features, and they have an immediate impact on revenue growth and/or operational savings. Your goal is to minimise the opportunity cost between having an idea and trialling it with your users, and You Build It You Run It is a key enabler in this. See Select You Build It You Run It for digital services.

Scenario 2

You have one or more software services that truly needs 99.99% availability.

We also recommend You Build It You Run It for any digital service or foundational system that needs extreme reliability. It’s rare for our customers to truly require this, and the engineering effort is enormous. See Select You Build It You Run It for 99.99% availability, and for more information on extreme reliability you can read What you should (and probably shouldn’t) try from SRE by myself and Ali Lotia.

When to select an operations team

So, now we’ve defined situations where You Build It You Run It is a good choice, when do we think it isn’t? We recommend retaining an operations team for one or more foundational systems with both of these outcomes: 

• Financial exposure on failure corresponds to an availability target between 95.0% and 99.9% availability.
• Product feature demand can be satisfied by monthly or fortnightly deployments.

Sometimes, you can’t buy a SaaS product for a back office business function, and self-hosted COTS or a custom application are your only choices. An operations team remains the right choice for that situation. Foundational systems have a low level of demand for new features, and they have an indirect impact on revenue streams and/or operational costs. Your goal with a foundational system is to minimise the risk of a catastrophic failure, and an operations team remains a cost-effective option. 

And in case it’s not obvious – many of the modern engineering practices we recommend for You Build It You Run It product teams will also help an operations team, such as a fully automated telemetry toolchain. 

How to make a decision

If you’d like a more in-depth understanding of our advice, you can follow the guidelines in our You Build It You Run It playbook. The step-by-step approach we recommend for a software service is:

1. Estimate its financial exposure on failure.
2. Calculate its availability target.
3. Estimate its product feature demand.
4. Calculate its deployment target. 
5. Select the operating model

We’ve created an operating model selector to help you out.

 In our playbook we include detailed steps on how to estimate financial exposure on failure and product feature demand, based on your own organisational context. For financial exposure on failure, we describe how to establish exposure bands for 95.0%, 99.0%, 99.9% availability levels. We ask “what’s the maximum revenue loss and operational costs we’ll incur if this software service is unavailable for one hour?” 

For product feature demand, we detail how to create feature demand bands for monthly, fortnightly, weekly, and daily deployment frequencies. We ask “what’s the feature demand we’ll see from users, for this particular software service?”

To find out more, you can continue in our What is You Build It You Run It series:

1. What is You Build It You Run It
2. How to decide when to use You Build It You Run It (and when not to use it) – you are here!

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.