In my previous blog about 20% Time, I gave a summary of Atlassian's "20% Experiment" but left readers hanging as to the future of 20% Time at Atlassian. Well, I'm glad to end that suspense now and officially announce that Atlassian is continuing with 20% Time, rather than keeping it under the label of being an "experiment".

We get a lot of questions about the 'nuts and bolts' of how we've implemented 20% Time, so I'm happy to share the details.

The Goal of 20% Time
	To encourage innovation in products, development techniques and the Atlassian development ecosystem. Not every 20% Time project has to lead to shipped features Internal innovation is encouraged - new processes, techniques, libraries Contribution to the larger ecosystem counts too, where it assists Atlassian Failing is OK

The key here is that innovation is not guaranteed. We can't mandate that every 20% Time project must lead to a new feature since we don't want people to be afraid of failure. Rather, we aim to create an environment where innovation is encouraged and where 'trying' is as much a cause to celebrate as 'succeeding'.

We have also stated a broad scope for 20% Time that includes work on productivity enhancements and external activities (eg working on Open Source projects) — but only where there is a beneficial link back to Atlassian. After all, 20% Time is a part of our Development effort, not a charity. (We have the Atlassian Foundation for that!)

Tracking effort vs Tracking projects

The next major decision we had to make was how closely to monitor 20% Time. The Management team want to track "return on investment" so they can justify the expense of 20% Time. Developers, on the other hand, want freedom to innovate without having to justify everything they do. As one person suggested:

Reporting against specific 20% projects can lead to a decrease in the innovation factor. 20% projects, by their very nature, will have a lot of false starts, dead-ends, and time spent that doesn't directly contribute to a production product (and that is how it should be). If you start tracking and reporting on individuals and how much time they are spending on a project, they might start picking safer, less innovative products, so they don't have a lot of false starts and dead-ends showing up against their name in the reports.

These two viewpoints lead to some friction. For example, we have two sign-off points to ensure projects don't consume too much time without foreseeable benefit:

• Any project that has consumed more than 5 days of developer time requires the sign-off of three supporters. These supporters should be developers who are not involved in the project, but who believe the project is both viable, and a good idea.
• Any project that has consumed more than 10 days of developer time requires sign-off from a Founder.

Enforcing these rules would mean that we have to track time against each project, but this is contrary to giving Developers freedom to innovate without a "big brother" watching over them.

After vigorous debate amongst management, it was decided to have Faith that our Developers would apply their time wisely. Therefore, we are tracking 20% Time at a high-level within our normal time-tracking system, but not at the individual project level. Developers are responsible for getting appropriate sign-off and updating the status of their own projects, the results of which are displayed on a dashboard on our corporate wiki.

(For those interested, we track each 20% project as an individual 'issue' within JIRA, then display those projects as a dashboard on our Confluence wiki.)

It's also worth mentioning that our quarterly FedEx days also contribute to 20% Time but are tracked separately. They involve specific days set aside for innovation in a time-limited, competitive-like atmosphere.

The Future

All of these decisions, however, do not help overcome our biggest problem — that scheduling 20% Time can be difficult and can seem unfair. That will be our on-going challenge as we continue with 20% Time.