This article is cross-posted from Blogs From The Geeks, the 7digital development team blog:
Assuming you had consent from up above*, you’d think it’d be a breeze to get an initiative like innovation time off the ground. Surprisingly at 7digital it took us three attempts before we got something to stick and speaking to someone else recently I found they’d had a similar experience. As we’ve had our “innovation time” initiative running successfully for over a year now I think it’s worth sharing how we’ve got it to work.
In our first two attempts we found the main reason it failed was putting too many barriers in the way. We didn’t think it was right that you could work on production code, you shouldn’t do it on your own, it should be justified and approved by your peers, like a business case. Innovation really hates these kind of things. Ironically we thought having “sensible” rules like this would ensure people didn’t waste their time on things we didn’t think could be classed as innovation, but they were based on a fundamental misunderstanding of how innovation occurs.
If you’re even slightly aware of your history regarding invention and discovery you’ll see a large proportion came about by happy accident, mostly when trying to prove something completely different. It’s such a common event it has its own name – serendipity. I strongly believe you’ve got to have a really open mind and shouldn’t have any particular expectations or goals in mind apart from innovation itself.
So for our third attempt we tried to really strip it down. Here’s the rules we agreed:
Conditions of use of innovation time
- There is no jurisdiction on how you use the time.
- If you’re working on production code, or any application or tool which supports production code, you must do it properly i.e. follow the development team standards.
- If you’re working on something unrelated to production code or existing applications you may work in any way you like. However if you wish for whatever you produce to be used in anger it must meet the usual standards (i.e. either write it to expected standards to begin with or rewrite it afterwards).
- We should put anything suitable in the public sphere e.g. on GitHub and hosted where appropriate.
Allowance
- You have 2 days a month you are able to request for innovation time.
- Innovation time does not accrue – if you don’t take your allocation in a particular month it does not carry over.
- If someone else does not use their allocation you cannot use it in their place.
Requesting innovation time
- Request time through whosoff.com as “DevTeam Innovation Time” (we set up a special leave type).
- It’s to the discretion of your lead developer (or head of development) to approve. (e.g. they may not approve if they consider that the ability for the team to function effectively will be compromised due to too many people being off or we’re really busy with something and need all hands on the pumps).
Accountability
- You must create a wiki page with the details of what you did and what you learnt.
- For each day you take against a particular activity you should have a diary-like entry with the date and who was involved.
Using our leave booking system was a particularly inspired move. It means innovation can be managed just like holiday – it shows up in everyone’s calendars and allows everyone to plan around your absence. It also means we can pull out stats on how much time people have been taking:
Interestingly out of a possible ~456 days in 2011 189 were used, making it “4.74% time”. Another particularly surprising observation was people took less innovation time when they were not feeling motivated about their usual work (we had a very painful database migration in the summer).
It really helps that we’re very team focused at 7digital (pair programming is really good for this) so it’s no great loss when any one person is away for a short time. It also really helps that we try very hard to work at a sustainable pace.
As for what’s been done we’ve had some really interesting and diverse projects. Many of them have simply been around investigating new technologies and ways of doing things rather than new product ideas (but we’ve had some of those too). I think in this respect a lot of the benefits are intangible, but that’s one of the interesting things about innovation – if you tried to measure it you’d kill it stone dead.
*I’ve no intention of going into the justification for initiatives like innovation time here. That would be another, very long article 🙂