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
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:
- 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.
- Step back from a recurring task and find a way to make it more
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!
- 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:
- 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.
- 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.)
- 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.
- 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
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.