Why Atlassian Chose 20% Growth Over Hypergrowth | CEO, Atlassian

We solve people problems. We don't solve technical problems. Most businesses nowadays are technology-driven businesses. We try to connect technology teams with business teams to run business processes.

The very first version of Jira was actually a bug tracker which was definitely for far more technical parts of technical teams. As that got more and more workflow, it became an issue tracker that evolved more and more into a broad workflow engine. So huge amounts of our customers use Jira for no part of software development whatsoever. Large parts of those business processes are going to be automated. I think we're in a world where people go, 'Oh, well the whole process is going to disappear' rather than if I think about it as a flowchart. I'm going to use agent technologies at different points in that process to get rid of this box or that box and then maybe a whole branch. That is largely how things are changing today. And that applies in both technical and non-technical teams. It's not like some robot will show up and just be like sending out emails or whatever. AI is not going to replace human beings. It is a force multiplier for human creativity. It is an accelerant. I'm not worried about being replaced by AI in my job. I'm worried about being replaced by somebody who's really good at using AI in my job.

Look, there's a big question. There's a lot in there. Firstly, most of our tools don't really work with developers. So, it's a little bit of an interesting thing. We have a biased view in the world maybe of what we actually do. I like to say since the start, we solve people problems. We don't solve technical problems, right? We don't really have anything that knows what languages you're writing in or anything else. And developers are a relatively tiny portion of our audience. Technical teams are less than half of our total audience of active users if you like of technology teams. But that's important because it comes to the nature of your question which is firstly what we do is we try to connect technology teams with business teams to run let's call them business processes. It's a big word, workflows, whatever you want to call it at a broad level. Turns out as most businesses nowadays are technology-driven businesses that is incredibly important, right? A bank, an automaker, a drug company, these are really using huge amounts of technology, software, hardware, whatever else to do their fundamental business. And so how their technical teams work and what they build and how they make products and business teams is really important. That's the core of what Jira and Confluence have done for 20 years. And in fact as we've grown there are far more business people in most companies than there are technical people broad as possible, you know, product managers, developers, all of them put together.

No, that's definitely true. It depends on the time frames. Again, we've been around almost 24 years now. 23. I keep saying 23, but it is almost 24.

Yeah, look, we're surviving. So, tick. We always said it was always one of our goals was to be a multi-decade technology company from the very moment we started because we figured that was hard. Every 10 years like right now you get this major technical shift, half the companies disappear, some new ones arrive and some survive and thrive in the new era. So we really wanted to be a multi-decade technology company. And someone asked me the other day on an interview, 'You've succeeded in that,' and I'm like, 'No we haven't.' I'm like, 'I guess we kind of have.' We don't think that we're like, you know, we're not done by any means. But yeah, so Jira, the very first version of Jira was actually a bug tracker which was definitely for far more technical parts of technical teams, so generally software developers, product managers, etc. to store bugs. As that got more and more workflow, and it became what I guess you would term an issue tracker. So, this is like 2002.

That evolved more and more into a broad workflow engine if you might say. So huge amounts of our customers use Jira for no part of software development whatsoever.

No, I'm saying more than half of our users are not in any technical job function.

