"Move fast and break things" - Facebook's infamous motto was a message to their team to choose speed in the trade-off between quality and speed. For years this trade-off was taken as fact - you could either move fast or you could build a high quality system. Luckily, we have learned that this is a false compromise - with test automation and continuous integration pipelines you can get high quality at high speed - or move fast without breaking things.

So now all we need to worry about is the trade-off between speed and product size. The prevailing wisdom is that the larger a system gets, the more complex it becomes and this slows down delivery over time. Teams are larger so alignment becomes more difficult, product decisions take longer because you need to think through the impacts on existing features, design decisions take longer because you need to ensure consistency across the product, and development decisions take longer because you need to identify the knock-on ramifications of changes in the code.

This leads to a lot of products suffering from the curse of success - the pace of delivery slows under the weight of the existing product. But, like the speed and quality trade-off, speed and product size is a false compromise as well. You just need to take advantage of the tools and techniques already available.

Process

There are two key ways of thinking about process - "move information to the authority" or "move authority to the information". The traditional project approach uses the "move information to the authority" approach. Business cases are created with fixed scope and the work is handed to the delivery teams. Inevitably issues are found with the original scope because we know the least about what we need to build at the start. The best information about what changes are needed is at the team level but the authority to approve the changes is a few layers higher. And like the kids game, telephone, the message gets distorted on the journey.

At UXDX, we run events around the world and we always ask what are the biggest challenges facing teams. The responses are surprisingly consistent regardless of location:

44% of people flag the inability to fix problems in the product because they are not in scope as one of their biggest challenges.

These problems, or put another way, these product, design and technical debts, are the real cause of the slow down in development speed because they increase the complexity of a system. But where do we track these issues in a project world? Each project is concerned only with its own scope. Any work outside the direct scope is a risk to the "predictability" metrics of time and cost. And because each project is measured in isolation nobody is managing the fact that projects keep taking longer and longer over time. In fact, these predictability metrics exacerbate the problem by encouraging teams to cut corners to hit a short term deadline, which increases the complexity of the system.

Make Sustainability a Key Metric

Peter Druker famously said, "you can't manage what you can't measure". So to fix the sustainability problem we need to make sustainability a key metric for delivery. Fortunately, there has been a lot of research done by Nicole Forsgren and her team at DevOps Research and Assessment (DORA) on how to measure a team for high performance and they have come up with 5 key metrics: Lead Time, Release Frequency, Failure Rate, Mean Time to Recover and Availability.

The first two metrics: Lead Time and Release Frequency measure how quickly a team can release the features that they are working on. The benefit of these metrics is that they force teams to work in smaller batches, allowing them run quick experiments to validate ideas before committing too much time. The remaining metrics make sure that teams aren't breaking things as they speed up. But there is an important difference between these metrics and the traditional long testing cycles approach to quality - recovery is as important as change failure.

In Ryanair, every product team can release to production. To counter the risk of teams pushing bad code they are all given a traffic light rating - Green is full trust, Orange means something has gone wrong in the past and requires an approval step whereas Red means the team needs attention. Teams all start on Green (start with trust) and they move down if they have a failed deployment. But crucially here, a failure counts as one that lasts for more than 5 minutes in production. To counter the fear of releasing they have told teams that if you can recover quickly (back out the change) then it is not even seen as a failure.

What these metrics do is get teams to focus on making their products more resilient. If you are being tracked on how quickly you can release then you will need to ensure that you are regularly paying down the product, design and technical debt. But, as we've seen with the project way of working, if teams have to wait for approval to do this it doesn't happen. To fix the problem we need to shift to a "move authority to the information" approach and empower the teams to maintain a high-quality solution while also making them accountable for product outcomes. This makes the team, who know the most about the product and customer needs, responsible for finding the right balance between feature work and sustainability work.

It's All About The People

We've taken quite a cold view of sustainability so far, focusing on the metrics and the work practices that are key to enabling sustainability, but these miss the bigger picture. Sustainability is all about the people doing the day to day product development work. These people have years of accumulated knowledge about the business goals, customer needs, product direction and embedded practices. The biggest drop in productivity comes from losing the people in your team. If 44% of your team are frustrated with the way of working this can lead to two problems - they check-out but stay in the job, working at a fraction of their potential, or they leave. Both situations are bad.

Luckily, using the research from DORA again, people in companies that exhibit high-trust product team structures are 1.8 times more likely to recommend their place of work to others. By shifting your way of working you can also increase team motivation and engagement.

What is the key to sustainability?

Sustainable product development comes from highly motivated and engaged people given ownership and responsibility for a product and it's related business outcomes.

We need to shift our metrics from "predictability" metrics like time, cost and scope to "sustainability" metrics like average lead time, release frequency, average failure rate, mean time to recovery and availability. This, in turn, requires a shift in our way of working from fixed-scope projects to empowered product teams, which, in turn, helps to engage and motivate our people.

Its a tough journey, and there are many challenges to overcome with decentralised teams including setting the right boundaries between teams, enabling independent release paths for teams, ensuring consistency across the company and ensuring everyone is aligned in the right direction. But the benefits are worth it - companies that make the shift are twice as likely to meet or exceed their organisational performance goals.

As the saying goes the best time to make the change was yesterday, the second best time is now.