When It’s OK Not to Focus on the Outcomes

In sports psychology, it's common to define three different basic types of goals:

• Outcome Goals, in wich an athlete focuses on the outcomes of an event or competition (rankings, podiums, points and similar).
• Performance Goals, which define the results the athlete will achieve independently of others or the ultimate outcome (for example finishing time).
• Process Goals are focused on specific behaviour during the performance itself (for example, applying proper technique).

Athletes are coached to focus mostly on performance goals. One reason is that reaching your performance goals is completely within your control. In many sports, your performance is not related to the performance of others. Think about track and field events, running, cycling or weight lifting. The second reason is that delivering on your performance goal will very likely have a positive impact on any outcome goals you have: If you are able to lift the weight you set out to lift, you will have done the best you can to realise your outcome goal of a good ranking in the overall competition.

Process goals are a useful measurement, too. Succeeding in your process goals will very likely have a positive impact on your performance and outcomes. Focusing on proper lifting technique will allow you to lift heavier weights, which in turn will lead to a better ranking in competition.

This idea of different types of goals can be applied to agile teams as well.

It's true that, ultimately, we should always worry about outcomes, because those outcomes are the relevant factors that drive our success.

But it can be beneficial to set performance or process goals, too.

In order to do so, you need to be sure that you can establish a firm relation between a process or performance goal and a desired outcome. In sports, the relation between performance and outcome is much clearer than in product development, but often, you can form a hypothesis that will be suitably robust.

For example, a team dealing with a legacy product with many known bugs might need to create a better user experience to avoid customers looking for alternatives and leaving. A low churn is the desired outcome, and the quality of the product is likely a big contributing factor to that overall goal.

The team might form a hypothesis of the form of "A low number of bugs will lead to a better user experience which will reduce customer churn".

But how are they going to define a goal around that? Using the outcome (customers not leaving) might be a terrible way to do that, because it's a trailing indicator, and we'll only know if we reached our goals at a moment when we no longer can do anything about it (after customers have already left). Additionally, there might be other factors of customer churn like price or service that might be outside of the teams control.

Instead of using an outcome goal, the team could define a performance goal, which focuses on what the team can control, for example the number of bugs closed per week. The hypothesis here would be that "Reducing the number of bugs in production at a rate of X/week, user experience will increase by Y.", both of which can be measured, but only the bug closing rate will be defined as a goal. (Let's set aside the question of which user experience measure we might apply.)

Another approach to this could be simply defining a process goal, for example "We will meet twice a day to find solutions to open bugs in production".

This is dangerous territory, because simply talking about bugs doesn't resolve them, and you somewhere have this assumption lurking around that after talking, someone will take action.

But defining such a process goal can still be useful:

• If a team is just starting out measuring things, process goals give you something that is easy to track.
• The link between following the process and getting a certain performance is quite strong within most teams.
• If the team is completely overwhelmed, they can focus on things they control.
• It helps you to create a habit.

The last point warrants some more attention. When we talk about process improvements, we often express that desired change as one-time interventions. Meetings are unfocused? Create an agenda. Too many bugs? Close more bugs.

What we really want to do is change a habit, break a habit or create a habit. Meetings are unfocused? Make it a habit to send out an agenda well before the meeting every time and for every meeting. The last part is often implied when it should be the main point of the message.

Process goals focus on the habit. Did we meet and talk about the bugs every day? Did we send out an agenda for all the meetings? No? Let's get back on track.

For long-standing issues, creating a new habit and starting to track how well you stick to it is often the first step out of stasis. It is still important to measure your outcomes. Otherwise you might fall into the trap of confusing the map with the territory. But it's ok to focus on the process, and define goals for that, instead of the outcomes.

Evolutionary change starts with one step, and sometimes, focusing on technique is a good way to do that.

Summary

While defining goals that are not directly linked to a wanted outcome is often seen as a bad way to measure things, defining goals that focus on what you do (process goals) can be beneficial when you are just starting out to use goal setting to drive change or when you want to create a new habit or modify an existing one.

When doing so, define a clear hypothesis how you suspect your process and your outcomes are connected and track the outcomes to validate your hypothesis.