Maintaining a High-Performing Team

I’ve read lots of blogs on “Creating” a HPT, but few on how to maintain them when you’ve got them.

This blog is just one way of maintaining them, my way.
I’m sure there are other methods people have employed.

What is a High Performing Team?

Let’s define our terminology, so you know what I mean when I say “High Performing Team”. A high performing team is accountable to each other, there is trust, and they are all moving in the same direction. Generally we might summarise this as “High Performing Teams are Psychologically Safe, and as such conflict is creative and work is completed at a fast pace to a gold standard.”

by Lenny LaCour

Building a High Performing Team

I’m not going to go into this in detail here, I’ll link some good blogs on the matter, in short, give clarity to the team on what everyone’s role is, collaboratively agree on your goals and what is important to you, iterate on these through several cycles until you are in a good place.

1. 5 Simple Ways To Build A High Performing Team Plus An Awesome Tool To Get Started
2. Common Characteristics of High-Performing Teams
3. Framework for Assessing High-Performing Teams
4. What is Forming, Storming, Norming and Performing?

Also known as Forming, Storming, Norming, Performing from "Framework for assessing of high-performing teams"

Maintaining a High Performing Team

Okay, so you’ve built your HPT and everything is going well, your team is happy and cracking through the backlog.

How do you maintain this state? (spoiler: you don’t)

If we think of the Team as a Car, then there are lots of ways we can envisage how to do maintainence the High Performance nature.

Firstly, we can perform regular check-ups, are we well oiled as a team, are there any warning lights coming on? This is where your Retrospectives come to play; ensure you occasionally mix up your retros (or change every time), to ensure you don’t fall into the same patterns and miss the blind spots those patterns have. If you’re always asking “What Went Well” and “What Didn’t?”, you miss out on things which were fine, or might go wrong, but just haven’t yet.

Secondly, flag your warning lights to a trusted colleague. Your team should be psychologically safe, therefore if something is annoying you, check in with someone else on the side, if they’re also struggling then the two of you can work together to raise or solve it, if the problem doesn’t frustrate them, they maybe able to see why something is happening and help you to resolve it. AKA find or be a Rubber Duck.

Making space for the Team

"Okay Tim, I’m doing all of this and my team is rocketing through the backlog, we’re just about to deliver another Feature the customer wants and everything is a-ok."
"Is it though?"

On the surface this looks great, this is your High Performing Team doing HPT things, you have a feature rich ecosystem and your retrospectives are all producing small actionable items and the team is happy.

But what if you’ve been going like this for a Quarter/Half year?

• Is your team on the edge of burnout?
• Do you have capacity to react?

Back to the Car analogy;

| If I am in the highest gear and at the top of my speed, I’ve got nowhere to go. If something suddenly pulls out, I can’t accelerate round it, my choice is slam on the brakes or crash, neither of which is going to do my car good in the long term (or in the case of crashing, the short term). |

We need to take our foot off the gas.

Rather than wait for something to force us back into “Norming” or in anyway break that High Performing flow, we can choose to stop High Performance.

I’ve done this in several ways with different teams, at different companies, it all depends on the setup, demands, etc. You may not be able to do this with the whole team at once but maybe you can do this in a split 50:50, 25:75?

• Post-Feature cooldown: you’ve just shipped MvP, or V2 of a feature, it’s with the customer and you know you’ll soon get feedback. You almost certainly built up some tech-debt in feature dev, if you don’t think you did… ask your Developers, because, let’s be real, you have tech-debt, everyone does. If you use a week/sprint to tackle the tech-debt from that feature, then it’s a molehill, if you leave it, it’ll become a mountain. By the time you’ve tidied up, you’ll either be ready for the next feature, or you’ll have feedback for your next iteration/bug-fixes.
• Firebreak: We’re trying this right now on my current project. Taking a week out of normal sprint activity, to recharge those batteries, get on some learning (which will inevitably pay off for our upcoming work), catch up on admin (issue management etc) and write some blogs (this one here). For teams without common Features, or other clean breaks, the idea is that every N sprints or weeks, you take time out to catch up on tech-debt etc.
• Onboarding: if you’re onboarding someone new, a good way to ensure they don’t get left behind is to slow down, work on those tech-debts and use it as a way to give them a great overview across the system.

You’re deliberately choosing to drop out of high-performing, so that it’s a lot easier for you to step back into it; the engine is still well oiled, the gears are smooth, you can hit that pedal and get the acceleration.

If you leave it until something broke, you’d almost certainly have to fully rebuild the High Performing team, which would take a lot longer and be more mentally taxing.

Go slower Now, to Go faster Later.