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
I've been at Google for 3 years and have 20%ed the entire time I've been there on: grpc-go, Drive, and Go tools (gopls, etc).
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 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.
The myth that 20% time is dead was started by mchurch. He was at Google for six month and was let go. He then went on to bad mouth the company here and elsewhere online.
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.
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.
I wasn't aware of anyone saying it was dead, but the narrative has shifted over time from "work on whatever you want one day a week" to "your team might let you spend up to one day a week working on something of your choosing if it's in the interest of the company". I'm not at Google, and never have been, but it's almost certainly the case that the narrative has changed - whether or not there was ever a change in policy.
I don't think things have changed that much, only Google grew so big that 20% projects became a potential damper on your career (the incentives of perf and promo and all that horrible stuff). But the freedom has always technically been there.
I am a tech lead and find it surprising that 20% projects could damper your career, perf & promo etc. Where I work, a well-executed 20% project is seen as very positive during the perf review. In fact, doing zero 20% projects for a long period of time could actually damper your career.
But if nothing came of the 20% work, you could've done 25% more on the core job, doing positive performance things there. I'm pretty sure that's what's meant about it being a career dampener, not that it wouldn't be great to hit on something fantastic and accepted as a new core product with thousands working on it full-time. (IANAG.)
Everything is obvious in the hindsight. 20% projects carry a risk, failing one or more 20% is fine. Failing many is seen as lack of judgment and does dampen your career eventually. My point was that, with reasonable judgment, an engineer can get good stuff done with a 20% project. Also, not every 20% project needs to become a fantastic new core product to be considered a success.
Sounds very plausible from the outside.
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.
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.
> the narrative has shifted over time from "work on whatever you want one day a week"
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.
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.
And who was later banned at HN: https://news.ycombinator.com/item?id=10019003
Wow; good job, dang! mchurch is a poison to the tech community; sucks since he’s such a good writer :(
Well Marissa Mayer also said 20% realistically didn’t exist at Google, and she’s the one he insulted to get banned.
It was a shame that he overstepped the mark that one time, because he had a lot of sensible and deeply insightful things to say. He is literally one of the best essayists in tech.
Wow I had no idea that happened. Thanks for posting this for context.
(I love dang.)
Been at Google for several 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.
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 you need to find better teams. It's always been an option on the teams I've been on.
>and done as a way to soft-interview for a team you want to join
Clearly it's not that easy.
Clearly it's not that easy.
I will say that usually it is easy to move teams, but if the expertise of the team veers strongly from your background (web dev wants to work on C++) they might ask if you want to do 20% first to get a taste. Also can help convince a team to take a more junior hire, e.g.
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?).
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?).
YMMV, that’s all I’m saying. Don’t come in expecting it or you’ll be disappointed. And that’s resonated with other coworkers of mine on other teams, too.
I spent 3.5 years at Google, and, like most things at large companies, 20% is very team dependent. Mchurch may very well have had the experience of being on such a, crappy, team, not that his record is a good indication.
Marissa Mayer also said it didn't exist [0].
[0] https://www.businessinsider.com/mayer-google-20-time-does-no...
[0] https://www.businessinsider.com/mayer-google-20-time-does-no...
She was lying to Yahoo employees to make them shut up. There's no nice way to put that. My opinion of Mayer just halved reading that, I had no idea she had been misleading Yahoo staff. What a pity.
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.
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.
Marissa doesn't exactly represent Google's culture, given she works at Yahoo... :P
We should ignore the word of one of the company's earliest employees, who worked there for over a decade and became a VP just because she no longer works there?
Yes, because context is key. In that statement she was attempting to craft Yahoo!'s work culture as it's CEO.
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.
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.
Google employs over 100K people. With that many people there are statistically going to be people with the most amazing and dreadful experiences of working at the place - none of them representative.
Well. They are representative of a wide variety of different work cultures within Google. And if one were to join it would depend on the team/manager one ends up with what part of the stories told would be representative to you.
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.
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.
She doesn't work at Yahoo for more than 3 years now.
I haven't followed her career, TBH, but at the time she made the statement, she was working for Yahoo, so where she's at currently is irrelevant.
Just because she's highly visible, doesn't mean her views are correct.
Just because she's highly visible, doesn't mean her views are correct.
It was amazing how some people lapped up everything he wrote about Google (case in point: apparently a lot of people don't believe 20% time exists at all any more), I guess because he was so prolific (it was hard for actual Googlers to keep up rebut everything), and he was playing into some confirmation bias.
The confirmation bias still exists today, too. On HN I frequently see users claim that Google sells user data, but that isn't true; user data is only used for ad personalization.
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."
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."
> Google sells user data, but that isn't true; user data is only used for ad personalization.
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.
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.
If your data isn't being sold, then no, they're not selling user data. That's changing the meaning of language to make it sound worse than it really is.
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.
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.
> If your data isn't being sold, then no, they're not selling user data.
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.
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.
That's not a social media problem. The claim that Google sells user data came from the traditional news Big Media outlets like the NYT and WSJ. I remember when it started actually: it happened around the time Google News launched. The narrative in the media industry became very quickly "Google is making tons of money whilst we're going through huge layoffs" and the media spin went from highly positive to very negative at dizzying speed.
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.
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.
> Google sells user data, but that isn't true; user data is only used for ad personalization.
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.
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.
> Google sells user data, but that isn't true; user data is only used for ad personalization.
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.
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.
How is that a Google problem and not simply the other company tracking their own customers?
Google is targeting the ads, with each targeted ad they leak personal information about the users. Advertisers only have to pay and Google tells them who's matching whatever demographic they want. On the other hand print and billboard ads don't reveal personal information to the advertisers.
IIRC the confusion over "Don't Be Evil" started due to changes by Google's parent company Alphabet when they restructured.
I think so too. Alphabet does have their own Code of Conduct, but it is an additional document. It didn't replace the original.
https://abc.xyz/investor/other/google-code-of-conduct/
https://abc.xyz/investor/other/code-of-conduct/
https://abc.xyz/investor/other/google-code-of-conduct/
https://abc.xyz/investor/other/code-of-conduct/
Also (and keep in mind I'm just repeating the rumor) wasn't it supposedly replaced with the slogan "do the right thing"? It was something else fairly harmless.
Not quite. That's the slogan used by Google's parent company, Alphabet. It never replaced Google's slogan which remains the same today.
TBF, it's not just mchurch. Whether or not managers know how to make space for it varies heavily from department to department.
Should be 125% though (or is it already obvious for everyone and just me being pedant ?)
I’d never heard of 120% until this thread, but I immediately interpreted it to mean “you’re free to do your self directed 20% work on nights/weekends/your “own time”.”
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?
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?
Yeah, you'd need to work 125% as effective for 4 days to make up one day you work on other stuff.
If you use 5 days a week as base and add 1 day for personal work, you're at 120%.
Of course interpreting it as "you need to work 125% for the 4 remaining days" is equally valid.
Of course interpreting it as "you need to work 125% for the 4 remaining days" is equally valid.
Or the 16.6666667% policy
[deleted]
I think of 20% time as error correction for management. Engineers can route 20% of their time to what they think is important, and not what management thinks.
Nobody from management told me to rewrite the primitive array handling in the proto libraries for Java. It just irritated me that they didn't do what I thought they should, so I spent some time fixing it.
In my experience, 20% time is something that has management blessing. Otherwise it's just a risky side project where you're still accountable for 100% on your main assignment.
Similar experience. I 20% on python...things. some python tooling, python3 was a major one, etc. I backed off recently just because most things I was involved in are wrapping up, but yeah, it was an active area for me. And also I am sort of 20%ing on my own project that is greenfield tooling with only dubious management support.
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.
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.
Wondered if I could ask... is Google a relatively normal place to work? I currently do my own thing but I would love to work on projects that go far due to the amount of talent involved... but at the end of the day I'm just concerned with "office politics" I get the vibe that you have to "pick sides" which might just be an availability bias due to the news stories. I guess just relatively speaking, when talking with Amazon I get a different feeling. Recruiters probably aren't the best way to judge a company though, so figured I'd ask.
It's fairly normal for a big company these days: extremely slow pace, red tape all over the place, your level matters more than your skill. It's an engineering-led culture so there's a lot of focus on code nitpicking and purity (arguments over whether mocks are evil, etc).
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.
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.
By 5+, do you mean over 5 years of experience? Or is that a reference to the internal leveling structure?
There's no argument over it
Mocks are evil.
Evil enough that new mocks should be banned by fiat and enforced by code that requires rarely granted permission to override against projects that are 5 years old and already have hundreds of them in place and do not have architectures that support better ways of testing?
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.
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.
This is a vast oversimplification of mocks. Mocks themselves aren't evil, they just enable subpar programming. I'd much rather spend 2 minutes making a functional test with a mock than 2 days rewriting a bunch of core functionality in the name of code purity.
This is an excellent answer
I would never try to judge a work environment by the recruiters (unless the recruiters are unusually bad, which could suggest a toxic management culture). If at all possible, talk to actual engineers.
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.
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.
> Both Google and Amazon use stack ranking, which is about the most brutal system there is.
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.
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.
IMO it's easy to avoid politics, activism, and the associated drama if it doesn't interest you. Most people seem uninterested in that stuff. I think you're spot on with the availability bias assessment. It exists and there are conversations happening all the time, but nobody expects you to participate.
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.
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.
Thanks for the answer!
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!
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!
How do the teams working full time on a project onboard contributors who are doing it with their 20% time?
Naively, I imagine developers would get annoyed or bogged down having to skill up these contributors rather than viewing it as a “free hand”.
Naively, I imagine developers would get annoyed or bogged down having to skill up these contributors rather than viewing it as a “free hand”.
I think it's incredibly healthy to encourage that sort of "visitor" committers in an enterprise codebase, for a couple of reasons.
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.
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.
Particularly at Google, programming languages, code styles, common libraries, and tools are incredibly similar between teams. There are really low barriers to jumping into someone else's codebase. It's not uncommon to review changes to your team's codebase from people you have never met (on average, maybe weekly?).
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.
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.
Others have answered this better than I, but I'll tell you what I've seen:
- 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.
- 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.
Well, Google values independence and so almost everyone is pretty independent. There is also consistency in the internal tools, libraries and infra used, so onboarding to the new team is just understanding their project. The 20% project that you work on is also usually a task that someone can work on independently and isn't hi-pri stuff which makes it pretty easy.
TL:DR - nobody has to hand hold anybody onboarding 20% - just answer basic questions and point to the right resource.
TL:DR - nobody has to hand hold anybody onboarding 20% - just answer basic questions and point to the right resource.
How does any open source project do it?
you only hire 1-2 for your team, and it's a longer term commitment
Do you have total freedom in how you use 20% time, or do you have to plan it out and tell your manager exactly what you're working on?
My company tried doing the 20% thing but they put so much process around it that no one does it.
My company tried doing the 20% thing but they put so much process around it that no one does it.
What is the company size where you think a 20% policy like this matters? Does it only make sense for large companies like Google?
Thank you for your take on these questions, your answer would be very much appreciated.
Thank you for your take on these questions, your answer would be very much appreciated.
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.
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
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
Where can I apply?
That's not "20% time" that's "normal engineering not in crunch time".
I’m curious what motivated you to leave a big tech company for a small one?
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.
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.
Twitch was basically a 20% project at justin.tv.
Let smart people do what they want.
Let smart people do what they want.
Survivorship bias could be at play. I'm a fan of 20% time. Though I think we'd need more data than some anecdotes to draw broad conclusions.
It can be good for your engineers’ sanity even if it does not end up a unicorn, though.
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.
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.
At my last Engineering job, I would spend slow time working on job automation.
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!
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!
Those 20% at a startup can be where one fixes everything they wanted to but was never given the time.
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.
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.
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)
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.
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.
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.
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.
thats great it exists for you but having worked there a while and known dozens of other googlers, ive never met anyone else who worked on one.
so for a lot of people it doesnt exist.
so for a lot of people it doesnt exist.
(OP here) i think thats great! :)
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)
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)
> and have 20%ed the entire time I've been there on: grpc-go, Drive, and Go tools (gopls, etc).
All Google related projects.
All Google related projects.
The point of 20% time is to work on things that help Google as a company. Not sure what your point is here.
It's not intended to just be using 20% of your work time to work on whatever the heck you want to.
It's not intended to just be using 20% of your work time to work on whatever the heck you want to.
My compensation for 100% of my time, if my company want me to go above that, I expect to be paid for it. I guess you're just working for free then...
I really don't get what you're saying here. You get paid for 100% of your time, you just get to work on something beyond your direct responsibilities that still benefits Google for 20% of it.
If you're alluding to "120% time", fair enough, but that's not what GP was referring to.
If you're alluding to "120% time", fair enough, but that's not what GP was referring 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.
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.
I've never ever heard of that actually becoming a requirement.
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%.
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%.
No the official policy is 80%/20%. The joke is 120% when you're assigned too much work for your 80.
Doesn't seem to be a joke...
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.”
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.”
I don't see what Marissa Mayer's comments actually add to the discussion. She was obviously acting in PR mode as the CEO of a competitor. It's barely information.
At the time she made this statement, she represented Yahoo, not Google, and was making major changes in its culture to fit her direction. I wouldn't put much stock into these statements.
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.
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.
As an ex-googler, my manager said that we should bank our time and then spend a week on our 20 to make good progress.
That's what I did so much in my early days at Google, banking a week's worth of time and making a huge push. I don't do that too much anymore, though.
Ah, no. Current Googler here: 120% is a misunderstanding of what 20% time is.
> It's not intended to just be using 20% of your work time to work on whatever the heck you want to.
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.
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.
You are misunderstanding what "personal" means here.
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...
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...
> You are misunderstanding what "personal" means here.
[citation needed]
Otherwise, a "personal project" is a project I own.
[citation needed]
Otherwise, a "personal project" is a project I own.
[deleted]
It looks to me like the Wikipedia text is misleading, because I agree with your interpretation of the text.
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.
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 did a 20% project for Google Music back its early days, circa 2012. I was working on the Executive Compensation team at the time, but running a music blog called Indie Shuffle on the side. It's a long time ago, but I seem to recall naïvly hoping they'd embrace me with arms wide open and invite me to join their team + revamp their strategy.
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.
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.
Oh shit you created indieshuffle?
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.
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.
Loaded question! I've done a lot of podcasts/interviews lately where I touch on this subject.
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 :)
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 :)
Love this back and forth. I think I remember submitting a track with a collaborator to SubmitHub years ago and thinking it was neat that it even existed.
Thanks for the explanation, make sense.
Was there an exit interview? Was any one curious about your plans?
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.
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.
They were very supportive of my departure to pursue my own business, and I've kept in touch with a number of folks there over the years. I was offered a "sabbatical" of sorts (assuming things didn't work out), but I declined that on grounds that accepting it would convey that I didn't have full faith in my ability to make it on my own. Thank goodness it all worked out in the end :-D
That's brave, congrats! I like that.
> Executive Compensation team at the time
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?
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?
> What exactly does that work entail
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.
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.
The executive compensation team is really interesting – if you read this and have a moment, I'd love to hear anything that you're up for sharing such as:
* 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.
* 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.
Some of this, for the top 5 to 7, is public in the annual proxy; not just at Google but everywhere. Due to the principal agent problem the public data conforms homogeneously due to the retention of consultants to “benchmark”. However it would be fascinating to hear the OPs answer.
Your (former) main job sounds like a treasure trove of valuable career advice!
Many many years ago I started as a junior employee in a big company together with a close friend. I was in finance, she was in HR. From time to time we had a drink to catch up and while I was doing unglamorous grunt work she was dealing with things like compensation packages for VPs, a short-list for a new regional CEO, the yearly ranking of all employees, etc. From time to time she gave me morsels of confidential information (like the salary a VP was getting or where they were planning to move the offices).It was a totally different ball game. That's why (among other things) it is very very unwise to cross off or even to confess stuff to HR, they are at a different level.
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)
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)
[deleted]
It's kind of interesting that the ~100 people would have a whole full-time support team just for assisting the decisions (not even making them) of their compensation.
Legally, you’d hire consultants anyways, so the cost basis is irrelevant. If you are required to have insurance or a specific license but you could avoid it through a costly self education process, you end up in the same place.
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...
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...
I just wanted to say thank you for creating Indie Shuffle - I discovered some of my favourite songs on there! I've found music discovery to be quite hard, and Indie Shuffle has been a great source for my taste.
Glad you plugged indieshuffle. I checked it out and love it so far. I'm going to make a point to listen to music through it for a bit and see what I find. So far all the songs I've heard are Soundcloud and it's hard to find any information on how/where you source the material. Is it soundcloud-only? Any interest or plans for integrating a site like Bandcamp that's more oriented around me eventually supporting the artist by buying something?
Great story, thanks for sharing. What is it like being on google’s exec compensation team? I had no idea that was a thing and would love to listen to any more fun stories (only if you’re allowed to share).
Exec comp is definitely a little-known function of most major companies. Normally folks would outsource that type of work to consultants, but Google was big enough that it needed 2 of us full-time.
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 :)
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 :)
I'm so envious of your experiences. Geek me was completely oblivious to all that practical stuff.
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.
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.
This was a great read! Thank you for sharing :-)
(OP here) thanks for the response!
so the tricky question is - why stop at 20% - why not 40% - or 80%? could you make a case for that?
so the tricky question is - why stop at 20% - why not 40% - or 80%? could you make a case for that?
You could argue that Valve' s stated policy is 100% time. I'm not sure what the reality of it is but it seems like they really do want to let you work on whatever, although it might be more directed towards things that are valuable for the company and that you're good at, not just anything you desire to do on a whim. Employee Handbook: https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
Both Google and Valve use stack ranking for performance reviews, which is a pretty brutal system.
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.
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.
It depends on the need/success of the project. My first 20% project was a disconnected caching filesystem back in 2005 and it was rapidly shifted to my 80% project as it solved a real need in our infrastructure.
SubmitHub is awesome! Used it to promote my last couple of EPs.
Over the last few years, I've used 20% time to:
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.
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.
Ooh, I've been doing text-related ML for work, and have been tempted to do birdsong recognition for a hobby project over the break. Aside from that Kaggle competition, do you have any other resources you like?
If you read a bit of the kaggle discussion you'll find a lot of interesting links. The BirdClef competitions have some good write ups which, at the very least, will get you to dinner best practices for augmentation, which seems to be half the problem.
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. :)
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. :)
Thanks! I will check these out. The notion of 'phoneme' transcription is especially interesting to me. One of the things I find unappealing about a lot of current ML is how much it seems like brute force to me. Looking for smaller structural elements seems more appealing to me.
As someone who's interested in this space, could you point me to the resources you used to ramp yourself up?
Also, what are you working on w/ Audio ML?
Also, what are you working on w/ Audio ML?
Hard to point at one thing! I started with a deep learning for artists course, and adapted the stuff I saw there to an audio mini project. And then started reading the big papers in neural networks independently.
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.
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.
At Google the joke was that 20% time was really 120% time since you still had to do your day job. I never personally saw a 20% time project turn into a product and I never felt comfortable taking 20% time. However, I did feel comfortable taking on what I saw as important work but which wasn't part of my job description --training myself up on it and becoming the go-to person for that work.
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.
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.
To be fair, 20% doesn't have to be a shipping product. I've had coworkers work on things like recruiting projects (running a puzzle/coding competition that ran on campuses around the US), employee resource groups, internal dashboards for various metrics relevant to employees, morale things like massive holiday lighting decorations around campus, and so on with 20% time. Those have all been very real things that contribute to company culture and morale and have "shipped" even if not to customers.
From what I hear through the grapevine, the most successful 20% projects are contributions to existing products.
I worked at a different company that had implemented a similar policy (10% I think?), and generally the problem was the same. There was no process to formally accept projects, and no formalized way of having managers ignore the productivity loss when evaluating people.
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.
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.
I'm not a Googler but wasn't Gmail a 20% project? (And maybe other Google products that I don't know?)
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%.
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%.
Well, Paul built Gmail in a day, by layering it on top of Groups, and that's 20% of a week, so I guess technically, yes, it was a 20% project? How it came about, though, is more that Paul had been working on email for many years before Google, then the execs decided people needed to be working on more important impactful projects, and Paul suggested he try to build email.
It's important to remember the difference between the old Google with ~1k people and today's Google with 100k+ people. Things were a lot more flexible back when gmail was a new thing.
I started at G in 2005 when there were 6k engineers, but it was doubling every 9-12 months. You could watch the ossification in real time.
My experience was definitely one of 120% time. Some people made 20% projects actually work, but that became more rare over time.
Yeah, I was there 2006-2009, and each year I got another layer of management above me:)
I'm sure there were area where 20% time was real, but in my department it was pretty much non existent.
I'm sure there were area where 20% time was real, but in my department it was pretty much non existent.
> I'm not a Googler but wasn't Gmail a 20% project? (And maybe other Google products that I don't know?)
I think the parent meant they didn’t see a 20% time project come to fruition while they were there, not in general
I think the parent meant they didn’t see a 20% time project come to fruition while they were there, not in general
Also I don't think gmail was a 20% project (at least according to wikipedia which links to http://blogoscoped.com/archive/2007-07-16-n55.html):
> [...] 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.
> [...] 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.
[deleted]
Sounds like in the early days it was worth something then Google became like every other massive corporation and lost it's soul!
I'm not and never was a Googler but at Atlassian we the same policy of 20% time and I really do think it was super valuable. There are a certain number of developers who will muck around and waste their 20% time and there are certain (terrible) team leads and PMs who discourage the use of the time because they're anxious about their own projects.
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.
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.
> 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.
Can we get some of that same love put into the actual business products?
Can we get some of that same love put into the actual business products?
I no longer work at Atlassian but I spent my last year working on a Jira frontend refresh that no customer ever asked for and few considered an improvement. So..... no? Haha sorry.
A missed opportunity... Seems my team spends more time complaining about Jira card load times & its interface than they do discussing the card..
Our beloved Trello now has some critical bugs. Makes me very sad.
I guess this is partial evidence that stakeholders and customers don't agree with 20%!
Linear just raised! Is that what you mean? :)
Another Atlassian here... I'll vouch for everything here, but I'll add on one thing.
> 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.
> 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.
Honestly I wouldn’t agree to have 100% of my effort dictated by others. I never had a visa situation but even as a fresh out of college worker, I demanded a portion of autonomy. I wouldn’t be fulfilling what I could do for my employer otherwise. I get odd looks for some of the things I get enthusiastic but some of them work out. And I learn a lot more about things and in particularly the growth of new things from being fully responsible for some things. If you are a smart person who can code, you absolutely have the labor market power to take partial control of your time and effort. I would say you have an obligation as a thinking worker to cultivate yourself in this way, for the benefit of yourself, your coworkers, and your employer.
When you say "100% of my effort", do you include the time you spend outside of work hours, or do you include those your employer pays you for?
I think I'm also in the same bucket as the original comment so can answer from my perspective.
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
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
I wish my company did this, it would give me time to flesh out all those ideas that I have as I do my regular job, but "we don't have time for that" that I refuse to take home with me :) 8-9 hours of coding a day is enough for me. I actually worked on an automation system (mostly on my own time) that literally reduced the "manual human intervention time" to an 8:1 ratio. I'll admit it was rough first and I estimated it would take me time to train a typical technician a day or two to wrap their head around it but it could be done (I actually trained one tech on it during an all-nighter demo to him, and he loved it). Anyway fast forward a bit, I presented it to my manager and his manager and he said "we don't time to train techs on that, we have to get work done" and I had already trained 1 tech on it, and we did it on our on time! I was so dejected after that that I left the company about a month later and was much happier.
From what I understand, 20% at Atlassian is more like: spend every Friday doing whatever you think is most important/interesting. That's quite different from my experience of 20% time at Google, which tends to require explicit manager approval.
Xoogler here who left a few months ago. The policy totally still very much exists, although isn't "advertised" as much per say. Like, I think maybe 25% of googlers use 20% time and most are driving their own projects rather than working on some larger project they were pitched on.
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.
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.
The most visible impact was in the company's internal services. Many "scratch an itch" tools such as Google bus schedule lookup, employee tenure lookup, or massage-room booking originated in 20% projects. The "internal social media" of Google such as "moma badges" ("achievements" for e.g. writing 100 CLs or contributing to a particular fixit -- anyone could add new ones) and the internal joke image board "memegen" also originated as 20% projects.
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.
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 like that a lot. although arguable whether memegen is a net conributor or detractor to Google's productivity (debatable) and culture (even more debatable)
I have no idea if it was good for their culture since I never worked there... but I reckon a lot of corporate software engineering jobs have the same luxury, informally. I work at a big US bank where you might not expect such freedom, but in reality there is great flexibility to do things outside of the normal day to day BAU, simply because it's not hard to deliver a sufficient amount of work in less time than you're expected to be in the office (or covid equivalent), and nobody keeps that close an eye on what you do anyway. Still, with all that freedom people don't always use it for good, they may actually just bunk off...
> Still, with all that freedom people don't always use it for good, they may actually just bunk off...
This 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.
This 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.
As a counterpoint, I've been promoted so that I could maintain leadership of a successful 20% project before. And I didn't go into it expecting it to get any visibility, it just happened.
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.
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.
Agreed, it absolutely depends on where you work and sometimes your management chain. I'm mostly referring to the finance industry where I've seen this pattern repeated many times.
Still, with all that freedom people don't always use it for good, they may actually just bunk off...
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.
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.
Why would one do twice the hours that one is paid for? That makes no sense. :)
At some places that is the culture, and I'll do it for a couple weeks during a crunch, but I refuse to do more than that. After a week or two your efficiency goes down incredibly unless it is "your baby" or your passion and it's basically "fun" for you. I've never had real fun working on someone else's baby. Burn out is a real thing. We didn't evolve to sit on our asses in front of computers 16 hours a day, it's a simple matter of biology. We are adaptable, but we're not that adaptable.
Exactly. I can’t work 12 straight hours on an average day, my mind wouldn’t have allowed me to.
> Still, with all that freedom people don't always use it for good, they may actually just bunk 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.
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.
I don’t trust software engineers without sufficient laziness.
> don't always use it for good, they may actually just bunk off...
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.
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.
I worked in a company that did not keep tabs unemployees at all. I was able to eventually reduce the amount of work it took to do my job to about 20 minutes per week. I use that time to learn how to program, then left and started an agency.
Tell us about your agency.
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.
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.
Business siders including HR, marketing, sales, product, execs, managers etc ALL universally don't work Fridays. They (used to) come in for a couple hours then "bunk off" to the bar for lunch and happy hour (starts at 3). I find it ridiculous that engineers actually do work on Fridays, much less Friday after 3pm.
Depends on the place for both counts.
In the heyday of 20% time, Google had more money than they knew what to do with and the engineers were generally overqualified. Remember that in the early 2000s Google was famous for hiring people with PhDs and asking them build web servers.
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.
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.
The way I've heard it expressed is "if you want to hire racehorses, sometimes you've just got to let them run"
I don’t understand. A PhD is a degree in research. If you have a PhD and are building web servers you sound misqualified.
That’s exactly the point- Google in that time frame did a TON of prestige hiring, whether or not it made sense for the actual work they needed to fill.
That’s not what I got from the original comment.
How so? That was entirely the point
You’re not the origianl commenter so I don’t know how you divined that.
Building google _was_ research. It grew out of a PhD thesis. There are publicly available papers describing lots of the infrastructure innovations along the way (GFS, bigtable, mapreduce, borg, spanner, etc)
Take it up with the grandparent comment!!! I replied to the part about hiring PhDs to build web servers, with the strong implications that they were overqualified (or—misqualified) for the task!!!
Because it was never a thing
My experience while working there was that like most things the experience varied hugely depending on your manager and your current rating. For me, it was also kind of irrelevant since I'm one of those "weird" people that write code to relax in my "spare" time. Google didn't care what time of day you worked, I would find myself during the weekend trying out different things with map/reduce to see how different algorithms would need to be adapted and what not. Was that 20% time or just using the company's assets to indulge my curiosity? A bit of both I guess.
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.
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.
>large and financially secure startups, say 1k developers and up
Sorry for the tangent, but what’s the definition of ”startup” we’re working with here?
Sorry for the tangent, but what’s the definition of ”startup” we’re working with here?
My working definition is something like “pre-product-market-fit” or “hockey sticking” growth. Once you saturate your market and have to fight for every percentage of growth (or are so big that new things can’t make a big impact even if they are exploding in their niche) then you’re no longer a startup
This also implies that linear growth companies aren’t startups, they’re SMBs. This is probably controversial and definitely valley/VC centric.
pre-exit, I presume.
(Opinions are my own)
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.
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.
> 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.
thats a fantastic way to put it. as a businessman, 20% seems super high but who knows what the right number is. it's not 0%.
i'd be careful about IP in terms of "plucking from my job's monorepo" - 20% time work is still work that they paid for. but im sure you've considered that.
lastly - my qtn was not just about retention and saving money - it was also about culture - i do worry that politics and weird team dynamics arise when you basically play on a different team 20% of the time.
thats a fantastic way to put it. as a businessman, 20% seems super high but who knows what the right number is. it's not 0%.
i'd be careful about IP in terms of "plucking from my job's monorepo" - 20% time work is still work that they paid for. but im sure you've considered that.
lastly - my qtn was not just about retention and saving money - it was also about culture - i do worry that politics and weird team dynamics arise when you basically play on a different team 20% of the time.
> i'd be careful about IP in terms of "plucking from my job's monorepo" - 20% time work is still work that they paid for. but im sure you've considered that.
Part of something I did was setup an internal process for clearing things for external release for which all of the projects on the company's GitHub page were passed through :)
I'm fortunate to have had such a supportive manager at my previous company. They're looking for senior engineers by the way so if you're interested in the company after looking at those repos feel free to email me and I can hook you up! They really are awesome people.
Part of something I did was setup an internal process for clearing things for external release for which all of the projects on the company's GitHub page were passed through :)
I'm fortunate to have had such a supportive manager at my previous company. They're looking for senior engineers by the way so if you're interested in the company after looking at those repos feel free to email me and I can hook you up! They really are awesome people.
i am very gainfully employed, thank you :)
There never was any real 20% time. It was, as others are saying, 120% time, at least if you care about actually moving upward on the career ladder.
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.
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.
> and gets to deny promo because you "spent too much time on your 20% project", as well
or "while that's extremely important and beneficial to Google, it's not valuable to this PA. Thus you should unmark yourself for promo otherwise our director will tank you in committee." True story. :) Glad I'm out of that toxic group; I was able to turn my 120% project into my 100% day job and am much happier and well rewarded.
or "while that's extremely important and beneficial to Google, it's not valuable to this PA. Thus you should unmark yourself for promo otherwise our director will tank you in committee." True story. :) Glad I'm out of that toxic group; I was able to turn my 120% project into my 100% day job and am much happier and well rewarded.
Fwiw I know of more than one person promoted to senior based primarily on 20% work.
I'd agree that it becomes rarer at staff+, just because your goal is to make cross Google impact and that's difficult in the context of most 20% work. But even there I know of people at that level who do 20% work. I'm not sure that they're any rarer than 20% at lower levels.
I'd agree that it becomes rarer at staff+, just because your goal is to make cross Google impact and that's difficult in the context of most 20% work. But even there I know of people at that level who do 20% work. I'm not sure that they're any rarer than 20% at lower levels.
It was great marketing among developers if nothing else. Don't forget the pre-hires!
Nobody just let you do passion projects! Get back to your work
Nobody just let you do passion projects! Get back to your work
Yeah it was great marketing. One of the reasons I so very much wanted to join the company. And here I am still, nearly 11 years later.
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.
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.
It was and still is part of our culture.
I work at 3M where we have had this policy for about 100 years.
It’s the only reason we still exist; most of our sold products were side projects a generation ago.
It’s the only reason we still exist; most of our sold products were side projects a generation ago.
I feel like at a place with expensive lab equipment, 20% time can go a lot further. Take smart people and give them a free day once a week to use all that expensive equipment they couldn't do on their own, and maybe magic happens.
I feel like access to Google's infrastructure + data definitely fits the profile here.
I don't really think so. Most programming tasks can be done with a 2010 year-model computer. In machine engineering etc. you need expensive equipment.
At Google it's commonplace for a single engineer to be able to run a MapReduce over the entire internet. Or do experiments with training huge deep learning models.
The fact that approval is not required (aka 20% project) to use staggering levels of compute is the advantage I'm talking about.
The fact that approval is not required (aka 20% project) to use staggering levels of compute is the advantage I'm talking about.
That sounds a lot like a hacker space. While with paid time and less beer, it's not that dissimilar. I still think cities should create these spaces, not just support them... and unfortunately even support is almost never given.
I'll caveat my remarks first by admitting that I nearly completely ignorant of Google's 20% policy, but since it was widely advertised, my workplace made a similar statement that one half of each Friday should be dedicated to learning something new to benefit the team and thereby our careers. All I could ever think of after this proclamation was that I was to do as I was told 85% of the time and innovate 15%. As a developer, I offended that my innovations are devalued to a time slot. I was under the impression that I was expected to innovate continuously within the confines of the deadlines given. My two cents.
Did you consider that maybe setting Friday up for everyone was to allow everyone who wanted to participate to work together without scheduling challenges or conflicts with their hired roles/team obligations?
This is like saying a Hackathon is devaluing creativity because it occurs at a scheduled time...
This is like saying a Hackathon is devaluing creativity because it occurs at a scheduled time...
I get your point, but without paragraphs of explanation, I doubt I could persuade you.
I can say this... It was meant as a solitary exercise, not as a group.
Bu then, if everyone stops to work alone at different times, you have a problem scheduling work things... I.e: if you want to take Tuesday afternoon to do your things, but then they need you for meetings/work on something else.
Don't you innovate during the other 85%? Likewise, couldn't you spend that remaining 15% doing rote, uninteresting work of your choosing?
To me, the concept of 20% time is the freedom to choose what you're working on, not how you should be working.
To me, the concept of 20% time is the freedom to choose what you're working on, not how you should be working.
oh i love this! unintended consequences always arise - this is one of those reasons why I asked the question. thank you for sharing how this felt.
Googler here: I did a true 20% project once. I was filing a ton of bugs about Android internally and the process was crappy, so I found another person and we started working on an app to report bugs directly from the phone.
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...
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...
I think it was great. The problem, in my experience, is that everything at Google is just too damn complicated these days. It's really hard to make an impact on a hard problem without an intense commitment. 20% context switching doesn't cut it.
Linters, code checkers, automation tools, IDE plugins, etc, have all been plucked. There's not a lot of low hanging fruit anymore.
Linters, code checkers, automation tools, IDE plugins, etc, have all been plucked. There's not a lot of low hanging fruit anymore.
My experience as a long-time Googler has been that people do 20% projects for two main reasons:
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.
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.
I used 20% time for things that were related to my work, but out of scope for my team. For example, I wrote a DNS library in Go for work and then I open sourced it [1] and used it to rewrite the standard library DNS client [2] as a 20% project. It actually worked out really well for me. The promo committee specifically called out my DNS project when they approved my promotion and ignored the stuff that I had been doing for my team.
[1] https://golang.org/x/net/dns/dnsmessage
[2] https://golang.org/cl/37879
[1] https://golang.org/x/net/dns/dnsmessage
[2] https://golang.org/cl/37879
It's successful branding for a thing that happens at all companies - if people want to do things other than their core job, they can do it. They won't get too much credit for it unless it truly pays off.
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'.
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'.
Current Googler -- AFAIK, 20% time is still a thing. You just have to clarify the project with your manager, just like you did before. I utilized it to write the Mendel development tool (mdt) for Coral boards here: https://pypi.org/project/mendel-development-tool/
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.
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.
Would you say it's more like 120+% time or is that a misconception of the policy by HN people that have never worked at google?
120% is a misconception. 20% is volunteer. 80% is assigned. I built MDT that way, taking a few days cumulatively to work on it, and I maintain a strict 40 hour work week, with my manager's backing.
thank you - i think i was misinformed by that one guy who claimed it was dead.
damn.. my interest in Google rose significantly after posting this...
damn.. my interest in Google rose significantly after posting this...
There's been multiple calls that the policy is dead or 120%, neither are accurate, most spoken by folks with ulterior motives and biases.
In The Reponsible Company (by the Patagonia founder), he credits Googlers doing 20% time to do environmental work. The book is really pro-corporation though, heavily a PR piece IMO.
I found that to be the case with all of Chouinard’s books, especially “Let my people go surfing.” Tons of lightly veiled corporate propaganda.
From my time there, the most important thing about 20% time, from my POV, was the message to all engineers that innovation, personal growth, and expanding the boundaries of your work, is important to the company. It was less important whether you really engaged in a true 20% or not. The point was that the company very loudly endorsed the idea of it -- even if in practice, it was hard to get right.
At my company (BigCo but not FAANG or SV), we have 20% time, but it's more for personal learning than side projects (and when it is projects, it's fine if those are just to learn, and not to help the company directly.)
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?")
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 worked at Google 2006-2009. I joined a 20% project with an awesome staff engineer, then recruiting one of my team-mates to join 20% too. We ended up working on it full-time. It didn't end up launching but I think the core code ended up being used as part of other products. It was incredibly rewarding and a great outlet from my typical day-to-day improving Adwords.
I worked there in 2010s and almost nobody was utilizing it anymore since general incentives were not aligned: it was hard to cut out time from your main project, and on top of the you had to pre-justify your 20% project as useful, which is for 20% project often more work than the project itself.
20% when i left Google in 2019-04 is all but gone. It was not practiced widely. In my group, Borg, I don't know personally a single employee does that. During my tenure at Google from 2013-2019, I only know one person did that.
The 20% policy definitely still exists. I am puzzled that there are so many comments saying it does not.
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 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 work at a company with 10% time, and TBH most people don't do much with it, if at all. A few do and really seem to appreciate it. We get more innovation and ideas from hack days.
The problem is that it is very hard to get something big from little splotches of time, or at least I find it hard, so I focus on little wins.
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.
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.
I write very little shippable code in first day of a 3 day task. Also my itch for unfinished work is very unhealthy. Does 20% favour guys who compartmentalize unfinished business to a fixed day every week and ramp up quickly?
Does the 20% need to be distributed evenly, time-wise?
Or could you combine it into a 5-10 week clump between projects?
Or could you combine it into a 5-10 week clump between projects?
Mine is one day every other week
We have a form of it called fix-it-friday and I find it helps a lot with minor UX improvements and tech debt that would otherwise fall in-between the cracks.
You're probably downvoted because it's semi-off-topic, but I think it's close enough to be relevant and worth discussing.
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.
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.
Yeah, that sounds about right. It's those little things that really help the whole platform long term.
This is not 20% time for personal projects. This is is scrambling after the fact to fix things that should be done as part of the normal development cycle. Formalizing it is basically saying "we know our process sucks, but instead of fixing it, we're going to sell it as a feature."
I'm sorry, but you're wrong. Look at the comment I wrote below for more context.
Fridays can be "lame duck" days, and I never start something new over after noon. So Fix it Friday is a good way to allocate smaller blocks of time for smaller tasks.
But 20% is about side projects. Meeting Free Monday could be a good policy to foster those.
But 20% is about side projects. Meeting Free Monday could be a good policy to foster those.
Yeah, my manager love his job and works 12-14 hours a day. I have to push back often on Friday to say "I'm out", he's always cool with it but he tends to forget what day it is so I have to remind him. It's on reason I stick with the well paid consultant by the hour work. I like programming but it's not my sole reason for existence. The only reason I still like it is that I survived a burn out job and realized that I didn't hate programming, I just hated not having a life because I was working such long hours and had no energy for other things.
Do you get to choose what to work on? Does it have to be in the backlog or can it be something not tracked?
Yup. Some people choose to just do regular feature work, others use it to great effect. Some of the best examples are slowdowns that sort of fall in-between feature teams, or debugging features that help other devs/QA, or tooling that helps debug customer issues. I imagine most of the things fixed come from annoyances that devs run into that they want to improve the product, QA, or tooling experience, customer experience.
AFAIK it still exists. In my several years there, most people didn't take full advantage of it, and that was as true in 2011 as it was in 2020. Most people just didn't come up with anything a technical project they'd rather work on than their core project. (I was one of those.)
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 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.
Can someone give us a review how the 20% rule works/worked at Google? What I've read has always been second hand. Not directly from a Googler. I suspect that at the very least the 20% gives high employees a way to decompress for a bit by working on projects they love rather than ones that they have to do.
The policy still exists (it is still encouraged, me & my coworkers used it in the last ~2 years).
The "120%" issue is up to individual / manager (like many things at Google), I just took Fridays off of my main project, other people have different approaches.
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).
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).
A broad, sweeping 20% time was never a thing even at Google. Some "rockstars" may have been left alone by their manager to pursue such projects, but the average engineer absolutely did not have this freedom. It was mostly all marketing.
I don't know about that. I was no rock star, but my teams let me pursue it with no issues circa 2008-2015.
I wonder if '20% time' but on some kind of 'approved' project might make sense?
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.
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.
Gmail supposedly came from Paul Buchheit building it for his 20% time. Likewise, Google News was created by Krishna Bharat for his 20% project when he wanted a way to keep up with news after Sept 11th.
Are there examples of successful results?
Are there examples of successful results?
Google Reader :(
from my experience at google. everyone is so obsessed with promo that no one does 20% projects because it distracts from their main project and hurts their performance review and delays their promo.
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.
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.
[deleted]
I was working at a fairly small company who tried to do the whole 20% thing. For me it was awesome as I got to work on some really valuable things without all of the bureaucracy around project management.
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?
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?
employee morale is worth a lot though and often overlooked at big corporations.
I think it was a great outlet for the people who enjoyed using it. But most people were busy enough with their regular jobs that they did not engage with 20% time.
Not at Google, but rather Shazam.
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.
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.
If I remember correctly, Orkut [0] was the output of one of these 20% projects (the Wikipedia page doesn't say that; my memory might be wrong).
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.
[0]: https://en.wikipedia.org/wiki/Orkut
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.
[0]: https://en.wikipedia.org/wiki/Orkut
Personally, I think it is a good policy for work culture. 20% does not just mean you have to work on your own idea but you can work on your other passions or to develop your skills. Say you are a backend dev and are passionate about ML, you could do a 20% with another team which is working on ML and develop your skills or just test waters.
If that work has impact you can also include it in your perf.
If that work has impact you can also include it in your perf.
The most important thing when building your company is that you encourage individual initiative: it might be via 20% or via some other ways. It is only reasonable to have 20% in certain situations.
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.
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.
OK, never worked at Google, most likely never will for a million and one reasons but... Could someone eli5: What's a 20% time policy?
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 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.
We started a 20% project to get stuff done when we were not able to get head count. It was related to ML and people that joined were actually interested to learn the skill to move to a new team or our team. Unfortunately it took a long time before we actually got something that was useful. There was not really commitment not accountability.
Waste.
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.
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.
Never went into a company that did this, but it would surely fit my brain, I often need personal outlet (unless the main tasks are already providing me this). It would probably drive my productivity up so I can finish the boring parts and enjoy a mind-free 20%
I've always wondered what the accountability for 20% time was. Did you check-in on your project with a manager? Did you present it at some demo meeting? If sufficient progress wasn't being made, did someone "encourage" you to change projects?
You can do it a few ways. But in my experience, the simplest and best way is to force people to demo something at a pre-specified time. If you're doing it "hackathon" style, then it should be at the end of the hackathon. If you're doing it 20% style, then probably end of the quarter? You could do it with zero accountability, but having tried to run these programs (see my other top-level reply here), I think you'll mostly get a lot of people not doing much if you don't have any accountability.
I have trouble appreciating the 20% time. What's the fun in doing something by yourself? Isn't the exciting part about Google working at scale with resources you'd never have anyone else? Personally I feel like I would decline on 20% projects.
You can use the time to work on existing projects and/or with other people.
I have used something like 20% time to help manage technical debt, keeping it from consuming our team in web of pain and complexity. Usually we come up with a week or two of time every quarter to take care of these things, instead of a day a week.
Shouldn't that be part of your core responsibilities and not "20% time"?
Eh, maybe. Your core responsibility is to ship on time. Especially at a startup, it's not only "ok", it's usually the "right" call to ship faster, and accumulate technical debt. This is constant, and never really goes away. So you tend to have to intentionally bake in this time, or else it never happens.
And I think this is OK! It's not always clear what is and isn't technical debt at the time it's being introduced. A lot of things seem "gross", but aren't actually much of a problem. Or you think, "oh god, this will never work when we add X feature", but then you just never add X feature, and so it's totally fine 2 years later.
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.
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.
Yes, we're in agreement. A coworker of mine pointed me to the book Accelerate [1], which I admittedly still haven't read, which also mentions that organizations where management tries to make sure engineers are at 100% utilization end up being dysfunctional, partly for the reasons you pointed out.
[1] https://www.amazon.com/Accelerate-Software-Performing-Techno...
[1] https://www.amazon.com/Accelerate-Software-Performing-Techno...
It's one of those things that works for a quarter or two, but then you start making your engineers hate their job and productivity drops quickly when morale is suffering.
I do like the idea of being able to spend 20% of your time on work that is worthwhile, meaningful, rewarding, and that you actually enjoy, but I wonder if the percentage could be increased somehow, maybe to 50% time or something?
The way to do that is to find projects/changes to do that marry the business requirements with what you believe is excellent and right and should be done. Don’t just blindly implement requirements and don’t just build what you like, but have a compelling technical vision and then find other important things that justify (to others) building the vision.
20% projects (and the policy supporting them) are very much still a thing at Google. Not sure how many people actually participate in one but my perception is that it is a relatively low percentage of employees.
I never worked at Google, but I did work for a different, fairly well known consumer tech company doing a lot of work around "hack time". While there, they didn't have any such program, and I really wanted there to be one. So I helped implement a program for "hack time", which was pretty close to 20% time. I did surveys of over 100 engineers, put together a presentation for leadership, got directors of various eng departments on board, did a pilot program, then did post-surveys and presentations to gauge impact. We also spent time with managers to make sure they were on board, and made it clear to their direct reports that they were on board, and that it was OK to use hack time. The point is, we really tried to do this right, and get people to use the time, and assess if it was actually valuable.
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...
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.
I worked on a 120% project but was advised not to let my manager know about it unless it was successful. Not sure that is an indication of it working as intended.
I worked at a company very close to Google and we adopted the %80 rule. It was forced. You were not allowed to make changes to production on Fridays.
I do this at work on a personal level. I don't push any changes of any "large" variety as I appreciate my off time on the weekend. It would be a dead obvious pattern if management checked my commit history :)
if this is a joke it's not really funny
I’m serious. NCF = no change friday. It was culturally unacceptable to force people to work on weekend to fix.
Where I work, many teams also don't push to prod on Fridays - although on our case we continue to work normally.
For user-facing things, we also have code freeze at the end of the year, over the holidays.
For user-facing things, we also have code freeze at the end of the year, over the holidays.
[deleted]
Are there any companies out there that allow a 20/80 schedule, meaning 80% working on own projects?
Yes - the vast majority of open source projects are run this way.
The down side is that you don't get paid. And I think that's pretty consistent -- no one is going to pay market rates for you to spend 80% of your time on "whatever you like".
The down side is that you don't get paid. And I think that's pretty consistent -- no one is going to pay market rates for you to spend 80% of your time on "whatever you like".
VC firms do. They call it Entrepreneur in Residence.
Wish they would spend that 20% time working on maintaining and keeping old Google projects that people use and depend on alive.
the policy still exists tho
[deleted]