Live data from Hacker News

Making 20% Time Work

begriffs.com

91–100 of 142 posts

Re: Making 20% Time Work

#91
post #59

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 y…

Id be happy to hire anyone who got fired under these circumstances

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.

Re: Making 20% Time Work

#92
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.

That sucks, that's not 20% culture.

Re: Making 20% Time Work

#93

Earlier quoted context omitted.

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 wor…

>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…

> 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".

Re: Making 20% Time Work

#94
post #35

Googler please chime in, but as far as I read it's been dead for years. http://qz.com/115831/googles-20-time-which-brought-you-gmail...

It was dead and gone when I worked there, as in manager explicitly told me not to take it seriously, and that was 2012.

Re: Making 20% Time Work

#95
post #60

Earlier quoted context omitted.

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 net…

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…

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.

Re: Making 20% Time Work

#96
post #34

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. sigh

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…

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?!

Re: Making 20% Time Work

#97

Earlier quoted context omitted.

>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…

> 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 insti…

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?

Re: Making 20% Time Work

#98
post #78

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 y…

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 u…

> unsanctioned side projects

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.)

Re: Making 20% Time Work

#99
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.

Re: Making 20% Time Work

#100
post #86
post #78

Earlier quoted context omitted.

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 u…

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 o…

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.

No one ever succeeds on their own.

Post reply on HN