May 29, 2016.
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.
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:
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.
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:
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.