In search of lost teams
A tech leadership expert explains why teams fail, and how to fix them
“Turn around where possible.” We all know what it’s like to be on a failing development team that’s going nowhere, stuck in a dead end of technical debt and spinning its wheels while everyone gets more and more miserable (and travel-sick). So, as a technical leader, how do you spot when your team is lost in the weeds, and is there anything you can do about it?
“Teams get toxic when you have multiple factions forming. People who feel bullied team up with others in defence, and it all gets nasty quite quickly.”
Mike Thomas is a highly experienced engineering manager and team leader with over 15 years in the web development industry, and he’s someone who knows a lot about finding and rescuing failing teams. Over the years he’s identified some key ways to tell if your team is in trouble, and he has some practical hints for tech leaders on how to get your paddle back and start reversing out of the particular creek you’re stuck in. He kindly agreed to share them with me for the blog.
“Sometimes, it’s the completely mundane things that have been driving people crazy. I’ve literally spent weeks mediating complaints of hot food in confined spaces.”
Give it to me straight, Doc. What are the signs that my team might be failing?
Feeling anxious and stressed about your business, a nagging feeling that everything needs to happen much, much quicker, and your developers/engineers must work harder and longer. Maybe deployments are tricky, and you find the team making excuses to not do that on a Friday. Agile is known as the ability to Yoda-flip between daily customer demands. Your go-to guy goes on holiday and the boat stops. You have a go-to guy. You only have guys.
Of course some people might think that this makes for a fantastic team, especially if you work in customer success or sales. And you might coast on that for a few years - you had early success - and the customer is number one. But customer led roadmaps leave no headspace for innovation. Overworked developers write short-term code with long-term consequences. Even if you have performance metrics, the figures are invariably used as a stick to beat them with. High bug rate. Technical debt. No new features get shipped, customers eventually leave because the competition is more innovative. They’re failing. You’re failing.
“Call out good work, and please, please, please find a way to reward it.”
What sort of metrics would you expect a team to be able to produce?
Cycle time of releases, up-time, rough date and cause of the last outage, average age of backlog items, critical bug rates - there’s so many things that should just rattle off the tongue of anyone in the technical team if they’re engaged and paying attention to their performance. This cannot be a one-way street though. It’s important that the rest of the business is focused on their own performance, because their inefficiencies can often morph into backlog tickets, creating awful feedback loops.
Where should I start if I don’t have any of those?
Assuming your business is concerned with time and money (extensive studies prove most of them are!) then I’d go with bug rates - not just as a measure of “failure”, but because they provide clues as to where you’re going wrong. Then the cycle time from requirement to release; this can lead to insights about your process bottlenecks.
Google has an excellent article called “Bug Prediction at Google”, which gives you some great ideas about how to make bug metrics useful, as opposed to just headlining bad news. Here’s a snippet:
“They found that simply ranking files by the number of times they've been changed with a bug-fixing commit (i.e. a commit which fixes a bug) will find the hot spots in a code base. Simple!”
So, identify the hotspots, and put warning comments in the file(s) for unwitting developers. I love the simplicity of that.
You’ve talked about ‘factionalism’ as a challenge for software teams. What is that, and what does it look like?
It’s quite an insidious problem that you’ll likely miss if you’re not keeping your team close. Issues can start where there’s a void of leadership, and unhappy individuals band together in an attempt to forge some common goals and unity which are sorely missing either in the team or business. Common goals and unity is not a bad idea if it involves the entire team, but it quickly gets toxic when you have multiple factions forming. Individuals start to feel snubbed—or worse, bullied—then they team up with others in defence, and it all gets nasty quite quickly with different groups pulling in different directions.
How on earth do you fix a team that’s so badly broken?
Fill that missing void of leadership. Start talking, start 1:1s, start retrospectives, and get some common goals on the table that everyone can agree upon.
Once you start talking to people, you start to figure out the root cause of their negativity and frustrations. If no one has been listening to these people, they’ll eventually let it all out, but sometimes you need to really home in and press a point to get to the bottom of it. Sometimes, it’s the completely mundane things that have been driving people crazy. I’ve literally spent weeks mediating complaints of hot food in confined spaces. Sometimes it’s less mundane: skipped code reviews, unscheduled refactoring. Sometimes it’s just plain bad: bullying, being unapproachable, general bad attitude behaviour.
Should I ask for help from senior management, or get HR involved?
Having a fellow manager to talk strategy with can help a lot when things are slightly toasty. I’d only really involve HR, if you have it, if someone has blatantly stepped over a line, or doesn’t show improvement. I think it’s important to say that although some of those things mentioned sound bad, a great deal of it can be perpetuated by good, but frustrated people acting out.
What’s your view on 1:1s? Do you have a set process?
I tend to rely on a more rigid process for new teams or team members. Mostly I focus on what’s been going well, and what’s not been going well, and aligning their work (as much as possible) with their goals.
I’m a big fan of Julia Evans, and she recently published a book called “Help! I have a manager!” which has this gem:
What I like about it is that its subject ideas are solely from the “reportee” side, rather than the manager. And that’s the point, really: the 1:1 is about them, and what you can do for them to get the best return on their time and commitment. Plus I like the fact that it’s a cartoon instead of a pretentious blog article.
What are the key things people should be doing to prevent teams from getting lost, and to get them back on track?
Have a strategy, make it visible, and shout about it often.
Have frequent "Town Halls”. Wheeling out the CEO once a year is not good enough.
Be transparent - tell us about the successes, and tell us about the failures. It’s amazing how many companies I’ve worked for where the pitches won and customers signed feel like a big secret.
Call out good work, and please, please, please find a way to reward it.
Thanks for sharing your insights, Mike! How can people contact you to get help and advice on tech leadership and engineering management?
My website is at https://michaelthomas.co/, or you can follow me on Twitter @determinedmoth.
You can buy Julia Evans’ comics. They are really good. Buy them: https://wizardzines.com/
You already give Google everything they need, but sometimes, they give back: http://google-engtools.blogspot.com/2011/12/bug-prediction-at-google.html
