‘We can’t respond to customers’: how Ops Run It denies you huge value (part 3).

If technology hampers your ability to respond to customer needs, you’re likely denying yourself enormous potential profit. And You Build It You Run It could be the answer.

Welcome to part three of this five-part series, highlighting how a traditional Ops Run It operating model can deny you of value.

This series is designed to help you unlock serious potential that’s dormant within your business.

How serious?

In a recent study conducted by Forrester, an organisation realised over $41 million of net-present value by improving time-to-market and reducing their ‘concept to cash’ timeline.

They achieved this result by implementing the You Build It You Run It operating model: by delivering new value streams to customers consistently and being able to pivot in response to evolving feedback or requirements.

This organisation realised $41 million worth of existing net-present value by implementing the You Build It You Run It operating model.

Why is the model so effective in improving speed to market? And how does Ops Run It create challenges that prevent you from achieving the same results?

Each part in this series examines and answers those questions in detail.

• Part 1: Ops Run It prioritises stability in a way that fundamentally stops you from delivering at speed (which you can read here).
• Part 2: Ops Run It involves an unnecessarily laborious and manually intensive deployment pipeline (which you can read here).
• Part 3: Ops Run It limits the agility of the development team, making it harder to respond to rapid changes in market conditions or evolving customer needs (this article).
• Part 4: Ops Run It involves an overly strict change management process and stifles change (which you can read here)
• Part 5: Ops Run It and potential impacts on resourcing for sustained innovation.

Ops Run It limits the agility of the development team, making it harder to respond to changes in market conditions or evolving customer needs.

Let’s consider this statement in the context of a change management process.

Imagine you work in the Ops Run It model. You’re delivering a new feature to customers.

The Delivery team—which is siloed and distinct from the Operations team—builds the feature. Because of the segmented nature of the teams, the Delivery team is likely incentivised to focus on volume of production and less concerned about stability.

Stability (or service availability) is a consideration, but likely not as significant as it might be if the Delivery team themselves were responsible for fixing incidents in production.

On completion of the new feature, the Delivery team conducts a lengthy handoff process (or series of handoffs).

And none of your customers actually use the feature.

In this scenario, it’s incredibly difficult to identify why no one is using the feature.

The Operations team will likely think “this feature is perfect; we haven’t had a single incident.” The Delivery team, on the other hand, have no visibility that no one is engaging with what they’ve built.

In an Ops Run It model, there is a significant gap between the Delivery team and the end users. This can contribute to a scenario where the Delivery team has very little understanding of their end-customers’ needs.

With no visibility of the impact of what they’re building, the Delivery team forges on…

The Delivery team is completely unaware that what they’ve built is surplus to requirements, so they have no cause to alter their approach. In this situation, they will continue to deliver more, similar features.

Remember, they are incentivised to build. They are charged with developing new features and they will continue to do so.

This creates:

• A substantial backlog, which takes time to work through and deliver.
• Wasted development resource, because they’re largely building redundant features.
• A surplus of features that don’t align with customer needs. This equates to frustrated customers.

Now, imagine the Operations team successfully identifies that no customers are using the feature.

They also manage to pull data on why no one uses the feature.

This is a perfect opportunity to provide value by responding to customer needs.

But in an Ops Run It model, the response will take time…

The teams will need to:

1. Enter the change request into the backlog of work for the delivery team.
2. Reshuffle the backlog and ensure the changes in priority are communicated to stakeholders.
3. Find a slot and deploy the change to production.

In most cases, there will be a separate team to perform that deployment to production. So, the team will also need to spend time onboarding them and provide context in relation to the update.

Once the update is deployed, the team will then have to handoff to the Ops Team to run the update.

Jumping through all of these procedural hoops takes time. Time in which you’re not satisfying your customers, and time in which you’re losing potential revenue from them.

Consider another example. Imagine you have a development team member monitoring your website; they notice a high amount of traffic in relation to a specific form on the website. Their response? Increase the scalability of the system to cope with a higher volume of traffic.

In reality, the button experiences high amounts of traffic because the design of that particular form is poor–it doesn’t provide any indication that it has received a submission, so people are clicking it rapidly and far more frequently. Without visibility of the customer, the development team can make assumptions and build a solution that doesn’t alleviate the root cause of an issue.

What would happen in the You Build It You Run It model?

In the You Build It You Run It model, the team that builds the software is the team that runs the software.

This means they are much closer to the customer. They monitor how customers engage with what they build and have direct access to customer feedback.

In the You Build It You Run It model, the team who builds the software and monitors the software in production have direct access to—and visibility of—their end users.

If they need to respond to customer requirements, they can make changes in real time. They do not have to navigate a lengthy and time-consuming approvals process, because they own the entire lifecycle of the product or service they maintain.

Generally speaking, You Build It You Run It fosters a strong culture of ownership and accountability. This encourages teams to be more responsive to customer needs and own the impact of what they build.

In my experience, developers are also happier. They derive purpose from knowing they are contributing tangible value for both customers and the business; they have a stronger sense of their value to the organisation and feel more pride in their role.

Are you denying yourself of substantial net-present value?

If you’re currently working in a traditional Ops Run It model—held up by overly rigid approvals and that stifle your team’s ability to respond to customer needs—there’s every chance you’re sitting on a gold mine of potential value.

Adopting the You Build It You Run It model could be the key to unlocking significant profits. If you’d like to have a conversation to assess how likely that’s the case, get in touch today.

Or, keep an eye out for the next article in this series, where I’ll focus on change management processes in each of the models.

Maximising Profits & Efficiency: Why Ops Run It Costs You Revenue By Slowing Time-To-Market – Part 3

Are your traditional processes dragging your business down? It’s time for a change! In part 3 of our 5-video series, we’ll expose how the Ops Run It model is holding you back and why switching to the You Build It You Run It model will help you surge ahead of the competition!