Healing a Burned Out Team

Googlers sometimes tell a joke that at Google there are always two solutions to a problem: a prototype which isn’t ready and a working solution which is already deprecated. It’s funny, except it isn’t funny. It’s a joke, but it’s not actually a joke, because it’s true, and it’s not Google, it’s every company with more than a couple hundred engineers and that has been around for over four years.

You hear stories of small startups replacing Cassandra with PostgreSQL over a weekend or rewriting their service in Go in a development sprint, but as companies grow to 10,000s lines of code and hundreds of engineers, technology migrations become extraordinarily complex projects which take years to complete, but which are typically viewed as low status work.

When I started my first at Yahoo! in 2008, they were in the process of migrating from cvs to svn. I can guarantee two things about that effort: first, that it took years of grueling effort, and that the team working on that migration did not feel appreciated for those years of labor.

These migrations are fascinating on a number of dimensions: how to avoid them, how they can be conducted effectively, how they reduce your organization’s ability to plan or forecast, and how they can provoke an entire team to burnout.

This post will focus on the last.

Team Burnout

Teams burn out when they are doing too much work, which isn’t interesting enough, and without enough recognition. While an individual on your team burning out is generally a structural problem, when an entire team is burned out, it is always a structural problem.

The best way to fight their burnout is by attacking the definition:

1. They’re doing too much work, so find ways to reduce their workload. This might require reopening timeline negotiations for the current project–which is painful for you as a manager–but is less painful than your team dying inside a little bit each day.
2. Step back from a recurring task and find a way to make it more interesting. My theory is that any project can become interesting when you reframe it as an automation and tooling challenge. Perhaps there is a sufficiently advanced tool (indistinguishable from magic?) you can build which will eliminate the manual components of the migration, or an architectural approach which can make the transition seamless (maybe adding a proxy with the old interface on top of a new backend). Look for it!
3. Never stop telling the story of why their work is important and how it’s enabling some kind of major improvement (if it isn’t, then figure out why you’re doing it and consider not doing it). In particular, keep telling this story up your management chain so that your team can hear the message from more than just you.

Over time, healing a wound comes from addressing its origin, but if you’ve just started that process, health takes time to recover. Having encountered this scenario a handful of times, I’ve found some practices which make it easier to start moving in the right direction.

Catalysts for Recovery

Team lunches or dinners are a key piece of team health, and work well for allowing a team to gel together, but for recovery from burnout, I’ve found they don’t work well because frustrated groups in a social situation tend to vent about their frustration, reinforcing the negative rather than melting it away.

Instead, you want to find activities for your team which will provide them a mental and emotional break from the grind. Activities where they come away refreshed with the feeling they’ve learned and experienced something new:

1. Technical paper reading groups are a great opportunity to learn something new together. Pick an interesting paper, have everyone read it before hand and then break out into groups of three to four people to discuss and come back as a group 20-30 minutes later for a larger discussion (this year we read Mesos and SWIM papers, among others, which I can happily recommend as good starting places). These work even better if you invite people from other teams to join in, providing a safe environment to build relationships with new people.
2. Hackathons during working hours are a great opportunity for the team to try out something new, ideally with people on the team they don’t work with as often, and get in some positive experiences together. (I’ve historically been very anti-hackathon because they are so often scheduled in a way prevents individuals with families and external demands from participating, but I’ve since found that they’re pretty effective and purely positive if you can schedule them exclusively during normal working hours over the course of a day or two.)
3. Having recurring sessions once or twice a month where you learn a new programming language together, can be very positive experience. These can be especially fun if the projects themselves are interesting, some of the ideas I tried this past year were writing Redis and Statsd server implementations.
4. At a quickly growing company, your team might be spending 20% of their time interviewing, but we rarely practice interviewing. This is unfortunate because we rarely get feedback on our interviewing, and also because practicing interviewing can actually be a fairly fun group activity. With groups of three, have one person ask a question, another work on answering the question, and a third keep notes on how the others could adjust their approaches.

These are just the beginning, any activity with an explicit focus which is not what you’re team is already focused on will be effective–and which is inherently interesting–will be effective.

Will these be enough to fully heal a burned out team? No, almost certainly not! You still have to attack the definition and find ways to get the team a reasonable workload with a mix of interesting work, but these can be useful for jumpstarting the process, getting you and your team out of mental deadlock and able to think again.