Focus on outcomes over outputs

Software engineering teams should focus on outcomes over outputs to deliver the best user and business value.

Focusing on outcomes over outputs can be vital for teams to create solutions that drive real value and customer satisfaction. Before launching into how this can be achieved, let’s outline the difference between outputs and outcomes. 

Outputs vs. outcomes

While outcomes and outputs are two interconnected elements of the software development process, with both playing a critical role in the overall success of a project, it’s essential to distinguish between these concepts and understand how they inform your strategies and decisions.

• Outputs describe the result of an activity, for example, completing the shipping of a feature.
• Outcomes are changes in customer behavior that drives business results. This may look like an improvement in user happiness, which, in time, impacts business metrics like sales.  

Why are outcomes and outputs important to software development

Engineering productivity is made up of many parts, but outcomes stand out as particularly important. This is because they represent the real-world impact of the team’s work i.e., the changes that occur as a result of delivered outputs.

However, outputs do not automatically equate to value. For instance, simply shipping features doesn’t guarantee that they will lead to beneficial outcomes. 

Focusing on outcomes ensures that the team’s efforts are aligned with the needs of the customers and the goals of the business. It encourages the team to think beyond simply completing tasks and to consider how their work can create value. When the goal is defined in terms of desired results (outcomes) rather than specific tasks (outputs), it allows for multiple paths to success. 

Outcome-based leadership in software engineering

Leading teams by focusing on outcomes, rather than outputs, can transform the way software development happens. 

The team is no longer just writing code or building features; they’re working to increase user satisfaction, enhance user engagement, or drive revenue growth. This perspective can be immensely motivating and can lead to more meaningful and impactful work.

Outcome-based leadership also opens the door for creativity and experimentation. Teams are given the autonomy to figure out the best solution to achieve a desired outcome, which may involve trying different strategies, learning from mistakes, and iterating on ideas. It also reduces the chance of a culture of “busyness”, where the quantity of work is valued over quality or impact. 

Practical example: an outcome-based approach in action

Let’s delve deeper into the practical implications of an outcome-based approach using the example of Spotify, a popular music streaming platform. Suppose the company decides to implement a new feature that allows users to save their favorite songs quicker.

In an output-focused approach, the team’s goal would be to build and ship this feature. But with an outcome-based approach, the team would also be concerned with the impact this feature would have on user behavior and business metrics. They might hypothesize that the new feature would lead to increased user satisfaction, more user engagement, and ultimately, a rise in subscriber numbers and sales.

After the feature’s deployment, the team would then monitor key performance indicators (KPIs) to validate their hypothesis. If the desired outcomes are not met, they iterate on the solution by tweaking the feature or developing additional enhancements.

This example illustrates how an outcome-based approach can drive value and keep teams focused on the bigger picture, rather than getting lost in the minutiae of feature development.

When not to use an outcome-based approach

While focusing on outcomes can be immensely beneficial, it’s not always the most appropriate method. 

There are situations where concentrating on outputs is more fitting, such as routine maintenance tasks, bug fixes, or other well-defined, repeatable tasks. These are situations where the outcome is already known and the focus is on the efficiency and effectiveness of execution. 

In cases where there is little room for deviation or innovation, such as regulatory or compliance-driven tasks, an output-based approach might be more suitable. The value in these cases is derived from the execution of the task itself, rather than any change it might drive.

Addressing technical debt and code health

Technical debt and code health are critical aspects of software development that don’t always have a clear, direct link to specific outcomes. However, they can have significant long-term implications on the ability to deliver outcomes efficiently. 

Technical debt, if not managed, can slow down the pace of development, make the codebase harder to maintain, and increase the risk of defects. 

Similarly, poor code health can impact the team’s ability to deliver high-quality software consistently. Framing these issues in terms of potential future outcomes can help underline their importance.

For instance, investing time in refactoring code to reduce technical debt can be seen as an enabler of future outcomes. By improving the codebase’s health, the team can deliver new features quicker and with fewer defects, leading to improved user satisfaction and potentially higher business results.

A North Star for engineering teams

Ultimately, the goal of any software engineering team is to deliver value to the users and the business. This value is best measured not by the sheer quantity of features or bug fixes produced, but by the outcomes these outputs generate. 

In an increasingly competitive business landscape, adopting an outcome-based approach can be a game-changer. It enables teams to be more agile, innovative, and user-focused, allowing them to create solutions that truly make a difference.

However, as with any approach, it should be applied judiciously. Understanding when to focus on outcomes and when to focus on outputs is key to leading a balanced and successful engineering team.

For further insight on this topic, Outcomes vs. Outputs by Workpath is a good place to start.