that's an awesome blog post, a great set of guidelines, and a really impressive team to take it this far and make it happen rather than just talk about it. can't wait to see the results!

"We are spending $USD 1,000,000."

What strikes me as odd is that you are assuming a full 100% utility of your engineers over 6 months.

I recently attended a seminar hosted by Agile Finland ( http://events.agilefinland.com/events/show/5 ) in which Mary Poppendieck talked about the effect of Thrasing, which if I paraphrase was in the lines of "if you try to push your workers to 100% you will get much less than that due to thrasing".

You can check out her slides on the matter : http://events.agilefinland.com/files/5/marypoppendieck_thrashing.pdf

So basically if you are in an environment where you are NOT pushing for 100% you will get about 80% utilization and that's it. If you start pushing for more, you get hurt. Thus if you give your engineers the 20% (i.e. don't push them towards 100%) you will a) actually get more utility/usage of their skills and b) be more of a relaxing place to work.

So you aren't spending a million bucks, but actually saving money - and the engineer's nerves - because you are accomplishing more.

Jan - interesting points (and I agree in the main!) but when doing costing, one really can't do anything but count full utility.

We pay engineers 100% of their salary, whether they are productive 100% of the time. The costs to us are 100%. If engineers are productive 80% of the time, or we push them to be so 80% of the time - then 20% represents 20% of the 80%, not 20% of the 100% despite the fact we pay them 100% of their salary, hence our costs are 20% of 100%.

We may well be saving money and / or engineers nerves - but either way the costing is $USD 1 million.

Does that make sense?

Well your accounting of course depends on where you are allocating that 20% time slice - whether it is at the end of each day or a full day once a week.

Since if you do it so that you allocate it to be one full work day then I can see your point of costs, but if you allocate it evenly on every work day then it is harder to calculate.

What are you really going to get from 24 days (per dev) spread over 6 months? I hope your expectations are low.

Jan - one of our rules is that 20% time must be taken in whole day slices. You can't spend an hour here and an hour there, you must take at minimum a whole day. Will be clearer when Charles posts our initial rules for discussion later today.

Ralph - it doesn't need to be spread, they can take it in pieces as large as they want. It adds up to almost 5 man years of development work. If we can't get a return on 5 man years as a software development company, we're in bigger trouble than the $1m :)

> What are you really going to get from 24 days (per dev) spread over 6 months?

Well, we get some pretty impressive features out of one FedEx day every six months. The problem with FedEx day is that (despite the name) it is optimized for demoing -- not for shipping. Every FedEx day we come up with lots great ideas, most of which end with a message saying "estimate three more days of work to complete...." But unfortunately, those three days never come.

20% time is an effort to help developer take some of those ideas to completion, whether it be over a long haul one day a week, or by saving up a big chunk of concentrated time for a special project. The allocation of 20% time is up to the individual developer (though they are intended to take their team members and project schedule into consideration).

As for me, I'm really hoping that 20% time will allow a lot more of those "Wow!" FedEx day features to actually make it to customers.

This serie is going to be very interesting. Now I´m trying how to take this idea to a service oriented enterprise, I mean, where there is no products where you can calculate the ROI. Good luck!

I think the 20% time has a lot of risks attached to it, and certainly wouldn't work in many companies.

I'm independent now, but I was working on personal projects outside of work for years -- and was allowed, thanks to a few pushbacks on our NCA -- but much of my drive to work on those projects was either:
* to build up software and websites that would be _mine_ -- so if they made it "big", I would get the credit and income stream, not the company. A company project I'd been tech lead for did win an industry award... and they got a bunch of press and new business out of it, but my name never showed up once in the press releases & news articles; that wasn't a nice feeling.
* to scratch itches and build a reputation by contributing to OSS projects.

My main job did often benefit, because technical problems I'd already puzzled my way through in my own time were obviously easier the second time around at work, and I explored a lot of new tech which definitely made me a better developer. On the other side, I'm sure I was sometimes distracted (and/or tired) at my normal job if I'd spent a lot of time in personal work.

What does the developer gain if that 20% project really takes off? If she/he just gets a pat-on-the-back bonus, and the company rolls out their great new product (and ongoing revenue stream, with their name all over it)... well, there's the benefit of having more control over how you spend that time, but I'm not sure that will get everyone excited ("what if I just want to keep working on this feature I'm already overdue on?").

