Following up from my presentation on Saturday at the Rakuten Technology Conference 2012 in Tokyo I received some questions via email. I wanted to share them below in case anyone else had similar queries.
Does Atlassian measure whether ShipIt Days are profitable? Everyone knows “innovation” is important for a company. On the other hand, it’s hard to measure the effect.
Atlassian does not measure profitability of ShipIt Day projects. You are right, it is difficult to measure the effect!
Sometimes a ShipIt Day project is a feature of an existing product, other times it is a new internal tool to assist other Atlassians and reduce a bottleneck in delivering value to customers, and still other times it has nothing to do with Atlassian at all. For example, in years past time has been spent contributing to Asterix, an open source PABX that we use.
We do measure the impact ShipIt Days have by keeping track of how many of the project do ship to customers – that is, how many projects have delivered customer value? That is the best proxy for identifying the value gained from the ShipIt Day activity without trying to infer the profit contribution.
At the last ShipIt Day, #20, do all Atlassian employees attend the ShipIt Day? Or is it voluntary? Which do you think is better?
Not all Atlassians participate, although it is certainly encouraged.
People from Talent, Product Advocates, Product Management, Marketing, Support, Operations, System Administration, Internal Systems, Quality Assistance, and yes, Engineering participate. We now run ShipIt Days in our Sydney, San Francisco, Gdansk, and Amsterdam offices.
These days most ShipIt Day projects have a team of people so that they can achieve more in the short space of time. Plus, this means they can have a cross-functional team – product owner, tester, designer, developer, etc.
One thing that prevents everyone from participating in every event is the queue. Those in direct customer facing teams such as Support and Advocates can not just drop everything and participate in ShipIt Days. These teams have to manage their load and so often some people will participate in every second ShipIt Day. Otherwise they would risk our SLA (Service Level Agreement).
About “Shipped” stuffs (products, services), are they maintained? If customer report some bugs or ask to improve, does anyone respond to it? I think because the developer who made the stuff have their own work, so it’s difficult to make time for maintain that. How do you do that?
The short answer is that it depends.
Keep in mind that we are our own best customers – we are building for software teams, and we are a company of software teams. So when we get value from a ShipIt Day project there is a good chance the customer does too.
If a project is included into a future release of a product then it is certainly maintained. Occasionally ShipIt Day projects end up on the Atlassian Marketplace as an Unsupported and Open Source plugin that is infrequently, if ever, updated. Others may live on after ShipIt Day as a repository on atlassian.bitbucket.org – allowing a customer to take the code and do as they please.
Finally, if a team is really passionate about the project they may continue to work on it during their 20% time (subject to their colleagues buying in to the idea and approving future 20% days). In most cases the projects that provide customer value have a place on the roadmap as the Product Manager believes in it.
Regarding the user feedback part, you’ve utilized issue collector to get a lot of feedback from customers. I’m also familiar with the way of working like Lean Startup. But I’m wondering if the issue collector is sufficient to collect customers’ voice in detail. Don’t you think if you need separated interview-type activity, some proactive things?
We do have a separate customer interview process where team members will Skype customers or visit them on-site. We also conduct usability tests. Heck, we even have customers come into the office for lunch or a beer. The Issue Collector is just one part of a broader Customer Feedback program at Atlassian. And that program is constantly evolving.
One thing to note, the ability to get feedback from the end user and not simply the ‘gatekeeper’ that has an Atlassian account is a huge bonus that the Issue Collector provides.
Sometimes, even customers don’t know what they want, which implies that it might be risky to heavily depend on customers’ feedback, right? Do you have any special operation to come up with an idea from totally different point of view?
Spot on! Customers don’t know what they want.
We conduct paper prototyping to explore new ideas and validate those ideas with customers. It is a cheap way to get feedback. However, some customers can not visualise something unless they see it, and it is only then that they tell you it is once what they are looking for – after you have built it. For that reason we try to minimise the time/cost spent building until we have satisfactorily validated that we solved the customer problem.
Another thought, we have used Five Why’s to get to the root cause of a customer problem. That is a great place to start building a solution!
Regarding the innovation part, I think that the system you presented like awards, contests would definitely work well. But it doesn’t necessary mean that all the people like this way of working. So my question here is – how have you kept people’s motivation apart from such award or so? Is they any special tips or operation to do that?
There is a whole talk here on extrinsic vs intrinsic motivation. Dan Pink says pay people enough so that money is off the table. The other piece then is the intrinsic motivation, for which autonomy, mastery and purpose are key.
Autonomy – we’ve given Atlassians ShipIt Days and 20% time to allow them to be self-directed.
Mastery – there are constant opportunities for new challenges and for individuals to hone their skills. For example, once an Atlassian really gets good at something we’ll ask them to present on it at a conference (or they will get invited, thanks Rakuten!).
Purpose – why do they do what they do? To solve a customer problem. This is where the feedback is key, giving the feedback directly to the team reminds them of the purpose.
Like that? Follow me on Twitter for more on Agile and Innovation. If you have any questions feel free to tweet or add a comment below. Thanks.
