You Build It You Run It: 3 things CEOs need to know

Digital customer experience is more important than ever before. To compete in today’s complex economic environment, you need the ability to adapt, transform, and rapidly launch new, compelling digital capabilities before your competitors.

According to Salesforce’s State of the Connected Customer report, 88% of customers claim the experience a company provides is as important as its product and services.

If that’s not enough motivation, this Forrester research shows that customer experience (CX) leaders grow revenue faster than CX laggards, cut costs, reduce risk, and can charge more for their products.

Basically, CX is critical. Your teams’ ability to deliver compelling differentiators and value for customers—consistently, at pace—will be crucial to your organisation’s success.

You Build It You Run It is the secret weapon that unlocks enormous business potential to give you the competitive advantage. Why?

Here’s what CEOs and CTOs need to know:

1. Delays in speed-to-market for digital services are costing you enormous amounts in prospective revenue.

“Speed is the ultimate weapon in business. All else being equal, the fastest company in any market will win.” – Dave Girouard, Upstart Cofounder and former President of Google’s billion-dollar cloud apps business, Google Enterprise Apps.

You Build It You Run It can play a significant role in reducing time-to-market when scaling digital delivery. And reducing your ‘concept to cash’ timeline is proven to drive significant business growth.

A recent Forrester TEI (Total Economic Impact™) study revealed that reducing time-to-market consistently across multiple delivery teams helped customers realise a 123% return on investment.

Building paved roads, adopting the You Build It You Run It operating model and using other techniques to reduce the time from ideation to deployment was the greatest driver of business benefit.

In the study, using data aggregated from four organisations we’ve worked with, over $41,000,000 of net present value was realised by improving time-to-market.

The You Build It You Run It operating model drastically reduces time to market for new strategic digital initiatives. Then, scales that capability across many teams.

One of the most critical things to do is understand your current time to market and quantify how much revenue you’re losing in opportunity cost and cost of delay. Cost of delay is an indicative calculation used to measure and understand the benefits you stand to lose by delaying a decision. It can relate to the delay of a migration, a feature update, or a production deployment.

Too many organisations have limited ability to deliver innovative digital services frequently, at pace. You may be hampered by slow, complicated processes to move ideas to deployment. Or perhaps you’ve invested in technology that is costly and cumbersome to change.

Whatever the reasons, decreased speed to market gives your competitors the advantage.

You only need to ask yourself: how long will you leave millions of dollars of prospective revenue on the table? How long will you let the competition reach your customers with new products, services and offers before you?

2. Markets are oversaturated and hyper-competitive: innovating frequently is the best way to establish valuable differentiation.

“Creativity is thinking up new things. Innovation is doing new things.” – Theodore Levitt, economist and professor at Harvard Business School.

Working with enterprise organisations, I notice far too many businesses struggle to offer meaningful differentiation in their digital channels.

Why?

Complex, inflexible deployment and approvals processes make it impossible to deliver new market offerings or strategic differentiators at pace.

And, as we’ve already noted in point 1:

If you’re not continuously innovating to offer new streams of value for prospective customers, your competitors are.

Choosing commercial off-the-shelf software is often seen as a strategy to launch new features quickly. But you’re only going to access and leverage the same features as your competitors.

You need to build and run digital services in a way that allows flexibility. In a way that meets the needs of evolving strategies or customer needs.

You Build It You Run It empowers teams to deliver far more features—and more business value—faster and at higher quality. We’ve supported global organisations to move from 10 deployments per year to more than 4,000, without a correlating increase in production incidents.

Are you delivering enough value, frequently enough, to stand out in a hyper-competitive market?

Learn more about how You Build It You Run It can help you launch new product features to market every day.

3. Poor, unreliable service is poor customer service: You Build It You Run It can reduce incidents, improve availability, and enhance profit protection.

When it comes to digital CX, exceptional service is the baseline expectation. Latency is simply not an option.

