Atlassian’s CTO on Scaling AI While Fueling ‘Developer Joy’
It seems like every company is in rush to fit AI into their product. But what does that actually look like at scale? How can you move fast without breaking all the things? Without breaking the bank on cloud bills?
At the end of 2023, Atlassian leadership brainstormed an AI wishlist for their suite of productivity tooling. Within six months — and with the help of about 400 engineers and an AI bootcamp — AI-powered Rovo was integrated within all Atlassian tooling plus third-party SaaS across the entire extreme dogfooding organization.
Soon after, with tight feedback cycles in place, Rovo Search, Rovo Chat and Rovo Agents were launched to about a thousand customers and partners. Less than 18 months after its inception, Rovo Agents is now being rolled out to Atlassian’s 300,000 customers worldwide, at no extra cost.
That’s fast even by the tech industry’s standards.
The New Stack sat down in April with Atlassian CTO Rajeev Rajan at the company’s Team ’25 conference in Anaheim, Calif. In this exclusive interview, Rajan reflected on his last three years leading the team of almost 10,000 engineers, with developer joy and an expensive bet on AI dominating the culture and technical strategy.
The New Stack: Atlassian famously measures developer joy. When and why did that come about?
Rajeev Rajan: I’ve been an engineer throughout my career. I loved writing code. The joy you get when you write code and you see something work is what got me hooked into coding and being a software engineer.
I’ve been in many teams, in many different companies, where developer productivity can get blocked or developer joy can get lost because of different things.
When I came to Atlassian, I found that [where] developer productivity was a problem, engineers weren’t happy. They weren’t as productive. They were running into issues — in the monolithic codebases. Even Jira has been around for 20 years. The tools were not working as well.
So as I came in, I talked to [Atlassian founders] Mike [Cannon-Brookes] and Scott [Farquhar], and I talked to engineers around the world. I realized that this is a problem and it needs a solution. And luckily, I’ve seen this before in other places, and there’s a certain pattern to it.
So we set about creating a program around developer productivity. And we had issues in both inner loop and outer loop. So we set about setting some quantitative measures in terms of issue cycle time, [pull request] cycle time, DORA metrics.
Then I felt, having been an engineer and talking to folks, we should not just measure these numbers. That’s the developer joy part:
- Are you happy writing code?
- Are you happy building things in Atlassian?
To me, that’s very important. I want engineers who are super excited, who wake up the morning and they’re like: I want to go and write this piece of code, because it’s fun, it’s exciting.
To measure that joy, we surveyed all our engineers, and asked them simple questions:
- Are you productive writing code in your codebase?
- Do you have problems with the tooling?
The first survey we did, I think two and a half years ago, the score was 49%, meaning less than 50% of engineers in Atlassian were satisfied or joyful about their writing code.
We just did the last survey. We do this every three months. The last one scored 75%. That’s a pretty big uptick in what we call developer joy. And the quantitative metrics have also gone up by many measures — 66% more PRs. We have doubled the productivity of our engineers in Atlassian over this three-year period.
When you say 66%, have you done a large hiring spree or acquired another company?
We have had some hiring, but not doubled the number of engineers. If you go back and look at per engineer, we have probably 2x [output] per engineer. In Team ’23 we announced Build, shipped 500 features. Team ’24 we did 1,000 features, right? And Team ’25, now we are doing 1,400 features.
What do you do with all these developer survey responses?
The whole developer productivity program has three pillars to it:
- Awesome tools.
- Modern codebases.
- Empower teams.
Some of the codebases were old, needed to be refactored, modernized. Some of the tech stacks where people were using too many different things — let’s standardize on a fewer set of stacks.
So we did some of that. And the third one — which is very popular, by the way — we call it “empower teams.”
For empower teams, as a team, you get back 10 to 20% of your engineering budget to go fix the things that bother you every day. Because there’s no single problem that bothers everybody. Giving every team back some permission to go and ask:
- What bugs you the most?
- What are the top five things that make you not have joy?
Go fix those. Six months later, there’s a new list of five things. Go fix those, rinse and repeat. And soon you find the potholes are getting fixed and lights are working, and the joy comes back. Because you’re no longer getting stuck.
The biggest thing that spoils joy is you’re writing code and you get blocked. You get blocked because you can’t make progress on a component, or you don’t understand the APIs, or somebody you need to talk to is in a different timezone and they’re asleep.
One of the things we’ve done for that is we have a product called Compass [internal developer platform] that we built internally. First for our own use, but now we ship it as a product. If you’re a developer, and you get blocked, go to Compass. Every single component and microservice that we use in Atlassian is there.
It’s basically your [internal developer platform] and a registry or repository of all of the components out there — the APIs, the documentation, the on-call roster, etc. You’ll get a whole bunch of information, and more likely than not, you can get unblocked and keep working.
If you’re a classic engineer, at 2 a.m. writing code, you don’t want to get blocked — that’s the thing that kills developer joy. Because when you’re in the flow of writing code and building things, you don’t want to get stuck because you don’t know what to do next. Or something’s not working for you or a tool’s not working right. So, because of our distributed workforce, we’ve tried to make it so that, you can do a lot of work async, without having to get to meetings.
Rovo is currently being rolled out to millions of users. How did you build this massive AI integration in a matter of months?
The story of Rovo is that we went from concept to something being available in less than six months. Around December 2023, we had a brainstorm — me, Mike and Anu [Bharadwaj, Atlassian president] — about what we could do with AI. January 2nd [2024], I pulled together my leaders: This is Rovo. It’s going to be great.
We pulled together like 400 engineers, and we got going on it. And in less than six months, we had most of what you see in Rovo up and running. And then, of course, it took a couple more months to actually make it generally available, but with super-fast execution.
A few things that worked in our favor. When I came in three years ago, one of the things I kicked off is — along with developer productivity being a pillar — the notion that we are here to build a world-class engineering team at Atlassian. Aspiration is far beyond being the Jira and Confluence company for engineers, to being the system of work for all employees and all companies.
We had a good engineering team, but to get it to world-class, playing in the same leagues as some of the big names that you see today, we needed some up-leveling of talent and practices and development productivity. We hired a bunch of really good AI/[machine learning] folks, people who had done search and AI and AI agent studios before.
Plus we took our some of our best engineers already in Atlassian and put them through AI school, [which] we modeled on Stanford University’s 16-week course. You go through the 16-week course, you come out an AI/ML engineer.
How can you shore that up and scale at such an exponential rate? It sounds like an exorbitant cloud bill.
With AWS, the advantage is they have good elasticity and scale.
Then it comes down to the architecture and to the fact that some of the people you’ve hired have built search engines for like 10, 15, 20 years.
When we built Rovo Search, we didn’t build it as a dinky toy. We built it like, this is going to run for the whole world. For every enterprise. Architecturally, we built it so that search and chat, AI agents, etc., can scale to the maximum limit.
In the last few months, we had to actually put it through its paces, [as] if we’re running it for 300,000 customers, as opposed to 1,000 customers. So, chaos engineering simulations and stressing out the models to say, “OK, if you had this, how much does it cost us?” So we do understand what that looks like in terms of the cost, billing and capacity in AWS.
Architecturally, we had already built it to be able to scale.
We then asked:
- What performance are we going to be able to give?
- What’s the reliability like in terms of the stability of the code?
We did some analysis to understand some of the weak points that we needed to go shore up. Let’s put 10 engineers there, 10 engineers there, and let’s go fix that up.
It’s still a very expensive bet that you’re giving Rovo away for free, even if that increases stickiness with your current customers.
We understand the cost. If we have a ton of people using it, and that’s going to cost us more in the short term, that’s actually a good problem to have. Because what we are after is usage and adoption and value.
We have no worries about being able to monetize this long term. What we feel very strongly about is that Atlassian is one of the few players who actually have a very good AI story that I think will resonate with our customers a lot, and we are really interested in unlocking that value. We’re not interested in making a quick buck on AI in the next year or two. We always say we’re a 100-year company — here for the long haul.
In this whole AI game, there will be a few winners that stand out. And we want to be on that list. We don’t want to put a bunch of paywalls and prematurely make some small amounts of money and not have the usage.
We believe we are one of the few players who can win this whole thing, because we have built something we think is phenomenal, and we want our customers to experience it. So we’re willing to take that hit.
The other part of the equation is on the broader R&D. We’ve made a lot of progress in FinOps. We have really fine-tuned our engineering in our usage of AWS, our usage of all of the different compute and storage.
What’s the motivation around the recent price change for Rovo?
When we made Rovo generally available last October, our plan was to ship Rovo as $20 per user per month. Quickly, what happened with all of the companies is, we realized that we’re so early in the AI usage journey that perhaps a better strategy is to give it away, because you want to get adoption first.
We’re less worried about monetization in the short term. We want to figure out what works. Let’s give it away [or charge $5 per non-Atlassian user per month.] Then figure out things, like, “Oh, these are the five things that really work well, both for our customers and for us.”
And at that point, we can figure out, we’re going to monetize this way — a certain number of searches and chats and agent stuff is free, but, if you’re really using it a whole lot and you’re getting a lot of value out of it, then we’ll charge you for that value. And customers then will be willing to pay, because they’ll be like, “OK, this is valuable for me. I understand paying for it.” As opposed to, we sell a bunch of AI and we make a bunch of money, and customers are like, “Oh, it’s not doing anything for me.”
We went from Rovo is going to be used by a few thousand customers to now all 300,000 customers are going to have unified search anywhere in Atlassian, whether it’s in Confluence, Jira or Loom, or any of our other products or third-party apps.
We are going to turn on for premium and enterprise customers by end of June, and then I think standard customers by end of September. It’s a pretty amazing technical feat to be able to go through that.
Since you’re an extreme dogfooding company, how has developer experience changed or improved?
A big part of it is Rovo. It really moved the dial on documentation. For a long time, the bane of developers is: I can’t find documentation for this API or for this code piece or this component. And that is one question on our [quarterly developer] survey that’s had the biggest jump — like 10 or 15 points. Because people are just able to find stuff, and they’re able to understand the code a lot better with Rovo.
The other part of it that’s really improving is, with coding agents that we have built, we have seen an increase of 45% in PR cycle time because of coding assistance and automatic code review agents.
We are seeing our own developer productivity has gone up. And then, of course they are happy on that survey.
