Innovation time

I'm keen to implement a Google-esk innovation time for my current team.

After a fair amount of research, I've found very little in the way on defined rules - so I thought I'd post my experiences.

So why?

Short answer - one of the team asked if we could. Longer answer - I'm always interested in allowing my team to perform to the best of their abilities. My initial thoughts where a little cautious (and still are - for good reason) but following some research I felt it was possible, and desirable, to take it further. Ok, a quick step backwards ... what am I talking about. Google have long publicised that a great many of their innovations have occurred during their 20% time. This 20% is time allowed for their employees to do whatever they want - without the need for management approval. The principle is that you have a highly paid, highly capable member of staff - surely left to their own devices they will do wonderful things. Scary??? As I say Google attribute many of their products to this time. Time where an engineer will have found an "itch to scratch" and go on with it without having to get it put through all the bureaucratically rubber stamping. Having looked into it more, it is clear that Google isn't the only - or the first. Both 3M and HP have quite a history with this. Apparently this is the genesis of the PostIt note. Even further than this Valve (games producer) operate a 100% policy (see their handbook here). There are certainly a fair amount of positive and negative comments about the various schemes (see some of the links at the bottom). My personal favourite is this animation.

## Rules? While going through the above, I struggled to find implementable rules. Part of this I suspect is that rules need to be fitted to the organisation and the team(s) involved. So for now, I've started with the following rules: Rule 1: 3 month trial of 10% (1 day in 10)

I think it is only fair to try and give the experiment enough time to run. But in the same respect I wanted to time box it so that we had a definite decision to go/ no-go/ extend it. The 10% was a basic case of looking at "real work". I believe we can fit 1 day in 10 - any more than that would be difficult to justify to myself. Obviously this can be reviewed at the end of the trial. Rule 2: Whole department to have our innovation day on the same day (Friday, at the end of our 2 week sprint cycle). This was a rule inspired by efforts by Atlassian (see links below). They originally implemented a 20% time based on a similar manner to holiday booking. A year later they found that due to business pressures that had difficulty getting the time approved - and resulted in something close to 1% to 2%. The benefit of setting a day is that everyone can plan round it. It also makes it easier to cooperate between team members. We have a well established sprint cycle of two weeks (starts from a Wednesday). The last Friday lends itself well to book as our innovation day. Rule 3: We still need to support the businessThe whole IT department is encouraged to take part in this innovation time, but we do need to remember why we are employed. If we have a system problem then it needs to still be dealt with. Luckily (or rather through good hard work) we get few urgent problems so I hope this won't be too much of a distraction. Rule 4: Has to be on siteThis is really in support of rule 8. The larger business needs to be able to see some justification to it. Being visible helps (although isn't the whole story). The lack of visibility however will be like garlic to a vampire. Rule 5: Has to be "some" way work relatedThis one I'm keen to be rather "flexible" on. From my reading, I think the more business justification you put on the individual, the more restrained their innovation becomes. On the other hand I don't want them to be doing something with zero business benefit. It is a difficult line to walk this - possibly one of the most difficult. I think this is one to report on as time goes on. Rule 6: Report back on what they've done with the timeSimple enough. I hope that I get lots of wonderful things to report back to the business - but as the very least I want to be able to explain what they have been doing. This helps to adjust for the next innovation day if the effort was too far away from rule 5. Rule 7: It is up to the team to justify the trail - not me.I'm happy enough to set up the trial and give it the room to run. I'm never however going to be able to convince the business that the trail should continue (or become a permanent fixture) if perception within the larger business is that it is a massive skive. The responsibility is, as it should be, on the team to make the trial shine.

Links

The following make good reading: * http://www.codinghorror.com/blog/2012/08/today-is-goof-off-at-work-day.html - article on the history of Google time and some advice on how best to make work * http://blogs.atlassian.com/2008/03/20timeexperiment/ - launch blog of Atlassians experiment to implement 20% time – probably more interesting is the summary at the end of the first year -> http://blogs.atlassian.com/2009/02/atlassians20timeayearinreview/. They are now focusing on the ShipIt day – a 24 hour period to make something shippable and their Innovation Week -> http://blogs.atlassian.com/2012/09/innovation-week-20-time-in-a-box/ * http://blogs.msdn.com/b/jwontech/archive/2012/05/25/google-20-time-vs-the-microsoft-garage.aspx- Culture comparison between Google & Microsoft – Google’s 20% vs Microsoft’s Garage.

## Next steps I announced the rules to the team just over a week ago, naming our first innovation day as this Friday - this has given then a fortnight to have a think about what they use the time for. As part of tomorrows team meeting I shall be having a quick round table to establish what each team member is planning for this Friday. Firstly this allows my to check what is being planned and "adjust" if required, secondly to pollinate ideas between them. It is certainly possible that the plans they leave the meeting with may not be the plan the came in with. For me, my difficulty will be giving others my ideas. Not because they are secret - but so much of this is about them having the confidence and space to have their own ideas. Wish me luck.

About the author:

Mark Taylor is an experience IT Consultant passionate about helping his clients get better ROI from their Software Development.

He has over 20 years Software Development experience - over 15 of those leading teams. He has experience in a wide variety of technologies and holds certification in Microsoft Development and Scrum.

He operates through Red Folder Consultancy Ltd.