I'm curious to watch your experiment, and see how it goes & what the engineers think of it! Thanks for making it public. Keep it interesting, and of course it's also an attention draw for the company.

P.S. I'll also disagree with the costing model, BTW, though I understand you're making a point about the scope of the developer effort that you're handling differently. I haven't seen your rules yet, but you've already mentioned a review process to make sure the 20% projects are useful... so it's not as if any of your engineers are going to be spending their 20% watching the clouds go by, and assuming they're bright folks as you say, you're also guaranteed they won't be building products completely unrelated to your business, or making features that all customers will hate. All IP that your engineers produce is also still yours. Plus there's the benefit of the publicity the experiment will generate, I imagine.

You *can* say that you're giving your engineers much more personal control (though not complete) over how they allocate that 20% of their time (and collectively, $1M) to the company & products.

@ralph & Mike about 24 days of effort and what to expect: I'm not sure the man years sum helps much, unless they're going to be working together on a single (or a few) large products of large features.

I was assuming it'd be mostly solo work -- in which case, no, you won't see any massive single development, but the value of 70 decent sized new features or small apps ain't nothing, is it?

@Mike: are you going to be pushing the engineers to scope their 20% work to be "complete" at the end of the 6 months? Or let the ambitious ones dig into multi-year stuff, then decide to let it drop vs. make it an official project at the end of the 6 months?

This sounds like a great experiment, and I can't wait to see what all of the talented Atlassian folks come up with in their 20% time. I'm especially keen to hear more on how your rules pan out.

However, I can't help but be a bit taken aback by the arguably sexist language in the post: "When can an engineer take his time?", "he (or she) is a full time software developer and ...", "but paradoxically he spends less time building the things he personally wants in the product." Despite what you may have been told, he/his is definitely not gender-neutral (have a look at this LanguageLog post for good arguments as to why: http://itre.cis.upenn.edu/~myl/languagelog/archives/005423.html), and relegating women to a parenthetical aside in an industry where we're already seriously under-represented feels a bit like perpetuating the misconceptions that have led to that situation in the first place. I personally know two female developers who work for Atlassian, so it's not as if we're talking about hypothetical women here.

I'm sorry to derail what should be simply an interesting and honest look into Atlassian's innovative work practices, but I stumbled over these sentences as I read them and just had to say something.

@Rob & Jan

I get the impression you're uncomfortable with Mike's use of "Cost" for something which may have a net positive return (or at least a net loss that is smaller than $1m)

To points:
1) Mike - we in the in-house corporate world struggle to remind our business sponsors that IT is an investment not a cost. Please support your comrades and call this a $1m speculative investment :)

2) Jan & Rob - Cost/Revenue and separate to Profit/Loss.
Paying staff $1m is a cost. If the resulting revenue is $5m then, then there is a $4m profit, but cost was still $1m. That's accounting.
So, Mike's in the situation where (assuming this policy doesn't eat into the other 80% time, and doesn't cause staff turn-over [why would it?] etc) he's got a cost of $1m, with an undetermined revenue stream.
His potential for profit/loss is something in the range [$1m loss, $5m profit] (I'm making up the profit side. I have no idea what the maximum upside on this would be)

Last I looked, the electricity bill still came at 100%, even if I wasn't working 100%

Good to see you lay it out on the table, there will always be the skeptics - but I don't see them laying down the investment on the table.

Go for it!

Just noticed this now. Sounds cool. I'm interested in how it all works out. If you haven't already, you should take a look at how 3M does (did?) their 15% time though I'm not sure how much details are available on that either.

@Robw - thanks for the insightful posts. There are no strictures about finishing projects inside 6 months or anything of the sort. A lot of projects will probably be one week efforts, others will be multi-month, multi-developer efforts. We'll see how it evolves.

@Alice - apologies for the sexist language, I was trying to indicate by my parenthetical statement that all developers after that point were either he or she's. I'll use she as a default in my next post!

@Jason - we've looked at a bit of the 3M stuff in doing our research. Theirs is mainly intended (as I understand) for scientific researchers which is a little different to software developers but there are some interesting parallels.

This is very cool Mike, Will be really interesting to see how this goes, I love the idea but know how hard I'd actually find making the call, taking the punt and doing it... What ever way people talk about accounting, its a million dollar experiment, admirable and exciting that you've built an organisation where you can make this happen... watching with interest, lead the way mate

Tim.