Using git to manage vacations in a large distributed team
Here at Zyte we are a remote team of 100+ engineers distributed among 30+ countries. As part of their standard contract, Zytebers get 20 vacation days per year and local country holidays off, and yet we spent almost zero time managing this. How do we do it?. The answer is “git” and here we explain how.
We have a github repository where each employee has a (YAML) file describing their personal vacations and each country has another one describing their public holidays. Employees are linked to the countries they live in. All this information in structured format is compiled to create an ICS file and expose it as a (company accessible) calendar with all staff holidays (including country holidays, medical leave, conferences, etc - it’s all in the YAML file, with that level of detail). Anyone can check this calendar to see who is off this, next week or anytime.
On top of this we have built some graphs to monitor your accrued vacation days (1.66 days per worked month) and warn you if you haven’t taken holidays in a long time.
Now here comes the best part: when Zytebers want to take vacations all they need to do is fork the time off repository and send a pull request to their managers, who merges them to approve the vacation. Because we are all technical people, we wanted to make the time off request process as developer-friendly as possible. Carefully wording a polite email to your manager is a thing of the past!. Just send a pull request
For country holidays we apply something similar. In a large distributed team there are many countries involved (in our case, more than 30) and the list of country holidays is better maintained by the people who live in those countries. They know better which holidays apply than a Human Resources person collecting them from Google. So Zytebers are required to submit (and help maintain) their country holidays pro-actively and responsibly. This is done also by sending pull requests (with changes to the country file) that gets signed off (ie. merged) by the HR manager.
This model is heavily based around trust and having a technically fluent team (working with pull requests may put non-technical people off or require training) but we are happy to have both. If your company is in a position to try this model, we strongly suggest you give it a try. Even if you can’t apply this company wide, you could try it in specific teams. Having all in structured data means you can deliver this information in any format requested by your company’s HR team. We have been using this method for half a year now and never looked back. We couldn’t think of a better way to manage vacations and country holidays from such a large distributed team that wouldn’t involve large Human Resources overheads. And we hate unnecessary overheads!
We plan to continue writing about how we manage our distributed team, so stay tuned and follow us on Twitter. If you would like to work in a strong technical team and can’t wait to request your vacations with git, we are always hiring.