In 2006, Amazon software engineer found that Greg Linden found that every 100 milliseconds in service latency cost them 1% in sales. In the same year, Google VP Marissa Mayer found that a half-second delay in generating search results caused a 20% drop in traffic.

In 2018, Google shared that as page load time increases on mobile devices:

From 1 second to 3 seconds, the probability of a customer leaving the site without any meaningful action (also called ‘bounce rate’) increases 32%.
From 1 second to 5 seconds, the probability of bounce increases 90%.
From 1 second to 6 seconds, the probability of bounce increases 106%.
From 1 second to 10 seconds, the probability of bounce increases 123%.

In other words, every second your site or digital service is unavailable, the likelihood your customers will defer to a competitor increases exponentially.

You Build It You Run It can drastically improve service availability and reduce time to resolve incidents by:

Incentivising teams to architect for adaptability, building contingencies so that vital customer service functions are still available in the event of an incident.
Encouraging teams to build proactive measures into services to prioritise availability because they own every aspect of the service, from feature development to operations.
And many more: learn how You Build It You Run It provides crucial protections against unplanned downtime.

***

There you have it. You Build It You Run It supports enterprise teams and organisations to unlock enormous value, based on:

Empowering you to deliver new services to customers faster than ever before.
Ensuring you can meaningfully and valuably differentiate your organisation in the minds of customers.
Enhancing service reliability and protecting against costly downtime.

If you’re ready to embrace high performance software teams that deliver consistent and significant business value, let’s arrange a conversation.

I speak with customers and consultants across the Equal Experts network, to help our customers understand how to speed up innovation and reduce total cost of ownership at scale. Sometimes, our customers refer to this broadly as ‘scaling agile delivery’.

We’ve helped a lot of organizations to scale agile delivery successfully. Forrester Research recently published a Total Economic Impact (TEI) study that shows partnering with Equal Experts achieved a 123% ROI and 60% reduction in time to market for:

A food franchise scaleup: 10 teams, 40 workloads
A consulting organization: 10 teams, 100 workloads
A high end retailer: 40 teams, 75 workloads
A government department: 80 teams, 900 workloads

It’s hard to implement cross-functional, outcome-oriented teams delivering complementary product capabilities. The good news is success leads to a faster time to market, better quality, reduced risks, lower costs, and better user outcomes which improve your bottom line. My colleague Jon Ayre recently talked about how to iteratively scale agile. I’ll take that a step further. Here are four ways to scale up your delivery capabilities:

Set teams up to have alignment with autonomy
Introduce a You Build It You Run It operating model
Focus on frictionless onboarding
Create paved roads to allow teams to focus on delivering business value.

Create alignment with autonomy

Teams make faster and better decisions when they understand the intent, purpose, and constraints behind their work, and when they can act for themselves. Teams need to be aligned to deliver on strategy and execution, and autonomous to deliver outcomes without handoffs.

The problem is organizations often implement alignment as command and control. Teams are forced to treat alignment and autonomy as opposites, and they become stuck in one of two scenarios:

Autocracy. Teams have high alignment but low autonomy. They incur delays because they can’t make decisions. At a media conglomerate, I saw 8 teams who constantly had to wait for 2 shared product managers to make all their decisions for them.
Anarchy. Teams have high autonomy but low alignment. They’re unaware if they’re making good decisions or not. At an insurer, I saw 10 teams spending ~80% of their time on unplanned BAU work, because they’d implemented 10 different services with 10 different AWS runtimes.

The solution is to replace command and control with contextual alignment, and give teams the freedom to make good decisions in aligned autonomy. See why you need alignment with autonomy at scale.

Adopt You Build It You Run It

Teams achieve higher throughput, greater reliability, and a continuous learning culture when they build and run their own workloads. Teams need to become accountable for reliability as well as functionality, and focussed on outcomes rather than outputs.

The problem is organizational inertia towards using a central operations team to run differentiated digital services. It’s not possible to achieve a high throughput, high reliability baseline when delivery teams and an operations team are set up to work at cross-purposes. I’ve seen many organizations struggle to innovate because handoffs, competing priorities, and misaligned incentives occur every day.

The solution is to adopt the You Build It You Run It operating model for differentiated services, and keep your operations team for foundational systems. Make your product managers accountable for reliability, and put product teams on-call. See You Build It You Run It sounds great but it won’t work here and the You Build It You Run It playbook.

Focus on frictionless team onboarding

Teams are more effective when new engineers can make meaningful contributions as soon as they join up. Teams need a friction-free onboarding process that allows people to join a team and be productive on day one.

The problem is organizations usually treat onboarding as an afterthought. The onboarding process is disjointed and time-consuming, because it lacks a clear owner and is split between multiple organizational functions. I’ve seen engineers on a new team wait for weeks to commit their first line of code, because they’re waiting for the necessary permissions.

The solution is to automate onboarding tasks and reserve team capacity for knowledge sharing, so new joiners are immediately productive. Replace gatekeeping with trust and verify, share business domain knowledge, and establish a Bring Your Own Devices (BYOD) policy. See seven onboarding tips to accelerate productivity.

Build paved roads

Teams can deliver many user outcomes at pace when a majority of technology challenges are solved for them ahead of time. Teams need tasks such as microservice creation and telemetry provisioning to be self-service, fully automated, and fault free.

The problem is centralized technology capabilities are rarely designed to be user-centric. Teams can’t accelerate because they depend on platform teams focussed on infrastructure standardization, rather than the needs of their consumers. I’ve seen teams wait for weeks for a microservice provisioning ticket to be actioned by a platform team.

The solution is for platform teams to partner with product teams to create bi-directional feedback loops, and deliver self-service paved roads formed around engineer user journeys. Create a positive engineering experience for teams, focus on solving business problems with minimal cognitive load, and prevent platform teams from becoming service desks. See the Digital Platform Playbook.

Find out more

If you’d like to know more about how to successfully scale for agile delivery, get in touch! We’d love to hear from you.

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.

In our recent You Build It You Run It playbook, my co-author Steve Smith and I take a deeper look at the embedded specialists pitfall. You can guard against this pitfall, and even escape it if necessary.

Teams of specialists suffer at scale

Steve and I often see organisations with small, central teams of specialists supporting a number of delivery teams. For example, you might have some delivery teams and an application support team dependent upon a small DBA team, for the provisioning of your on-premise relational databases and management of your user data.

You don’t want developers to manage database backups themselves, nor to debug a live database with millions of rows of user data. At the same time, your DBAs can’t transfer their depth of expertise to developers. This means DBA workload will inevitably increase as you add more delivery teams, no matter how skilled your DBAs are. Conflicting prioritisation calls, strained relationships, and a lack of delivery team progress are likely, as well as burnout for your DBAs.

Steve and I have seen specialists in this situation too many times, in different organisations and in different specialisations. We’ve seen it with DBAs, InfoSec analysts, network admins, and operability engineers (which you might know as DevOps). In addition, the easy answer of recruiting more specialists into the central team doesn’t usually work, because there’s a consistent scarcity of affordable specialists in the marketplace.

The embedded specialists pitfall

You Build It You Run It is an operating model in which product teams build, deploy, operate, and support their own digital services. If your organisation adopts You Build It You Run It and you have multiple product teams constrained by a struggling specialist team, one solution that could be considered is embedding those specialists into the product teams. In other words, if you had 10 product teams and one team of 10 DBAs, you would embed each DBA into one of the 10 product teams.

Steve and I call this the embedded specialists pitfall. It’s the logical extreme of You Build It You Run It, and it’s not a good idea. In theory, embedded specialists will act as first responders, and influence technical quality on product teams via their deep expertise. However, we’ve seen serious problems emerge for embedded specialists:

