How To Help A Struggling Team
Hey, Luca here, welcome to a new edition of Refactoring! Every week you get:
Here are the latest editions you may have missed:
To access all our articles, library, and community, subscribe to the paid version: 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:
Let’s dive in! 🥇 Most people want to do good workWhat 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 roomThere 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 visionOnce 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:
Think big, but also be realistic:
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 problemsThe 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:... Subscribe to Refactoring to unlock the rest.Become a paying subscriber of Refactoring to get access to this post and other subscriber-only content. A subscription gets you:
|
