I think it's fantastic. The whole 120% thing is up to the individual: there have been times I've made it a 120%, and there are times when it's been just "take a friday off to work on other stuff". You end up getting less of your "job" done but my managers have always been supportive.
It's been great for sanity: some weeks/months feel just, like, meetings and chore work. It's great having that one day a week to work on a rockstar feature request in some fun project. It's also cool to work on your dream projects without the luck/physical move/whatever to get on the actual team. (you can effectively work on anything since no project is going to say no to free headcount)
It's also nice because it spreads your professional network in the directions you choose to spread it, rather than the more organic spread that your normal job entails (assuming luck and available are big drivers of where and which projects you "end up" working, rather than 100% your choice). So, maybe I don't work on project X today, but I can 20% on it and build up those connections, and later in my career I have a much better shot getting on the project. That agency is a nice feeling.
So, as far as the employee happiness goes, I think it's fantastic.
I met with a couple members of their team who were open to entertaining me given my background with a music blog. I remember being really excited about it - and I spent a lot of time preparing a deck about how exposure provided by the Google Music blog could be used as leverage to give the platform legitimacy in the eyes of independent artists (something that SoundCloud was doing really well at the time).
A few senior leaders agreed to let me pitch my ideas, and after a fair bit of head-nodding, nothing actually happened.
I ended up leaving Google about 3 months later to take my music blog full-time (still up and running at https://www.indieshuffle.com, and eventually started a much-more successful music venture called SubmitHub - https://www.submithub.com). I count myself fortunate to say I have no regrets leaving Google.
Reflecting on the idea of 20% projects, I do appreciate that my managers gave me the opportunity to explore alternate opportunities within the company, and that the Google Music team was receptive to me poking my head into their affairs. I think it holds a lot of potential when it comes to retaining top talent that's at risk of jumping ship for something different, and made me feel like I was part of the larger company rather than simply stuck in a silo.
a) Learn deep learning on audio with a friend, via online courses, reading research papers, and re-implementing things. Then, to put the knowledge to work, I...
b) Joined a small bioacoustics project working with external researchers to level up their ML,
c) Developed some models and deliver some results to the external researchers, and, finally,
d) Got hired onto a new team doing ML on Audio full time, largely on the strength of recommendations from bioacoustics people.
e) I've kept hacking a bit on bioacoustics, including launching the birdsong id kaggle competition earlier this year. https://www.kaggle.com/c/birdsong-recognition
IMO, 20% time is "just marketing" until you actually put in the personal effort to make something real out of it. Doing so is non-trivial, though.
There's a real risk of falling into a 'half-ass two things' pattern. It's difficult to do exactly one day a week on some project, then cleanly drop it until the following week. Context loss is a real problem. This year, I find myself looking out for 'low stress' times during my day job to do some deeper dive on bioacoustics and create a bunch of new stuff in a kind of sprint, rather than consistently setting aside 8 hours a week. It's hard to do a research 'sprint' in two areas simultaneously; it's better to let a research question take over my brain for a while.
(I also find that my personal limit for meaningfully tracking experiment outcomes is two model architectures. I tried three at some point this year and it was kind of a disaster.)
It's tough to motivate myself to do important-but-boring things like write unit tests in 20% time, which (combined with the context shifting problem) has often lead to pain down the line.
All told, it's a hard road, but very rewarding, IMO.
That part of the culture WAS consciously cultivated and I found it very valuable. It drew me up and made me more than I was. It was bound up with a culture of open sharing of ideas and cross-training. A notion that you could find compelling work at the company and shift your focus to that work/team.
There was also an effort to encourage new projects and ideas but they didn't go far enough. If I could give one piece of advice it's to create explicit approval and some serious financial incentives for people who start new products at your company. Treat projects like this in the way you'd treat an acquisition of the company making that product. E.G. if your company adopts a side project as a product, give the creators cash, respect, authority, and support to grow it into something great.
But for the most part it contributed massively to the happiness of the developers. And the outcomes, in my opinion, were invaluable. It's not always visible from the outside, but Atlassian now has swathes of valuable internal tooling, built with love by developers who were invested in solving their own productivity problems.
The quintessential "20% project" is GMail but I think that misses the incrementalism that 20% projects really provide. Developers will absolutely take advantage of the time to improve their personal ergonomics, and everyone around them benefits from that.
But this is obviously very difficult to measure.
One of the biggest positives of 20% time was just blocking off every Wednesday - no meetings, minimal distractions, etc - for my 20% work. It was pretty refreshing and kept me at the company for probably 8 months longer than I would have without the 20% time. The other great thing is that I was able to push a project I believed in but that everyone was afraid to fund. I had ownership of something I cared about. It was something that helped out dozens of teams, helped me shape the direction of the team, and heavily pad out my perf packet.
In general, folks are very protective of 20% time. My director didn't want to fund the additional maintenance cost of the project, but was respectful of the fact that it was 20% time. My manager and tech lead were in a similar boats.
This kind of modest, privste service was much lower-commitment than trying to single-handedly kick off a new external-facing service. Having all these volunteer-built projects around created a good vibe of being part of a community of engineers, each building whatever we needed to make our days better and sharing it with our coworkers.
Within that climate, 20% time was a great policy. Nobody needed "permission" to take a day out of the week to write a better source code management workflow or a config file VIM code completion for the internal codebase or improve build times or fix an annoying bug in another team's codebase, or even just generate good will for the company by contributing to open source projects. It was good for the company, and good for morale.
As a manager I'm pretty cognizant of the risk of burnout, and one cause of burnout is being hammered by a problem day in and day out. To avoid that I always coached my team members to have "three" jobs, one was their main job, one was their time to work on things that were important but not urgent, and the third was to indulge their curiosity and learn something new or further their understanding of something. But I also respected people who wanted to just "do their job" and go home, so for them we'd keep it simple about what was expected and how it was measured.
Sorry for the tangent, but what’s the definition of ”startup” we’re working with here?
As someone who has worked for a long time at small startups (<30 people, <10eng) my "20%" projects (what other people are referring to "120%" here) that I've done on my own time have, in some cases, saved the companies I've worked for more than thousands of eng-hours and have taken less then a weekend. Attacking a core business problem from a new angle that no one else sees and designing a revolutionary approach to solving it that saves everyone time, money, and reduces stress is very common. Some examples of this from my previous job:
1. https://github.com/CaperAi/branchpoke
2. https://github.com/CaperAi/bazel_compose
3. https://github.com/CaperAi/pronto
These were the ones that were easy to pluck from my job's monorepo and generally applicable.
As someone who is leaving a small startup for Google I can also add that it's one of the biggest compensation-y things in the offer. My manager seems supportive of 20%ing, the project I'm on is an offshoot of a 20% project, and the skip level I spoke to supported the idea of building tools.
So... From a management perspective the startups I've worked for have lost a senior engineer to another company more supportive of personal projects. This is very expensive as 1 senior engineer could represent 10%-40% of your eng team capacity at a small company. So, even just as an employee retention mechanism 20% of a salary spent on retaining your core engineering team and, possibly, obtaining huge benefits to overall company productivity is a worthy trade.
Paradoxically, this makes it a good policy _for Google_: if you're an idiot, you'll put in 120% effort and Google gets more work per dollar from you (and gets to deny promo because you "spent too much time on your 20% project", as well), if you're not an idiot, you will work 8 hours a day, but then spending 20% of time on things unrelated to your next promo completely dooms your chances of getting it. Some people used to take advantage of this, truth be told you're paid pretty well even at the senior level, and Google expects most people stay at that level indefinitely. Although then there's the question of why one wouldn't just take it easy at work and spend their spare time on hobbies instead that Google won't own the output of.
OTOH some people are taken in by the Google mythos, and they think spending 20% of their time on semi-random shit is _conducive_ to their career advancement. You get disabused of that notion after applying for a promo even once, which is when any experiments with 20% usually cease.
Exceptions are few and far between. To establish this for yourself, try to find if people around you promoted to Staff and above have any real 20% projects that are actually 20% projects, that is, that take substantial time. They don't.
Nobody just let you do passion projects! Get back to your work
It’s the only reason we still exist; most of our sold products were side projects a generation ago.
This went from nothing to a company-wide utility to a publicly launched app with full-time engineers (although I stopped my 20% contributions before that) [0]. So I think in this case we had a clear positive impact on the company that would not have happened without the 20% program. This app was launched by 2-3 20% engineers and 1 20% PM.
This was way outside my core job role (Developer Relations) but it was a great experience and I believe I was rewarded for it when it came time to apply for promotion.
People always seem to focus on the question of 20% time vs 120% time, but I don't think that question can be answered. Google does not have a time clock culture. I work about 45-50 hours a week. I have coworkers who work 30, I have others who work 70. When we had an office I got there at 7:45am, I sat near people who arrived at 11:00am. So basically time management is personal and so is how you choose to do a 20% project. In all cases the mandate is "get your work done".
0: https://9to5google.com/2019/03/12/android-q-beta-feedback-ap...
Linters, code checkers, automation tools, IDE plugins, etc, have all been plucked. There's not a lot of low hanging fruit anymore.
1) They want to change their role and view the 20% project as a means to an end. As an example, I worked with two 20%'ers that wanted to transfer from non-SWE to SWE roles. One of them has already succeeded, and another is hoping to be able to do so as soon as head count permits.
2) As a labor of love. As an example, we have an epitaphs page containing information about/farewells from people that have departed Google. It's not an officially supported project but is still quite popular. These kinds of projects don't necessarily lead to promotions (although the criteria for promotion have recently changed), but on balance they make people's lives better.
It isn't completely dead. Like everything in Google, it's a ton more formal than it used to be and it's super hard to get an external launch, but tons of people still participate in 20% time at every level from 'maintains important project' to 'messes around in their free time'.
On my current project, I have other Googlers spending 20% time to help the team I lead as well.
20% is very much still a thing here.
Execs call it out and focus on it too, so managers will even be happy to hear you're using it (and say "what can we do to get people to feel like they can use it?")
I did a 20% project 2 years ago. My goal was to get into a new area of the company since my then current role was not going anywhere. I worked 20% on the new role and 80% on my existing role, so no extra hours required.
I worked on a project that ultimately failed, but I got to know enough people in the new domain that I was able to find a project to join in that area. So as far as I'm concerned 20% is a great (and ongoing) thing about Google, even if it does not lead directly to new products.
I think most who took advantage actually worked on improving and facilitating employee training & learning programs. Google has great internal training material -- mostly for internally-used technologies, but sometimes for external technologies people are curious about too, and also for soft skills, and even not-work-related skills (e.g. fitness classes).
Overall I think the 20% resulted in more "community" work than most other companies have, and I think it was a positive for company culture.
And for the few people that actually worked on technical projects, the existence of 20% time seemed highly motivating for them.
Whether doing 20% impacts performance / promotion - it again depends on the individual and their level, two data points:
- I used 20% to start a team / role transfer, ended up on a very interesting project & team which helped my career growth
- one of my coworkers used 20% to start & maintain an internal feature of a large product that directly helped his promotion case
so I think 20% is great for Google and its employees (when applied wisely).
None of us 'fully agree' with the product features set. We all have 'that thing' we feel different about.
I wonder if instead of 'work on whatever' - you can just 'work on something else, that you really want to' - but that has practical value. Like XYZ feature, or creating online training, or that researchy thing with the local Uni.
So 'in line with company objectives' but still fun.
Because frankly, Google has been rolling in surplus since day 1, they have all the money in the world, that's fundamentally a different economic space than companies who are on the line.
Are there examples of successful results?
its not even 120% time because if you have time to do 120% you should just do it on your main project to get faster promo instead of something your manager wont care about or know how to evaluate in a perf packet.
the only time people did it was to try to switch teams. or if their main project was low impact/easy to do in 80% of your time so you wanted to pad perf.
For the more junior folk though it seemed like a waste of time as their stuff seemed more fun than valuable to the company.
At Google/Atlassian is it entirely 20% on what you want or do you first need to propose and justify the value of the work you plan to do with an approval?
I've always been a big proponent of 20% time. Shazam is the first place I worked at which taught me about them and I've written about it here:
https://umaar.com/blog/lessons-learned-from-working-at-shaza...
It was the way in which I learnt what I'm passionate about.
Interesting to think that Google had an opportunity to build Facebook, but didn't pursue it.
And yes, of course, years later there were Wave, etc.
If that work has impact you can also include it in your perf.
In short, focus on the reason why google had this: to encourage the initiative. In many corporations showing initiative (inventing things, doing more that required, etc.) is a career ending move.
At smaller companies, engineers eventually need some time to vent.. "energy".
After the first ~2-3 years, most go to work in order to then go home. They have been given the education and realize there's nothing. Further, whatever they do is owned by the company. That is, only garbage would really get pushed.
We did this for a quarter across a few different large eng teams. We eventually shut it down. My high level takeaways were the following...
* Way more engineers *say* they're into doing hack projects than actually ended up doing them. We had huge initial survey response of people saying they wanted to do something, and only ended up having like 5-ish projects that were seen through. And there were probably 20ish projects that started at the beginning of the quarter. So large drop-off.
* BUT! That can be totally fine! Many people who actually used hack time were some of the best engineers at the company. Other ones were some of the newest at the company. You're really helping job satisfaction for those top engineers, and really helping mentorship and learning for the new engineers.
* I now believe it's better to have regular highly condensed hack weeks (or hack days if you're a small company), rather than a spread out "20% time". Even people who really liked hack time found it hard to actually take the time when deadlines were approaching. But when you just eliminate those things with a condensed period of hacking, then people can focus. You also tend to increase participation considerably through this method. (I know cause we did this method as well)
* Stop trying to create Gmail in your hack time! A lot of the most valuable stuff to come out of hacking was internal tools, refactors, and little things that improved daily quality of life around the company. (ie. someone made a batch upload tool for the customer support team that they *loved*!). Or small UX improvements for customers. Some people did try to create certain new products, but it's super rare that those make it into the main product Not saying it can't, or won't, or even that you shouldn't do it. But as a general rule, the best you can hope for there is you've de-risked a new feature, or gotten your manager excited about the possibility, and they'll slot in time to "do it for real" in the next quarter. Realistically, people tend to have more fun just making stuff that they actually can see the value of the next day. Or when they get to hear thank you emails immediately from a whole other team.
* You get a lot of other value from hack time besides break-through products. Specifically, you get people across teams mingling with each other. You get new and experienced engineers hanging out. You get a feeling of autonomy. People learn new tech or new parts of the company. For example, I made one of my most lasting relationships at that company by just randomly deciding to join his hack team for a hackathon project. I also got to use GraphQL and React for the first time on that project.