Negative velocity: how to lift the complexity limit

Reaching the complexity limit may feel inevitable, but there are some indicators that teams are approaching their limit. I’ll preface this by saying there is no absolute metric that tells you how close you are to the complexity limit, but these indicators may help you identify how close you are.

The clearest indicator that a team has reached the complexity limit is when they spend more time navigating organizational complexity than solving the gnarly problems they should be focused on. Trending the DORA lead time for changes (speed), and change failure rate (quality) metrics show if teams slow down or speed up over time. Though there are other factors that influence these metrics, they’re a good indicator of team effectiveness.

Developer satisfaction is another indicator of how much organizational complexity software teams are navigating. More than any other role profile, developers love spending their time solving gnarly problems, while equally loathing unnecessary tasks that get in the way. Low developer satisfaction is a good indication that organizational complexity is an issue for your software team.

Reaching the complexity limit may feel inevitable, but there are some indicators that teams are approaching their limit. I’ll preface this by saying there is no absolute metric that tells you how close you are to the complexity limit, but these indicators may help you identify how close you are.

The clearest indicator that a team has reached the complexity limit is when they spend more time navigating organizational complexity than solving the gnarly problems they should be focused on. Trending the DORA lead time for changes (speed), and change failure rate (quality) metrics show if teams slow down or speed up over time. Though there are other factors that influence these metrics, they’re a good indicator of team effectiveness.

Developer satisfaction is another indicator of how much organizational complexity software teams are navigating. More than any other role profile, developers love spending their time solving gnarly problems, while equally loathing unnecessary tasks that get in the way. Low developer satisfaction is a good indication that organizational complexity is an issue for your software team.

When companies realize their teams are drowning in complexity, they often start a “simplification project”, aiming to restore simplicity in their organization. Simplification is a losing strategy for two reasons; complexity increases faster than any organization can simplify its environment, and these “simplification projects” operate in the very same complex environment they aim to simplify.

A common starting point for simplification is to reduce the number of applications by decommissioning or consolidating where possible. Decommissioning an application requires the team to understand all upstream and downstream dependencies, who the uses the application, how to replace the functionality, where and how the data will be archived or migrated, and deal with a host of other complications that arise with this type of work. Unfortunately, the significant investment in effort required to do this is not rewarded with an equally significant reduction in complexity. There is a limit to the amount of applications a company can decommission without impacting core business or user experience, but there is no limit to how many new software components engineers can create. In the 12 months it takes to decommission one application, it’s likely that hundreds of new microservices have been created. Since a healthy technology environment grows over time, it’s not practical to keep the environment to a fixed number of applications or software components to reduce complexity.

Simplification projects typically include reworking the organizational structure to remove complexity in communication flow. The least complicated organizational structures involve large hierarchical teams with all staff co-located. The most complicated organizational structures involve small, distributed, and autonomous teams. Conway’s law shows us that large hierarchical teams are likely to produce monolithic applications, while small distributed teams are likely to produce applications using modular architectures like microservices. Producing high-quality software at speed is enabled by modular architecture patterns such as a microservice architecture, which means the more complex organizational structure is more likely to lead to success. While “simplifying” the organizational structure makes it easier to understand, it is counterproductive to the ultimate goal of the simplification project.

Simplification is important and worthwhile, but is best built in as continuous improvement for software teams (and teams of teams) rather than a one-and-done activity. Simplification may delay reaching the complexity limit, but will not restore an organization to the fast-paced freedoms enjoyed in a startup environment.

To return to software team effectiveness, organizations need to raise the complexity limit. Lifting the complexity limit essentially means increasing the amount of organizational complexity each team can navigate before it impacts job satisfaction, and the quality and speed at which the team ships software.

Platform engineering is an important concept in the quest to lift the complexity limit for an organization. Strong platform engineering teams focus on reducing the cognitive load of software teams by abstracting organization complexity from their day-to-day work. When implemented correctly, platform engineering enables teams to rebalance the bulk of effort towards solving gnarly problems, with less time spent navigating organizational complexity.