The software development methodology of you build it, you run it otherwise known as YBIYRI has been around for almost two decades now. The idea was first proposed by Amazon’s CTO at that time, Werner Vogels, in 2006. Amazon decided to move from a two-tier monolith to a decentralized, fully distributed, service platform, serving several applications. So, naturally, a lot of innovation was required, especially with the unprecedented level of isolation they wanted to achieve. During the process this idea of building, serving, and scaling applications independently came, and with it came the idea of YBIYRI. In his interview, he further explained:

“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, 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.” 

But does it sound too much like DevOps? Let’s see how it is different or similar to DevOps.

How is YBIYRI Different from DevOps?

While the two are closely related and share some common goals, there are distinct differences between the two. (YBIYRI) is a specific practice or principle within the broader framework of DevOps. YBIYRI focuses specifically on the principle that the team responsible for building a software product is also responsible for its operation and maintenance. On the other hand, DevOps encompasses a broader set of organizational, and technical practices to improve communication and collaboration between development and operations teams. 

Let’s take a simple example to better understand the distinction between these two approaches. Think of DevOps as having a team of friends who are building the treehouse (developers) and making sure it stays strong and safe (operations team). It is focused on having good teamwork and communication between everyone involved in building and maintaining the treehouse. Conversely, “you build it, you run it” is more like having a rule that says whoever helps build part of the treehouse is also responsible for making sure that part works well and stays in good shape. So the person who built a room or a ladder is responsible for making sure that it is safe to use and in working order.

Does YBIYRI Actually Work or Was it Another Fad?

Ever since the idea came out, it took off and many other companies tried to apply the same or a slightly modified version of this idea. Netflix, Etsy, and Stepstone are some of the companies that practice some version of this approach. Since the idea has been here for so long, is you build it, you run it, really the ultimate way of getting rid of all the bottlenecks and achieving DevOps nirvana? 

Our research to find hard numbers was in vain. There is no numerical data to show exactly how fast YBIYRI makes the whole development cycle, or how much it benefits a company. However, several companies have successfully implemented it and use it to date. Unfortunately, not many of them have openly talked in detail about the intricate details and their overall progress with the said approach. Stepstone is one of the companies that came forward with their process of implementing YBIYRI.

You Build it, You Own it: The Way Stepstone Does YBIYRI

Stepstone applies a slightly modified approach of you build it, you own it. They aim for teams to own products from ideation through development, operations, and eventual phase-out, embedding this thinking into their company strategy. As a part of their ideation phase, they developed an Ownership model with three pillars (Product, Platform, Engineering), each containing areas described in terms of Autonomy and Alignment. They visualized the idea, so everyone in the organization had a clear understanding of what they were going for.

Now the next step for them was implementation. They focused on building awareness, desire, knowledge, and capabilities for change, reinforced by continuous measurement, feedback, and recognition of good behaviors. The first step was to build awareness, the group working on the idea, held Q&A sessions with everyone in the organization. They presented their work and gathered feedback. Based on the feedback they refined their idea and its presentation. They then went out to hunt for the early adopters, people who were interested in change and wanted to experiment with YBIYRI. They soon realized they had no tools to assess the team's maturity, and their ability to support teams on their you build it, you run it journey was weak.

To cater to these problems, Stepstone took two initiatives, first, they ran highly specific assessments for Ownership models. It helped them gather data to understand the maturity levels of teams and also enabled teams to reflect on their progress. Based on the results from these surveys they established designated ambassadors (people who were good with particular topics) to support teams in different areas of the Ownership Model. The area ambassadors also created documents containing tips, tools, and initiatives, something resembling a cheat sheet to empower the other team members.

As of now, Stepstone continues to work with the same model and as per them, this change did work out well for them. However, they face some challenges in increasing middle management engagement and balancing short-term goals with long-term investments. Their current focus is on enablement, and implementing new tools and processes to accelerate the journey towards YBIYRI.

Recommendations and Key Takeaways from Stepstone

1. Start small: Begin by implementing YBIYRI principles within small, cross-functional teams to assess the feasibility of this approach and gather feedback.
2. Invest in Training and Education: Provide developers with the necessary training and resources to develop their skills in the areas they lack the required experience or knowledge. 
3. Measure Maturity level: Have concrete processes to assess the maturity levels of teams to measure the progress.
4. Establish Clear Processes and Guidelines: Define clear processes, guidelines, and best practices for developers to follow when taking ownership of their code in production.
5. Promote a Culture of Continuous Improvement: Encourage a culture of continuous learning and improvement, where teams are empowered to experiment, iterate, and learn from failures.
6. Share Knowledge: Encourage people to document and share knowledge within the team and also on the organizational level about the topics they have experience in.

What Do the YBIYRI Non-Believers Have to say & Is that true?

Despite some big tech companies adopting the approach and calling it the ultimate way of getting rid of silos, there are opposing views about you build it, you run it approach. While some people call it downright impractical and compare it to expecting an engineer to be able to fly a plane just because he built a part of it, others claim switching to YBIYRI just creates new challenges. From waiting on other teams to spending hours troubleshooting a pipeline they can’t understand, the bottlenecks just move from one point to the other. It also requires a great deal of experience and horizontal, cross-platform knowledge for developers to actually build, run, and maintain code. Moreover, the drastic cultural and organizational change may cost you product functionality or employees who don’t get on board. These are some challenges that may cause issues or sometimes prevent organizations from adapting you build it you run it, despite all the upsides of this approach. 

Implementing YBIYRI with the Right Tools

Most of the problems with you built it, you run it methodology lie in the fact that regular developers just outright lack the required experience in areas such as deployment automation, monitoring, and incident response.  Even if they manage to deploy and maintain applications at a smaller scale, things are likely to change for the worse, as soon as the application gets hits in millions. So adopting YBIYRI might mean letting go of otherwise valuable people in the process or having to find people with high levels of expertise, which in itself is a difficult task and gets expensive fast. This is where having the right tools can make a difference. Codesphere is a platform that can provide your organization with the tools that make you build it you run it easier. It can empower/enable an otherwise less experienced developer to develop, deploy, and maintain the code. 

If we expand on the previously mentioned example of building a house, Codesphere can provide developers with all the required tools they need to build that house. It is like being in a Minecraft simulation, where you just have all the required assets at your disposal. Codesphere not only streamlines and parallelizes the development process, the features like automated CI pipelines, autoscaling, and monitoring alerts take the deployment stress away from the developer’s shoulders.