March 30, 2023

Getting teams to evaluate their performance

There has been a lot of buzz lately around high-performing teams, team health checks, and ways to evaluate them in the right way.

For a few years, I have been developing my own approach in evaluating what I call 'team awesomeness' and I've found people around me seem very interested in how I do it. It may seem straightforward or a box-ticking exercise, but I think there are a couple of key factors that really make it impactful.

Make the evaluation meaningful

To start with, the self-scoring statements should be relevant and important to the teams filling out the survey. I do this by drawing on Lean-Agile principles, themes of diversity and inclusion, psychological safety, as well as company values in the context of the teams filling out the survey.

I like to run the questionnaire with cross-functional software teams, but it can be adapted for any type of team. I usually run them every 3-6 months, and compare the team with their former selves. Never compare a team to other teams!

The purpose of the survey is not to report to management but for the team to improve - it is important to communicate this to the individuals filling out the survey.

Design the survey for meaningful visualisation

One of the tricks I learned was to have every survey statement be answered with the same type of response. The likert-style scale is useful because it standardises the responses for rapid visualisation, and thus making meaning out of the data. It is typically a range of 5 replies, such as from "strongly disagree" to "strongly agree" or from "very dissatisfied" to "very satisfied". The responses I use in my survey are: Never, rarely, sometimes, often and always. Here is an example survey statement:

Our pace of delivery is indefinitely sustainable; risk of burnout is low.

Visualise and communicate the results

The survey can be administered in a number of ways. I typically use Microsoft Forms or Google Forms. Once they've filled out the survey, you can use clever formulas to take all the responses and generate a visualisation by taking the number count of each response option for each survey question. The full survey can then be visualised as a heat map using colour coding for the responses.

No alt text provided for this image
An example of visualisation heat map of responses to a survey for a team of 11 people


However, there is a crucial step that you mustn't leave out: review and discuss the results with the team! You'd be amazed at how many team coaches leave this step out. I typically have a stand-alone session, which can be as short as 30 minutes. Once discussed and you understand which themes the team values, you can then align on what improvements to work on together.

Let the team help decide what to take action on

During discussion of the results, I use facilitation techniques to find out which questions are important to the team, and which are less important. I can then find out whether a consensus can be reached on what area to work on. This is the moment where I typically am given permission to develop a short workshop to address the area of improvement.

Each item in the survey is associated with a theme. Themes can include psychological safety, company values, DevOps or Agile fundamentals. The example given above is related to the Agile Manifesto Principle number 8:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Keep the momentum by taking action

I typically like to develop, schedule and deliver a workshop to address the agreed-upon topic within a few weeks, so that we can form new habits as a team. This will give us some lead time to evolve before the next evaluation.

I typically run this kind of survey with a team every 3-6 months, depending on the desire for change.

Running the survey again in the future is where things can get interesting. You can start to identify things that are trending up and trending down, and communicate them with the team.

It is important to compare a team to their former selves, and not compare teams to each other.

I do not recommend reporting a team's results to management. If multiple teams are involved, results can be rolled up and anonymised for purposes of departmental performance reporting.

Try it yourself

If you're a team coach, engineering manager or delivery director, you should be able to run a team awesomeness survey by sticking to a few principles:

  • Make it meaningful
  • Design the survey in a practical way
  • Visualise and communicate the results
  • Let the team guide you on what is important
  • Follow through and keep momentum