Beyond developer experience: joy as a metric
Atlassian has spent over two decades shaping the conversation around developer tooling. A year ago, the company pushed that conversation further by introducing a new term: developer joy. In the second installment of our series on foundational team principles, Matt Schvimmer, Senior Vice President of Product for Agile and DevOps at Atlassian, explains where the philosophy came from, how it compounds, and why it is expanding into "team joy."
On the surface, developer joy—removing friction so developers can focus on what they love—might look like a rebrand of developer experience. But the distinction runs deeper. Developer experience focuses on the ergonomics, processes, and products shaping a developer’s end-to-end workflow. Developer joy centers on the craft of development and the standards and values that define it. Atlassian considers developer joy the next iteration of developer experience and has made it a company priority.
Where the friction lives
By 2022, Atlassian was hitting productivity walls. "We routinely missed almost everything on the public roadmap," says Schvimmer. "It was just, 'We'll change Q2 to say Q3.'" Developer satisfaction scores sat below 50%.
Schvimmer points to a Stack Overflow survey finding that 25% of developers spend over an hour per day searching for answers. "It's like 10% of your week is spent just looking for information to help you do your job," he says. He estimates developers also spend 20–30% of their time on design handoffs, cross-functional collaboration, and planning—time away from core development work. "There are all these friction points that create cognitive load that take the joy out of work."
Operationalizing joy across the org
To attack the problem from every angle, Atlassian launched a "champions" program: a cross-functional group tasked with finding and fixing friction points across the organization. The workstream had two focus areas: systems and culture. Systems meant taking stock of existing tools and processes, prioritizing standardization and elimination. The working group found many teams ran redundant pairs of tools—a pattern Schvimmer calls the "Noah's Ark of tooling." Culture meant codifying a set of standards the team would follow to operationalize values and align on metrics. Those metrics indexed on cultivating craft, not just gaining efficiency.
While the working group built the scaffolding, leadership asked every engineering team to set aside 10% of their time for developer productivity initiatives. That gave developers an "ownership stake" in the solution, Schvimmer says. The early results convinced leadership to make developer joy a company-wide effort, one of the Objectives and Key Results (OKRs) that teams still report against every month.
Joy as a business discipline
Making developer joy an OKR meant accepting short-term tradeoffs, like optimizing for engagement over earnings. "You have that short-term revenue itch that'll always be nagging at you," Schvimmer says, "but the discipline rewards itself." He likens it to a 401k—hard to prioritize early, but the benefits compound.
Fixing the tools, addressing process work, and then being clear on what we’re going to measure has yielded results.“Fixing the tools, addressing process work, and then being clear on what we’re going to measure has yielded results.”
Within months, Atlassian saw gains on both quantitative and qualitative measures: a 50% increase in developer satisfaction, a 50% reduction in median pull request cycle time, and a 3x increase in deployment frequency. Internal Customer Satisfaction (CSAT) scores rose from below 50% to 80%. The team also delivered on every customer roadmap item. "Fixing the tools, addressing process work, and then being clear on what we're going to measure has yielded results," says Schvimmer.
From developer joy to team joy
The measurable impact helped rally the organization behind an initiative some initially resisted. "People fund [developer experience] because they understand that they can draw a straight line from that to organizational performance," Schvimmer says, but they may feel uneasy supporting joy. Grounding joy in bottom-line results made the case.
Going forward, a dedicated "developer productivity" team owns 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 Schvimmer. The next step is reaching beyond engineering. "We're focused a lot on developers, rightfully so. 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 could all benefit from expanding developer joy into team joy—elevating not just the processes teams rely on, but the products they ship.
