YBIYRI*: why balancing autonomy with support is key to success

Last month, Atlassian published their first ever State of the Developer Report. One of the key findings was the rise of the *“you built it, you run it” (YBIYRI) philosophy, along with the need for greater autonomy among development teams to choose their own tools and platforms.

What is YBIYRI?

The term, first coined by Amazon CTO Werner Vogels, refers to bringing developers into the daily operation of their software, and giving them regular interaction with the customer. 

How does Adaptavist use YBIYRI?

Ever since we started building apps for Atlassian cloud way back in 2015, Adaptavist has been practising YBIYRI. During that time we have reaped the benefits and run into the sharp edges of the practice in pursuit of delivering the best possible products to our customers. Atlassian 's report emphasises autonomy for engineering teams, but the real benefits are to be realised when the whole team is given greater scope for authoring how and why, and deciding on tooling and new ways of working.

YBIYRI gives the responsibility to the team for all aspects of the product lifecycle. At Adaptavist, this means the team owns the direction and roadmap of the product, maintenance and support and, ultimately, are responsible for delivering value to the customer. 

Teams also own how they work, including development processes. The accountability of providing the team with all they need to be successful falls on senior leadership, as does the need to coach, mentor and give feedback to teams. Senior leaders set the standards and business frameworks that teams must meet and follow, putting the necessary oversight and policies in place.

What are the benefits and pitfalls of YBIYRI?

At the heart of YBIYRI are agile and DevOps principles, specifically customer-centric action, end-to-end responsibility and cross-functional autonomous teams. Development teams should no longer be following the antipattern of building something and then throwing it over the wall for operations to run and manage–they should have the customer at the centre of what they do, and the team should have all the skills required to execute on their mission.

While all of this sounds great, there are a few caveats. YBIYRI shouldn’t, and doesn't cover everything. Teams should have more autonomy than teams bound by legacy approaches. It’s not as simple as autonomous or not. The type of autonomy, and its boundaries, are important. They’re just as important as the foundations a YBIYRI team builds on.

For example at Adaptavist, teams don't run their own analytics platform or manage their development tools and hosting products on AWS as standard. Other organisations have an internal platform that must be used, but that freedom is provided on top of that, or a mandated framework and operating environment. 

Ultimately there is no "one size fits all" approach for enabling teams to execute using more autonomy. Context is key and any practice should only be followed if it meets the goals and intent of the team or organisation that seeks to benefit from adopting it. A common antipattern in this area is pushing teams towards being responsible for running the services they build without giving them the support they need, expecting a team of developers to operate a service on their own with no assistance, guidance or access to the tools needed.

Should you embrace YBIYRI if you’re not already practising it?

The short answer is, it depends. 

According to Atlassian's report, teams felt greater job satisfaction when they had more autonomy. But this doesn't necessarily mean everyone needs to adopt YBIYRI. 

In my view, giving teams the right level of autonomy with the support they need is essential. In all cases, autonomy means a level of trust, and that level will vary depending on your context, leadership style, organisational constraints, and the teams you're working with.