Understanding High Performance Teams in Context

An exploration into identifying signals and leading indicators of high performance software delivery teams

Photo by James Thomas on Unsplash

I am fascinated with the concept of high performance teams. What does it mean to be high performance? How does a team become high performance? Once they are there, how do they stay high performance?

Frequently we reach for lessons and analogies from sport and the military. I am an absolute sucker for a talk by someone from the top of their field, talking about the hard work, dedication and inspiration that got them there.

These talks are often inspiring and their broad themes are directional useful, they are not necessarily practical in terms of application. The accumulation of marginal gains is a compelling concept, but you probably aren’t likely to find yours by testing the aerodynamic properties of the latest technical fabric.

For Software Product teams that are lots of industry examples that are more immediately applicable. There are numerous frameworks and evidence-based methodologies to help you design teams, their interactions and metrics to set your teams up for success. Sooner, Safer, Happier; Team Topologies; and Flow Engineering are emerging as good models to draw on to help create winning environments and teams.

As a leader it is perfectly possible to apply these frameworks and set yourself up for success from a text book perspective.

But how can you judge whether things are working?

Applying High Performance Theory in Context

One of the first things to consider is what does high performance look like in your context?

Ultimately teams are judged by the outcomes they help create, but this can be challenging to do as there are so many factors involved, many of which are likely to be outside a team’s control.

Also outcomes are, by their nature, lagging. That is to say you can only measure them once they exist, which is after the work has been done. If you are to lean on a sporting metaphor, the final score is the outcome. You can only affect it before it happens. Thus you need to look at not just the outcomes, but also the inputs and outputs.

There are plenty of examples of the sorts of measures that can be applied to inputs and outputs, which trends to watch for and benchmarks to apply in order to give an indication of whether a team is pointing in the right direction to achieve the desired outcomes.

What’s in the box? Looking within the team itself.

Let’s return to the concept of high performance. The concept emerged in the 1950s and has been the subject of much research and discussion. Whilst there is a lot of great, and accessible, research into team dynamics and performance - Lencioni’s Five Dysfunctions of a Team being a personal favourite - I don’t believe that there is a single definition that everyone would agree on. Commonly cited¹² ³characteristics of a high performing team:

1. Goal Orientation: High-performance teams have a clear understanding of their goals and objectives and are aligned towards achieving them.

2. Collaboration and Trust: the teams exhibit high levels of collaboration, mutual trust, and open communication.

3. Shared Leadership: Leadership is distributed among team members rather than centralised in one individual.

4. Conflict Resolution: High-performance teams possess effective methods for handling conflicts in a positive way.

5. Accountability: members take responsibility for their contributions and actions.

6. Continuous Improvement: teams strive for continuous improvement in their processes and results.

7. Adaptability: they can quickly adapt to changing circumstances while maintaining focus on their goals.

These are largely qualitative by nature, which presents a challenge: how do you assess them?

An experienced leader or coach is likely to recognise whether a team is set up to be high performing based on observation. Making these observations is a crucial responsibility of leadership, along with giving teams the support they need to improve. But it takes time, and if you have a lot of teams this can present a real challenge. Equally, if you have limited frames of reference, spotting patterns can be challenging.

I’ve recently been working with some teams who have been operating and relatively stable for a couple of years. The outcomes their business is interested in are served by both teams, and those are tracking reasonably well.

By some measures, such as customer satisfaction, Team A would be considered high performing and Team B are merely performing.

So what’s the difference?

Both have a good period of reasonably stable velocity of work items done (if you care to measure that).

The teams have similar inputs in terms of capacity, skills, tools.

The organisation has a “ways of working” framework for software delivery, which the teams both follow. The framework promotes and supports practices that involve setting and achieving goals, collaborating, adapting, and continuously improving.

From a quick observation, the teams both exhibit characteristics that would be considered high performing and both seem set up for success. Yet they are not both achieving at the same level.

More data, please

My first port of call in these situations is always the team themselves. What do they think? What are their strengths? What are their challenges?

There is always gold in those conversations - the people at the coalface almost always have the answers.

These conversations always have a filter applied, whether conscious or unconscious, so, whilst a rich data point, they only paint some of the picture.

