Incident management for high-velocity teams
Is ‘you build it, you run it’ living up to the hype?
It’s been 13 years since “you build it, you run it.” Did it deliver on its promises?
Thirteen years ago, a new rallying cry for for deploying and operating software snuck its way into an interview and upended IT processes across the world. Today, more businesses than ever are embracing the collaborative approach of DevOps and the “you build it, you run it” mindset that typically comes with it. But now that we have over a decade of change under our belts, is the concept still relevant? Has it brought the benefits it promised?
The history of the shift
It all started in a 2006 interview with Amazon CTO Werner Vogels:
“Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.”
So began “you build it, you run it”—a new way of doing things that merged nicely with the subsequent rise of the collaborative DevOps movement, where breaking down the wall between those who build and those who support was paramount.
The idea took off—and with good reason. Bridging the gap between development and operations makes a lot of sense. Why shouldn’t the team that wrote the code—the team intimately familiar with the product—be the one that dons their superhero capes when an incident strikes? The practice not only speeds up time to resolution. It also brings developers closer to customer feedback and real-time issues, helping to facilitate always-on services.
Clear benefits…and clear challenges
As with all process shifts, along with the benefits came a set of challenges—and plenty of resistance from more traditionally structured businesses.
The benefits included less pressure on IT teams, production-ready design, quicker response times, and more thoroughly tested code (after all, if you’re the one getting paged at 1 a.m. to resolve a bug, your chances of double-checking the next deployment are bound to increase). It also made for better, more well-rounded developers, tasked with learning new skills and thinking about the business in new ways.
Since the responsibility for the code stays with the same team, this approach also has a positive impact on incident prevention. One report found that companies with code review done by external teams before deployment had the same success rate as companies with no code review at all. Peer review, on the other hand, handled by developers who already know the product, had a positive impact on incident prevention.
As for the challenges, our team addressed some of the challenges of this shifting approach to incident management here: “The challenge of [decentralizing incident management] is that organizations still need some centralization. Leadership needs access to reports and documentation. Business stakeholders want updates. They want to see incident metrics like mean time to resolve and mean time to acknowledge. They expect clear incident updates, incident postmortem reports, and remediation work.
For many companies moving toward decentralization [and a “you build it, you run it” approach] and doing it well, the answer to this challenge is technology that allows for decentralization and team autonomy to keep incident resolution nimble and still centralize information to keep the business in the loop.”
The other core challenge is that for many businesses, embracing “you build it, you run it” means changing team structures and internal culture. It requires an openness to collaboration, new ways of thinking about product, and new team structures that break down communication barriers. Changes like these are challenging and take a very specific approach if they are to succeed.
So, is “you build it, you run it” delivering on the promise?
Despite the challenges, in our experience the answer is yes. “You build it, you run it” is still transforming the industry, with even traditional IT teams slowly testing the waters.
There are no studies available on the adoption of “you build it, you run it,” but in our experience it often comes with the adoption of DevOps principles in general. And we do have numbers on those. In 2017, 63% of organizations said they’d implemented DevOps, according to a Forrester report. Another 27% had plans to hop on the bandwagon within the year. And only 1% expressed no interest in making a change.
More compelling, companies reported a 45% average increase in customer satisfaction and a 43% increase in employee productivity when adopting DevOps principles.
Getting started with "You build it, you run it"
Adopting a "You build it, you run it approach" is impossible without a platform that is flexible and highly collaborative. The whole premise is that Dev and Ops can work together seamlessly — this type of collaboration can only be unlocked with the proper tools.
Jira Service Management unites teams with integrated, collaborative communication, allowing teams to connect with their preferred communication method, from chat channels (Slack, Microsoft Teams) to video conferencing (via a native video bridge or Zoom). Nearly every aspect of Jira Service Management can be customized to suit every team's needs — from alerts to routing rules and more — to loop in necessary responders and provide context to all parties from initial response stages through postmortem reporting and problem management.
Learn more about how Jira Service Management can unlock your team's collaborative potential.
Setting up an on-call schedule with Opsgenie
In this tutorial, you’ll learn how to set up an on-call schedule, apply override rules, configure on-call notifications, and more, all within Opsgenie.
Read this tutorialPros and cons of different approaches to on-call management
On call teams are rapidly evolving. Explore the pros and cons of different approaches to on call management.
Read this article