Goal setting for software teams: 99% of your problems are goal problems

Photo by Katie Moum on Unsplash

If you work in any sort of software development role, you’ll be familiar with disagreements. Disagreements about architecture, about what type of user research to do (or whether to do any at all), about user flows, about functionality, about the time something should take, about the colour of buttons.

These disagreements are rarely because people have bad motives, are unskilled in their roles, or are poor decision-makers. They are almost always because of goal misalignment, and a great deal of time, effort, and general disgruntlement can be saved by focussing on goal alignment rather than on those disagreements.

Set goals

There are a great many approaches to setting goals — from ways to phrase them, through ways to explore them, to methods for workshopping them. But broadly, every software project or initiative or iteration has goals.

At their basic level, goals tend to have the following characteristics

1. They change something for someone (usually a person, or an organisation)
2. They make things better in some way (easier, more enjoyable, possible, more lucrative, more maintainable)

Often, they have a couple of other characteristics

1. They try to avoid making something that already exists worse when making this improvement
2. They have critical constraints (often time, sometimes technology, or people)

Many software initiatives will have several goals, perhaps across different actors in the system, or across different aspects of the improvement to achieve. A good goal is also going to be paired with a measurable outcome that defines what success looks like.

For example, goals for a project could be:

Enable people who pay a subscription to change the level of their subscription flexibly, to account for when they are on holiday or closed

• 9/10 subscribers can find and understand this functionality without training or support
• This functionality is available by 31st March, to meet the legislative deadline
• The overall revenue received from the product does not decrease due to this change
• The number of inbound calls to the contact centre does not increase due to this change

Software teams and projects inevitably have to make trade-offs, and clear goals are fundamental to enable teams to make the right trade-offs.

Failure point 1: Goals are not defined. A common problem is that an activity has started in earnest (e.g. “Flexible subscriptions”) without the goals for the project being defined, or with key elements of the goals (e.g. “don’t reduce revenue”) assumed but not expressed.

Be explicit & consistent about goals

While writing things down is not sufficient, it’s really useful. Writing things down in a visible, shared space is even more useful. People will leave and join the initiative, and other people will inevitably forget as time passes.

Repetition is also a useful tactic: restating the goals at the beginning of almost every conversation can feel tedious, but it is probably only when people have the goals firmly cemented in their minds that you are truly being boring.

The lack of clarity about what the goals are is often apparent only when some level of detail is being disagreed on.

For example, for the project above, let’s imagine you’re in a meeting where the product person is proposing a subscription management page in the application, which lets users pick a different subscription level. The developer calls out the technical challenges in doing so and suggests just adding the contact centre phone number and some text instead.

“You’re making it over-complicated,” the developer complains. “But what you’re suggesting will make for a poor user experience,” the product manager retorts.

Failure point 2: People don’t know what the goals are. Often even if the goals are defined, not all of the people involved in the project know what they are, or they forget over time.

Update goals when they change, or are refined

We all know that the world is always changing, and that plans, objectives, and solutions must be able to change with it.

Something that can happen though is that although the work changes, the goals themselves are not updated. This can mean that some people are working towards the old goals, while others are now working towards the new ones. Again — this is often surfaced only through debate or disagreement about the details.

For example, imagine that the legislative deadline moved back by two months, but the project goals weren’t updated. Maybe two or three people are really clear about this change, but others on the team aren’t.

The existing architectural approach is based on having to take an undesirable shortcut to meet the deadline, and this decision was made months ago. Now someone is challenging that decision and arguing for it to be done properly. Perhaps they are accused of being “unrealistic” or “idealistic” while others are being “pragmatic”. But perhaps some of the team simply don’t know that the goals have changed and that what was initially ruled out is now possible.

Similarly, it could be that the goals initially defined weren’t quite right and need refining. For example, the goal stated above includes avoiding an increase in the number of calls to the contact centre. But perhaps what was really meant was any increased demand on the contact centre. So a solution that was based on generating emails into a contact centre queue wouldn’t be appropriate either — but if that goal has been refined in someone’s head but not updated with the team, we may again go down the wrong path or end up disagreeing about that solution without being clear about why.

Failure point 3: Goals change but people don’t know. Even when goals were defined and people know what they are, they may well change. This may have a big impact on the solution, but it will be difficult for the team to adapt if they are not all aware.

99% of problems are goal problems

The vast majority of problems and disagreements in product teams are directly or indirectly related to one of these three things:

1. Clear goals aren’t defined, or important elements are missed
2. People on the team don’t know what the goals are, or forget over time
3. The goals change or are refined, but this isn’t explicit and known by all

For teams that are happier, move faster, and deliver better outcomes, spend the time to express, embed, and update your goals.