tags:

views:

1617

answers:

24

As an interesting motivation technique (usually called Innovation Time Off), all Google engineers are encouraged to spend 20% of their work time (one day per week) on projects that interest them.

Does your company offer something similar? Is it a good idea? Should you encourage developers to work on other projects?

The company that I work for do allow me to work on personal projects in "work time" (I just finished RoboHum) and I find it extremely useful to sometimes just relax and work on something I enjoy or find interesting.

Is it good or bad?

[UPDATE] Read more here

+1  A: 

We dont have something as formal as Google, but anyone can spend his time on things that are of interest. If they are useful to the company in someway its reflected in better grades in Apps. If not they are not peanilized.

Dheer
+4  A: 

Depends on what happens to your results. There has to be some kind of Laffer Curve that describes the relationship between productivity and employee freedom.

Will
Probably more like the neo-Laffer Curve.
Even Mien
Well, if you grouped together disparate employee populations/cultures you'd get that kind of lumpy curve. If you concentrated on a single "population" it would, of course, be more appropriate.
Will
The proposal isn't "pay people to do whatever they want", it's "pay people to do things that are relevant to your business." I don't think Google's 20% time is for going to the gym, making your own porn, or refinishing your hardwood floors. Unless you have some hi-tech ideas about how to do those.
Jay Bazuzi
Nobody said it was. But you can waste just as much time doing things related to work as you can doing things not related to work.
Will
+3  A: 

I'd suggest that it is a good idea. A full day a week on personal projects is fairly significant in terms of what you could get done, and allowing it (and paying for your time on it) means google doesn't have to deal with programmers staying up till 1a.m. working on personal projects and being unproductive the next day/week due to lack of sleep.

My company doesn't do this currently, but I could see it as a useful incentive to get developers to be productive and to branch out their skill set :)

workmad3
+4  A: 

The company I'm working for doesn't offer anything like that, but I would say it's a good idea... always given that the engineers work on something similar to their 'normal' work, e.g. no dumb browsing. Perhaps you could combine it with presenting the results on regular basis; everyone gets feedback on their work and new ideas from other people as well as it's guaranteed that the engineers are working on something useful.

So if I'm a boss sometimes in the future I will think about offering something similar :)

swalkner
+21  A: 

We've tried out Google-days. It's an excellent way to foster innovation, and it can help motivate and keep the best staff long term.

The downside is that most management really don't get it. For their point of view it looks like a waste of 1 day a week per developer. Why should developers get this additional time when no-one else does? I can see their point.

Google is all about innovation - they're constantly looking for the next great idea. It's ideally suited to them. For the same reasons I can see it really fitting with organisations like 3M too.

For a more 'static' organistion it becomes very hard to justify. It really depends on the company.


Update:

Note that this idea didn't originate at Google - I think 3M did it first, but they called it 15% time. Basically the same idea though.

I think it was during his 15% time that Art Fry came up with Post-It Notes. By allowing this extra time for innovation 3M came up with iconic products that they are known for.

Even at 3M this 15% time is sometimes regarded as waste - see this article on it.

