How targets prevent high performing teams

Group of business colleagues discussing at desk in office

We need high performing teams!

High performing teams bring value to our customers at a greater rate.  The faster we do that, the more competitive we are.

The use of individual performance metrics is a highly corrosive anti-pattern to the realisation of that goal.

Teams deliver projects, not individuals

In a follow-on post I’ll deal with the problems of targets even at the team level, but for now let’s concentrate on the problems they cause for individuals.

Let’s start by reminding ourselves of a key principle of the Agile Manifesto:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

High performing teams are made of motivated individuals who have had trust placed in them to get to a result in a complex environment containing many unknowns.  

Setting people targets just tells them that you don’t trust them, and that their work is so simple it can be reduced to a number.

Many aspects of Agile are about ensuring that software processes become fundamentally team-oriented. Those teams become empowered and self-organised to discover the unique process that will work for them. Every organisation is different, and most teams are composed of a set of individuals who have not worked together before. This unique set of factors is why a single prescriptive process or metric doesn’t work.

A common mistake in Agile adoption is to use it as the new top-down process of standardised micro-management. We talk of freedom and self-organisation but still have managers acting like hall monitors, keeping an eye on those unruly school children that can’t be trusted to run their own affairs.

A high performing team is the last thing that this will create.

Story points as a weapon

Story points can become an unintentional weapon in such a dysfunctional process.   We used to make people estimate in man days and justify actual effort against the estimates.  Now we ask team members to ‘own’ stories in a sprint and justify how many of those points they achieved at the end.

This is personal target setting, and produces many negative effects in an environment where the individual has insufficient control of the factors in meeting the target.  This is usually the case in software projects (waiting for stakeholders who are unavailable, and unforeseen technical difficulties, are the two majority causes).  

Target setting in these contexts weakens team bonds and reduces emphasis on doing the right thing.  It pushes people towards a less ethical mode of operation where everything becomes about beating their personal performance number.  We only have to witness the disastrous effect of many sales target regimes to see that.

The negative effects produced by targets in complex environments

We should remember that software projects are usually complex. It is not reasonable to expect team members to foresee everything, but setting targets tells them they should be able to do exactly that!

Whilst we are not talking directly about sales targets or financial compensation here, there are many similarities – in the case of assessment of “done story points” per developer as a target, we can foresee the following:

  • a reduction in willingness to help other team members (it will only make them look better at our expense);
  • weaker team members becoming even weaker over time, as stronger team members are disincentivised from mentoring them;
  • picking stories that look the easiest to achieve, pushing harder ones to later in the project and increasing risk;
  • gaming the story point system as the project progresses, exaggerating the number of points to make us look better;
  • deliberately weakening or undermining the “definition of done”;
  • discouraging the creative thinking, discovery and experimentation needed to reduce second order ignorance (the things we didn’t know we didn’t know), leading to higher risk of very nasty surprises in the later stages of the project.

That last point is serious – the early stages of complex projects need to be chiefly about shining a bright torch into those murky corners we didn’t even know were there.  Let’s get the nasty surprises out as early as possible. Such discovery cannot be quantified through numbers, and the organisation discourages it at its peril.

Celebrate the early discovery of bad news – don’t unintentionally encourage your team to bury it.

Assess individual performance only by exception

It is reasonable to wish to identify weakness, but not reasonable to do it using numbers that tell you nothing.  If someone is weak, you won’t need numbers to tell you. In such exceptional cases, you need to put in the leg work to properly assess their contributions (such as historical pull requests) to provide real evidence. Use this as input to a program of mentored improvement for that person.  If things go too far, it’s real evidence for no longer being able to work with them.

Using individual performance metrics is an alluring “fear response” to micro-managing people whose work you do not understand.  Instead, invert the responsibilities – make managers serve teams by removing impediments, and creating the trusted environment for the team to self-organise and become high performing. Where there are real concerns over individual performance, employ credible and honest methods of assessment.

This article about Google’s research into what makes the best performing teams is highly informative – it’s all about a safe and trusting environment, and actually far less to do with the abilities of the team members.  Google have a lot of data from which to draw these conclusions, and we should take notice.

Use real metrics to engage your high performing teams

Meaningful metrics in software development are a great driver of engagement and motivation. Team members want to know that their efforts have a purpose in the real world.

When you kick off your project define the targets through which you will assess the performance of the product, such as a 20% increase in sales, 20% reduction in customer complaints, or whatever other change in behaviour you want to cause. Without doing this, how do you know there was any point to developing the product?

As you deploy your software and measure those things, your team will gain great pleasure and motivation through seeing those targets being hit or exceeded, or learning why they weren’t and hitting them next time.  They will be desperate to meet or exceed those types of numbers.

And that’s how to motivate people and produce high performing teams.

Simon Godden 27/09/2016

Tags: , ,