Ask HN: Was 20% time a good policy for Google's working culture?
I know the policy doesn't really exist anymore, but I still like the idea a lot in principle (for large and financially secure startups, say 1k developers and up). Just wondering what Xooglers and others think about it.
316 comments
[ 16.8 ms ] story [ 6296 ms ] threadThis is the right call. If you ever actually move the needle on anything important your fun 20% project will assuredly be taken over by middle management and you will get pushed out. If you have free time at a bank either slack off or work on low-effort projects that look good on your performance reviews.
Not all workplaces are toxic. You generally have to take charge of your own career. But often the politics align such that it'd be strange to kick someone off their 20% project if it's successful.
Which is good if you're tired, overworked, didn't sleep well or just want to spend some time with family. I usually use it to read books not closely related to my daily work, but related to what my coworkers do. Like about subscription models, devops, scrum master roles.
What have you worked on? How did you find your clients or customers or projects?
Is it a consultancy? Or did you develop a marketable product?
What technologies, programming languages, databases, and tech stack did you use?
Keep the information anonymous, of course, if you want to maintain your privacy.
I imagine no one at Google used their 20% time project to bunk off, simply because it was 20% of their working time, and not 20% of their contracted hours. If you're supposed to do 40 hours a week but you actually spend 80 hours working on work and 20 hours on your 20% project then you aren't bunking off.
Working smart and not hard and reaping the rewards is not "bad".
The Protestant work ethic and living to work aren't healthy for everyone and I don't really see why we need to assign value judgements to people who do or don't subscribe to it.
Where I work, we dedicate 1 day per sprint to tech debt where everyone can just work on fixing whatever they want. It's made HUGE differences to the developer experience. So many of the things that slow us down and annoy us have gotten fixed this way. Sounds about the same as your fix-it-fridays.
But 20% is about side projects. Meeting Free Monday could be a good policy to foster those.
My company informally allows for spending time like this, but if it works out to an hour or two a day in between meetings and Slack requests, I can't really do much with that.
Or could you combine it into a 5-10 week clump between projects?
But to your point, of "well shouldn't that intentionality be part of normal duties?" Sure, but shouldn't coming up with Gmail? Or fixing bugs or UX improvements also be part of normal duties? Yes, they all should. The truth is it's hard to prioritize small things like that, and it's really hard to get a sense for their value as a centralized management team. They aren't close enough to the code or the product to always know. So I think 20% time is a great way to just decentralize that, and allow the engineers closest to the issues to pick what's important to work on.
[1] https://www.amazon.com/Accelerate-Software-Performing-Techno...
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.
We helped the CEO and SVPs figure out how much to pay the company's top ~100. That meant we were hands on with performance bonuses, equity packages, hiring negotiations, promotions, and more.
The coolest part about it was getting to frequently join Laszlo Bock (head of People Ops at the time) when he met face-to-face with the CEO (first Eric, then Larry) and the SVPs to discuss all of the above. It got to the point where they all began to recognize me, which was pretty darn cool as a 20-something-year-old.
A byproduct of all that exposure was that I ended up being privy to a huge chunk of the "corporate drama" taking place in the upper ranks. It's been 7 years since I left, but as I'm sure you can understand, getting into details is probably a bit of a no-no :)
Scott Galloway (?) has observed that successful entrepreneurs and CEOs are nurtured, just like all other professionals. So 20 somethings doing leadership stuff are more likely to be pretty good once they're 40 somethings. Steve Jobs, Larry Page, Michael Dell, many others are pretty good examples.
What exactly does that work entail?
> A few senior leaders agreed to let me pitch my ideas, and after a fair bit of head-nodding, nothing actually happened.
I suspect successful 20% time projects are the ones where permission is not required, and don't need someone else to implement?
We helped the CEO and SVPs figure out how much to pay the company's top ~100. That meant we were hands on with performance bonuses, equity packages, hiring negotiations, promotions, and more.
> I suspect successful 20% time projects are the ones where permission is not required, and don't need someone else to implement?
Part of my proposal was that they bring me on to help them run their fledgling music blog, so it wasn't so much that they needed to execute much themselves -- more that they needed to decide the music blog was worth having a dedicated employee. At the time I think they were more focused on trying to get all their licensing ducks in a row.
A petty thing I noticed with the years is that in HR, even very junior people will treat you with condescension and a sort of disdain. They know your salary and know where you were in the corporate ladder,they deal with the CEO packages so you are just a mediocre fish in the pond for them.
Skillful HR people also create a pretty solid network so if they leave the company they usually land sweet gigs in other companies or they can start a consulting agency. Out all the places of a corporation HR must be one of the best to be. (Cue hundreds of actual HR managers refuting me)
* Was the purview of the team to craft a compensation "system," or to handle specific decisions / one-offs for exec comp?
* Was there a technical/quantitative aspect to this, ie were you all trying to make data-driven decisions on how to pay executives based upon pulling data, testing what comp packages worked etc, or was it more of a general analyze-the-market-and-make-recommendations process?
* To what extent were you advising CEOs/SVPs vs. actually making a call on what their reports would make comp-wise?
I didn't realize that teams like this (specialized comp analysis for top executives) existed, I always figured that it was baked into existing compensation-focused teams.
Going back, let’s say the top is $100M, let’s say the bottom is....(not sure how to guess this)....
Ok, so, the 7th executive made $20M based on this dated public doc (1). So let’s say the top slate is $250M. Going from $20M to $1M for everyone else is ... $900M? Anyways so $1.15B.
The real thing though it’s probably not the cash expenditure part. It’s probably the GROWTH you can get by designing it correct. You’d be okay to spend for results.
Anyways at a high level, let’s say you have 5 FTEs at $200k, plus overhead at 100%, that’s $2M on $1B or 0.5%? Meh, it’s a transaction cost.
https://www.sec.gov/Archives/edgar/data/1288776/000130817913...
We're getting way off topic here, but I'm curious what your thoughts on the current state of the world on music blogging is. I was pretty big into following the music blog/hype machine scene in 2010-2014ish, and it seems like the other streaming services (particularly Spotify) have more or less killed that world with the exceptions of the biggest blogs, which seems pretty unfortunate to me.
Spotify did indeed take away a lot of the "regular listeners" from music blogs, but they're not alone in the downfall of music blogs as a whole. I think a lot of that can be pegged on the way the internet has shifted in general. Music blogs lost a lot of things in that 2013-2015 era, including (but not limited to):
- A steep drop in advertising revenue (we used to charge $5+ CPM - but folks learned Google/Facebook were far more effective). This wasn't specific to the music blogging industry - pretty much all independent publishers went through this.
- Google giving 50% of their real-estate for song searches to a giant YouTube thumb. Killed SEO for music blogs overnight.
- Technology: Spotify just does music-listening tech better than any independent music blog could ever hope to.
So, in an age where Spotify is king and everyone's buzzing about TikTok, where do music blogs fit? And are they even relevant?
Heck yes they are! Thing is, music blogs are where people actually go to discover music. Spotify, on the flip side, caters toward "passive" listening experiences where they make sure you never have to think about it for yourself.
Net result is that for artists a targeted blog promotion campaign is still quite important as it can lead to valuable exposure within the industry: A&R teams at labels, Spotify editorial staff, and festival bookers (RIP) still look to music blogs to do the grunt work of sifting through the 25,000+ new songs coming out daily.
In 2015 I launched https://www.submithub.com/ to help music blogs deal with the hundreds of music submissions they were receiving daily. That platform has since taken off - recently passing its 16 millionth submission (in less than 5 years).
We allow artists to easily connect with blogs, Spotify playlisters, YouTube channels, Instagram/TikTok influencers and more -- and compensate those curators for the time they spend listening to and considering each submission. And believe it or not, one of the most-targeted outlet types on there is still the humble "blog".
I could go on for hours, but I'll leave it at that for now :)
In my future perfect alternate reality:
Google Ventures, GoogleX, or even just thwarted & bored midlevel manager aspiring to become an angel investor, would offer seed capital to any one turning in their badge.
"Hey @jasongrishkoff, if you ever need some cash for an idea, please talk to me first."
In my mind, that parting offer is central to Silicon Valley's magic. There's an apocryphal tale about a much disliked boss offering seed money to mutinous employees. I thought it was Shockley and the Traitorous Eight, but I can't find a cite.
so the tricky question is - why stop at 20% - why not 40% - or 80%? could you make a case for that?
So the picture I get of Valve is that yes, you can pick whatever you want to work on, but choosing poorly will bite you in the ass.
Nobody just let you do passion projects! Get back to your work
I have done some fun stuff in 20% time. Some relatively serious projects that went somewhere; enough to keep me entertained. It’s true that if you have a demanding role it becomes more like 120% time. However it’s more the spirit of the thing that matters; the fact that you’re encouraged to pursue your interests on work time has led me to learn and experiment more than I would have otherwise.
Are there examples of successful results?
Sorry for the tangent, but what’s the definition of ”startup” we’re working with here?
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.
Can we get some of that same love put into the actual business products?
Coding is my hobby as well so spend pretty much most of my time awake working on something whether it's for the company, freelance or personal projects that interest me.
It's quite common that I'll discover something or gain relevant experience that I can reapply to projects in and outside of my 9-6.
There's a list of things we want in JIRA that I'll work through and if someone says that something is important then I'll absolutely work on it but quite often I'll get random ideas of features or improvements and just go straight ahead working on it because I know it'll improve what we have or is valuable to the product.
The project manager kind of hates me and asks how I decide what to work on and what my schedule looks like but it's mostly spur of the moment problems I'm excited to solve.
Sure I'm able to do what I want but I still stay on course somewhat and it's all valuable.
I've had a case where I did this when getting paid hourly. They told me it's not what they're paying me for so it probably only applies when it's on a salary or rev share basis :D
> 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 flip side of this is that we have countless nonfunctional tools because the core maintainer has either left the company, switched to another project, or simply does not have the time to adequately adapt to new user/company requirements.
We do a great job encouraging innovation through 20% time, but we don't seem to be great at supporting these projects past the initial "hack it together" stage. The process can still be incredibly rewarding, but it is not without some shortcomings.
I wonder if any other companies implementing 20% time experience similar problems.
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.
It seems to me that it would be entirely worth it to Google if 99.99% of 20% projects don't go anywhere, but every now and then, you get a big hit like Gmail whose newfound revenue completely eclipses the lost 20% experimental time from the 9999 other employees.
And even for those 9999 other employees, even if their 20% projects don't go anywhere, they are likely still hugely educational in ways that would make them more productive in the other 80%.
I think the parent meant they didn’t see a 20% time project come to fruition while they were there, not in general
> [...] they asked me if I wanted to build some type of email or personalization product. It was a pretty non-specific project charter. They just said, “We think this is an interest area.” Of course, I was excited to work on that.
I'm sure there were area where 20% time was real, but in my department it was pretty much non existent.
I suspect the management liked the concept of having their smart engineers invent new products, but ultimately preferred buying companies. It somehow seemed less risky even though most of the acquisitions failed.
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.
Also, what are you working on w/ Audio ML?
I found it helpful to read the source material (eg, ml text books and academic papers), paired with blog entries (which often have a good basic idea, but skip out get wrong some details), and actually building things for my own interests.
On the work side, I'm doing low bit rate speech coding, which is good fun.
Beyond the web, Nathan Pieplow has a couple great guides to birdsong, with excellent introductory essays. There's a British book called the Sound Approach to Birding with some excellent general propose knowledge, as well.
If you're looking for a fun project which to my knowledge hasn't been done, 'birdsong asr' or 'phoneme' transcription would be super cool. Feel free to send me an email ($username at gmail) if you're actually digging in. :)
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.
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.
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.
Thank you for your take on these questions, your answer would be very much appreciated.
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.
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 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)
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.
Let smart people do what they want.
That was until my boss flipped his shit one day and wanted me to memorize a bunch of shit in my down time.
So instead of automating 6 figure Engineering jobs, I did what everyone else does on their slow Time. Facebook!
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.
It's impossible at a company if you haven't built your main product yet so I'm not sure how it could work at a startup.
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.
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.
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.
Naively, I imagine developers would get annoyed or bogged down having to skill up these contributors rather than viewing it as a “free hand”.
The problems of getting an existing employee up to speed with the codebase are a subset of what you need to do to get a new hire up and running. And so you really should have a decent story for this regardless.
And culturally, it's super-valuable to have a certain percentage of visitors, since it helps break down the silos, one commit at a time.
The counterpoints, of course, are that no team really wants to have to maintain a bunch of crap written by someone who's moved on after a quick stab at something, and it sorta sucks for the sustaining team if all the "rockstar feature requests" (as the GP put it so succinctly) are picked up by folks in their 20% time.
The former can be mitigated with a good model for managing incoming pull requests, in my experience. The latter is a tougher nut to crack.
Anecdotally I also think a lot of code was generally really well documented. There is some effort to document things for a general Googler audience (i.e. you should understand most of the documentation on any given page without having to read all the other docs).
All in all, once you have onboarded into the Google ecosystem, it's fairly painless to jump around the codebase.
TL:DR - nobody has to hand hold anybody onboarding 20% - just answer basic questions and point to the right resource.
- grpc-go and gopls had great "Contributors welcome" issues set up. For both of them, I had to email/chat various people for help getting used to the code, but everyone was extremely pleasant and helpful (and happy to help). - Drive treated it like an internship, where a TL curated a set of low-priority issues and I just went and chatted with folks when I had questions. Again, everyone was very helpful. - Other Go tools I've worked on have had really intuitive codebases, or were quite small, and have been easy to dive right in. That's helpful too, though I do end up chatting with people a lot.
If I had to make a general statement I guess I would say: don't allow 20%ers if you don't have the time for an intern. Treat the 20% like an internship: free labour with a little bit of extra onboarding. It's ok to not have that time, but I think most people are usually happy and excited to provide that help! =)
Oh, actual tip: having a myproject-users@ / myproject-devs@ mailing list, or a #myproject-devs chat channel, goes a long way. Then, chatting and asking questions can be informal and ad-hoc.
It's given me exposure to lots of stuff, I've learned more about a favorite language, met some cool people, etc. Not to mention earned a handful of bonuses directly related to my 20% work.
There's also now done tech debt reduction work that I've been tangential to that's clearly a value add, and it's primarily 20%ers.
20% time at Google exists and managers are supposed to adjust the workload - it's not supposed to be 120% time. That said I think it would be hard (but not impossible) to a launch a 20% project to external users that doesn't have people working on it full-time.
Also implies a widely varying experience with the program; levels of promotion politics must vary across the company, and levels of recognition for anyone's particular project must also vary.
This was never the narrative, except maybe when the company was a few hundred people. The project has to have a relevance to the company, just not to your primary project. Most 20% has always been chipping in on a team whose problem space interests you and that you might want to transition to. That's definitely what it has been for me.
I also frequently see the claim that "Don't be evil" has been removed from Google's code of conduct, but it's still clearly visible in the document.
I hope we develop better tools to combat misinformation in the next few years, because social media is far too effective at propagating it. For every person that verifies and corrects a claim, there's ten others who will gladly repeat it. This is especially problematic when there's a bias to exploit, be it political or otherwise.
"A lie can travel halfway around the world while the truth is still putting on its shoes."
https://abc.xyz/investor/other/google-code-of-conduct/
https://abc.xyz/investor/other/code-of-conduct/
And other companies getting referrals can’t connect the dots when they know the user clicking on the AdWords Ad and what the Ad was for?
Companies that work with big data companies run AdWords campaigns in Google for other companies, right?
Even if Google isn’t evil and does everything in the interest of privacy, if their ads, based on your preferences from your emails and browsing history, are used to direct you to some product, there is a way that other companies will learn of those preferences, store them, sell them, and use them.
I mean, i guess that's a lot better in principle, but it still seems like basically the same thing with an extra layer of indirection. It certainly doesn't give me warm fuzzy feelings about google.
That is selling user data. It’s just got a layer of bullshit in between.
As long as Google offers ways to target ads at specific demographics, they are selling that demographic indicator about you whenever you click on one of those ads.
You might argue that this data is being leaked, but that isn't clear either. Ads work on an auction system, and there's no guarantee that a user clicking an ad meets a demographic. You'd need to make a case that user data can be accurately built from buying ads alone.
Even if you could prove that, that's _still_ different than the claim that Google is selling user data directly.
That’s just phrasing to attempt to weasel out of the fact that it’s selling the ability to derive the user data. It’s effectively the same thing with a layer of indirection.
> Ads work on an auction system, and there's no guarantee that a user clicking an ad meets a demographic.
Auction system is irrelevant. Unless Google is ignoring your target demographic and keywords entirely, they are selling you a stream of traffic that matches that demographic on average.
A major inflection point was when Rupert Murdoch gave a speech proclaiming the iPad was the future of news and Google was some sort of parasite sucking the blood of journalists. The tone of the output from his newspapers changed overnight and they immediately started digging around for largely fake 'scandals'. The rest of the news industry didn't need much persuading and the rest is history.
Claims you see on social media since then are largely just repeating the media's talking points. It's not like it originated there.
[0] https://www.businessinsider.com/mayer-google-20-time-does-no...
In contrast, I've been at Google since 2006 and have been utilizing 20% time since I started, and other Googlers here echo the same experience, and many of our projects are publicly available.
Not sure how her statement jives with the experience and artifacts of other's work other than to say it's not correct, and shaped by the context of the statement.
As always in big corporations there is no one culture, but an amalgamation of many different subcultures. They can have a shared core, but even that becomes more unlikely the more a company grows. At least in my experience.
Just because she's highly visible, doesn't mean her views are correct.
I worked at Google for quite a long time and had multiple 20% projects. One of them went into production and now has (I'm told) a team of more than 20 people working on it full time, so the idea they can't go live to users or become real products is totally wrong.
A few things were consistently true when I was there even in 2006:
• Some people would claim 20% time didn't exist or was theoretical
• Other people would be simultaneously taking it and launching new products based on it
News started as a 20% thing. So did GMail, if I recall correctly. Google Sets, if you remember that. There were many, I'm just picking whatever examples spring to mind quickly.
Now, can I believe that at times teams were put under pressure and some managers asked people not to take it? Yeah, absolutely. I spent my time at Google on teams that were doing maintenance and operational time work, first as an SRE and later on a did a tour on the front line fighting spam and hijacking. Those are the sorts of things where there are no product driven "crunch times" (except when there's an attack). So the culture there is maybe more conducive to side projects.
But the idea that it never existed at all is just a lie, sorry. It existed for me across multiple parts of the company and a span of nearly 8 years.
20% time is dead for all intents and purposes in all of the teams I worked (~4 dif teams).
I would not join Google and bank on having it. It’s usually 120% time and done as a way to soft-interview for a team you want to join.
Clearly it's not that easy.
I’m not sure if it’s ever been an explicit requirement and if you have strong performance reviews it’s usually pretty well-oiled.
Real 20% time though I don’t think I’ve ever encountered.
Maybe if you work on a team without a high-traffic product (internal tooling?).
It actually took me a second to see yours, but I guess you mean more of a “ya you can do whatever you want on fridays as long as you get 100% of work done by Thursday” vibe?
Of course interpreting it as "you need to work 125% for the 4 remaining days" is equally valid.
All Google related projects.
It's not intended to just be using 20% of your work time to work on whatever the heck you want to.
If you're alluding to "120% time", fair enough, but that's not what GP was referring to.
From other comments, it's obvious that 1) Google expects you to do your 100%, and then a 20% on top of that of "Google related projects", most likely owned by Google, for free.
What happens is that some managers really don't buy into the 20% concept, and don't provide time for it. Employees in those teams determined to do it anyway end up doing 120%.
There is absolutely no requirement at Google to put in time on a 20% project.
That said, what happens in practice is that 20% projects are the way that Google engineers are able to move across teams: You pick a team you want to join. You do something for that team as your 20% project with the goal of getting that manager to request your transfer to their team.
So if you're desperate to get off your team without quitting Google, you could get backed into committing 120%.
https://en.wikipedia.org/wiki/20%25_Project
Former Google employee and Yahoo CEO Marissa Mayer once stated “I’ve got to tell you the dirty little secret of Google's 20% time. It's really 120% time.”[6]
https://www.businessinsider.com.au/google-20-percent-time-po...
Yahoo CEO and formal Googler Marissa Mayer once bluntly denied its true existence.
“It’s funny, people have been asking me since I got here, ‘When is Yahoo going to have 20% time?'” she said on stage during an all-employee meeting at Yahoo. “I’ve got to tell you the dirty little secret of Google’s 20% time. It’s really 120% time.”
As a current Googler, I've been spending 20% of my time on self-directed work, and 80% on what is assigned since I started, and my contributions have been to both open/released software and also internal stuff, and I joined in 2006.
Yes it is, I quote:
https://en.wikipedia.org/wiki/20%25_Project
The 20% Project is an initiative where company employees are allocated twenty-percent of their paid work time to pursue personal projects. The objective of the program is to inspire innovation in participating employees and ultimately increase company potential. The 20% Project was influenced by a comparable program, launched in 1948, by manufacturing multinational 3M which required employees to dedicate fifteen-percent of their paid hours to a personal interest.[1]
Nothing say anything about company related projects, it only mentions personal projects. If you're talking about company projects, then it's not a 20% project. Even less so if you are talking about doing 100% of your company work beside.
I've got a feeling SV companies have hijacked the term 1) for PR bs, and 2) to get more work from employees.
It means personal preference for work, not personal activities.
If it just meant "34 he work weeks" they would have called it that.
Does "inventing the post-it note" sounds like a personal non-3M-business-related project?
https://www.3m.com/3M/en_US/careers-us/working-at-3m/life-wi...
https://www.fastcompany.com/1663137/how-3m-gave-everyone-day...
[citation needed]
Otherwise, a "personal project" is a project I own.
Somebody should update Wikipedia...
I think that originates with Google's PR, because I remember the PR when the 20% initiative was introduced was misleading at the time too. To outsiders, I remember (~20 years ago) the PR gave the impression you could work on anything of personal interest, such as running or contributing to open source projects, your own programming language or editor or whatever for 20% of the week if you joined Google. Google would own what you did there so they would benefit (much like the 3M post-it notes thing), but other than that it was like paid personal-development and mind-refreshment time. But it's not like that and probably never was.
i guess I was asking this because I've never worked at Google and wondered about any downsides - e.g. distraction (the 20% project would seem to be the "cool" project, which makes the 80% boring) or politics (could be anything from jockeying for position on a hot 20% project or something else I can't even imagine because humans are petty)
Great place to work if you're high level (5+) and land on a good team with a good manager. Mind numbingly boring if not.
It might be a nice thing to avoid them, but you're always working with legacy code, and I've literally had "I need to add a button to accept new permissions" blow up into "I need to refactor our entire class structure across 200 files because I'm not allowed to add a new test that follows our old patterns nor commit this code without coverage, and oh yeah, nobody wants to review that CL in one go so I have to figure out how to break it into 20 bite sized changes. There goes my quarter...". That's just dumb, and that type of dumb is very fashionable at Google.
My two cents on Google and Amazon: Both companies are large enough that making blanket statements about company culture is a dangerous game. What you need to do is find out which silo you would be working in, and try to figure out what the culture is like in that silo.
One thing you can grill the recruiters about is what the employee review process looks like. Both Google and Amazon use stack ranking, which is about the most brutal system there is. At Google, feedback from fellow engineers factors heavily into your performance reviews. Amazon seems to be more focused on measurable performance goals and demonstrable contributions to the company's bottom line.
This isn't really true (at least at Google, IDK about Amazon). "Stack ranking" historically has two components:
1. Being rated relative to your peers as opposed to a rubric.
2. (Usually fast) removal of the lowest performing individuals.
When combined, these become "fire and replace the bottom 3% of people on every team every year." The downsides to this approach are that if you're on a strong team, you may be a median employee, but be the weakest on your team, and be forced out for this reason. It's clearly problematic.
IDK about amazon, but the first is only half present at Google, and the second isn't really at all.
In some sense you are rated to your peers, not a rubric. But only in the sense of at aggregate (that is, in an organization of 1000 people, you'd expect ~30 people to be in the "worst 3%" category, so if only 10 are, that may raise some questions.) This removes the competition and potential animosity with your direct peers and aligns more with the rubric based idea, though it is possible that a an organization may have across the board above-average (or below) performance on occasion.
For the second, people with NI ratings aren't immediately fired (I know of a few people who got NI and found new teams and much more happiness), though obviously consistent NI could result in that.
Amazon has a more singleminded focus on succeeding in the business and making money. This can be good or bad depending on your personality and goals.
I want to say I would fit more with Amazon based on the vibe I got and my personality/goals.
It's good to know that Google isn't totally out of the question though (provided I would pass interviews etc).
It really seemed like there was a "fiasco" every year or so regarding politics and that's sorta my worst nightmare in the workplace lol
As long as I can work in peace I think I'll be happy.
Thanks again for your response!
so for a lot of people it doesnt exist.
My company tried doing the 20% thing but they put so much process around it that no one does it.
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.
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?")
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...
Overall, I think hack time/ 20% time / whatever you want to call it is very very valuable, and companies of all sizes should do it. But you have to do it right, and you have to go in with the right mindset about why you're doing it. Do it because it's fun. Do it because you help your company meet one another. Do it because you'll probably improve the daily quality of life in small tangible ways for a lot of people ...