We have a similar policy but even more open. The one rule is that any time-off needs to be approved by the person's team: can the team still meet their commitments?
We figure that if we need to trust teams of people to make complex technical decisions and want to have people around who are basically programming artists... Well, then we should be able to trust those teams with managing their own time.
Any time someone takes vacation their team is going to move a bit slower on the current project. Commitments should be built around vacation, not the other way around.
Sad to see responses like this on Hacker News (referring to your usage of the word crap). Ah well.
Why we know this isn't "crap".
Commitments are built around Vacation AND Vacations are built around commitments. It doesn't have to be an either/or proposition and here is why:
We apply Agile and the management aspect of our company uses Scrum. The teams are self-organizing. This even includes who is hired into the team and who is fired from the team. The team commits to an amount of work (it isn't forced on them by management).
This commitment process is very well defined in Scrum through the iteration planning meeting. If someone wants to take time off to go on vacation, then during the planning meeting (and hopefully they talked about it with their team members before), they let the team and product owner know at the start of the planning meeting (every team member, as Scrum requires, let's everyone know the number of hours they have available to commit directly to the current log).
In this case - Commitments are built around vacation.
On the other hand, the team has been given the authority and responsible of getting out potentially shippable product increments (a part of Scrum). The team, as a whole, has taken on this responsibility so, as a whole, must take that into consideration when taking time off.
In this case - Vacations are built around commitments.
Our approach to time-off and vacation aligns quite nicely with the Agile process and, in my opinion, is an other example of why Agile (and Scrum in this case) is such an amazing way to manage the production of software.
Aren't people chronically optimistic about how much time something will take? Unless your teams are awesome time estimators, this sounds like it would mean that if the schedule slips, out goes your vacation? And that sounds like a recipe for a burn-out spiral.
Agreed. I generally take a three to five week trip each spring (I get about 20 days of PTO). I generally try to work remotely for roughly one week of the trip (depending on overall length), and I always give my team plenty of lead time. I've never been denied my request, nor has it affected project time lines.
When you say "no one has ever taken advantage of this", do you mean that nobody has ever taken any time off at all, or that you feel nobody has abused the rules in your opinion? I certainly hope it isn't the first, because if so, that's a very very bad policy.
We figure that if we need to trust teams of people to make complex technical decisions and want to have people around who are basically programming artists... Well, then we should be able to trust those teams with managing their own time.
So far, no one has ever taken advantage of this.