Having formerly worked on 20% projects at Google and now working at a small company, I'd say that 20% time can be valuable at any size.
For smaller companies it's easy to essentially always have feature work which means never really having time for code health; anything that wasn't done right the first time will be hard pressed to justify getting done ever unless it's either breaking something or preventing features. 20% time can allow engineers to do something about issues they see and care about which could improve things for everyone else in a way "one more feature" may not.
We do something like this: Maintenance Monday. The dev team is just working on the bits of code they think need it, cleanup, test case, formatting, all those little things - that have no direct customer facing value.
And then we do a Feature Friday so folks can work on the fun new stuff (of their choice). It's all company project related tho - sometimes loosely - we don't yet have a business case for AR/VR or using templates on a Remarkable 2 - but maybe - and they are used to spread knowledge around the team
I imagine it's not appropriate for startups, since they're burning money fast and mental health appppears to be less of a priority? I've not worked at one, so hard to say.
Besides startups, I think it's fair play at companies of all sizes. Employees are the most important thing to companies, and the overhead of losing trained, context-carrying talent tends to be heavy. So, why not let them fulfill that scratch and keep them at your company.
I've seen some companies allow 20% on any team within the company (rather than any project whatsoever): that could be a nice middleground for a company that is unsure about the whole thing.
Not really; the consensus view within the company was that the justin.tv website wasn’t long-term sustainable and the company needed a narrower focus.
There were three segments with sizeable viewer counts at the time: sports, video games, and social streams. The people streaming sports probably didn’t have the necessary permission from the copyright holders, so that was only possible through the DMCA safe-harbor provisions; obtaining the rights ourselves didn’t appear to be a viable option.
The entire company basically split into two divisions: the social division turned into SocialCam, which had some moderate success, and the gaming division turned into Twitch.
Wow, that is a great insight of them. Usually my managers want to do MORE disparate things, and spread more thinly. It's nearly impossible to get them to cut anything and focus on a mission.
It definitely has more impact imo in organizations that tend to specialize and get too big to known everyone.
I worked in a larger technology/shared services team where the execs set an expectation of “no email Friday” policy and encouraged peer learning and training on Friday afternoons.
It wasn’t 100% effective, but helped establish a personal development culture, got SMEs talking outside their “turf” and sparked a few good projects and staff transitions. (We discovered we had a change management guy who was passionate about kubernetes)
Where I work we don't get 20% but we do get 1 day a month (so about 5%). We're a lot smaller than Google.
When I first started with the company I used the time to gain experience using the products we make. That gave me more insight into our user's perspectives and paid dividends in future tasks like bug fixing.
Sometimes people use the time for small things that they want to add but aren't important enough to be scheduled. I work with people that are passionate about what we do so it's nice to be able to make improvements in the spots we care about.
Sometimes people will use the time to throw together a proof of concept for a bigger feature. The real feature might take months to get working to the point where it is stable and polished enough for an end user but you can get a lot of management buy in if you have something tangible that can show people what the feature could do.
I don't really understand the focus on the 20% thing. I have worked at different sized tech companies, from startup to medium sized, to giant. And I have worked in several capacities, from line engineer, to middle manager, to director. In my experience, it is impossible to measure an engineers performance with an error less than +/- 20%. I have worked on side projects that large and my manager never noticed until I demo'd the results.
Generally, if your manager is not shit and not under unusual time pressure, they should have no problem with a project that doesn't significantly impact the primary work and has some chance of benefiting the company.
Google is interesting as they have an explicit 20% policy, but in practice it doesn't really matter one way or another.
We used to do it at my previous company, maybe 30-40 engineers, but only 10%.
It didn't really work, in the sense that no project went anywhere.
Based on the feedback here, it seems to work if you can contribute to external projects, where it's easier to add marginal value.
In our case, everyone worked on the same project, so it was either develop some new features for the existing project, or create something brand new.
We would develop some POC, and every time the answer by management was "that's cool, but we don't have the resources to polish it up/bring it to market and it's low priority". It was pretty depressing to me.
For smaller companies it's easy to essentially always have feature work which means never really having time for code health; anything that wasn't done right the first time will be hard pressed to justify getting done ever unless it's either breaking something or preventing features. 20% time can allow engineers to do something about issues they see and care about which could improve things for everyone else in a way "one more feature" may not.