Atlassian's 20% Time Policy

In my quest to find other companies’ experiences with side projects policies, I failed to find very many details on how companies were actually implementing them. One exception was Atlassian, who went on a similar quest 3 years ago, and also came up short, and fortunately, decided to blog about how they managed their “20 percent time.”

The Basic Guidelines #

Here are the basics, from what I’ve gleaned from reading their blog and watching this presentation:

Why? #

Innovation. They were already holding Fedex days (hackathons), but found that the products of these weren’t shippable. They needed more time.

What? #

• Pet features/improvements that never made it onto the roadmap
• “This always annoyed me” bug-fixes or architectural improvements,
• Integration of some technology-du-jour with a product
• Random wacky sh*t
• Contribution to open source projects.

When? #

Treat 20% exactly the same way that they treat annual leave. Get approval from manager ahead of time, with the expectation that approval will be given, exceptional circumstances notwithstanding.

How? #

Peer review. After spending 40 hours on a project, you must find three supporters who think it’s a good idea and viable. After 80/120/160 hours (this number varied, but I think settled on 80), you must get one of the founders’ sign-off.

Their Year In Review #

After running their experiment for a year, they reviewed how they did and what the results were.

• Developers only spent 1.1% time in total.
• The “20% time” was spent incubating features, while the features were completed in the normal development cycle.
• Tracking this time was difficult.
• With “real” work to do, finding time was even more difficult.

My Observations #

This is an exercise in trust. More important than the specific number of hours spent on side projects versus billable projects is the idea that the company has faith in its engineers to do innovative things. It’s recognizing innovation can’t be mandated and is not guaranteed, but we can create an environment that nurtures innovators—where experimenting is welcomed and failing is OK. Giving engineers autonomy is a powerful motivator. It’s a fact.

Before running this 20% experiment, Atlassian began to hold hackathons that they entitled “Fedex days”, wherein developers would spend a day coding and would “ship” (demo) by the end of that day. Since these had been, and continue to be, successful, this tells me that their culture was already heavily a creative, maker’s culture. They had the right kind of people who get excited about a day to run wild and do something out of the ordinary. And this is what is fundamental in order for any kind of side projects policy to work.

Having Atlassian’s foray into 20% time as a data point is very helpful. Most of the big ideas that they learned will certainly transfer to our forthcoming policy. However, they are different from our company in significant ways. They are a product company, with multiple successful products,  over 200 employees, tens of thousands of customers and $59 million in revenue. We are primarily a consulting firm, with 10 developers, and not-so-much revenue. They recently closed $60 million in funding, we didn’t. So, there will be elements that we will need to adapt from their approach.

Wednesday, June 15, 2011