From most of what I have seen, 20% time mainly ends up being taken by the same people who use free time to work on projects anyway. Which then means that 20% time for employees ends up largely “just” a worse way of working a 4-day week.
Your stats are consistent with this, with only a fairly small percentage of people actually using said policy. (Although they do not rule out other hypotheses.)
All of the same concerns that I have with any vacation policy where there isn’t a policy that everyone must take all of it. (This includes, but is not limited to, every ‘unlimited vacation’ / ‘flex time off’ plan under the sun.) You do tangentially mention some of this, but it’s worth explicitly noting the parallels.
The restrictions that employers put on projects generally mean that you as an employee can’t commit to anything. And this most affects the more careful employees, which in turn means that the more careful employees see this as less of a benefit, which in turn means that you have benefits that are weighted towards attracting less careful employees.
If Atlassian’s policies are truly “requires no approval to start, 3 uninvolved colleagues to vouch for a project to go beyond 5 days, and founder approval at 10 days.”, no wonder they see a giant number of buggy tools.
A bunch of people each working on a software project for 5 (or even 10) days is a great recipe for a maintenance nightmare.
If anything, I’d expect this to increase technical debt.
See also your proposed benefit for an employer of “Builds slack into the dev pipeline, such that emergencies can be handled without affecting customers.”. You say that and my immediate reaction is “so an employee cannot actually treat this as a reliable benefit, because they are expected to drop it at a whim”.
“Careful” is, I freely admit, likely not the correct term. I don’t know of a better one offhand.
20% time when well-implemented can be decent. Having the ability for someone to go “nope, I know you keep pushing off the debug documentation for module X in favor of putting out fires because we can’t debug module X, but I’m going to put my 20% time into fixing this module up into a coherent whole” is great, and often under-appreciated. Having that then shot down because we’re currently too busy putting out fires because we can’t debug module X rather defeats the point. Having that shot down after 5 days, meaning that instead of a single coherent debug document written by one person in a year of 20% time we have a Frankenstein mess put together by ten people each of which gets pulled off in five days because, again, the debug documentation isn’t seen as important? Again, rather defeats the point.
Interesting.
This doesn’t cover my major issues with 20% time:
From most of what I have seen, 20% time mainly ends up being taken by the same people who use free time to work on projects anyway. Which then means that 20% time for employees ends up largely “just” a worse way of working a 4-day week.
Your stats are consistent with this, with only a fairly small percentage of people actually using said policy. (Although they do not rule out other hypotheses.)
All of the same concerns that I have with any vacation policy where there isn’t a policy that everyone must take all of it. (This includes, but is not limited to, every ‘unlimited vacation’ / ‘flex time off’ plan under the sun.) You do tangentially mention some of this, but it’s worth explicitly noting the parallels.
The restrictions that employers put on projects generally mean that you as an employee can’t commit to anything. And this most affects the more careful employees, which in turn means that the more careful employees see this as less of a benefit, which in turn means that you have benefits that are weighted towards attracting less careful employees.
If Atlassian’s policies are truly “requires no approval to start, 3 uninvolved colleagues to vouch for a project to go beyond 5 days, and founder approval at 10 days.”, no wonder they see a giant number of buggy tools.
A bunch of people each working on a software project for 5 (or even 10) days is a great recipe for a maintenance nightmare.
If anything, I’d expect this to increase technical debt.
See also your proposed benefit for an employer of “Builds slack into the dev pipeline, such that emergencies can be handled without affecting customers.”. You say that and my immediate reaction is “so an employee cannot actually treat this as a reliable benefit, because they are expected to drop it at a whim”.
“Careful” is, I freely admit, likely not the correct term. I don’t know of a better one offhand.
20% time when well-implemented can be decent. Having the ability for someone to go “nope, I know you keep pushing off the debug documentation for module X in favor of putting out fires because we can’t debug module X, but I’m going to put my 20% time into fixing this module up into a coherent whole” is great, and often under-appreciated. Having that then shot down because we’re currently too busy putting out fires because we can’t debug module X rather defeats the point. Having that shot down after 5 days, meaning that instead of a single coherent debug document written by one person in a year of 20% time we have a Frankenstein mess put together by ten people each of which gets pulled off in five days because, again, the debug documentation isn’t seen as important? Again, rather defeats the point.