What was additionally interesting about these teams is that they had both been regularly conducting retrospectives, and these were documented, and I mean every comment captured, rather than just summaries. Even more gold!

Earlier in my career as a consultant I spent a fair amount of time pondering the opportunity for performing quantitative analysis of qualitative data. All the rich feedback data that you gather than add colour and depth to the sharply focused, black and white spreadsheets.

This was when word clouds were starting to be a thing. Remember those? You plug some text in, take out all the stop words (”the”, “a” and so on), and the words are arranged in the shape of a cloud, with their size based on their frequency. Thus you can gain some sort of insight or start to build a story.

Turns out this is now called data science. (To be fair, it probably was then, but I wasn’t sufficiently tuned in to notice).

So I pulled on my (metaphorical) lab coat and cranked out some python to build a pipeline to prep and analyse the data.

The pipeline was built with spaCy, which is a free, open source library for Natural Language Processing, and I used Jupyter notebooks to help with the workflow and infrastructure.

I took their retrospective outputs and plugged them into my data pipeline to see what we got.

The comparisons were interesting. There were definitely common themes, which are by no means unusual to see:

• data quality and environment management - things that get in the way and make it hard to develop and test

• dependency management - challenges with getting support from other teams

• capacity challenges - not having enough of the right skills at the right time, for a whole range of reasons, coupled with constant pressure to deliver more

So there are definitely factors that are impacting both teams ability to achieve their outcomes. Having the characteristics of high performance are not in themselves adequate.

And what about the differences between the teams? If they share the same external and technical challenges, are there other things that could contribute to the difference in their performance?

The thing that stood out with Team A was the amount of discussion about collaboration and communication. They actively raised social aspects of team dynamics - group work, support, gratitude, and techniques that are actively collaborative and support the building of trust, such as swarming and mobbing.

Sidebar - swarming is a practice where if a problem arises, the team all move to focus on that problem to get it solved. Mobbing is a collaborative practice where multiple people work together on an activity, in a similar pattern to pair programming.

The other, crucial, thing that came through in the language used was Team A displayed more of a bias to action. They generated well defined actions and talked about whether they had been effective.

Signal, noise and the notes not played

Jazz music is often said to be as much about the notes the musicians don’t play as those that they do. The methodology, if you can call it, that I employed here is limited. The analysis was purely based on the data available. The patterns in the data came only from what the teams discussed. There are plenty of other things that never came up in the conversations I analysed that could be what the teams need in order to drive their improvement.

This is something that is particularly pertinent at the moment with the rise of GenAI and LLMs, and the seeming ability to quickly generate a plausible answer to any question.

They are amazing tools, but need to be used with judgement and critical thinking. For one thing, their frame of reference is determined by the data they are trained on and the biases built into algorithms that are employed in their construction.

I also need to acknowledge the ethical concerns of using data in this way, and the downside risk of comparing teams. I recommend treading very carefully, collaborating with the people involved and being transparent about what you are doing.

Streetlights and Shadows

At the risk certainty of repeating myself, I will once again draw on the tale of the drunk man who looks his lost keys where the streetlights cast their glow, as that is the only place he can see. By only measuring the easy and obvious things, or relying on what comes out of the box in your workflow systems, you risk missing out on a lot of potentially useful information.

The proliferation of collaborative tools that document everything, and the increased accessibility of analytical tools mean that there are huge opportunities to find signal in new and interesting places.

I don’t think everyone should construct everything for themselves from first principles, and I absolutely do advocate for drawing on evidence based frameworks and approaches such as Team Topologies. We can all benefit by standing on the shoulders of giants.

The best of these frameworks recognise that a team is not an island, rather it exists in a system. You can’t judge high performance of a team in isolation of the system, which requires a wide range of data and understanding of context.

My belief is that the organisations and teams that apply these frameworks and new techniques with the right framing and thinking for their context will be the ones that flourish in the future.

1. https://en.wikipedia.org/wiki/High-performance_teams

2. https://oxford-review.com/research-downloads-home/high-performance-teams-special-report/

3. https://www.iod.com/resources/employment-and-skills/how-to-build-a-high-performing-team/