A few years ago, I read an amazing quote from Jerome Kerviel, who was fresh
off losing his bank $7.2B USD:
“It is one of the primary rules of internal control: A trader who doesn’t take vacation is a trader who doesn’t want to let anyone else look at his book”.
His story is remarkable, and it also made me think about how this applies to software engineering.
Does it follow that it should be a primary rule of engineering management that any engineer who doesn’t take vacation is an engineer
who is producing unmaintainable software that they don’t want anyone else touching?
It’s a tempting conclusion to reach for, and I’ve seen it come to life in a couple of hero engineers,
but generally I haven’t found it to hold true, simply because it’s often the case in startups and hypergrowth companies that no one takes vacation.
When you interview engineering management candidates, they often describe hiring as their number one priority,
and for many years, this was indeed my number one priority. Even today, if you ask for something that I’m proud of, I’ll
recycle the story of growing Uber’s platform engineering team from five to seventy in eighteen months,
which was certainly a feat of partnering with our recruiting team to hire, hire, hire.
Recently, I’ve started to suspect that my priorities should be:
- retaining the existing team,
- acting as leverage for their productivity,
- adding to the team to fill gaps (aka hiring).
OK, so retention. Let’s do that.
On the teams I’ve had the fortune to work with,
occupational burnout has been the largest source of attrition.
We have ideas around how to heal a burned team,
we just need to figure out one more thing: how do we get people to take vacation?
Foremost, we ourselves need to be role models for our teams. If we are in the office twelve hours
a day, and rarely take vacations, then our teams will feel compelled to work long and rest seldom. (This is
an interesting gradient to gauge: if you go too far the other direction, then it’s also easy to feel the team thinks you’re
not working hard enough.) I recommend mapping out your vacation early each year, to ensure that you get a solid week
We should also set explicit norms about what is a reasonable amount of vacation to take, especially for companies with
unlimited vacation. Jay recently proposed a very simple set of norms that serve as a good
starting point: you should take a full week off every quarter or a full two weeks every other quarter.
Once you have your norms defined, shared and posted for posterity, then once a quarter, perhaps during a quarterly
career trajectory discussion, ask your teammates about their last and next vacations. The idea of
taking vacation is so abnormal for some that they simply don’t think about it, and you have to periodically remind them!
Something that I haven’t tried yet, but is an idea that I’m excited to experiment with is whether we can create a simple
nudge which encourages more vacation without the paternalism of telling your
team how to take vacation: integrate witih Workday or other HR software to email all employees
once a quarter with a report that tells them how many vacation days they’ve taken this year, and highlights where they fit
in the distribution of vacation takers at the company. (Perhaps also showing the company’s goal distribution as well.)
This automated feedback loop would give everyone a sense of whether they’re taking a reasonable amount of vacation.
For leadership, this would also be an amazing dataset to help understand if you’re burning out your
team, and if you yourself are setting a good example. Another analysis I’d love to see is how tight the correlation between
a manager’s vacation days and their team’s vacation days is!
You can imagine a bunch of other interesting questions here. What if companies started to compete on the distributions of vacation
days taken by their employees? Perhaps that is the real way to show that you’re investing into your team.
How are you helping your teams take vacation?