More than half of our users are in non-technical teams and have been for well over a decade. It doesn't mean we don't love technology teams, don't get me wrong. Our point is you need to get these two groups of people in your company working together. That is the essential ingredient of what we do. In Jira, obviously in projects and issues and workflows, whether that's in product discovery type ways or in Jira Service Management. So I know you guys at Weights and Biases, right? A big Jira Service Management customer for service-driven workflows. Those can be technical or non-technical. Is that an IT DevOps team or is it an HR or finance team? You have the same thing. You have a piece of work that comes in, you have a queue, you need to manage the service alongside it. Confluence also... I will go back to your question. It is a really interesting question. I think it's worth setting that context because if you think about what Jira or what Confluence do, they handle at a high level business processes, right? Large parts of those business processes are going to be automated, quickened, more efficient, more accurate, higher quality by AI agents, LLMs. We see large numbers of our customers doing that already. I would argue in small ways today but you can obviously see it's going to grow. The question is does that entire category disappear? I think that's a question where we largely disagree, right? Or we don't disagree, but like we disagree with the world or what the world seems to believe at the moment. There are massive numbers of business processes that are going to be made better with AI. I don't know there are huge numbers of business processes that are going to completely disappear. And that's weirdly a controversial thing to say. A business is based on a number of people. Their brain power is still important. They're going to have to get together and track things. We've built a series of features recently for assigning work to agents, either our Rovo agents or agents that come from other agentic platforms, be that Salesforce or Google Agent Space or be that from Cursor or GitHub Copilot for example. There are code-writing agents and there are lots of business-writing agents. Being able to assign a piece of work to an agent is a really powerful feature to have in a work management tool. What that agent does is up to the agent. So if I have a marketing project and I assign something off to Writer or one of these startups that can do interesting things in certain domains. Awesome. What happens when that work is done in a business? It's going to come back. It's going to add a file. It's going to send me a link. It's going to add a comment, a piece of text. Maybe another agent picks it up. Maybe a human being picks it up. And maybe that needs to be approved or authorized or sent to another department to print it or to send it out to the world or do something. These business workflows and processes are what I think is the most fascinating part of how AI is going to optimize things. I think we're in a world where people go, 'Oh, well, the whole process is going to disappear' rather than if I think about it as a flowchart. I'm going to use agentic technologies from probably lots of people and LLMs and AI and whatever technology we want to talk about at different points in that process to get rid of this box or that box and then maybe a whole branch. That is largely how things are changing today. And that applies in both technical and non-technical teams, right? You get lots of interesting use cases that are very similar across both.

Yes, for sure. I think this gets to this question around software development. And I think I suspect what we might end up doing is separating the nature of software development from the nature of creating technology. And this gets kind of blurry, right? If you think about what a lot of kids do with their iPhones nowadays, you'd argue they're kind of making technology in a lot of ways, but we don't think of them as software developers. Vibe coding, if we take a definition being a largely non-technical person that can be a product manager that's a little bit technical, it can be a finance professional that's completely, you know, that has never written code, can use AI-driven technologies of various forms to create effectively to write some code and then run some code and create an application or a surface area or a dashboard or whatever it is that they want and there's obviously a huge spectrum of what they can create. I don't think that makes more software developers in the world in and of itself. I don't think suddenly the finance professional who vibe codes something that spits out a big bit of Python that does some analysis and spits out a dashboard like they're not really writing software. They don't think about it in their head. They're solving a problem. They have an issue they need and they're using a piece of technology and they're usually quite happy to throw away that technology. It's not usually super long-lasting. It may eventually be very long-lasting. It depends on the standards we put underneath it. But that is about what I would argue many more people have the ability to create technology to solve their own problems which is awesome, right? That is a huge net positive for society. It's like a force multiplier, right? For human creativity. We have people in marketing who can make websites and basic apps and stuff. We have people in finance who can do really complex analysis that required programmers. It doesn't mean the programmers and developers disappear, that they're suddenly just vibe coding their jobs. So it's going to change how businesses run in a huge way and it's going to be based on the frameworks, right? The problem when you're in the enterprise is you have permissions, you have compliance, you have governance regulations, you have auditing requirements, you have all sorts of standards you have to live to. And so you're going to have lots of these frameworks that aren't about can I make a website and put it on the internet in advance, an application arguably that's on the internet, but how do I do that in a world inside a company and where does it get the data for that application? How is that data secured? We have a lot of frameworks to allow you to do everything from enterprise search to enterprise data organization as a part of our core platform because of all those workflows, right? We can't build an agent without understanding the data layer underneath in a really interesting and deep way.