Multiple assignments. Your embedded specialists are each assigned to multiple teams, because you have N product teams, less than N specialists available, and recruiting more specialists is difficult.
Unpredictable workloads. Your embedded specialists are either bored from a lack of work, or burned out from too much work across multiple product teams.
Lack of knowledge sharing. Your embedded specialists don’t have opportunities to work together, learn from one another, or even talk to another. They can feel lonely.

Tom Clark spoke at DevOps Enterprise Summit Europe 2019 about how this pitfall affected the ITV Common Platform. ITV tried to embed a platform engineer into each product team, and the engineers suffered from multiple assignments, unpredictable workloads, and a lack of knowledge sharing. This had a direct, negative impact which led to technology stagnation and reduced developer productivity.

So, if the answer isn’t adding more specialists to a central team, or embedding specialists into product teams… what do you do?

Establish specialists as a service

You can achieve a step change in productivity by turning your specialist teams into consumable specialist as a service offerings, and achieving a balance between cross-functional product teams and depth of specialist expertise that’s right for your organisation. Steve and I recommend the following:

Offload non-specialist tasks to product teams.
Map out specialist tasks and the associated actions. For example, you should offload repeatable, low value tasks to your cloud provider. You should automate repeatable, high value tasks in a deployment pipeline. And retain ad hoc, high value tasks as is. See the table below for more details.
Establish low friction, public messaging channels for bi-directional feedback loops, #ask-the-dbas, #ask-network-admins.
Create public ticket queues to show planned work and work in progress for specialists.

Specialist tasks can be mapped in terms of repeatability and value-add.

The goal is to remove toil for your specialists, and free them up to concentrate on high value scenarios in which product teams really need their deep expertise. Their expertise is too scarce, and too important, to be wasted on tasks that can be handled by your cloud provider or product teams.

Deployment in ‘Ops Run It’: the common, conventional IT approach.

Many software teams use an operational model called ‘Ops Run It’. In this model, Operations teams are charged with the responsibility of deploying and supporting applications in production. The above graphic highlights a composite IT department, where Delivery and Operations function as silos.

In this approach there are many delivery teams building and testing software services. Once those services are built and tested, there’s a handover. In Operations, there’s a Change Management team running change-advisory board meetings (or CAB meetings) to ensure the services are stable and safe. Then, there’s an App Support Team doing the deployments.

How does ‘Ops Run It’ work in a day-to-day capacity?

The Delivery team adds a delivery request into the change-management queue.
Each delivery request is approved or rejected in a CAB meeting.
An approved change is added into the deployment queue.
The Application Support team perform the actual deployment at the scheduled time.
Post-deployment validation testing will be performed by either the Operations App Support team or, in some cases, the Delivery team.

What are the drawbacks in this approach?

It’s incredibly slow to approve a change request: in this operating model, deployments are mired in bureaucracy because it takes hours, days, or even weeks to approve a change.
The act of deployment itself is slow-to-complete: it can take hours or days to actually complete deployment. Additionally, if the deployment tasks are not automated, the act of deployment can be risky and time consuming. In some cases, the architecture itself may prevent teams from being able to make changes while the system is running. This means all deployments must be timed to correlate with planned outages. If the team does not have automated production verification tests, then testing must be completed manually after each deployment. All of these factors—whether individually or in conjunction—can contribute to lengthy deployment times.
It’s slow to synchronize knowledge between teams during handovers: every time the delivery team completes a piece of work, they need to conduct a handover process to pass the deliverable to Operations for approval and deployment. This involves a detailed summary of what was built, why it was built a specific way, and anything to be mindful of in support cases. Providing this context is time consuming and often arduous, given the Operations team was not involved in building the change and typically have very little context as to why it is important.
You can’t sustain innovation with Ops Run It: while Ops Run It is suitable for commercial-off-the-shelf software (COTS) applications and foundational systems, it does not facilitate the rapid time-to-market required for sustained innovation. This is because it is slow to approve, implement and learn from new product features.

