“It’s time to make coding fun again”
Some of the best code I’ve ever seen was as a young developer at Microsoft working on the Windows NT operating system. I would finish my work for the day, then come back after dinner just to read the kernel. It was so well-written, it was like poetry. Not only did I learn a lot, but the experience of working with it was pure joy.
When I joined Atlassian as CTO about a year ago, I set a goal of helping our 5000+ developers at Atlassian experience that same joy as part of our pursuit of becoming a world-class engineering organization. In truth, the goal isn’t joy for its own sake. The original idea was to improve efficiency across the engineering department. But there’s no point trying to make developers more productive by threatening them with quotas or pressuring them to take shortcuts that will haunt them later.
My leadership team and I made a bet: that joy unlocks productivity. If you constantly have to work around sub-optimal systems and missing information as you code, productivity and creativity suffer. Conversely, being in a state of frictionless flow sets up a virtuous cycle. You’re working quickly, you feel good about what you’re building, and you’re happier as a person. This allows you to pour more energy into the creative aspects of development, as opposed to being frustrated by speed bumps.
This approach is working very well for us so far, and I believe it can work for any engineering organization.
Three pillars for sparking developer joy
We looked for ways to remove friction so our devs can stay in their flow state longer. We asked teams what problems they would fix if they could take time away from working on new features. Ultimately, we arrived at a three-part framework that has proved successful: 1) provide awesome tools; 2) empower teams; 3) foster an amazing engineering culture.
In concert, we defined baseline metrics for overall developer satisfaction, the time between commit and deploy, pull request cycle time, self-serve documentation, and self-serve dependency maintenance. Because you can’t improve what you don’t measure.
Awesome tools
Even before we finalized our baseline metrics, we knew that cycle times for deployments and pull requests were too long, so we looked at our tooling right away. We’ve been setting incremental goals with milestones every few months to maintain a sense of progress and momentum. Some of our latest work in this area includes introducing new automation in the pull request process, migrating to new test libraries, and external service mocking to enable testing against upstream services within a local dev environment. The work is ongoing, and we’re tracking toward a 90% reduction in cycle time for changes in shared services making their way into our biggest products and available to customers.
Other issues we identified stemmed from macro-level changes across the entire tech industry – like the fact that software isn’t just programmed anymore. Today’s software is assembled using fresh code along with hundreds of shared microservices, libraries, and other components. (Most Atlassian products comprise many such components!)
If you need to get up to speed on an unfamiliar microservice so you can use it in a new feature, it can take hours just to locate the documentation you need – if documentation even exists. Or maybe the colleague who knows that microservice lives many time zones away and won’t be online for several hours. Now you’re stuck.
As Atlassian opened up more offices around the globe, then transitioned to a distributed work model, our developers found themselves in this situation more and more. And we knew our customers faced the same struggle. So we built Compass, our developer experience platform, which removes friction by establishing a catalog of all software components, including who owns each one, changelogs, and health-check metrics. Now our developers (and yours) can self-serve information and maintain their flow state.
Empowered teams
We also gave our teams more control over their roadmaps. When we spoke to our dev leads, we found that each team had its own unique blend of issues, but didn’t feel they had permission to spend time fixing them. So my leadership team, along with Atlassian’s co-founders, told our developers to use 10% of their time improving the things that make their day job suck.
For example, before our developer joy initiative, less than 12% of the Confluence team’s pull requests reached production within 48 hours. Through a combination of restructuring their repositories, improving test efficiency, and deployment pipeline automation, they bumped that number up to 31% in just one quarter.
Similarly, the Trello team eliminated 24,000 lines of dead code and adjusted their branching model to reduce code freezes. And one of our central services teams increased their deployment frequency by 300% by eliminating manual approvals for low-risk changes. These are just a few wins we’ve scored by granting teams more latitude and asking them to explicitly set time aside to go fix things.
Amazing engineering culture
We want Atlassian engineering to be known for clean code, an ownership mindset when it comes to quality, and strong agile practices.
On the coding side, I thought back to my days of writing kernel mode code on the Windows NT operating system. The code was rich with comments and supporting documentation that let me understand it on the very first read. That’s not the case with all of Atlassian’s code, so we’re in the process of filling in the blanks.
In concert, we’re building a framework for engineering standards, complete with metrics that will keep us honest. This includes guidance that helps engineers write the right tests at the right time, as well as pulling considerations like security and compliance upstream. We’re educating developers to write code that is secure and compliant from the start so we have fewer rewrites on features that are nearly complete.
But not all our work in this area is so structured. An amazing engineering culture also creates space for developers to learn, experiment, and share. To that end, we’ve run hackathons focused on developer productivity and started a monthly internal newsletter showcasing the progress we’ve made and which improvements we’re working on next. We’re also looking forward to strengthening our “demo culture” by kicking off a weekly showcase with teams presenting projects they’re working on to exchange ideas and focus on iteration.
Better than yesterday, not as good as tomorrow
Developer joy and its side effect, developer productivity, is now part of the everyday conversation within Atlassian engineering. It’s also a company-level OKR, complete with funding and teams empowered to execute on it.
We even created a central team that takes on department-wide projects and then rolls them out to the teams – a hub-and-spoke model. For example, they’ve started rolling out cloud-based development environments. Not only can these be spun up in a few minutes, making onboarding far faster, they also leave laptops free to stream video calls and use collaborative whiteboards while processor-intense operations like compiling are handled in the cloud.
Paying down technical debt and automating manual processes is an ongoing investment. Like joining a gym, it’s a lifestyle change that starts with an initial “get back in shape” push. A year in, our teams are noticeably stronger, moving faster, and have more room to test out new tech. We are especially excited about experimenting with AI tools that will help our developers, like coding assistants, and all the opportunities to build on top of our AI platform.
Developers are indeed finding more joy in their work. When we launched this initiative, developer satisfaction scores were hovering just below 50%. Now we’re on track to hit 71% by September, driven largely by our commitment to empowered teams. This is perhaps the most promising signal of all.
A code base is like a human body in that if you take care of it, it’ll take care of you. If you neglect the upkeep, however, eventually it’s going to break in very painful ways. This isn’t just a project – it’s a lifestyle. There will always be a next step to take. I couldn’t be happier that we’re on the path and have come this far in such a short time.
If you’re interested in helping us build a world-class engineering team and experiencing developer joy for yourself, check out our open roles by visiting our careers page.