Archives For Internationalisation

T-Mobile have been fantastic. When we moved to San Francisco in 2012 they were the carrier we chose. Over the course of our time in San Francisco their coverage improved tremendously, their prices came down, and their service remained exemplary.

Now that we’re back in Australia most of the time it made sense to find a local carrier. We’ve chosen Boost and we hope that they live up to the high expectation that we’ve got, given our experience with T-Mobile.

One of the other benefits with T-Mobile was the international roaming – the best in the world. Kudos to the team for an amazing offering. Check it out if you travel a lot.

Having said that, we no longer needed all the voice, message and data that we used over in America. Yet we wanted to retain our numbers. As such we’ve decided to port our T-Mobile numbers to Google Voice which will lower our monthly bill to $0 and direct all calls and messages through Google Hangouts (with data provided by the Boost/Telstra 4G network).

Screen Shot 2015-11-11 at 10.04.43 PM

Here’s how we did it:
1) Read through the Transfer your number to Google Voice instructions.
2) Disregard the need to replace your existing carrier with a new one, as you’re going to make and receive calls via the Google Hangouts app (on iOS and Android).
3) Head over to Google Voice and either a) sign up for an account, or b) replace your existing Google Voice number. If you’re already outside the US try an SSH Socks Proxy to a US server (ssh -D 51443 user@server) or TorBrowser (you’ll have to get a new identity until you get a US IP address)
4) Fill out the form with details of your T-Mobile account, billing address, etc and then pay $20 for the privilege to port your number to Google.
5) Keep an eye on the porting status at this special page.
6) Make sure you have the Google Hangouts app installed to send/receive calls.

Voila. Simple as that. Give it a whirl if you’re moving overseas after a stint in the US and want to keep your US number.

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 – 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.

Atlassian Translations

May 21, 2011

Over the past 18 months I have been working to bring Atlassian products to a broader audience globally. Our approach was to allow our customers, partners and users to translate the products into their language – who better to do the translation than the people that use the product every day.

It has been a very successful approach. We now have 40 language packs available for JIRA, GreenHopper and Confluence. Over 260,000 strings have been translated. Atlassian Translations will soon expand to include the add ons and plugins that are available on the Plugin Exchange, further enhancing the Atlassian community in languages other than English.

I sat down with OneSky recently to share Atlassian’s approach to crowd-sourced translations. OnSky is a startup that specialises in assisting companies with rolling out their own crowd-sourced translation site, and building a community to foster contributions. The full Q & A can is included below for reference.

Bring it to the world: Atlassian

This is part of our series “Bring it to the world” which profiles apps that offer localized versions to reach happy users from many parts of the world.

Q&A with Nicholas Muldoon of Atlassian

What does your company do?

Atlassian makes tools that help great teams build great software. More than 22,000 companies use our issue tracking, collaboration and software development tools to work smarter and deliver quality results on time.

How many languages does Atlassian support now?

Atlassian now has 40 language packs for our flagship products JIRA, Confluence and GreenHopper. As these language packs are crowdsourced by our partners, customers and end users they are in various states of completion. Recent additions include Russian language packs for JIRA and GreenHopper and a new Icelandic language pack for Confluence. Also, as I write this we are just localizing Confluence by adding a Hungarian language pack.

What types of apps do you have?

Our focus is on helping software development teams deliver great software, our products include:

  • JIRA, issue and project tracking for software development teams to improve code quality and the speed of development;
  • GreenHopper, an agile project management add on to any JIRA project;
  • Bamboo, for automated building, testing, deploying, and releasing of your software;
  • Bitbucket, a free code hosting site for the popular Mercurial distributed version control system (DVCS).

How did you get the idea of localizing your app?

Japanese, German and French language packs were provided for a number of years. In 2010 we decided we wanted to open this process up to all of our customers and ensure everyone had equal access to the necessary language packs. Not having the language expertise in-house we decided to build an in-house translation platform, Atlassian Translations, that would allow anyone to contribute to the localization.

What tools do you use?

Atlassian Translations was developed internally and open to the world – everyone can use it to translate our products. Official partners ensure the quality of the language packs is maintained and assist with translating new product versions.

How has localization helped your apps so far?

Over the past 12 months we have seen significant growth in our European operations. Localization has certainly played a role in this growth. Furthermore, with the current level of interest in the crowdsourced translation from Asia Pacific I envisage a similar trend in that region over the coming 12 months.

Aside from the sales growth we have seen a translation community form around which is very encouraging.

How long does it take for translating the whole product in a new language?

The fastest translation so far has been Vietnamese which was completed by a handful of people in a matter of weeks. More often though it is a slow process that picks up speed as the translation nears completion.

I recommend any endeavour to crowdsource the translation of products be seeded with key contributors for each language. This will ensure that there is someone passionate about the translation who can drive it forward and assist new contributors in coming up to speed. In the long run this will lead to higher quality of translation and a stronger community.

With new features such as in-product translation I expect the time taken to decrease yet again. This will make it easier for the contributors to keep the language packs current as we release new versions of the products.

What made you go for crowd-sourced translation instead of traditional agency translation, or even machine translation?

It was simply more accurate than the traditional agency translation we had seen previously. Our customers and partners know our products inside out – they were the best people to translate them.

Machine translation also features in our in-house tool. We seed incomplete language packs with Google Translate to assist the contributors through suggestions, or in the case of a simple word the acceptance of a suggested translation. That can speed up the translation at the beginning stage.

Any advice for someone considering localization?

I would recommend folks explore the open source solutions that are available, provide incentives to contributors and moderators, integrate it closely with existing user management systems and make the translation process as painless as possible.

Nail those items and you’ll see a great community form which drives your business forward in new languages and regions.