Massively. Yeah. I mean, Rovo, like maybe we should step back and explain what we've built, I suppose. So we think about ourselves as unleashing the potential of teams through those workflows and business processes that exist in every team, right? We're a collaboration company. We help your organization collaborate on tasks, on content, on everything. We've always been very profligate with other SaaS applications. We, I have a post I wrote internally called 'Links are the shipping containers of the SaaS trade' because I really think a link is the most important fundamental unit. Right? This is a link to a Google doc that tells me so much more about... there is a doc there. It's important to someone. They've connected it to the Jira issue or put it into this Confluence page. Is it a spreadsheet? Is it a doc? This all tells me just from the link itself. It's at Google, you know, it's collaborative. We started maybe six, I think 2019, building what we call the Teamwork Graph. So that is because our applications have many, many links in them to each other and to many other apps right across our 20-odd apps collected in maybe five or 15 collections. They all have a central cloud platform. We track billions of links to other applications. Be it a Google doc, be it a Figma mockup, be it a pull request at GitHub, be it a Salesforce customer record. These links we started to assemble into a big graph. It's now a massive graph. It's north of 100 billion objects and connections and it's going up at like I think it's growing like north of 50% quarter-on-quarter at the moment. The reason for that is the most essential part is how are all these objects floating around in your world connected? We've put all those into the Teamwork Graph. That seems like a simple challenge at the start. Turns out it's very complicated because you have to understand the type of the link. In a technical scenario, if I have an issue in Jira connected to a pull request, I can infer something about that. That pull request is part of a repository. That repository is part of a project. That project is part of a business initiative, etc. That initiative has a spreadsheet. So the types of content are really important in the Teamwork Graph. And obviously, all of that in enterprise has permissions. So, I need to be able to navigate it, surf it, query it, and get things back. Then we add semantic search over the top. That's the core of what we've built into Rovo. So we call it for customers often an enterprise search engine. It's probably one of the biggest if not the biggest enterprise search engine in the world at the moment. And I would also argue it's the best because we spend a lot of time. We have a lot of knowledge to give you great ranking and context on that information. Now 2019 when we started on Teamwork Graph that was because we needed it to connect our workflow applications with all the other SaaS things you were doing. You're starting to use Figma diagrams over here in product management and you started to see IT teams connecting, you know, the Datadog or BigPanda or Splunk reports and you started to see marketing teams connecting into Sales Cloud and so we had all these links and we started to put them into a bigger and bigger graph. It got more and more complicated. Call it 3 years ago when along come LLMs, we have a superpower change moment because we have a graph of all of the objects in your company, your organizational knowledge that's now become your organizational memory. Why does that change? Because now we can understand the content of the document, right? We can use the LLM to get out concepts, definitions. We have a feature that's super popular where you can select any word in Confluence, Jira and just say 'define this word.' Now people don't usually define, I don't know, the word 'progress' or the word 'disruption.' They define the word 'fairy dust' or 'alchemists' because they're like, 'What the [__] is this internal code word mean?' And we can give you a full history and then you can start chatting to it with Rovo Chat. So obviously the graph and the organizational memory is a large-scale permissioned knowledge base of your organization across hundreds of SaaS apps that is at the core of what Rovo is as a piece of technology let's call it for now that sits in the cloud platform. That's the same graph that Jira uses to give you smart ranking in your, you know, of your product features if you're doing backlog management for example. It's the same graph that Confluence uses to say, 'Hey, there's some related content. You might want me to go read the spreadsheet.' It just turns out that AI lets us do very new things in interesting ways. Those features from Rovo already surface in Jira in lots of different ways. So, you know, we said on our last earnings call, we've passed three and a half million AI users. And I still think we're the only public company that's giving out this number because in our world like we again we solve collaboration problems across our platform. Collaboration doesn't happen unless someone's using it. Like collaboration without activity doesn't make any sense to me. So we've always tracked monthly active users as our number one metric. It's not how many customers we have. It's how many seats people have purchased. The gap, what I call the shelfware gap, is if someone's bought 100 seats and they have five now we're in trouble like they're not going to keep buying 100 seats maybe they buy 20 seats right? So we care about activity. Hence in AI we always say we don't want to market AI, we want to ship it. And a lot of people are giving great demos and shipping things and talking about things but they're not actually getting people to use them in organizations. We now have north of, that was a while ago now, three and a half million users every month that come and use our AI features and products. And yes, they can be coming to Rovo Chat to ask a question, you know, 'Hey, what is the history of this piece of the organization?' It might be coming to search and getting AI answers to a question that may come from a Google doc. It may come from anywhere in their organization, but a lot of them are inside of Jira saying, 'Hey, I want you to summarize this issue for me. I want you to tell me what's going on here. I want to assign this issue to an agent. I want to do all of these things.' So, I think the... sorry this is a long answer. I don't think that we're going to end up with kind of AI products and non-AI products. I think we're just going to end up with products. They're all going to be infused with AI. I think you need to think hard about a lot of these elements like the data structures underneath them. What access to information do they have? Because Jira that only has access to Confluence data is nowhere near as useful a workflow and business process engine for a company in project work or in service work as soon as it has access to Figma and Slack and Google Docs and Microsoft Teams and Zoom and all of the history of your organization, all of your Salesforce records, customer records, etc. As soon as we can play with all that information, we can make your workflow a lot better and ostensibly we make those applications a lot better too because we're both driving traffic to them but also changing the way that they can work right in terms of these integrated processes across your SaaS landscape.