First, some quick background. My name is Charles Miller. I am (not counting the founders) the fourth-longest serving Atlassian employee. I started back in 2003 as a developer on the Confluence project, worked my way up to be team lead for a while, slipped sideways into an architect role, and am currently on temporary secondment to the Jira Studio team.
About three months ago, at our not-quite-quarterly all-hands meeting, Mike announced that Atlassian would, at some time in the future, in some way shape or form, begin an experiment with 20% time.. My immediate reaction was:
- This is a great idea.
- What can I do to make sure this still isn’t on the drawing board when the next staff meeting rolls around?
Generally, the biggest barrier to getting something running is finding the time to take care of the boring details, so I decided on a neat hack around the problem: I would volunteer to spend the first six months of my own 20% time… on organising 20% time.
Explaining why I think it’s a good idea is another post, and probably repeats a lot of what Mike has said already. This post is all about implementation. I’m not going to go into all the details straight away (that would be long and tedious), but hopefully this is a good overview of how the project has been set up.
Bootstrapping
My first task was to work with company founders Mike and Scott, and Soren (our Director of Engineering) to come up with a framework in which we could start the experiment. For the most part this meant coming up with a list of questions we expected developers might ask, and having answers ready for them. (Sometimes the A in FAQ stands for ‘anticipated’).
We made a conscious effort to make as few rules as possible. In many ways this whole programme is an exercise in trust between Atlassian and its developers, to see what is done when the restrictions are removed. Shackling it in proscriptive regulation would be counter-productive. Even some rules we did come up with were discarded — one draft rule barred new developers from taking part in 20% time until they had passed their three-month probationary period, until it was pointed out that this would have excluded our most recent ShipIt Day champion.
Expectations
What are we expecting people to work on in their 20% time? I put it this way in the FAQ:
“Our experience with ShipIt Day, and with general developer slack-time is that the output of developers left to their own devices will fall into the following categories:
- 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 shit
We’re also going to try to use 20% time to encourage contribution to open source projects, JSRs or other community projects, because we want to be good citizens.
Forces
The first three core Atlassian values are:
- Open company. No bullshit.
- Build with heart and balance.
- Don’t fuck the customer.
It turns out that a lot of what we need to guide us through 20% time comes out of these three values.
Open Company, No Bullshit
This exercise is, as of now, an experiment. For the experiment to be successful, we need to have some idea of what is being produced, and what effort it took to produce it. For this reason, all projects have to be documented on our internal wiki, and we’ll be organising “demo lunches” where developers can show off their achievements… or warn others away from the jagged rocks of their failures.
Build with Heart and Balance
How do you set up a program where developers are free to pursue their passion, to do what _they_ feel is most worthwhile for them to be doing, but at the same time stop developer time disappearing into black-holes and dead ends?
We really only put one a priori restriction on projects: that 20% time not be used as a technological masturbation aid. If you have some concrete goal in mind and honestly think that Haskell is the best way to reach it, that’s great. If you just want an excuse to play with Haskell, that’s what weekends are for.
Beyond that, the most powerful force to keep it real is peer review. If you have to justify your project to your peers, who will feel it is their duty to ask the difficult questions you may have been fudging over, it should be apparent if your project is worth continuing or not. So there are two mandatory checkpoints. If you want to spend more than 40 hours on one project (one developer-week), you must find three supporters within the company who agree that the project is both a good idea, and viable. After 160 hours, the project also needs to be signed off by Mike or Scott.
Don’t Fuck the Customer
Atlassian needs to innovate. We need to devote resources to research and development. We need to take risks and try new things. If we don’t, our products will grow stale, wither and die, and the company will follow them. That’s not good for us, and not good for our customers. At the same time, we have development schedules. We have customers who are waiting on far more mundane, bread-and-butter features. If we have developers running off to do 20% work whenever they feel like, our release cycles will suffer.
The solution we’ve come up with is to treat 20% time exactly the same way we treat annual leave. If you want to take time off from scheduled work to work on your own project, you have to give your manager reasonable notice and have it approved ahead of time. And like annual leave requests, managers are expected to approve them unless there is some good reason not to, like the developer being on the critical path for a release, or too many developers taking time off at once.
On Success
One problem with the emphasis we have placed on peer review is that it might cause developers to become too conservative in what they attempt. To quote a Russian proverb my girlfriend is fond of, “He who does not risk does not drink champagne.” To remind everyone that failure is, in fact, an option, I put this in the FAQ:
A failed 20% project is not necessarily a bad thing. 20% is an exercise in innovation and risk, and when you take risks you invite failure. You could work on some cool technology and discover that it doesn’t really produce the result you were after. You could work on a product feature and find that it doesn’t fit in with the direction the product is going. You could just realise, as you develop your project, that it isn’t such a good idea after all.
The best advice is to fail fast. Don’t get stuck in a death-spiral of unproductiveness, don’t spend your days trying to bang a round peg into a square hole. Don’t be afraid to draw a big red line through your project, and move on to something that could bear fruit.
(Warning: mixing this many metaphors can be dangerous.)