Atlassian tech support secrets revealed – less Jira, more poker

Source: crn.com.au

Atlassian has revealed it’s tech support secrets, posting insights into how it’s used on gamification to massively reduce bug tracking problems.

In a post titled “How to gamify b ug tracking”, the company’s Senior Development Team Lead Andrew Burleson Explain but the company used Statuspage to track bugs. 

Most of the resulting reports “ were passed from customer support to the escalation engineer (EE),” Burleson wrote. “Most of the time, the EE would either figure out what was wrong with a customer’s account and manually fix the data or push a simple one-liner bug fix. For more complex issues, the EE would usually ask a developer to fix it. That approach worked well enough when the team was small, but also posed some major problems that only got worse as we grew.”

“Customer support had to babysit the devs in order to get a response to customers, and response times varied widely. Ad-hoc projects assigned peer-to-peer were interfering with our mainline work. Large or complex issues would get filed as a Jira issue and never looked at again. “‘Put it in Jira” ‘became code for ‘forget about it’, and since putting things in Jira didn’t feel valuable, people often didn’t bother, so a lot of good ideas or observations weren’t getting captured.”

All of which added up to a bad way to run software development, a suboptimal customer experience and a big “overhead” of unresolved customer issues.

So the company made a change, and now follows  three support principles:

1. We can’t fix everything immediately, but if we communicate to customers and give them timely communication throughout the process, that’s okay.
2. We can tame the “unpredictable” flow of interrupt work – unexpected bugs and high-priority requests – by throttling it. If we know the long-term rate of tickets flowing in, and fix at the same rate or just a little faster, then they won’t pile up.
3. That ocean of work to be done was actually full of work that was done, wasn’t relevant anymore, or didn’t fit with our product vision.If we could filter out all this noise, what was left would be manageable.

The company also decided its processes had to be fun, so “started by giving each developer two poker chips.”

Developers earn more chips when they complete tickets.

“Every week, we collect a tax – typically one poker chip from each developer. The tax goes up and down as needed to make sure we’re draining the Overhead backlog.”

“The developers owe the tax each week, but typically have extra chips ‘in the bank’, so they can use their reserves to pay the tax – and avoid overhead work,” Burleson explained. This arrangement means that developers can  spend chips to buy time when they have deadlines “and tackle more overhead work on lighter weeks to rebuild their stockpile.”

“By empowering developers to control their own schedules, we actually get more mainline and overhead work done, with less need for micro-management.filter out all this noise, what was left would be manageable.”

“Since adopting the Overhead process, we’ve gotten our bug backlog in check without derailing our mainline feature development work,” Burleson wrote. “The biggest wins have been for our customers. Because individual issues are triaged, assigned, and completed at a regular cadence, we’re fixing more bugs – and more important bugs – faster. Customers appreciate that we can respond quickly, set expectations for what can and cannot be fixed, and then deliver the fixes we promise.”

“Our Customer Support Team has really benefited from this change as well. The improved process makes it easier for them to keep customers informed, and since every issue ends up with a resolution, the Support Team can always close the loop, without having to babysit developers.”

“Overall, this strategy has made a huge difference for our team,” Burleson concluded. “We’ve battle-tested it for several years, and now we’re happy to share it with other teams in hopes that others can benefit as much as we have.”