Adopting a You Build It You Run It operating model can unlock enormous business growth. It can provide greater flexibility and enhance reliability for your digital services. It can create much happier developer teams.

Inevitably though—like anything that offers genuine growth and value—it can also come with some perceived challenges and scepticism. After all, as humans, many of us are hard-wired to resist change.

Additionally, there’s a sentiment from pockets of the software development community that ‘developers don’t want to do operations’, and therefore by extension, don’t want to adopt You Build It You Run It.

Interestingly, this is a sentiment I hear from industry commentators more so than developers themselves. That said, in my experience there are some common reservations that developers do offer up when presented with the prospect of moving to You Build It You Run It.

So, here they are, with some techniques you can use to overcome them.

1.    “It’s really difficult to support the service”.

Adopting You Build It You Run It means teams will both build and support digital services.

When development teams suggest that a digital service is difficult to support, it’s often a symptom of deeper issues.

The first of these issues is that the service hasn’t been architected for adaptability. So, in reality, it is difficult to support.

The second is that there are no ‘paved roads’ in place. As defined in this excellent article by Equal Experts’ Alan Coppack, paved roads consist of low-friction, hardened interfaces that comprise common user journeys for Digital Service teams. Examples might include building a service, deploying a service, or service alerts. In summary, building paved roads is about removing friction from frequent processes or user journeys.

Without paved roads in place—which abstract unnecessary complexity and cognitive load away from the team’s day-to-day responsibility of focusing on a single digital service—the development team has to do everything associated with operating the service, all the time. This means:

• Running the deployment pipelines
• Running the cloud underneath the service
• Testing
• The whole shebang.

In this scenario, it’s common for a team’s workload to become overwhelming because the cognitive load becomes enormous. Without correcting, teams will inevitably suffer burn out. Incidentally, you can read more about mitigating developer burn out in this article.

How to overcome this challenge.

No prizes for guessing this one: build out the required paved roads.

This allows you to abstract problems away from one development team, so they can focus more exclusively on their role in relation to a specific service.

Generally speaking, you can consider paved roads in relation to four broad categories:

• 1: Build and deployment—How do I build a service? How do I deploy it? How do I get it out to production?
• 2: Telemetry—How do I monitor a service? How do I log on it?
• 3: Enablement—How do I create a service in the first place? Is the cloud set up to manage and provide resiliency?
• 4: User access and security controls.

Beyond removing complexity for one team, paved roads also provide valuable economies of scale. For example, when you have multiple delivery teams, these paved roads can support all of them. In that instance, you would have a dedicated platform team to solely build and run paved roads.

If you’re keen to learn more about paved roads, there is enormous insight and value in our Digital Platforms playbook.

2.    “We don’t want to work on support out of hours.”

Firstly, this is an entirely valid reservation. We shouldn’t expect teams to work out of hours without the right supports and incentives in place.

Here, we need to understand why the architecture is built in a way that forces people to work out of hours. It’s enormously important to understand so we can rearchitect the service to remedy the situation.

At a personal level, it’s also about understanding and empathising with peoples’ circumstances.

They could have all sorts of things going on. Some common scenarios include:

• Not having the skills or support to feel confident in an out of hours role.
• Caring for children or family members.
• Sometimes, even having responsibilities with another job, because they’re not being paid enough to complete this type of support work.

How to overcome this challenge.

There are two courses of action to take in response to this concern:

1. Understand and empathise with peoples’ personal circumstances.
2. Analyse the service to determine whether out of hours support is necessary. In my experience, in many cases, it’s not.

This is because many organisations mistakenly take a blanket approach to operations—rather than select an operating model based on the actual availability requirements of that service.

More often than not, businesses assume a service has a requirement of 99.9% availability.

People wrongly assume ‘we need this service available all night’, and developers are unnecessarily supporting those services out of hours.

There are ways to test that assumption and determine the real availability requirements of a service.

With less requirement for out of hours support, you’ll have less requirement for developers to do this type of work. And less cause for their concern.

3.    “We won’t be remunerated properly.”

Again, this is a legitimate concern for teams adopting a You Build It You Run It operating model.

In my experience, developers are often asked to work out of hours and they’re not paid for it.

A common technique is to provide ‘time off in lieu’—rather than pay—as compensation.

This can be a fallacy though; despite receiving time in lieu, developers can’t actually take time off because of a critical requirement to produce more features from an overwhelming backlog,

In these situations, you can become trapped in a never-ending cycle of ‘get more features out’—support the service—get more features out—support the service.

And there’s no real time to take the time off in lieu within this cycle. So, from the developers’ perspective, there’s no respite and no remuneration.

How to overcome this challenge.

This pressure to deliver new features can come from a range of sources:

• Perhaps you’re not delivering frequently and iteratively enough.
• Perhaps there’s pressure to develop features rather than ensure reliability of service—or that there’s not an appropriate analysis of where the most value lies; whether in developing new features or keeping the service live.

There’s a simple solution to managing this bottleneck: appoint a product manager to the team—or across multiple teams—to assist in clarifying priority and managing backlog.

4.    “We just want to build new features. Our job is to focus on development work, not operations.”

Again, I hear this statement being referenced by industry commentators, but I don’t see it expressed in the reality of working with development teams.

If we do encounter this sentiment, I’d look at the team’s motivation. Particularly, how they view the problem they’ve been tasked with solving.

How to overcome this challenge.

Re-frame the problem so there’s no perception the team is being forced to inherit operations.

For example, give them the space and support to focus on rebuilding the service so that it’s robust and reliable, with a number of contingencies in place to mitigate the need for onerous operations tasks.

Rather than say ‘monitor this and ensure there are no incidents’, try the following:

• Use your creativity to build something that won’t fall over in production.
• How might we ensure the service is architected for adaptability and create something that’s highly resilient?

How to support your team(s) in adopting You Build It You Run It.

It’s one thing to tell a team ‘we’re implementing You Build It You Run It and you’re in charge of operations now’.

It’s another thing to implement the necessary supporting mechanisms and structures that allow the team to flourish in a new operating model.

I often see teams being told to support a service in You Build It You Run It, without being appropriately supported themselves. They’re not given the things that allow them to prosper, and the success and value of the operating model is compromised.

To recap those things are:

• A service that’s architected for adaptability.
• Paved roads.
• A thorough assessment as to whether services genuinely require out of hours support.
• Appropriate remuneration for out of hours support.

To find out more, watch our video below.