Software development has become more complex in the last 10 years with the introduction of the cloud, containerization and microservices – not to mention increased attention to security and governance. All of which falls on developers to manage.
On the surface, this seems like a sensible way to keep engineering organizations lean. But it comes with a price. The increased cognitive load combined with less time for actual coding turns what should be an exciting job into a series of chores.
As CTO of Atlassian, my goal is to build a world-class engineering organization. I want our team of 5,000+ developers to be productive, sure. But more than that, I want them to experience the joy of creation and a sense of pride in their work.
So, my leadership team and I made a strategic bet. We wagered that unlocking developer joy would, in turn, unlock productivity. It’s paying off so far, and I believe it’s an approach that can work for any engineering organization.
Where is the Love?
To be clear, the goal isn’t joy for its own sake. It’s joy in the service of improving productivity across the engineering department. Because it’s not as if developers are inherently lazy, they want to perform at a world-class level. So what’s getting in their way?
Unsurprisingly, our devs knew exactly what was slowing them down: Brittle systems in need of some major TLC, lack of time to fix them and fundamental best practices that had fallen by the wayside. It was papercut after papercut, sapping the energy from even our most enthusiastic engineers.
With that in mind, we looked for ways to remove friction so our devs could stay in their flow state longer. We ultimately arrived at a three-part framework that has proved successful. 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. You can’t improve what you don’t measure, after all.
Part One: Provide Awesome Tools
Even before we finalized our baseline metrics, we knew that cycle times for deployments and pull requests were too long. Other issues we identified stemmed from macro-level changes across the industry. Like the fact that increasingly a lot of software is assembled from existing components, we believe this trend will only increase over time.
Most SaaS products, Atlassian’s included, comprise hundreds of microservices, libraries and other components woven together with fresh code. If you need to get up to speed on an unfamiliar microservice, it can take hours to locate the documentation or wait for a colleague several time zones away to come online.
We built Compass to solve this. It removes friction by establishing a self-serve catalog of all software components, including who owns each one, changelogs and health-check metrics. Other 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.
We’ve set incremental goals with milestones every few months to maintain a sense of progress and momentum. As of now, we’re tracking toward a 90% reduction in the time it takes for changes in shared services to make their way into individual products.
Part Two: Empower Teams to be the Change They Seek
Our developers were well aware of the issues slowing them down but didn’t feel they had permission to spend time fixing them. So my leadership team, with support from Atlassian’s co-founders, told our development teams to use 10% of their time removing speed bumps.
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 obsolete code and adjusted their branching model to reduce code freezes. Another team 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 fix things.
Part Three: Foster an 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 working 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 modernizing our code base and documentation.
We’re also building a framework for engineering standards. 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 want secure and compliant code from the start so we have fewer rewrites on nearly complete features.
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. We’re also strengthening our “demo culture” with a weekly showcase where teams present projects they’re working on, exchange ideas and generally catalyze innovation.
Continuous Improvement for the Win
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 a central team that takes on department-wide projects and then rolls them out to the teams.
A year in, our teams are noticeably stronger, moving faster and have more room to test out new tech. (We’re especially excited about our experiments with AI tools like coding assistants and all the opportunities to build on top of our AI platform.) And we can see this in the data. At the start of this initiative, only 50% of our developers reported being satisfied with their work environment. Now, our internal surveys show that number hovers around 70%.
A code base is like a human body; 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 toward greater developer joy and have come this far in such a short time.