The Atlassian method: The power of developer joy

For over two decades, Atlassian has been synonymous with developer tooling, shaping the conversation around developer experience. A year ago, they introduced a new term to the lexicon: developer joy. In the second installment of our series on foundational team principles, we speak with Matt Schvimmer, Senior Vice President of Product for Agile and DevOps at Atlassian, to learn about the origins of this philosophy, its compounding effects, and the emerging concept of “team joy.”

What is developer joy?

On the surface, developer joy—the concept of removing friction so developers can focus on what they love doing—might seem like a rebrand of developer experience. But go a level deeper, and it’s clear that it’s a much more considered philosophy. While developer experience largely focuses on the ergonomics, processes, and products that define a developer’s end-to-end workflow, developer joy centers around the craft of development and the standards and values that define it. In fact, the Atlassian team sees developer joy as the new developer experience, and they’re making it a company priority.

Atlassian recently conducted a survey on developer experience and found that developers lose 8+ hours a week to inefficiencies, ~20% of their time.

In 2022, Atlassian was facing productivity hurdles. “We routinely missed almost everything on the public roadmap,” says Matt. “It was just, ‘We’ll change Q2 to say Q3.’” Beyond a productivity hit, developer employee satisfaction scores were less than 50%.

This echoed a broader industry trend of systemic dissatisfaction, largely caused by poor tooling and systems. “It’s like 10% of your week is spent just looking for information to help you do your job,” Matt says. By his estimate, many developers also spend 20–30% of their time interfacing with design, working with other cross-functional teams, and participating in planning—all activities that take time away from core development work. “There are all these friction points that create cognitive load that take the joy out of work,” he adds. Atlassian needed a way to infuse joy back into work.

Operationalizing joy

To address the issue from all angles, the team spun up a “champions” program, a collection of cross-functional collaborators tasked with identifying and fixing points of frustration to improve developer joy organization-wide. The team started a workstream with two focus areas: systems and culture. Systems involved taking stock of existing tools and processes, with a focus on standardization and elimination. The working group found that many teams had redundant pairs of tools—Matt calls this the “Noah’s Ark of tooling.” Culture required identifying a set of coding standards the team would follow to operationalize values and align on key metrics. These standards, values, and metrics also indexed on cultivating craft, not just gaining efficiencies.

While the cross-functional working group built the scaffolding for this overhaul, leadership asked every engineering team to set aside 10% of their time for developer productivity initiatives. In doing so, developers across departments felt empowered to be part of the solution, what Matt calls an “ownership stake.” The results of the program spurred the leadership team to double down on the commitment by making a company-wide effort to improve developer joy. In fact, it became one of the Objectives and Key Results (OKRs) that teams across the company continue to report on every month.

Measuring the business value of joy

Making developer joy a company-level OKR meant making short-term tradeoffs, like optimizing for engagement over earnings. “You have that short-term revenue itch that’ll always be nagging at you,” Matt says, “but the discipline rewards itself.” He likens it to 401k—tough to prioritize in the early stages of a career, but with benefits that compound over decades.

In just a few months, the team saw a meaningful improvement in both quantitative and qualitative measures. Top level metrics include a 50% increase in developer satisfaction, a 50% reduction in the median time it takes to cycle through a pull request, and a 3x increase in deployment frequency. And this translated to cross-team initiatives. Rather than pushing out feature launches, the team delivered on all customer roadmap items. In terms of qualitative results, internal Customer Satisfaction (CSAT) scores hit 80%, up from below 50% months earlier. “Fixing the tools, addressing process work, and then being clear on what we’re going to measure has yielded results,” says Matt.

Charting the path to team joy

This measurable impact helped the team further rally around the joy initiative, a concept that some bristled at in the beginning. “People fund [developer experience] because they understand that they can draw a straight line from that to organizational performance,” says Matt, but they might feel uncomfortable supporting joy. These results grounded joy in the bottom line.

Moving forward, a “developer productivity” team is tasked with scaling developer joy. “It’s [their] job to find the harmony of how we can let developers be the best they can be, keep them happy, while still maintaining some semblance of consistency across the organization,” says Matt. And plugging into the broader organization is key. “We’re focused a lot on developers, rightfully so,” he continues. “They’re the largest share of the population. But there’s a bunch of other roles that are also instrumental that live in massive process pain.”

Designers, product managers, and data scientists are just some of the other teams that could benefit from expanding developer joy to team joy. This, he says, would allow teams to elevate not just the processes they rely on, but the products they ship.

Stay tuned for the next installment in our series about how teams build products and the principles and processes that guide their work.