The philosophy of “you build it, you run it” allows teams to flourish in the midst of their autonomy.
The philosophy of “you build it, you run it” empowers teams to fully own their work. In 2006, Amazon’s CTO Werner Vogels explained, “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 engineers into contact with the day-to-day operation of their software.”
When I began my tech career in 2014, this approach was uncommon and sometimes considered impossible to implement. Fast-forward ten years, and the tech industry has evolved significantly, and this philosophy is now more prevalent.
“You build it, you run it” means the same team responsible for writing the code also deploys and maintains it in production. This model addresses inefficiencies in traditional methods, where accountability was spread across multiple teams. Even though the benefits – such as breaking down silos and speeding up software delivery – are clear, organizations must strike the right balance to see success.
Embracing “you build it, you run it”
In one of my first interviews for my current position, my manager opened the floor with, “We do ‘you build it, you run it’ here. Are you familiar with this approach?” While I had a good theoretical understanding, I had almost no practical experience, which I candidly admitted.
When I joined my product team, it consisted of just three engineers working on a product coupled with a vendor solution we needed to replace. Our product was more of a platform instead of a user-facing system, with an API serving as our integration point. My initial thoughts on how to set the new team up for success while adopting a “you build it, you run it” culture revolved around the four themes below.
1. Ownership and accountability ensure a long shelf life
It’s crucial for the entire team and organization to remain committed to following the principles of “you build it, you run it.” This means all teams must accept full responsibility for their own product.
As a leader, you need to clarify your team’s product domain and define the established ways to interact with other product teams, preferably facilitated by a platform team using sync or async APIs. For us, domain-driven design has been helpful in defining the boundaries within our subdomain and establishing contracts between teams. These boundaries may expand or shrink over time, but it’s in the leader’s best interest to ensure the team always understands them.
However, it’s important to remember that teams will still need to communicate and there will be dependencies. One useful observation I made was that fewer dependencies often led to reduced cycle times and increased velocity. In other words, the less we had to interact and align with other teams, the faster we could deliver. This aligns well with Netflix’s culture concept of being “highly aligned and loosely coupled,” where teams are unified with their strategic goals but autonomous in how they execute to get there.
Loosely coupled product teams can move quickly through large-scale changes or deployments, as they have the freedom to work independently of others, but it also places greater responsibility on engineering leaders to maintain strong alignment across teams. To achieve this, leaders should stay organized and consistently review progress.
Ensure the team understands how each user story (feature written from the end user’s perspective) ties into organizational goals. Regularly reflect on progress toward objectives after each software increment. This practice enhances alignment and boosts motivation by clarifying how individual contributions support broader goals.
In my team, each individual evaluates our progress on objectives before the end of every sprint, and then we discuss the results during our sprint review. This helps us identify and address any discrepancies in how we perceive progress.
2. Recruiting new members with a versatile skill set
As the product scope expanded, we began looking for a new engineer to bolster our product. In a company with a strong culture of “you build it, you run it,” we focused on finding candidates with versatile skills so that the team’s dependencies were reduced in the development process. But people cannot do everything – there are cognitive and motivational limits. While there isn’t a clear-cut rule about what areas should always be covered by the product team, I believed that for our setup to work well, our engineers needed to cover the following:
- Coding
- Testing
- Code reviews
- Infrastructure
- CI/CD
- Architecture
- Incidents
- Advising and supporting stakeholders
- Documentation
The first three activities are naturally part of every software engineer’s job. Historically, though, the other activities were often handled by separate teams, with the structure varying by organization.
There is a lot of breadth in skill set here, so before you consider following suit, think about whether you need specialized roles within your team (e.g., QA, architect) or if a generic engineer archetype can cover everything. This approach reduces bottlenecks or delays in cases where people would have to wait on specific roles like QA to complete their work.
To my surprise, recruitment wasn’t as big of a challenge as I’d expected. Initially, I anticipated reluctance towards such a versatile role, but the sentiment was positive. Every few months, we added a new team member eager to embark on this journey to improve our product. The appeal was clear: the chance to push their work to production with minimal delays.
Drawbacks to consider
Our “you build it, you run it” approach encouraged versatility, but it also revealed the drawbacks of not having specialized roles. We had engineers testing their code, ensuring it worked as intended and avoiding delays from waiting on a QA engineer. However, we missed out on the expertise a dedicated QA specialist could bring.
QA engineers don’t just test code; they assess the entire application from a user and business perspective. They conduct thorough end-to-end, manual, performance, and regression tests. By relying on engineers to test their own work, we lacked these broader insights, which are crucial for delivering a well-rounded, user-focused product.
However, since our user base was limited to other engineering teams interacting with our API, we managed without a specialized QA role, even though our retrospectives often emphasized the need for increased focus on testing (e.g., end-to-end tests). I would highly encourage a closer look at the QA role for user-facing teams where extensive testing is business-critical.
More like this
3. Strong technical foundation streamlines the path to production
Implementing a “you build it, you run it” philosophy requires a robust technical foundation to ensure engineers have the tools, resources, and processes to own their products. Without a strong technical foundation that eases the cognitive burden, aiming for autonomous teams managing their own production software is a risky endeavor with unpredictable outcomes.
What, then, should the organization provide in its tech foundation toolbox? The answer depends on multiple factors, with size being a significant one.
Smaller organizations, for example, are often less inclined to build specialized teams due to the associated cost, but over time, with growth, this usually becomes inevitable. The best approach is to observe and identify the most painful areas in the software delivery process and subsequently evaluate whether to create specialized squad(s) to address them. This targeted focus helps streamline the path to production. However, to maintain team autonomy, try to avoid creating too many specialized teams.
In larger organizations, though, specialized teams often exist as a legacy from past IT structures. The approach here is similar: observe and identify which specialized squads are helpful and which slow down the entire process.
Should you worry about infrastructure?
One area that may be a roadblock to a “you build it, you run it” model is infrastructure. Historically, there was a clear distinction between software engineering and infrastructure engineering. However, the rapid adoption of cloud services has significantly reduced this divide, allowing teams to make architectural changes without the involvement of infrastructure teams. Serverless offerings from major public cloud platforms have made infrastructure much more accessible to software engineers, which is why my team aimed to use it. But even with these advancements, cloud governance – ensuring compliance, standardization, security, networking, and cost transparency – remains a complex task that shouldn’t fall entirely on product teams and would be better managed by specialized teams.
In my case, the team’s skill set was versatile enough to assess and choose the right services, integrate them into a cohesive architecture, write infrastructure as code, and implement security best practices. However, this does not take away from the fact that we sought to eliminate as many challenges as possible to certify better control of our product development.
4. Ways of working
As a leader, it’s your responsibility to facilitate the introduction of processes and methodologies that define how the team develops and operates the product. A leader is not a “doer” but rather an “enabler” who elevates the team’s confidence.
While some processes, like onboarding or a definition of “done” apply to all teams, others depend on specific technical and organizational needs. For instance, another team may have to handle day-to-day incidents, so that the product development team can focus on development. In such cases, responsibilities should be clearly defined to ensure smooth handovers between teams.
The question then arises: what ways of working do we need to establish, and how? There may not be a definitive answer, but a guiding principle can help. Any activity essential to delivering and operating software in production – something that can’t be outsourced – should have an established procedure within the product team, such as release procedures or on-call support.
Final thoughts
The “you build it, you run it” philosophy empowers development teams by giving them complete responsibility for their software, leading to faster delivery, fewer silos, and greater job satisfaction. This works best when there are clear agreements on what each team is responsible for and where they can get support. These agreements should be made at both the organizational and team levels, with flexibility for teams to offload functions when necessary.
While teams benefit from being loosely coupled, challenges can arise in maintaining tight alignment with organizational goals. It’s a leader’s responsibility to ensure their team’s efforts contribute to the overall objectives of the organization.
