I'm not doing 20% time to trend shit for YOU on GitHub so that YOU can feel like you're doing something as a manager; intruding on and micromanaging "free time" until it's anything but "free".
I'm doing it to answer a burning question I have about something and do some exploration whether YOU think it's useful or not.
And before you whinge and bitch that I'm there to serve the company, a) if that's what you want then don't fucking act like its free time because it's not, and b) irrelevant disconnected ideas and the curiosity to pursue them are not only the indicators of your smartest and best employees they're also a precondition to keeping them happy and keeping them at all.
This time benefits me. There have been plenty of HN articles that breakthroughs come from tying together these previously thought irrelevant ideas. And in my experience researching some side project always comes to provide needed knowledge somewhere else eventually, always.
Just not perhaps in the short 30 second timespan and timescale of an idiot clueless irritating manager.
I also had the same initial reaction, but also keep in mind that these guys are paying your salary. You are literally there to serve the company in exchange for money. If your manager wants to make your 20% time more structured, then so be it. It's not free time, it's just a block of time set aside for research, experimenting, and innovation. You're still being paid for it, and it's not like you're being asked to work overtime or during your lunch break. If you want a lot of free time, then you can find a part-time freelance job and work from home.
>If your manager wants to make your 20% time more structured, then so be it. It's not free time, it's just a block of time set aside for research, experimenting, and innovation.
Then don't call it 20% time. Fold it in as a "spike", in the normal sprint planning process.
The visceral reaction you're seeing to this system stems from the disconnect between the promise of "20% time" - that I get to work on something that I think is cool, without having to justify it to the company - and the reality, which is that it's just normal sprint work by another name.
If 20% time is subject to the normal planning and prioritization processes that the company uses for planning out the rest of its work, it raises the question of why you're placing that time into a separate bucket in the first place.
> If 20% time is subject to the normal planning and prioritization processes that the company uses for planning out the rest of its work, it raises the question of why you're placing that time into a separate bucket in the first place.
A cynical answer: Other companies have heard that Google does this cool thing called 20% time, and they want to be hip too, but don't want to give up any actual employee-hours to institute it. So instead they just rebrand some portion of their normal work as "20% time".
But who can resist the lure of paying down technical debt during one's allocated "20% time" that was accrued in their job vs all the other things not necessarily related to their job that one may find satisfying and might make them more valuable as an employee or to other human beings outside of their job?
I provide my time in exchange for compensation and I do what I think is important with a little grey area that I also join in (for example, meetings).
Ultimately though I decide what I'm working on and this usually works because I'm in touch with what's going on, I'm good at my job, and I want to keep it. However I still spend most of my time working on my own ideas of what's important and how I'm going to achieve it. This works for me and it works for the managers who are strong enough to let go of micromanagement.
If the company feels that this goes wrong, or is out of touch with what they need, or simply (as has been the case once before) agree with exactly what I'm doing but feel the need to repeatedly "take control" and put structure on what I'm doing already, then this is fine and we can part ways.
But I don't go to work to serve, follow, or otherwise be a slave to others. I would rather kill myself than live feeling like that even for 8.5 hours a day. No.
Really? Seems like you just vastly over-analyzed the word. Working for an organization means serving them. That's the actual definition. It doesn't mean you're a slave.
This kind of touchy sensitivity to completely normal words is what I don't want in employees.
You cannot structure or manage idea time. Actually a lot of successful open source projects were started by single persons in college. Many sponsored or managed projects progress slowly, because management kills off all creativity and drive.
Absolutely. I'm an administrator but I do a lot of programming to automate parts of my work.
Some people fail to understand what a creative engagement that is. I'm not saying my code is fantastic or anything but it is an extremely emotionally driven art.
Some people only understand clocking in, working 8.5 hours, then going home. To me, I might be working 16 hours 4 days in a row to fix one function in some code I use that is driving me crazy; and if I can't then I'm just not going to be able to do my job anymore.
On the other hand once it's fixed it's one of the best tools the company has (in that it's doing something that few others in the industry are doing, even if... nobody except me is using or knows about it... because it's managing an aspect of my work and it's not important to them HOW I do it).
> You are literally there to serve the company in exchange for money. [...] If you want a lot of free time, then you can find a part-time freelance job and work from home.
Fully agree with the premise — you are a servant meant to obey orders. But there's another conclusion: try to set aside time for freedom regardless of what Big Boss says.
For example, everything is negotiable: how much they surveil or micro-command you. Or if you consider yourself an adult, you simply do what you think best, with whatever expedient little tricks to keep the local bureaucrat happy.
(Obviously, this advice is not intended for those who identify with the boss. Most know the ways the deck is stacked against them, for example bosses colluding to weaken their bargaining power, or simply being born in a time in history where they must be servants to have a decent life.)
My paycheck is there to make me considerate of my employer's priorities, it does not make me be a slave to them. If those priorities are misplaced, I have no obligation to support them.
Agreed. Correspondingly, if you don't adequately support their priorities, they have no obligation to continue to employ you.
It truly is a two-way street and works best with cooperation and some give and take on both sides. Treating it as a purely antagonistic relationship is poisonous and generally not sustainable. If you think it's that bad, go someplace else.
Do companies act like it's "free" time? My impression was that it's intended to be free time to focus on projects of your choosing, but still things that will (or may) benefit the company. This is a far cry from free time to work on personal endeavors which you seem to be describing.
It's not like you're digging a hole in your backyard. It's meant to be (or should be) providing time to do something outside of management's understanding of what's important.
Sure, but has any company ever had a completely hands-off approach to 20% time? That seems unrealistic to expect for such a large investment. I'm sure you have to strike the right balance in order for that time to be effective but your initial comment came across sounding like any attempt by the company to ensure that the 20% is time well-spent is some sort of intrusion into developers' "free" time.
Did we read the same article? What I got from it is that you can work on any project of your choosing, not a company project.
Here's a relevant quotation:
"To start we ask each person to add to a vertical list of project names on the left side of a whiteboard. These are projects the group can work on. It’s fine, and in fact common, for people to list their own pet projects."
Also, I see no reason why you can't use this system and, at the same time, have someone work on whatever they want, if that's what they feel like.
"Each person now chooses from their original three the task which consolidates the collective work on as few projects as possible."
It's an "enforced teamwork" situation (the article is pretty explicit about this up-front). If you want to work on a personal project, you're going to have to attract some others to join you.
We have successfully pulled off 20% for 5+ years now at Kiva, doing some of the things suggested here.
However, the key thing we do is actually make the 20% be a full two-week sprint, it just happens every 5th sprint. That way, you can have the time to do some planning, suggesting, and documentation before setting out to build something and you get the full amount of time you needed to build it. We purposefully do try to keep features limited to something shippable during that time period, though some folks will spread it out over a few for bigger efforts. It's pretty great and a key part of our culture that I'm happy we've been able to keep. It's also produced some of the best features Kiva has (as well as served as a great time for engineers that like to tidy things to clean up the codebase).
If a developer places an idea up requiring only 4 points, can they pin their own 4 points to it and work on it alone without having to answer to anyone?
The entire point of the 20% concept to me is that I get to work on my own idea. I do not like your version that makes it a popularity contest between developers and their separate ideas. Most of the fun that can be found in 20% is the lack of constraints and oversight. The 20% should not have to be justified to anyone, let alone planned out and required to fit within a single sprint.
To be fair, I despise agile (or is it capitalized Agile?) in all its bullshit incarnations. The most interesting aspect of a 20% project is that the business keeps its filthy hands out of my time. Applying agile into the 20% makes me sick.
I've been through the agile process at 5 different companies, and it has never been successful. My biggest issue is with the people who are brought in to implement it. The scrum masters always try to spin the whole thing as a positive for both the development team and the business. Both the team and the business's management are supposed to be disciplined. But the scrum masters always wind up being scum masters, always bowing to the will of the business's management. Meanwhile the team is left with nobody to defend their right to have the process respected.
The primary selling point is always the removal of the "old waterfall method". And yet every single sprint, 20-40-80 hours worth of "more urgent tasks" get dropped in without proper grooming or advanced planning. Whether or not other tasks get removed from the sprint to equalize the incoming work does nothing to alleviate the frustration.
Every agile process I have seen always winds up being the same old bullshit of management having no discipline to actually follow the rules. We call it agile, but it's still just waterfall glossed over with a name - with none of the actual principles being taken seriously.
Ok, I can see why you might be jaded about it! I've had very different experiences, and, as you say, it probably depends on the people who are implementing it - the discipline is very important, and perhaps we were fortunate in that regard without realising it, because it was something we implemented as a group rather than being imposed on us from above.
Yep, a developer can work on their own 4-point project and doesn't require collaborating with anyone or any oversight other than approval from a PM before making it live if it is a user-facing feature.
The only requirement is documenting how the project is good for Kiva. Some people would like to do something like say go learn Perl with their time. That's great for the person, but better covered by the professional development budget than innovation iteration. So, sometimes something like that gets shot down, but it's rare.
I like the idea of every 5th sprint being devoted to this – a day week is barely enough to just switch context and get into gear. I can see how getting a couple of days distance between "real" work and the 5th sprint would be beneficial just to clear your mind and start fresh, knowing there are two glorious weeks of focus ahead.
I worked at a large company which in its quest to deploy agile everywhere introduced an innovation sprint. The actual concept went well, and we even had some great show-and-tell sessions from it, but absolutely zero things created during those sprints were allowed to ship. So in the end it was more of a blow-off valve for engineers before sending them back to another 10 weeks of normal engineering drudgery, while their innovative projects collected dust on a manager's shelf somewhere. If these were research spikes I feel like they would have gotten a little more respect from the higher-ups.
That's a really great idea. Two weeks is just about enough time to see if an idea is going to go anywhere.
I've worked under 6-8 week fail fast R&D regimes before as well and have found they really help provide focus...though in all cases it seems to push the R&D effort much more towards an Applied R&D approach than a theoretical one.
That's funny, psychologically it seems much easier to accept 1 day per week spent on side projects. But a whole block of 2 weeks to work on whatever you want sounds really crazy, even if it's after 8 weeks of regular work. It sounds like it would work a lot better though, context switching can be a real pain.
How to make 20% time: Just do it. Don't tell anyone. Tell that asshole trying to control your work to fuck off. When you've got something, tell the right people about it. Watch the other assholes at your job trip over themselves as they trash your work that you already got buy in from from the right people. Publish it. Launch it. Put it on your resume. You'll probably get fired because the assholes will resent that you're not under their control. So what? Make getting fired part of your career progression plan. Start your new, better job, rinse and repeat.
So, if I'm understanding you correctly, you think the way to advance your career is to spend 20% of your time working on unsanctioned side projects in work time, writing code that will be owned by your employer that you can't publish legally without permission, all the while taking longer to do your assigned tasks and looking like you slack off for a day a week? And you think that if that gets you fired you'll move up your career ladder? Would you seriously hire someone who'd done that?
I wouldn't do that. I'd take some of my spare time, a few weekends, to document the idea and maybe hack together a prototype, and take that to "the right people". If they're going to be happy with the project then it's better to do it without pissing off everyone else.
I agree with GP. Can't really answer the hiring question (because I am not interested in being anyone's boss), but why not? Do you think that the way to advance your career is always do what you're being told? GP's suggestion, at least, makes life a lot more interesting.. And people willing to take risks and make their own projects typically will have better CVs.
I would rather see somebody genuinely advance in the organization by genuinely improving something (and taking some risk), while taking time from a stupid project, rather than by taking credit for work of someone else (but that never happens, right?). And in fact it's the latter people who get angry, so for that really doesn't matter on whose time you do it.
As for your suggestion, why is it OK for employer to steal employee's free time and not OK for employee to steal employer's time? We are talking about improvement to the employer's business, after all.
I would rather see somebody genuinely advance in the organization by genuinely improving something (and taking some risk), while taking time from a stupid project, rather than by taking credit for work of someone else (but that never happens, right?).
What you don't seem to realise is that there are no stupid projects. Someone in the business believes that the "stupid project" is a good idea that's worthwhile paying a developer to work on, and they've persuaded the people higher up that this is the case. If you just decide that it's not worth your time and something else is more important then you're effectively telling everyone who has agreed to let the "stupid project" go ahead that they're all wrong and you know best. That is not the best way to further your career.
Open a dialogue. Provide evidence. Don't just say "I know best!" and forge ahead while ignoring everyone else's input. If you're right then people will listen.
I have at times needed to keep projects "secret" because I knew that there would be a 95% chance that the idea would be shot down immediately in any meeting due to being infeasible, politically/personally tricky in some way, difficult to explain, and so on. So I have worked on these ideas sometimes at off hours, or while also making progress on other tasks. Thus far, these skunkworks have been very successful. There is an element to it in many things I do... I often prefer a bit of vagueness around what I am actually doing, since it gives me more freedom to consider solutions that might not be in line with what everybody would expect. Which sometimes makes me wonder if I am being a "cowboy coder" or something. Some of it is due to my skills of persuasion and communication—if I were better at that, maybe I wouldn't need secrecy. But I also just know that some good ideas will not fly in a group meeting before a prototype exists. Then my duty and passion for the product and company override my duty to clear everything with the whole team, I feel. It's not an easy question.
It seems akin to saying there are no stupid moves in chess. Because every move is vetted by the player, and he has a good reason to do it. Unfortunately, people do make mistakes and at least, better moves - than the ones you decided to do - happen.
> you're effectively telling everyone who has agreed to let the "stupid project" go ahead that they're all wrong and you know best
But sometimes you do know best. I didn't say you have to drop work on the stupid project entirely, I just think you should be entitled to be part of the decision too.
Speaking about that, what is the theoretical ideal of how the hierarchical decision-making should look like? I mean, when someone decides things on higher level, how can they do that? If they were to made optimal decision, they need all the information that individual decision makers under them have. So isn't the decision they made always suboptimal? Isn't actually the best way how to make decision in a hierarchy at all to let all the deciders on a lower level decide what decisions have to be made on the upper level?
There should be a mathematical model supporting how hierarchical decision making works, but I have never seen one.
> That is not the best way to further your career
If you do what I suggested, you're taking a risk. It may give you a good result or a bad one, as it happens.
> No one ever succeeds on their own
Even if that is true, which isn't, you can still at least spark a success on your own.
If you can't find 20% of your wasted time in your normal day-to-day work to direct to something more useful, then you are in the 1% most productive office workers.
Or you need to invest in automating some of your grunt work, so you can do the same work in less time. Laziness is a virtue.
> all the while taking longer to do your assigned tasks and looking like you slack off for a day a week?
The difference between a hirable employee and a fireable employee is not 20%. There is usually 2x or more of variation amongst people in a pay grade. As long as you're in that ballpark of productivity, you're fine. Personality conflicts will get you fired long before a 20% dip in stories checked in.
In fact, there's a good chance that taking the 20% of time off will actually increase your productivity the rest of the week. But if it drops you below the "worth their weight in pays stubs" line then you are already on very thin ice.
Wrong focus. Unplanned, but valuable and necessary side projects, that focus on the long term, setting aside for a moment that permanent focus on the short term next milestone next sprint next story next task next function next line of code cyclic trap of short term focus - that product managers (along with literally everyone else, myself included) fall all too easily into.
If my employer doesn't trust me to have some sense of what constitutes valuable and necessary, why the hell did they hire me in the first place? And why do I want to work there? And how soon will I be laid off, fired, or quit of my own accord - leaving for greener pastures where there's higher morale, and less micromanagement? These things will translate directly into better productivity, in turn translating into moving up the career ladder faster?
(I should note: I pick jobs where I consider my "20%" projects to be business relevant. That doesn't mean they're sanctioned.)
> I'd take some of my spare time
1) I can't focus on proper work projects outside of work. I've tried it. Even if I could, reducing my weekends to 1 day a week sounds like a great way to burn out. If somehow I don't burn out, bluring the line between work and play enough for the last day of the weekend I kept for myself to never quite feel like I've left work at work.
2) Prototyping is insufficient.
3) What spare time?
> writing code that will be owned by your employer
That's a feature. Do you have a copyright assignment clause in your contract for all your home projects? Is it legally enforceable in your jurisdiction? Nebulous. Here's the deal: I work on things at work, they get to own it - clearly and unambiguously. Best case scenario? I get recognition, praise, raises, bonuses, promotions, and they ask me to work on it even more. Worst case scenario? I'm off on an adventure, in search of employers that better value my talents. Win/win situation.
> all the while taking longer to do your assigned tasks and looking like you slack off for a day a week?
If it looks like you're slacking off, you're doing 20% time wrong. I have no games open, no social media, no reddit, no HN - my 20% time is sit down and write some code time. You'll hear my keyboard, and you'll see code if you look at my screen. In the lulls, you'll see me thinking hard, unaware of the world around me.
Even if I made it as regular as one specific day a week (I don't - it's hours here and there, fit in and around the normal ebb and flow of my daily work) I'd wager that fluctuation in stats-measured productivity would still get drowned out by the standard deviation of noise in normal work. Some days I commit 10, 20 things with relative ease - other times a single obscure bug wastes 2 weeks of my life to track down - and you're worried about a day a week?
> If they're going to be happy with the project then it's better to do it without pissing off everyone else.
Here's the thing: 20% time (possibly rogue, possibly unsanctioned) is how you pull this off. Which is easier to plan project schedules around: Consistent 80% time spent per week on the project, or sometimes 100% and sometimes 0%? Which sells better:
A) "I want to add an unplanned week to the project schedule so we can replace some terrible tools that we've been limping around with. No, it's not a customer requirement, why do you ask?"
Or:
B) "By the way, I wrote a spiffy new tool that replaces that old terrible one. We can now get those customer requirements that require the tool done faster. You're welcome!" (Unmentioned: You implemented it in about a week, amortized over the previous month or so.)
Rinse and repeat? I could be missing something, but are we saying we should adopt the mentality that we are too good for any job we might find ourselves in? It sounds a bit arrogant to automatically assume that what you've chosen to divert your attention to has merit, and anyone who thinks otherwise is an asshole... I could be misreading, but your tone seems to veer more towards self-centeredness than empowerment.
Hey, you don't know what it's like. Certain people claiming to be engineers have optimized on finding out what you're trying to accomplish and either blocking it or taking credit for it. They also have figured out how to punish people who do work that they are not getting credit for (i.e. authorized). This is their whole 'job' for which they get impressive titles and money for doing little actual work and having little actual knowledge. While you are sitting there coding all day they are off telling some VP about how they have you working on their project that was actually your idea and your sweat. The best policy for an engineer is the one I described.
> Certain people claiming to be engineers have optimized on finding out what you're trying to accomplish and either blocking it or taking credit for it
This is not universal, perhaps you ought to stop working for dysfunctional organizations
> The best policy for an engineer is the one I described
Again, not universally applicable. It might be the best policy for brogrammers.
What makes you so sure you know best? What if everybody within the organisation did this? Why wait until you've pissed people off enough to get fired, rather than leave and find somewhere that can accommodate your great ideas? Shouldn't be too difficult if they are so good. Or even better, start your own business where everyone gets free rein to indulge themselves as they please.
Because I work on huge swaths of the business and know where the huge piles of technical debt and risk are. I also know that people that are not rank and file engineers are hired for their ability to look good not do good. They can make polishing a turd look good by selling it to executives and having everyone else polish turds.
>What if everybody within the organisation did this?
Then you get a high functioning organization that makes billions of dollars.
>Why wait until you've pissed people off enough to get fired
Leaving early is a pattern for top people. They accomplish a lot and job hop before the unpleasantness starts. It can take up to six months for an organization to react negatively to the fact that some engineer actually got credit for something they initiated.
>start your own business where everyone gets free rein
Yeah, this is ideal but you need three or four years cash runway and that is very hard to get. Incubators and angels only give enough that you become dependent on financiers who have their own set of goals.
Agreed. I like the cut of your jib. IMHO denying orders to focus on what you're told rather than what you know is important is not only a hallmark to a good employee, nobody cares that you pissed off some random boss at work when you have something worthwhile on the resume (assuming you have a good reference though).
Working on what's important rather than what you're told to work on assumes that you know what's important and that no one else is working on the important project.
Saying "this project isn't important enough for someone like me" won't just annoy your manager. It'll annoy everyone, because someone else will have to pick up the work you dropped. You'll get the reputation for being awful to work with, and that is toxic to your career.
I think most functioning engineering groups in large companies depend on a degree of it, and it's not even really a big secret, so people aren't actually often fired for it, except at the most dysfunctional places. Large companies tend to accumulate a certain degree of organizational "difficulty", but one thing that keeps everything from going to shit is that there is also usually enough flex in the system that engineers can fairly easily carve out some percentage of their total time to do things that, in their own estimation, actually need to get done, without having to get a bunch of management approvals for it. Management usually looks the other way (if they notice at all), except maybe to occasionally investigate whether anything good came out of these side projects so they can retroactively claim they commissioned it on purpose.
The method seems interesting from the "help people be aware of what's out there and how other people are working" perspective...However, personally, I get lost on one major point in two ways:
- Organized 20% time
First, for me, twenty percent time is that thing I work on when I'm blocked on something, have an inspiration, or just need a distraction from my major project.
Second, I can respect the organizational aspect and helping people understand how to contribute, etc, but really formalizing it in a table / chart and meeting to discuss it?
Maybe I am taking too strict of a view, but 20% time for me is that thing that is fluid and fills in the gaps or gives energy when I need a break from the day to day tasks.
Exactly. I take 20% time to make my 80% time at least 25% more productive, whether that's by tooling, using new approaches or frameworks, or just need a small break.
This isn't bad, per se, and it's good to think about, but I want to throw it out there that the only reason 20% time works decently at Google is because of Google's culture. By virtue of empowering employees to find problems and solve them, and being supportive of career dev & internal transfer, and making boatloads of money, it makes it easy for the org to tolerate the slack this forces in defined teams. Almost none of the kinds of things that encourage 20% projects at Google typically exist in large enterprises, and when those companies try things like this it typically ends up being much more forced and much less organic, for better AND for worse.
I'm glad to read this post. I tried instituting 20% time in my previous job and almost no one took advantage of it. They just didn't have an adequate level of trust in exec mgmt that diverting their attention from core responsibilities wouldn't cause adverse personal reactions down the road. So sad. :(
20% doesn't even work at Google. The reason being, if you care about your career, it ends up being 20% _on top of_ 120% you're already putting in. And I don't know about you, but I'd rather the company did not know about anything I do on my own time and with my own resources, so that they couldn't lay any intellectual property claims to it.
> 20% doesn't even work at Google. The reason being, if you care about your career, it ends up being 20% _on top of_ 120% you're already putting in.
From what I've heard from close friends who work at Google, this depends a lot on the team you're on and the manager you have. If you Google around a bit you'll see a lot of mixed feedback on the idea for this reason.
> And I don't know about you, but I'd rather the company did not know about anything I do on my own time and with my own resources, so that they couldn't lay any intellectual property claims to it.
They don't need to know about anything you do on your own time to lay IP claims on it. In California at least, there are very clear rules [0] that state that an employer can lay claim to IP under a number of conditions, none of which is that the employer knew it was happening at the time.
If it's anything worthwhile, it's likely to come up on your employer's radar at some point. It's better just to be upfront about such things instead of sneaking around. If you can't trust your employer you should probably find a new one.
It's not dead. It's manager dependent, I guess - It's not carte blanche to do whatever you want (was it ever?), so whatever you're doing needs to have, or potentially have, _some_ value to Google, but the bar for that value is pretty low.
It also isn't necessarily just "picking up other team's bugs" (I mean, you can if you want) - just last week my teammate finished up a 20% project to make a new UIView templating/auto-layout system for iOS, for the first example I can think of. This sort of thing is pretty common.
I've had a number of different managers at Google and I've never had one that ever tried to tell me not to do anything, and even when they wanted me to do something their direction wasn't particularly strong. As far as my experience goes you can do anything you want at Google as long as it appears to have some value.
Not a googler, but I'm related to one, and I'm told that it's dependent on your ability to set boundaries for yourself. Nobody should dock you for saying "hey, I'm working on my 20% time now". If 20% time is dying, it may be partly that there are some bad managers who will dock you for it, and it may also be partly that programmers would like it but don't feel empowered to use it (for political/personal/personality reasons).
Having worked at both Google and Facebook I prefer Facebook's strategy of "hackathons" and "hackamonths" to encourage people to sometimes work on different projects than they usually do, to mix it up. Hackathons (1-3 days at FB) are cool because they really encourage you to work with a new set of people. Hackamonths are usually tied to, "this project is with a different team and if it's going well I would join this other team". I think that is cool because they make it explicit that maybe your side projecty thing is going to turn into your real project. The setup is aimed at a similar thing to 20% time and I think it is overall more effective.
There are IT departments inside of non-IT companies that would love to have this sort of luxury. But with department heads that would have their heads explode if you try to explain this to them.
Also, slightly off topic, but for similar reasons I can't figure out why bosses want IT workers that mostly sit at their desk on a computer to work at the office (instead of remote locations) for a full 40+ a week. It's like there is distrusting management who thinks if they didn't walk the hallways once per week at random and see people staring at their computers then the same work wouldn't happen. Let these people work alot more wherever they want if their work isn't location dependent.
I saw a fascinating comment a few weeks ago that, why does a company think it's fine for you to "work from home" when you're on call all the time to fix their problems; but not the rest of the time when you're fixing their problems?!
I love this BASEDEF acronym. I have an IRC bot that I've been working on for 3 years on Github. I've also tossed it on up-for-grabs.net. About 7 people have submitted contributions, I think because of up-for-grabs.
I think that acronym perfectly describes what a successful open-source project needs to thrive.
I have 80% time, i.e. I only spend about 20% of my time on my clients.
To hell with this wage employment bullshit. Keep your productivity and the fruits thereof for yourself. Don't give them away for a pittance to an employer, who probably also made you sign an agreement that they get to take anything you make, whether you made it on their time or not.
As an IT manager; the biggest problem with 20% time I've seen is people using for 80% time stuff. Like, critical training they should have gotten as part of normal work, etc.
There are many, slightly different ways to describe innovation.
I have found that 20% of the time project is about personal motivation to show on something different (than my usual tasks) that I can do it or make it better. Managers only need to enable it, and shall not force it. If the individual is not motivated to show that it can do better, let it be, because they may be just fine with their normal work.
Groups working on things together for a week (~yearly 20% time) is more about exploring the team's creativity, exploring business or product ideas. It can be called internal pitch or demo days.
Some ideas need time to get some exploring, some trial and error, some fiddling, some long discussions, and may not be doable in a week (wall clock time). Due to their different nature, they will result in different products.
I have written a couple of other points that are related about product development (e.g. moonshot, 10X, competitions), you may find them useful:
Re: article. I think the author is using the 20% projects as a team building exercise. It could be working for that purpose, and maybe for some incremental changes, but will not explore innovative ideas.
Creative processes actually CAN be well-organized and fun at the same time. Just look at hackathons, which teams get stuck halfway and which teams are productive and take the prize home?
If you only care about code and learning new APIs, that's your right. (I'd say do it at home.) If you want to ship something real with 20% company time? Get your project organized.
Either they want me to solve their problems and plan this with me to do it like normal work, which IT IS or they want me to do my own thing and don't bother me if they can't use this......
Sounds like all this crap loke pingpong, Snacks and billiard tables to me :D
It's 20% of the time you're paid to work on things that aren't necessarily part of your core responsibilities but still have a plausible positive impact to the company, even if it's just goodwill and team building.
I had loads of things I wanted to work on at my last job (only been at the new one a little bit, so not so much yet :p) that just would never be a priority or were too far from my teams normal stuff.
Unfortunately we didn't have 20% time. It's one of those perks that actually sounds great to me (free food, meh).
Jobs don't give workers 28% time to do what they need. Workers exchange 72% of their time to jobs for income, and retain that 28% to do as they wish. It's worth noting there's a difference. Said your way, it's as if workers ought to be grateful to their jobs for allowing weekends. And that is fucked.
Either way, it's still fucked that working and living isn't an even 50% split. It should be.
Hours of commuting and working per week: (2 + 8) * 5 = 50.
Hours of living on weekdays per week, exclude sleep: 6 * 5 = 30.
Hours of living on weekends per week, exclude sleep: 32.
Total hours living per week: 62
Total hours working per week: 50
You're right, it's not an even 50% split.
There's 6 hours of free time a day, plus 32 hours on the weekend.
Three nights a week I watch a movie or a couple of episodes on netflix (90 minutes), I play an hour or two of games (90 minutes), I write code for another hour or two (90 minutes), and the rest of the time is spent eating dinner.
Two nights a week, I forgo gaming and netflix to hangout with family and friends. I still manage to code. It may be on the train, but I do it.
And there's the weekend.
You know what? I have a good life, and fucked or not, I am grateful for it.
If a company is paying you for your time, what do you expect to be doing, if not to do what the company wants you to do?
If you want to not do what others want you to do, and still receive a regular pay check, that's called taking on welfare.
Now you've moved the goalposts from your original 28% figure (2 days out of 7) to trying to defend a stupidly made point by drilling into a hourly breakdown. You can't have it both ways.
An even 50/50 split would be working no more days than you live--taking the day itself as the unit of measure. By the week, that means recognizing there's something inherently off with the notion that it's at all balanced to exchange 5 days to an employer so you can get 2 days to yourself in return.
If you want to make yourself feel better by counting how many hours you can squeeze out of a day for yourself, that's fine. I doubt I'm the only person who thinks that is no way to live.
In contrast to your example that, to me, seems insanely driven by the tyranny of the clock, a different take:
There are 365 days per year. When I decided years ago I wanted to achieve work-life balance, that left 182 days for working. By the typical American work week, if I was working a job, I'd be expected to surrender 251 days (for 2016). That's 70 days too many.
So, there are 183 days of free time per year.
Some of those days, I binge-watch Netflix. I don't even know how much time that totals.
Some days, I play games all night until the sun comes up.
Some days, I dabble with some code related to something I want to play around with, experiment, learn, rebuild, whatever.
Some days, I see the computer and say, "Fuck you, computer. It's gorgeous outside."
I wake up whenever by body wakes up. I shower. Grab some food or a meal shake. Head to the gym for a couple hours. Maybe take a nap, read, or just sit and breathe.
Some days I'm just sick of being at home, so I leave. I'm not counting any hours here, so I call up some friends out of town and say I'm coming their way for a couple days. I head out of state. I leave the country. I think of who I haven't seen in a while and get together with them.
> If a company is paying you for your time, what do you expect to be doing, if not to do what the company wants you to do? If you want to not do what others want you to do, and still receive a regular pay check, that's called taking on welfare.
That's an oddly binary and ideologically ridiculous notion you have there. As if there are no other ways to exist and subsist besides welfare and doing what others want you to do to receive a paycheck. I mean, come on. This is HN. This place exists for people who don't want to do what others want them to do in exchange for a paycheck.
P.S. I never said you shouldn't be grateful for having a good life. I think it's great when people recognize how good they have things, and are genuinely grateful for it. I was picking on a very subtle but important nuance in your original statement that I felt important to highlight. It's fine if you don't get the nuance, or don't care for it. For me, I like to remember where the agency and empowerment lies in my life. I'd never be able to stand a situation in which I actually had to think that an employer gave me a couple days of my life on the weekends before coming back to work.
I agree with you, 183 days definitely is a more relaxed way to live. My point was if people wanted to work on their company's stuff 4 days a week and improve their technical knowledge 1 day a week, they ought to negotiate a 4 day work week rather than demand they be paid for the time they're doing their own things. I understand you don't like the sound of 'employer gave you. But what I said was jobs give you two days off. If you can find one that gives you 183 days off then, great!
Main point aside, I think it's important to realise our entire lives are given to us by the circumstances and fate of the universe itself. My job is one part of the universe.
Like have a life, do your laundry, tidy up your place, that sort of thing? What does it have to do with work supporting 20% of your time for coding something of interest to you or learning a new language/framework?
I do all of those things and code something of interest to me and my company has no 20% time. I understand, you'd like more time to do those things, but time when we get to do whatever we want is called a day off.
Look, if you want to study web frameworks, tell your employer you want to work 4 days a week and spend a day studying for yourself.
How's the conversation going to go?
"Can I spend every Friday learning this new web framework? No, we don't use it, but I think you should be supporting me increasing my skill set. Yes I still expect to be paid."
Getting some tomatoes thrown your way, but I think your sentiment has merit. In what other industry is it really a thing to feel deprived if you don't get to spend 20% of your working hours exercising your creativity? I think it's worth recognizing that defending the sanctity of your personal creative time is a pretty nice problem to have. For many, it's not even up for discussion.
I read this less as the company trying to control your 20% time, and more as the company making your 20% a first-class citizen among its other projects, by using the same resources and processes.
20% time is important because not everyone has a ton of free time to improve their skills and do whatever they want to.
People with families, hobbies (that aren't programming), classes to take, or even extra-long commutes are not overflowing with time to devote to side projects.
I already do that, and My boss is aware. When it is necessary to fix things quickly or do scouting or in general problem solving your time invested returns, but you are faster.
I've seen this tried in a few ways that didn't really work out and one that worked well: (edit - this is always highly dependent on the people and small differences, this is only my experience of 10/20% time that I've actually participated in and the issues that appeared at my workplace)
# One day a week:
Cons: people are off more on fridays, feel like they're missing out. Some things need more than one day, other priorities pop up a lot on fridays. Hard to force people to suddenly switch for one day.
Pros: Simple, everyone gets time together. Easier to actually 'enforce' and not see it just disappear.
# One week/similar per longer time period:
Cons: Lots of time to stop everyone working, doesn't line up with all schedules, etc.
Pros: Longer to do things, everyone available together. Same pros as one day per week.
# Organise it yourself, completely freestyle
Cons: People don't actually do it most of the time, seems like they're taking time away from their main project.
Pros: Timing issues pretty much disappear, but things can always be put off. Easy for it to just be forgotten.
-----
The way I've seen it work well had these properties:
No fixed time or schedule, you booked off time to work on what you wanted.
Your manager can't indefinitely say "no", but if you're trying to book off the day of a release when you're planning a big release then they'd ask you to wait a bit.
To get it you have to say what it was you wanted to do, but this only needed to be a brief sentence on a wiki somewhere (could be "play around with X" or "try and make a Y"). You also needed to say if there was anything you required, and they'd help you sort this out.
The time is considered like holiday. You don't pull in workers from holiday to help out, you can't pull them away from the time they'd requested for the project.
You were encouraged to go and work in a different building/office if you wanted so you're not surrounded by people asking "quick questions".
You were required to put any code in a particular place.
You needed to briefly say how it went.
You had to be reasonably willing to say what you did in the next all-hands.
This was all fairly lightweight, booking time off wasn't a difficult thing and getting approval was just a quick chat about what you were planning. You could grab a few days or an afternoon, and they'd help out if you needed other equipment/etc.
Overall I think what will work varies massively on your workers and current workplace, it's vital to try a few different things and tweak as you go.
I have 100% of the time. I work for myself. What this has resulted in, is that everything I work on, either manifests into something that has a direct consequence on the bottom line. Or I have something that is in progress and I get back to it when I have some inspiration. Or it is something that I can't yet crack and goes into a folder until I pick it up again way down the line.
I know if I recruited for my company. I would have this 20% philosophy.
Not 20%, but I got the manager to give us 2 hours every Friday. I guess that would be 5% time. I was doing C# enterprise work at the time, so I would use those 2 hours on totally different stuff; like brushing up on C++, or dicking around with Perl.
Are you joking? 2h is the time I need to just switch language/framework contexts to write anything morecomplicated than helloworld, never mind understand some code I've written a week ago.
Not formally. However, if I was getting my job done and was productive, I don't think anyone would complain about 20% time. Although my employer is quite flexible and I have unlimited vacation as well, though that is a privilege and not a right, of course.
Just keeping it 100: if you come up with a really good idea, (orthogonal to the companies business) that can make a lot of money in 20% time and give it back to your company rather than starting your own shit with it, you're stupid. Or just have low testosterone.
A lot of ideas fit somewhere between viable startups and obvious new features. If you think in terms of the next 20 years being able to put, developed X could easily be worth a few million. Even if X can't really be done as a startup.
IMO, the biggest benefit from a companies standpoint is people can try out new things without cluttering up the main product. Boring but works is often best for a company and terrible on peoples resumes.
I'm not doing 20% time to trend shit for YOU on GitHub so that YOU can feel like you're doing something as a manager; intruding on and micromanaging "free time" until it's anything but "free".
I'm doing it to answer a burning question I have about something and do some exploration whether YOU think it's useful or not.
And before you whinge and bitch that I'm there to serve the company, a) if that's what you want then don't fucking act like its free time because it's not, and b) irrelevant disconnected ideas and the curiosity to pursue them are not only the indicators of your smartest and best employees they're also a precondition to keeping them happy and keeping them at all.
This time benefits me. There have been plenty of HN articles that breakthroughs come from tying together these previously thought irrelevant ideas. And in my experience researching some side project always comes to provide needed knowledge somewhere else eventually, always.
Just not perhaps in the short 30 second timespan and timescale of an idiot clueless irritating manager.