Deployment in You Build It You Run It: how to launch new product features to market every day.

The above graphic shows a hybrid model.

It’s important to note that You Build It You Run It and Ops Run It are not binary propositions. It’s a common misconception that you can simply choose one model over the other and employ it universally. In most cases, you’ll have different models working together, because different services have different requirements. You should also frequently review your operating model depending on the maturity or lifecycle of the product/system you’re supporting.

Here, the Delivery team employs the You Build It You Run It operating model for all activity involved with developing, testing, deploying and evolving digital services.

The same Delivery team could be using an Ops Run It model—in conjunction with a central Operations team—for work associated with commercial-off-the-shelf software (COTS), foundational systems, or even mature digital products that require little intervention.

How does You Build It You Run It work in a day-to-day capacity?

In You Build It You Run It, an on-call Delivery team has total ownership over developing, deploying, monitoring and supporting digital services. As a result, there is no hand-off from Development to Operations.

The Delivery team has all the skills and context needed to do this across the entire lifecycle. It’s made possible by a loosely-coupled service-oriented architecture, and an automated deployment process.

In the You Build It You Run It operating model, the on-call product team will determine for themselves whether what they want to do is a regular, low-risk change. We trust they’re in the best position to make this call, because these team members have built the service and best understand the intricacies of its codebase.

If the Delivery team deem it is a regular low-risk change, they use a pre-approved change request process, and it’s managed by the team as a standard change. This process is extremely fast when implemented correctly—updates can be deployed daily to help organisations sustain innovation and consistently deliver value.

If the Delivery team deem it is an irregular or high-risk change, it goes through a normal CAB process with the same change-management team from Operations.

When a deployment happens, the Delivery team perform it themselves—at a time of their own choosing—and report their successful changes to the Change Management team.

Critically, this removes the bottleneck you see in Ops Run It where the Delivery team is dependent on the App Support team.

In You Build It You Run It, we also typically see Delivery teams being much more considered and cautious with their deployment times than an Operations team might be. This is because the Delivery team themselves are responsible for fixing any problems that arise from the deployment.

Often, in scenarios where deployment is automated and the architecture is built in a way that doesn’t require downtime for deployments, Delivery teams will deploy during the day to give themselves a working day to monitor for issues and implement immediate fixes as they arise. This, in turn, means fixes are provisioned faster and services are more reliable in general.

What are the benefits of this approach?

In the right environment, there are many benefits to You Build It You Run It. The top three we typically see are:

It’s much, much faster to approve change requests: in this operating model, an approved change request for a regular low-risk change can be obtained within minutes or even immediately. As opposed to days, weeks, or months.
It’s much, much faster to complete deployments: the deployment process can be fully automated by the Product team using the deployment pipeline. Crucially, even if you choose not to automate this process, there is no handoff to any other team as part of the deployment workflow; the team is entirely self-sufficient.
It’s much, much faster to synchronise knowledge: there’s no requirement for meetings or phone calls to facilitate a deployment handover for an Operations team. The only requirement is to synchronise knowledge within the Product team; through an approach like paired development, everyone on the team has far greater clarity of what’s happening at any point in time.

So how do I get started with You Build It You Run It?

Like many things, You Build It You Run It can be incredibly powerful when implemented in the right context. But it’s not necessarily the right approach for every organisation universally.

If you’re interested to learn more about You Build It You Run It—including whether it’s right for you, and how you can start to determine its suitability for your team —I’d love to set up a conversation.

You Build It You Run It accelerates your time to market, increases your service reliability, and grows a learning culture. All by empowering your product teams to own every aspect of digital service management. However, there are some pitfalls, which can put the success of You Build It You Run It at risk. One pitfall involves implementing the same reactive change management process. It creates something we like to refer to as treacle.

In our recent You Build It You Run It playbook, my co-author Bethan Timmins and I take a deeper look at the change management treacle pitfall. You can guard against it. And how you can even completely escape it.

