[Slack to the Rescue] Forever in Down Under


Slack at Atlassian

It’s actually pretty hard to get real data on slack. Most data you can find is diffuse and contains lots of rumours. It seems that especially on Google’s 20 % there are more myths than facts available. 3M and Gore are mostly legend, nothing concrete, almost no details. Atlassian to the rescue!

Atlassian’s 20 % Slack Experiment

Atlassian is an online product development company, known for products like their online collaboration tool Confluence or their online project tracking tool JIRA. They were founded in 2002 in Sydney, Australia, and by now they have almost 300 employees, 20,000 customers in 134 countries, and took a $60 million founding in 2010. It’s a highly successful company.

Atlassian did a slack experiment in 2008 – and blogged about it. With 70 employees and 10,000 customers those days, they feared that innovations would slow down, so they looked at Google and decided to give it a try.

The experiment should last 6 months. They calculated the costs to be $1 million (USD). And they assumed a huge benefit for themselves and their customers.

Given their preconditions, they were right to assume to win. They already had a culture of innovation established with their FedEx days, 24-hour-build-and-ship-it product creations. And, maybe Atlassian’s most valuable property, they had trust and faith in their employees:

“We have an _absolutely awesome_ engineering staff. I can’t wait to see what they come up with.” — Mike Cannon-Brookes, Atlassian’s Co-founder and CEO, in Atlassian’s 20% Time Experiment

Another highlight in their slack experiment was that they wouldn’t consider the experiment failed when their products developed during slack time failed. They added the following to their slack 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.)” — Charles Miller, Atlassian employee, in 20% time nuts and bolts

Atlassian’s Experiment Results

One year after they started their 6-months-experiment they published the results (the original blog post seems to be lost; this is a copy I discovered). The experiment lasted 12 months. These are the numbers:

  • number of projects worked on during slack time: 48
  • number of people who used slack time: 34
  • number of days spent on slack: 248

The last number was the most surprising one. Although Atlassian supposed that not all developers counted all days spent on slack, the official 248 days were only 1.1% slack time in total!

So they worried about the $1 million they spent on slack, when it actually was only about $60,000. They emphasized, that the total number could be 2 or even 3 times higher, but that would be still only a fraction of the estimated million.

More numbers:

  • Shortest project in days: 1
  • Longest project in days: 18
  • Number of projects, which were finished in normal development time and incorporated into products: 16
  • Longest project in days, which was finished in normal development time and incorporated into products: 5 (!)

Another interesting outcome of that experiment was, that it was actually hard for developers to schedule slack. Atlassian has frequent releases of their products, which interfered with planned slack time. Also, developers didn’t want to have fun slacking around while others had to do hard work on the products.

Slack Forever at Atlassian

A month after their evaluation blogpost, Atlassian announced that they’ll continue with their slack time initiative, not as an experiment, but as part of what they do and what they are. This is the vision and the rules for their slack:

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”

— John Rotenstein, Atlassian employee, in Atlassian’s 20% Time now out of Beta

Slack Groups: No Budget, No Authority, Full Passion

Created innovations during slack time would be doomed to spend their existence in the shadows of the already money-making top-dog products, if the organization didn’t take care of their delicate flowers.

During slack time employees are already encouraged to form groups for their projects. One reason is to separate the wheat from the chaff:

“Gore is a marketplace for ideas […] As one engineer put it: ‘If you can’t find enough people to work on your project, maybe it’s not a good idea.'” — Gary Hamel in Future of Management

Another reason for slack projects done by groups is that only good ideas will gain a movement. Google’s employees group themselves together to grouplets to work on products on their own initiative in their 20 % time. Grouplets don’t have a budget and don’t have decision-making authority, but grouplets can influence the rest of the company better as an individual could.

Atlassian has a peer rule for their slack:

“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 [, founders of Atlassian].” — Charles Miller, Atlassian employee, in 20% time nuts and bolts 

  1. [Slack to the Rescue] What You Want to Do
  2. [Slack to the Rescue] Culture of Autonomy
  3. [Slack to the Rescue] Harder Than It Sounds
  4. [Slack to the Rescue] Forever in Down Under
  5. [Slack to the Rescue] The Future
This entry was posted in General and tagged , . Bookmark the permalink.

About Bernd Schiffer

Bernd Schiffer is consultant, trainer and coach for Agile Software Development in Melbourne, Australia. Learn more about him on his personal homepage, have a look at his company Bold Mover, or contact him on Twitter, Google+, Facebook, XING or LinkedIn.

2 Responses to [Slack to the Rescue] Forever in Down Under

Leave a Reply

Your email address will not be published.