Keith
Management frequently get like this with developers :( It can be very difficult to grasp that a bit of freedom like this can make developers more productive on their actual work because they aren't thinking about problems with personal projects, etc.
workmad3
"...when no-one else does?"OT, but maybe they should (ie: get 20% also). Having one set of people developing processes for another set whose jobs they do not have day-to-day experience with is the norm. Maybe better to give staff time each week to work on the big picture.
username
That's a valid point, but it's a much tougher argument. Anyone working in a research role has the clear creative/innovation argument. You could argue it for strategic roles too, but for admin, support, maintenance staff?
Keith
We convinced the management, but with one caveat. The project has to do something with our existing products in one or another (indirect) way...
Tom Deleu
+2  A: 

At my place, our developers tend to be busy working on a set of tasks pretty much full time. We are encouraged to learn and apply things to those tasks but, no, we don't have anything like a 20% time working on something we'd want to do. I've never been in an environment that had so much cash rolling in from advertising that the company could essentially bankroll 20% of the work on personal projects, though I think that would be cool.

I'd love to have one day a week to work on my personal stuff because, honestly, 168 hours a week isn't a lot of time and I don't have hours and hours of my off time to devote to personal projects - I'd like to but I don't.

As long as a company can work out the scheduling and make sure that 'real' tasking doesn't suffer because of 'personal' projects, I think it is a great way to keep devs happy, encourage innovation and potentially open new avenues for revenue, which companies always like.

itsmatt
+1  A: 

I think it's an excellent idea, if you have the right people. It's a good way to keep the staff motivated, and gives them something to look forward to from a techie point of view when they're knee deep in A N Other line of business app. Even if you only get a shaky prototype out of it, you can still potentially use that to generate more ideas or wet the appetite of a potential customer.

If you're staff are leaning towards the "I won't do it unless you train me" mentality then unfortunately it's a bit of a non-starter.

Steven Robbins
+1  A: 

Thoughts... is "envy" a thought?

We don't have anything like that and don't seem to be doing anything similar soon, as I work in the software development department of a bank. It is not hard to guess that the top brass (most of whom have risen through the ranks of internal auditing) here don't have a clue about the boost of productivity such practices can provide. At banks, you collect a lot of data about your customers and given enough free time, innovative products that benefit both the customers and the bank can be conceptualized and built, just by analyzing the already-collected data carefully. However, there is always so little time :)

egiboy
+1  A: 

I suppose that is their answer to resisting regression to the mean.

dacracot
+1  A: 

My company does not offer a similar program; however, I believe it is a GREAT idea. In addition, 3M pioneered the practice decades before Google was even a glimmer in someone's eye. I think 3M's bottom line and history of innovative products answers if it's good or bad.

Dan
+1  A: 

My boss is ok with the concept. He limits it to half a day tho.

But it seems like we never get to actualy have "developer days" since most of the time there is something mission critical going out, or we are behind on something else.

J.J.
+2  A: 

Almost every company has some time it gives developers for their personal projects (sometimes even more than 20%). It's just that they call it 'downtime'. :)

alex
Unfortunately in my experience such 'downtime' only comes around when you're already creatively drained and physically shut down from the 'crunches' before the downtime. :P I.e. you can't be innovative when you've been hitting the wall with your head repeatedly. :)
Spoike
Unfortunately in *my* experience such 'downtime' only comes around because despite whatever indication you give to your managers you don't have anything 'real' to be getting on with, which sadly means you're in a demotivated unresponsive state you'll still have to self-justify on your timesheet.
annakata
+13  A: 

In the eighties there was a book, "In Search of Excellence", 1982/2006, showing what made companies succesfull. In the chapter about 3M it had an awesome example of the 20% at work: an engineer invented PostIts in his 20%. He was allowed to use all resources of the company.

This shows that great "old economy" companies were quite innovative even before the .com, "new economy" bubble, and that some old principles of excellence are by no means outdated.

Ralph Rickenbach
+1  A: 

I guess those are the perks of working for someone like google or 3M , but in most cases you will have a hard time trying to convince management with such a concept. but then again...most managers just want to get through the day and the only people who would be interested in such might be the company owners,founders...etc (those who the future is their consent)....not the day to day consent.....I still love the idea though

Ronald Conco
+1  A: 

Brief answer: Were I running a software development team, I'd be inclined to allow it, possibly even to a level beyond the 1 day per week for some staff, but not to generally offer it to all staff.

Long drawn out answer with some background: When first employed as a developer, my company offered "training days" - one day per month which you could dedicate to learning anything you wanted. A number of the staff used this time to build tools, etc, many of which proved extremely valuable, became adopted, with further work on them scheduled into real development time.

Outside of these training days, you were expected to perform scheduled development work, support work, bonus targets, etc, were built around this scheduled work, it's timeliness, quality, etc.

Despite this, numerous "personal projects" were certainly worked upon by the development team outside of these training days (I had more than one over the years), and certainly, whilst not advertised, some time was built into the schedule to allow for this.

In my experience the "20% coders" (those responsible for the bulk of your teams valuable output) are the team members who "find the time" to work on these personal projects, which often (but certainly not always, at least one could be sportingly considered "team building") turning out useful tools for the team or the business.

Were we to have offered the Googlesque 1 day a week personal project option, I suspect it would have been embraced by the "20%" bunch more than the "80%" bunch, and for many it may have well have just been tagged "lazy time" and not delivered the value we'd hope.

All in all, when you're employing both programmer types (unlike Google, who obsess about these 20%ers) it seems sensible to allow it, but not to promote it.

Gavin Carey
I think, if you only offered this Innovation time off to a subset of your group this would cause a great deal of resentment and actually damage the moral and productivity of the group.
mrwiki
+1  A: 

I'm pretty sure that if you work on anything during working hours(and get paid for it) the rights of the things you produce belong to the company, not you. So it is a win-win situation for them anyway. They are not doing this out of charity. I can see banks and other non software selling companies to be less open to this because they have less to gain.

In the end it's all about making money not about you having a good time. If they stop making money then the good times will stop too.

chrissie1
Contracts in Switzerland for example have paragraphs that take care of exactly that: "All rights for papers, concepts, and programs as results of work belong to the employer..."
Ralph Rickenbach
malach: Contracts everywhere usually have that clause/paragraph. It's almost de facto that the company you work for owns the right to whatever you produce.
Spoike
But those contracts are based on the premise that your working week is entirely your employer's. If you're changing the ground rules, you would expect contracts to change too.
Unsliced
+2  A: 

I find that in the places I've worked this sort of thing is not contemplated, acknowledged, or, if pushed on the subject, permitted. However, I do find that over time little brain breaks every few weeks can be very helpful. In previous employments I've taken some downtime (assuming no looming deadlines) in a morning or afternoon where I was too burned out to focus on actual work. I let my mind wander in new realms of development or system administration, read some articles, played with some software, and, in the end, was smarter as a result.

It also allowed me 'downtime' to be re-energized for my actual task list. And a couple hours every few weeks never seemed to be an issue. I never used that time to develop any personal projects (probably why they're all still in the concept stage). I use it to become enlightened on frameworks, language features, etc. that I can then consider when confronted with a new problem. While I don't walk away a content expert on the matter I do better understand the breadth of what's out there and can be more informed in my decisions and recommendations.

Milner
+1  A: 

You can only really see something like this in product companies that have established product lines generating revenue on solid margins. Your typical run of the mill IT shop could never make this work... as they are typically staying afloat charging consulting hours while pushing to get their first product out the door.

Google is a bit of an IT aberration because they make 99% of their money on a mature product, adsense. And their numerous betas are as much advertising as actual attempts to grow new product lines.

+1  A: 

The OFFICIAL google page

We offer our engineers “20-percent time” so that they’re free to work on what they’re really passionate about. Google Suggest, AdSense for Content and Orkut are among the many products of this perk.

http://www.google.com/support/jobs/bin/static.py?page=about.html&about=eng

Other Links

rudigrobler
+1  A: 

Stackoverflow Podcast #25 with Steve Yegge (from google) touches on the google 20% time... very cool podcast!!!

rudigrobler
+1  A: 

The question that I've been asked when discussing this with senior management generally resolve around two points: ownership and direction of the IP and when the "20%" can actually be taken.

Firstly, any resulting intellectual property might, according to most contracts and terms of employment, actually end up being owned by the employer. This will have an impact on FLOSS development as well as anything that I might want to develop for a third-party non-competing entity. What direction does the employer have - or is a completely green field site. If what I do has no relevance to the company's core competencies yet I'm consuming company resources on it, that's different from just being given your independent head and told to run with some slightly wacky ideas.

Secondly, my current role is mainly development, but significant portions of many says is maintenance - so if my "20%" day is Friday then what about the support I might give? We don't stand over our developers' shoulders and count their hours so monitoring this project would need an infrastructural shift away from the current methods of working. What if my 20% clashed with my colleague's? It will always have to be a low-priority project ... and my low-priority work never gets done, there's too much important stuff!

I think it's a great sounding idea that just has too much baggage in practice.

Unsliced
+1  A: 

As soon as we will reach critical mass, I intend to make sure that the people here have some free time to work on whatever they fancy. I don't know yet if 20% is the right amount of time.

Advantages I see :

  • Very often you have tasks that are never done because "there is no time". It is my experience that these "never done tasks" often evolve in costly problems
  • It is very good for motivation and help relax when the team works hard all week
  • 20% is not very expensive, especially because I think it will increase the productivity on the other 80%.

Disadvantages :

  • If you rely on external investors, this may be hard to sell
Edouard A.
+1  A: 

Check out this Google Tech Talk: 80:20 rules! - Building software smarter http://www.youtube.com/watch?v=zXRxsRgLRZ4

Tilek
+2  A: 

let me be devils advocate here: Most often, it doesn't pay.

First, you need a diverse company that can turn innovation into money: you need suits that recognize that recognize the value of an idea, and tell apart the good ones from the bad ones, and they need to make it or find someone to make it. Many companies wouldn't be able to turn postit stickers to money - patenting it and blocking the market woukld be their highest acievement.

You also need competent staff management, to hire the good guys, and get rid of those that turn out crap... err, unsuitable for the company. Realistically, most developers will use the day to slack off and have some fun. (Somethimes, that's enough, but see next point).

You also need a decent population of developers:
You can approach it from a techies POV - 90% of everything is crap, or from a venture capitalists view: You can lose no more than 100% of your investment, but you can win 1000%.

Even when everything is right, most projects will be of low commercial value, not worth to exploit further. You are waiting for the one hit wonder, that gives you 10x, 20x the return.

In a shop with only 3 developers, that's quite a risky bet. It might take you years to stumble over something worthwile. Can you survive so long with cost that is 25% higher than your competitions? That's "total cost of developer ownership", not just pay. On top of the competetive pay and the posh offices.


Yes, there are effects that can't be easily measured. it helps retaining the primadonnas - but herding them is hard, and a fun, creative environment will motivate developers who'd otherwise dig themselves in in a secure position. But with all that extra cost, aren't there other, better ways to achieve that?

I agree, none that sound so deceptively simple.
But then, throwing kopecks at chickens is simple, too.

peterchen