Change management is needed

Let’s start with a little more explanation of the You Build It You Run It hybrid operating model:

Product teams build, deploy, operate, and support their own digital services, such as user-facing microservices.
An application support team manages foundational systems, like self-hosted COTS and custom back office applications for which there’s no equivalent SaaS or COTS.

This diagram shows how we think of deployment throughputs for digital services and foundational systems in You Build It You Run It.

In the diagram, you can see an approval step for foundational systems, prior to the release step. The delivery team has to file a change request to the change management team, who then review the change and approve or reject it. If the change is approved, the application support team performs the production deployment.

“Our change management is too slow” is a complaint we’ve hear often. Now we all recognise the need for change management, it’s necessary for large, complex changes with lots of moving parts. It’s also important that your IT department can produce an audit trail of all production changes, to assist in incident diagnosis and to satisfy internal compliance requirements.

It’s easy to blame slow change management on ITIL. But we’ve helped plenty of organisations to implement daily deployments within ITIL parameters.

In our experience, slow change management is caused by using a heavyweight, one size fits all process. We’ve seen many organisations get stuck when they don’t make the time to rethink how to do it well. But You Build It You Run It depends on a slicker change management process, which still satisfies the needs for change approvals and auditing.

Change management treacle

Bethan and I refer to slow, heavyweight processes as treacle. You can’t move faster, because you’re stuck in sticky syrup where you are.

When you adopt You Build It You Run It, copying and pasting the same reactive change management process causes a lot of treacle. Product teams are empowered to build, test, and deploy their own digital services, but every change still has to be approved by the change management team. This causes a lot of problems:

The change management team can’t approve changes fast enough for weekly or more frequent deployments, so product features can’t be rapidly tested with customers
Changesets per deployment become much larger, which makes it harder to test changes and diagnose production failures when they occur
Product teams suffer from low morale, because their hard work is often trapped in a change request queue for days at a time
Relationships between product teams and the change management team become frayed, and resentful

This is what we call the change management treacle pitfall. It prevents you from achieving one of the key goals of You Build It You Run It – an acceleration in deployment throughput, as a means to increase product revenues, keep BAU under control, and reduce operational costs.

You need to re-implement change management for digital services and You Build It You Run It – but how?

Here are our 4 suggestions to remove the treacle

We recommend you aim for a twin-track approach to change management. This way you allow digital services to move at a faster pace than foundational systems, while allowing for change approvals and auditing. Try these practices and you will quickly see how you can cut out the treacle.

Pre-approve low risk, repeatable changes. This is known as ‘standard changes’ in ITIL. Establish a template with your change management team for pre-approving small digital services changes, and retain the regular process for large changes to digital services or foundational systems.
Encourage frequent, small changes. Incentivise your product teams to make their planned features and changesets as small as possible.
Automate change auditing. Record all deployment pipeline changes in a persistent store, and create an information portal so your change management team can view ongoing changes.
Run regular chaos days. Ensure every product team runs Chaos Days, to validate their approach to change management, deployment failures, and incident handling.

This will result in a streamlined change management process for digital services, akin to:

Product manager creates a pre-approved change request template
For any low risk and repeatable changes, automate filling in a pre-approved change request whenever a release candidate passes all functional tests
For any high risk or unrepeatable change, send a change request to the change management team for approval.
Automatically check prior to a production deployment that an approved change request exists.
Automatically close the change request when the deployment is completed.

That’s it. It’s the most effective way we have discovered to remove your change management treacle, and allow your You Build It You Run It adoption to be successful! We hope it helps.

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

7 pitfalls to avoid with You Build It You Run It
5 ways to minimise your run costs with You Build It You Run It
Why your head of operations shouldn’t be accountable for digital reliability
How to manage BAU in product teams
4 ways to remove the treacle in change management – you are here!

Our people

Insights

Contact us