Saturday, 28 July 2012

Give your people time to innovate

Developers who are too busy to experiment are wasted talent. Software developers are smart people who need to be creative to be good at their jobs. In all but the most lax environments, team members will have their work set out for them. Even in Agile environments, there might be flexibility in who does what work and developers will be involved in the work estimation process. Ultimately, it is management and customers who decide what work is done.

Google has made the concept of 20% time famous. However, 3M have been encouraging their employees to experiment for 15% of their time since 1948:

"[..] workers often use 15 percent time to pursue something they discovered through the usual course of work but didn't have time to follow up on." Kaomi Goetz -

The idea is very simple. Give your teams a little slack so that they can try out new things. For example, a programmer might want to try out a new library, learn a new language or build an app. There are some solid benefits:
  • They can work on an idea that they think will be great, but would never be able to convince management without a prototype. Products like Google Mail and the Post-It note came out of these kinds of schemes.
  • Fix something in the product won't ever be a high priority, but these kinds of things tend to add quality to the product over time.
  • On the smaller scale improvements to processes and smaller innovations that can be added to existing products.
  • It is great motivation for employees. All projects will have periods of grind where developers are just cranking out repetitive work. A bit of a break when they can let their hair down does wonders for morale.
  • It's a great form of training. No matter what people work on in this time, they'll be learning while doing it.
Ok, so assuming that you're now convinced, how would you implement a scheme like this? Mike Cannon-Brookes of Atlassian says:

"You see, while everyone knows about Google’s 20% time and we’ve heard about all the neat products born from it (Google News, GMail etc) – we’ve found it extremely difficult to get any hard facts about how it actually works in practice."

It will ultimately depend on your organisation. I think the key is to keep it as open as possible. Any constraints on the developers are going to limit any possibly innovation. However, a few constraints will help keep everyone's goals aligned:

"Self-organizing systems are able to create their own rules. All is needed for such a system to work is a set of simple constraints, sometimes called a boundary. It is important for managers to tune these constraints, and not to try and design all the rules. This means the job of a manager is to manage the system, and not the people in it." Management 3.0 - Jurgen Appelo

For example:
  • Your project should be something that would improve the company
  • Your project should have short, achievable goals
  • Your project must be visible to everyone
The first point is designed to steer people to work on something relevant to the company but without limiting them so much that they play it safe.

The typical scheme will be between 10% - 20% of the employee's time. Any less and they won't have time to produce anything of substance, any more and it will interfere with their jobs. However, this is still not much time, so it's important to make sure people aren't being too ambitious and setting themselves unachievable goals (e.g. write an operating system in 4 hours). This also helps with the other two goals. 

Lastly, people should be talking about what they are working on. This is important for stakeholders to see that people aren't just wasting time. More importantly, however, it means that people are sharing ideas which is going to generate more ideas and collaboration. A wiki and small demos might be a nice way to kick start this.

So why not try it and see what happens. Friday afternoons are typically productivity sinks anyway. Why not use that slow time to stir things up a bit?

No comments: