How to Help a Struggling Team 📉
My favorite strategies to reverse course and create long lasting change.
Last month we had a great mastermind session about how to raise the quality bar of your team.
Intentionally, we kept the term quality generic. We didn’t want to fixate on code quality specifically, but rather on the all-round quality of the work of your team, which has many shapes and facets, and see what participants needed the most help with.
Out of the various stories, we spent a long time talking about how to help a team that was struggling.
I won’t go into details, because I don’t think these are particularly helpful: they may or may not apply to you. But I will try to take the best advice that was shared, and distill first principles and ideas that should be useful to most.
By the way, this is always hard to do, because of the Anna Karenina principle. Anna Karenina starts with a famous line:
Happy families are all alike; every unhappy family is unhappy in its own way
What looks as a witty statement about humans, is actually a precise property of systems whose success depends on a number of factors all working well.
Since failures are born out of deficiencies in any number and combinations of factors, the amount of different failure modes is bound to be high in any moderately complex system. Conversely, when success is born out of all (or most) factors doing well, it creates less variance.
But I digress!
Now, if we trust this principle, one way to treat this topic could be to model software engineering as a system, identify all these factors, and write recommendations for each of them. This is too hard though!
Instead, I’ll try to address this as a doctor who visits for the first time a patient that is not feeling well. Where do you start? How should you think at the system (the team) as a whole?
So here is what I would like to cover today:
🥇 Most people want to do good work — and they generally care about it.
🔭 Create a shared vision — setting a north star goal and rallying people around it.
🔬 Identify problems — figuring out what is truly holding the team back.
🎌 Find your allies — lasting change needs bottom up support.
📈 Create visible progress — create small victories, and show them!
💼 Help the team from the outside — provide external help once you can show momentum.
Let’s dive in!
🥇 Most people want to do good work
What does it even mean that a team is struggling?
Visible problems can be many — speed, reliability of commitment, accuracy — but there is one property, to me, that is the true mark of a struggling team: people have capitulated. They have gotten used to problems and believe they can’t be solved.
This is an important preface. Problems happen all the time, but as long as people are aware and working to do better, they are in a good place. Sometimes, instead, the same problems have been there for so long that people feel they have become a (nasty) part of your culture. Issues are evident, but people stop addressing them. They don’t even talk about them. It is what it is.
When problems are not addressed, you might think it’s because people don’t see them — especially if you joined a team that was already struggling, you might ask yourself: “how tf people don’t see how bad we are doing?!”
Well, they most likely do. But they also think there isn’t much they can do about it.
I have met and worked with hundreds of engineers, and I can confidently say >99% of people want to do good work. Our default state, as humans, is caring about what we do. When we stop, it’s because we don’t think it’s possible to do work worth caring about.
So what do you do?
🐘 Address the elephant in the room
There is a time and place for small wins and iterative improvements (we’ll see later) but when you are in a hole you also need a singular moment that starts the inversion. The moment you stop digging and start climbing back.
Hard conversations need to be had sometimes, and if you are in a leadership or management position, this might be one of those times.
In my experience, there are two main things that you need to address: 1) the team is, indeed, not doing well, and 2) you care about improving. That’s it! Chances are you don’t have to bring detailed proof or numbers, because people already know. They won’t be surprised.
But they need to hear it: the team needs to identify the fact that they are falling behind, and working to get better. So they need someone who 1) addresses the elephant in the room, and 2) brings the initial spark that eventually turns into momentum.
🔭 Create a shared vision
Once people agree the team is struggling, the next step is to create a shared vision for what a high performing team looks like.
This is useful to do before you even start to address problems. In an ideal world, ask people:
How would you spend your engineering time?
What would you work on?
How often would you ship features?
How would you work with product and the other stakeholders?
Which meetings would you have, and which not?
How would CI/CD work?
Think big, but also be realistic:
You might love tests to run instantly, but you should know that e.g. 15 mins is achievable, down from 1 hour that they take today.
Spending zero time on maintenance and tech debt is an impossible dream, but going from 60% to 30% is probably doable.
Visualize your high-performing reality. Imagine a sprint / dev cycle: what type of work do you commit to? How do engineers spend their time? How does communication work?
Try to run this as a mini-workshop, and write down everything. The goal is to create some initial momentum, plus giving the team a north star to work towards.
🔬 Identify problems
The next step is to identify what the struggle is about.
Before you talk any specific parts of the process, what are the visible problems in the team’s outcome?
Here are the four big candidates: