Atlassian’s Most Controversial Growth Decision | Mike Cannon-Brookes

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.

Sorry—can I back up for a second? I think of Jira, at least, as having its heritage in a technical ticketing system product.

The very first version of Jira was actually a bug tracker, which was definitely for the more technical parts of technical teams. As that got more and more workflow, it became what you would term an issue tracker, which evolved more and more into a broad workflow engine. Huge numbers of our customers use Jira for no part of software development whatsoever.

Large parts of those business processes are going to be automated, made quicker, more efficient, more accurate, and higher quality by AI agents and LLMs. I think we're in a world where people go, “Oh, well, the whole process is going to disappear,” rather than thinking 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 nontechnical teams.

1. Introduction

It's not like some robot will show up and just start 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.

You're listening to Gradient Descent, a show about making machine learning work in the real world. And I'm your host, Lukas Biewald.

All right. This is a conversation with Mike Cannon-Brookes, the CEO and co-founder of Atlassian, which was one of the very first companies to do PLG, or product-led growth, and is right at the forefront of AI and developer productivity. This is a really fun conversation, and I hope you enjoy it.

One of the things that made me really excited about this interview is that it's rare that you get to talk to one of the creators of tools that you've used for over a decade. I'm intimately familiar with some of your products. I was thinking about your developer tools, like Jira, Confluence, and Bitbucket—the ones I think I'm most familiar with.

We're in this moment where AI is really changing the developer workflow, and I'm sure you're thinking about how those tools might change, or maybe they don't change. What do you think about an AI-assisted workflow? Are there parts of the tools that you think are going to become obsolete? Are there big new blocks of features that might be necessary to support people working with AI? You actually have an AI developer assistant, and there's an explosion of them right now.

Look, that'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, maybe, of what we actually do.

I like to say that, since the start, we solve people problems. We don't solve technical problems. We don't really have anything that knows what languages you're writing in or anything else. 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.

2. Connecting Technology and Business Teams

That's important because it gets to the nature of your question. What we do is 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. It turns out that most businesses nowadays are technology-driven businesses, so that is incredibly important.

A bank, an automaker, or a drug company is really using huge amounts of technology—software, hardware, whatever else—to do its fundamental business. How their technical teams work, what they build, how they make products, and how their business teams work is really important. That's the core of what Jira and Confluence have done for 20 years.

As we've grown, there are far more business people in most companies than there are technical people. Broadly speaking, take product managers, developers, and all of them put together.

Sorry, wait. Can I back up for a second? I'm sorry—I didn't realize that. I thought I knew your company better than I did, but I guess I have a technical lens on it. I think of Jira, at least, as having its heritage in a technical ticketing system product. Is that true, or was it always for a broad base of users?

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

Congrats.

Yeah, look, we're surviving. So, tick.

One of our goals was to be a multidecade technology company from the very moment we started because we figured that was hard. Every 10 years, you get this major technical shift: half the companies disappear, some new ones arrive, and some survive and thrive in the new era.

Someone asked me the other day in an interview, “You've succeeded in that,” and I'm like, “No, we haven't.” Then I'm like, “I guess we kind of have.” We don't think that we're done by any means, but yeah.

The very first version of Jira was actually a bug tracker, which was definitely for the more technical parts of technical teams—generally software developers, product managers, and so on—to store bugs. As that got more and more workflow, it became what I guess you would term an issue tracker. This was around 2002.

What's the difference between a bug tracker and an issue tracker for me? An issue tracker is not just bugs; it's also feature requests. You start to look at future road maps. You have way more programs sitting in a road map, asking, “What sorts of things are we going to build next year and this year?” as well as, “Hey, this thing's broken; we need to fix it.”

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

Did you say more than half—or is that more than half of your users? Are you saying that more than half of your customers have no technical development in their Jira use case?

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

I see.

If you take product managers, designers, developers, network analysts, systems engineers, machine learning engineers—take a big swath of a company and call them technical teams at a broad level—and everybody else, including finance and HR, call them business teams, nontechnical teams, or service teams: HR teams, finance teams, sales teams, marketing teams, and so on. More than half of our users are in nontechnical 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 that you need to get these 2 groups of people in your company working together. That is the essential ingredient of what we do.

In Jira, obviously, you have projects, issues, and workflows, whether that's in Jira Product Discovery-type ways or in Jira. I know you guys at Weights & Biases, right? You're a big Jira Service Management customer for service-driven workflows. Those can be technical or nontechnical. Is that an IT/DevOps team, or is it an HR or finance team? You have the same thing: a piece of work comes in, you have a queue, and you need to manage the service alongside it.

Confluence, obviously—I'll go back to your question. If you think about what Jira or Confluence handle at a high level, they're business processes. Large parts of those business processes are going to be automated, made quicker, more efficient, more accurate, and higher quality by AI agents and LLMs. We see large numbers of our customers doing that already, 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 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 that there are a huge number of business processes that are going to completely disappear. That's weirdly a controversial thing to say.

A business is based on a number of people. Their brainpower 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 AI agents that come from other agentic platforms, be that Salesforce or Google Agentspace, or be that, I don't know, 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.

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 or 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, 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 thinking about it as a flowchart. I'm going to use agentic technologies from probably lots of people, LLMs, 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. It applies in both technical and nontechnical teams, right? You get lots of interesting use cases that are very similar across both.

One of the things that we see at Weights & Biases is that a lot of our customers are more interested in creating their own interfaces. It seems a lot more possible to vibe-code a quick-and-dirty dashboard that's sort of outside of our own product. Do you see that as a trend? We've been thinking a lot about how to make APIs, maybe MCP servers, or these types of interfaces to support customers in that way. Is that something you agree with, or do you feel that trend as well?

Yes, for sure. I think this gets to this question around software development. I suspect what we might end up doing is separating the nature of software development from the nature of creating technology. This gets blurry, right? If you think about what a lot of kids do with their iPhones nowadays, you'd argue they're making technology in a lot of ways, but we don't think of them as software developers.

Vibe coding, if we define it as a largely nontechnical person using AI-driven technologies of various forms, can involve a product manager who's a little bit technical. It can be a finance professional who's completely nontechnical and has never written code, using those technologies to write some code, run some code, and create an application, a surface area, a dashboard, or whatever they want. 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, does some analysis, and spits out a dashboard is really writing software. They don't think about it that way. They're solving a problem. They have an issue they need solved, 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 a force multiplier 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 previously required programmers. It doesn't mean the programmers and developers disappear, or that they're suddenly just vibe-coding their jobs. It's going to change how businesses run in a huge way.

It's going to be based on the frameworks, right? The problem when you're in the enterprise is that you have permissions, compliance, governance, regulations, auditing requirements, and all sorts of standards you have to live up to. You're going to have lots of these frameworks that aren't about, “Can I make a website and put it on the internet?”—an application, arguably, that's on the internet—but, “How do I do that inside a company?”

3. Developer Productivity and AI

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.

So I wanted to ask you: You have Rovo, which looks like essentially an augmenting development application, but I was curious about your more traditional applications, like Jira. Do you feel like AI has opened up a space of new features that you're excited about? Does AI cause you to massively rethink any of the ways that your longstanding products work?

Yes. I mean, with Rovo, maybe we should step back and explain what we've built. We think about ourselves as unleashing the potential of teams through the workflows and business processes that exist in every team, right? We're a collaboration company. We help your organization collaborate on tasks, content, and everything. We've always been very profligate with other SaaS applications.

Mhm.

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 so much just from the link itself. It's at Google, so it's collaborative.

We started what we call the Teamwork Graph about 6 years ago, in 2019. That's because our applications have many, many links in them to each other and to many other apps across our 20-odd apps, collected in maybe 5 or 15 collections. They all have a central cloud platform. We track billions of links to other applications, whether it's a Google Doc, a Figma mockup, a pull request on GitHub, a Salesforce customer record, or something else.

We started assembling these links into a big graph. It's now a massive graph—north of 100 billion objects and connections—and it's growing at, I think, north of 50% quarter on quarter at the moment. The most essential part is understanding how all these objects floating around in your world are connected. We've put all those into the Teamwork Graph.

That seems like a simple challenge at the start. It 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 pull request. That pull request is part of a repository. That repository is part of a project. That project is part of a business initiative, and so on. That initiative has a spreadsheet. The types of content are really important in the Teamwork Graph.

Obviously, all of that in the enterprise has permissions. 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.

We call it, for customers, an enterprise search engine. It's probably one of the biggest, if not the biggest, enterprise search engines in the world at the moment. I would also argue it's the best because we spend a lot of time on it, and we have a lot of knowledge to give you great ranking and context on that information.

In 2019, when we started on the Teamwork Graph, that was because we needed it to connect our workflow applications with all the other SaaS things you were doing. You started using Figma diagrams over here in product management. You started seeing IT teams connecting Datadog, BigPanda, or Splunk reports. You started seeing marketing teams connecting into Sales Cloud. We had all these links, and we started putting them into a bigger and bigger graph. It got more and more complicated.

Call it 3 years ago, when along came LLMs, we had a superpower change moment because we had a graph of all the objects in your company—your organizational knowledge—that had now become your organizational memory. Why does that change? Because now we can understand the content of the document. We can use the LLM to extract concepts and definitions.

We have a feature that's super popular where you can select any word in Confluence or Jira and just say, “Define this word.” People don't usually define the word “progress” or the word “disruption.” They define “fairy dust” or “alchemists” because they're like, “What the fuck does this internal code word mean?” We can give you a full history, and then you can start chatting with it through Rovo Chat.

Obviously, the graph and the organizational memory are 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.

It's the same graph that Jira uses to give you smart ranking 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 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. We said on our last earnings call that we've passed 3.5 million AI MAUs. I still think we're the only public company that's giving out this number because, in our world, we solve collaboration problems across our platform.

Collaboration doesn’t happen unless someone’s using it. 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, or what I call the shelfware gap, is if someone’s bought 100 seats and they have 5 active users. Now we’re in trouble. They’re not going to keep buying 100 seats; maybe they buy 20 seats. So we care about activity.

Hence, in AI, we always say we don’t want to market AI; we want to ship it. A lot of people are giving great demos, shipping things, and talking about things, but they’re not actually getting people to use them in organizations. We now have north of 3.5 million users every month who come and use our AI features and products.

And yes, they might be coming to Rovo Chat to ask a question: “Hey, what is the history of this piece of the organization?” They 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 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 don’t think that we’re going to end up with 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? 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, Slack, Google Docs, Microsoft Teams, Zoom, all of the history of your organization, all of your Salesforce records, customer records, and so on.

As soon as we can play with all that information, we can make your workflow a lot better. Ostensibly, we make those applications a lot better too, because we’re both driving traffic to them and changing the way that they can work in terms of these integrated processes across your staff landscape.

4. Measuring Developer Efficiency

Well, sorry for the focus on developer productivity, but this is my background and something I feel passionate about. I saw that you recently bought a company called DX, which kind of measures developer productivity. On your website, you talk about measuring AI-enabled developer productivity.

I thought that was really interesting because I’ve been wondering, for myself and my team, whether AI is making us more efficient. There was a recent study, I think, where they asked people, “Do you think you’re going to be more efficient?” People said yes. Then, after they used the AIs, they were asked, “Were you more efficient?” That was highly correlated with thinking they were going to be more efficient, but it was actually uncorrelated with being more efficient.

It made me think, “Wow, I probably shouldn’t trust my own perception.” I do feel much more efficient with AI, but that got me thinking: Am I actually more efficient? Are these developers in my organization more efficient? I was wondering, it seems like you would actually have hard metrics on this stuff.

Yeah, for sure. We have the advantage of sitting on arguably the biggest data set of developer efficiency and development team, engineering team, and R&D team efficiency.

I think we sometimes get into two issues here. One is that we talk about developer efficiency as, “How quickly can I write 20 lines of code?” And I’m like, that is a very poor way to measure developer efficiency.

Totally. What we should be measuring is how much customer value I’m shipping per week as an organization across developers, designers, analysts, product managers, and all the people involved in this equation. Are we getting out higher quality or more technology per unit of time? That is ultimately the efficiency we should be aiming for.

And I think, sometimes, firstly, we get into this developer coding question, which is, again, covered by lots of studies. It’s about 1/3 of a developer’s week. Our data would reflect this as well. Again, tens of millions of technical teams show up to use our applications every week, so we have a huge data set that lets us understand trends and how these things are changing.

There’s no doubt, I would argue, that coding speed is improving rapidly. You might argue that if you look back 20 years, it’s been doing so for a long time. If you could graph it, there’d be a step change.

Why is that? Go back 50 years: we were all writing assembly. It was really, really slow to write some unit of functionality and ship it. Now we have Node.js and higher-level languages, JavaScript, TypeScript, and everything else. So, language itself, coding, and AWS—I can spin up a million machines. I can be more efficient.

And so, wait, just to clarify: when you say “coding speed,” do you mean delivering value to customers or something else?

I mean, I have to start with an idea, an issue, or a task. I turn that into a piece of code that’s actual physical characters. That code then needs to be approved, shipped, tested, and deployed at some level to get to customer functionality.

Most of what we’re focusing on at the moment, in a lot of this conversation around developer efficiency, is literally how quickly I can take the task I’m given and turn it into, let’s call it, committed code, tested code, secure code, or something. That is a measure of code speed, maybe, rather than team speed.

Team speed is: Did we build the right thing? Is it good quality? Did customers like it? Were we able to get it deployed? There are a lot of those questions.

Mhm.

And so, you’re saying that code speed has been improving for the last 50 years. You just see this study.

I would argue that as we’ve built better languages, coding speed has improved. We’ve built better tools, right? I knew the JetBrains founders really well. We started in the Java world in the early 2000s—just dating myself, 25 years ago.

I wrote a book on open-source Java programming when I was a teenager. JetBrains brought along a new IDE called IntelliJ IDEA, and it changed my coding. It wasn’t a new language, but the speed and the way it did autocomplete, the way they built these language models—IDEA was absolutely amazing. It was a complete step change.

VS Code has come along. We’ve had lots of language improvements, tool improvements, and other things in the development world for the last 50 years. You would argue that if you could plot some notion of this development speed, it has just kept increasing.

5. Future of AI in Development

I would say we’ve hit an inflection point with code generation. GitHub Copilot has now become Rovo Dev, Cursor, Claude Code, and all the things that generate code. They are massively changing the speed with which we can turn a task into code.

That is awesome. That’s great. Internally, we use all 5 of those tools a lot. We really want to do this. But you then run into a separate problem, which is what DX is trying to solve: Is that perception of value actually there?

You’re also paying a lot of money for it this time around. When we moved to VS Code, or even IDEA, it wasn’t very expensive. I think it was about $50 a head. Now I have the potential to spend thousands of dollars per developer in token costs across all those tools.

I’m like, “Hey, now I really need to know if that’s important and working for me,” because suddenly I have real bills. Tens of millions of dollars could be spent by us every year on these types of tools. I’m happy to spend that if I’m getting value, but I need to understand where the value actually is, which is where DX has been really excelling.

Again, it’s a fantastic company. What they do is look at qualitative and quantitative measures of engineering team efficiency. That’s from a developer to a team to the whole organization.

When we say qualitative and quantitative, it’s really important to combine both. Historically, there are DORA metrics and all sorts of numbers like that. DX has a scheme called DX Core 4, which is, I would argue, better than the DORA metrics. It’s written by some of the original authors of those metrics.

These are numerical, quantitative measures of pull request cycle time and things like this. You need to combine that with qualitative metrics: thoughtfully put-together, researched surveys of your engineering base that are then relative.

When you take qualitative and quantitative measures together, you can find action points. You ask people, you look at numbers, and you see that you seem to be going faster. Then you ask people what sucks about working here, and they’re like, “The build system is horrible. It takes hours.”

When you get enough of those responses, you can be like, “You know what? I think we should fix the build system, because everyone seems to complain about it.” It turns out that if you just ask people what sucks and fix it, it’s probably a better thing for developer productivity than anything else.

At Atlassian, we try to track what we call developer joy. We don’t actually track developer productivity. We kind of do, but we don’t. We track what we call developer joy. Why is that? I believe development is a creative task.

It's a creative profession where you are most productive when you're joyful. You feel in the flow as an engineer. You're like, “Man, I just crushed today. I've built some amazing things. The builds are working. The tests are going smoothly. I'm shipping value.”

I find that you're really joyful in that creative task. You are there. When you're unproductive, you're incredibly unjoyful. The build system's breaking, and the tests aren't working.

So, actually, if I focus on making my developers as happy as possible—and I believe they're mature adults—as in, it's not just, “Hey, I put more sugar in the cupboard,” or [laughter] “I doubled the number of pool tables we have,” right? These are not really measures of true joy and satisfaction in your job. If you got into this job because you want to create software, great. The more software you're creating, the more joyful you'll be.

AI has changed this because we have these interesting things in code generation where, as you pointed out, you measure people's joy and it seems to go up, and then the productivity isn't going up. You're like, “Wait, how come these things have become disconnected?” I think that's just because we, as humans, are going through this learning cycle about these technologies.

6. Core Metrics for Sustainable Growth

You had one of my friends and competitors, I guess, on recently—Arvind from Glean—and he said exactly the right thing at the end, I think, which is that human beings are good at adapting to new technologies. We take a technology, adapt it into our daily lives, and it becomes just the default. We all kind of learn and grow as a species.

That was no different when we came out with the plow, the axe, the laptop, or the phone. We adapted our whole lives around these technologies, became productive as a result, and we never have a point where we're like, “Before and after.” It's kind of a continual loop.

I think AI coding tools at the moment are in that exact space where they feel magical, and because of the magic, you feel like you're super productive: “Oh, look, it wrote code for me.” But when you wrote your own code, you built a mental model of how the thing worked, and then you wrote code. When it spits it out, you now have to rebuild the mental model. So you end up reviewing a lot more code—whether it's in your IDE, just written for you, or in the actual code review—than writing code, and that requires a shift in our mental model, right? So we have to do that.

What DX does now is track not only all the metrics quantitatively, but also the amount of money and time you're spending in different coding tools. So we can tell internally which of those 4 tools—Rovo Dev, Claude Code, Cursor, and GitHub Copilot—we have all 4 for our engineers here—which of them are better and worse ROI-wise and cost-wise, and which of them are getting used more and less.

All of them have thousands of users now at Atlassian. We have R&D orgs with over 10,000 people, so we have lots of statistical data on them: which ones are actually driving different levels of productivity, and also in which areas.

Tell me what you've learned. Can you share some of the insights? This sounds incredibly practical. In what situations would I—

Well, it depends on a lot of different things, and I think what you're going to see is models actually merging as well, right? So you're going to end up seeing a lot of different things as people learn from each other.

If you think about Rovo Dev, our coding agent, we call it a software agent because our job is to take Jira issues and make them into approved pull requests. A merged pull request is a great data signal, in a machine-learning sense, that this code is good.

Totally.

What we've started to do in the Rovo Dev team quite a lot is work on self-reflection. Coding tools are going to make mistakes just like engineers. How do you get the right data in an organizational sense? That's different because we have thousands of repositories and lots of different pieces of code—old code, new code. It's not this lovely greenfield world all the time.

It's like, “Look, I started with nothing and I said I want an app that's like Uber,” and it spat out a mobile app and I'm done. In the real world, that's really hard. So you need a way for all of these coding tools to help themselves reflect, self-improve, and avoid similar mistakes in the future, which, weirdly, is exactly how we teach graduate developers.

Right.

The code review process is really important. Some of the tools—and Rovo is very strong at this, as an example—it sounds like I can speak to my own book, so I can talk about how other tools are much better at finding bugs, maintainability issues, and security issues.

The writing of new code tends to be better in certain tools, and again, it depends on the context that you have. One of the reasons Rovo Dev does really well is because of that Teamwork Graph I talked about beforehand, right?

For example, we know all your pull requests, all of your issues, and all of your repositories in the technical part of the graph. That means when you ask us to go solve an issue or a problem, it can use prior solutions to other issues in other repositories as a way of learning. If it's got all of that context, that turns out to be really important from the technical point of view: how to actually write the code in the style that your company wants.

The second issue is how they get the data context. That usually comes from Google Drive, Confluence, Figma, and other areas where you're like, “Okay, what is the thing we're trying to build?” That's a different part of the graph. So context turns out to be really, really important.

A lot of these things use each other's models. I think we're in the era of AI where everyone's talking about chips—NVIDIA is doing pretty well—and then they're talking about models. We're at the application layer, so we're way above all these layers, trying to deliver customer value.

Our AI gateway has—I’ve lost count now—north of 75 models running in it in production. Rovo Dev, to do a general task, will probably use 2 or 3 models on most turns of the conversation, from different providers. A lot of times, it's using Claude Code as a model, for example; it's using Gemini, because our job is actually to pick the best model for the best task based on the data, rather than just kind of giving you a task.

7. Legacy Technology and Code Changes

I'll tell you another thing that's maybe interesting and that I think is underappreciated. Again, I run an organization with a massive amount of technology—a massive amount of what would be deemed legacy technology, which I don't quite understand this term. But let's just say code that I already have written over the last 20 years. Maybe it was written a year ago; maybe it was written 5 years ago. It's running, it's in production, and it's great. When I make a change, I need to understand all of that in some way in terms of the change.

We have architectural ways of solving this. We come up with microservices, so we have lots of services that contact each other to do all sorts of things: identity, logging, media storage, whatever. Awesome. It's a good cloud platform. Now make a code change.

It's very hard for tools to look at the entirety of Atlassian's code bases and make that code change. That is still many orders of magnitude out of what we are likely to be able to do. However, we've seen with coding agents that this is a really powerful solution set for existing, running businesses. We have tons of examples internally where we use that quite a lot.

As an example, we had an internal service that changed its shape and location. I'm trying to think what the service did. I forget now, but let's just assume it was a REST kind of endpoint and someone was changing the URL, I think. But they weren't only changing the URL, which is kind of find-and-replace; they were actually changing the shape of the request that went to it and how they came back. The API sort of changed in some way—not meaningful, but small.

We had to change more than 500 repositories internally. Sometimes it was configuration; sometimes it was actually the code, depending on how they used the thing. That is a great task to put AI coding agents into, which is very different from what we traditionally think about.

How we did that was by using Rovo Dev, agents, Jira, and things like that. I think we mostly used Rovo Dev to write a few examples of how this worked—maybe 1 in JavaScript, maybe 1 in Java—and commit those examples so you get them into the graph. Now you can say, “Go find me any other place you think I should do this,” and it comes back.

But I think the other learning is that we have a model where we think about human-AI collaboration as the way the world is going to evolve. AI is not going to replace human beings. It is a force multiplier for human creativity. It is an accelerant, not a replacement.

I don't think I'm 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. That is the fear that I have: “Oh man, someone will come along, and they're just better at using AI to get better results.” It's not like some robot will show up and just be sending out emails or whatever.

The technical version of that is that you require this human-AI loop repeatedly. So, in that example, we'd written some examples of how it worked. Then, using the Teamwork Graph and enterprise search, the agents can go off and find other examples and come back and say, “Here's a whole bunch of examples that we think are better and worse.”

Now, there are lots of ways you could say, “Just go write the code,” and it'll give you back 500 pull requests. Then some human goes through them all, and you're like, “Oh, it's applied to that problem.” I worry about an AI code reviewer of AI-written code with no human in the middle. Because if it's off by a few percent and you multiply it through, it's going to be pretty tricky. I worry about the AI-worm, 1980s-equivalent scenarios where it kind of feeds on itself and goes off. Someone's like, “We were 1% off at the start, but after 1,000 loops, we're in trouble.”

So I think those types of tasks where we talk about it as code maintenance—it's a pretty apt term—the analogy to gardening is probably the easiest one. Most of the code creation is where you're saying, “Look, I want a waterfall over there, and I want to put down some rocks, and I want to move around and plant a big tree.” This is landscape architecture. A lot of the day-to-day work is mowing the lawn, taking out the weeds, putting fertilizer on the fruit trees, or whatever it is you need to do. That's what AI can help us do, to get back to some of that landscape architecture.

8. AI's Role in Developer Productivity

All of these things are going to be done in a loop with AI, and I think there are going to be lots of coding models to do that. So, yes, DX is going to really help organizations understand their productivity, both qualitatively and quantitatively, but more importantly, come back with actions on where to improve that, right? Where, to your point, it feels productive and it's not, and where it isn't, and also where you get examples, hopefully, of this productivity. We've done a lot of work on things like accessibility and translation—any of these large-scale tasks where you need to do them across massive code bases. That is where it's really, really helpful.

Mm-hmm. Do you think there are other ways that you're using AI differently from someone like me, where I'm not actually rigorously measuring it? I'm just operating off a general intuition.

That's a good question. I'm not sure. I come from a school of thought that AI can't create. I have to phrase this carefully: AI generating net-new knowledge is a pretty tricky thing. Now, arguably, all knowledge is generated from other knowledge, right? But the idea is, all businesses and all products started with an idea that came from someone—who knows where they got that knowledge from. Yes, they talked to customers. They had a problem they wanted to solve. They came up with an innovative idea for a solution. They've hired a few people. They're trying to go through this world, right?

I think that's one of the reasons why you'll see more developers in 5 years than today. I don't think you'll see these mass layoffs of people like everyone's worried about with this sort of AI-efficiency argument. I'm an optimist. I think you'll see AI applied to creativity to help me do my job better, rather than AI doing it. But it still requires me as a human. We've got to keep the humans in that loop—not because I want to keep humans employed, but because I think that's where we are actually best. That's what will probably end up happening.

People talk about, for example, AI writing the memo for them, writing the document for them. I think we spend a lot more time thinking about how to use AI to help me write the best memo, because it's unlikely that memo—most pages written in Confluence or on whiteboards, or any blog, whatever it is, even if it's an announcement—is just me taking all the knowledge I already had, transforming it, and spitting it out again. This is a great outcome. AI can do that very, very easily, right?

We have all these writing tools and everything else in Confluence today. It's amazing what you can do. And don't get me wrong, these are amazing as a user: “Help me rewrite this paragraph. Make it more pithy. Do this.” This is awesome. You add the Teamwork Graph and your entire organizational memory. You add your personal memory, everything you've done, and in the browser world now you've got everything that you've seen. You add all that, and it can do amazing things, but it's still not going to create raw source knowledge—insights and source knowledge—without your help.

So I think the thing that we would say is, it's about the human-AI collaboration loop. That is very different from just whether that's a workflow or a business process, whether that's a creative process or a new process. The loop between humans and AI is where we should all be looking to accelerate the progress and competitiveness of our business. That is where I don't believe in this magic button, right? There's a button that I hit and it does the work. I give it to the agent, it'll go off and finish the task, and it's done. I think that agent is too trivial.

I think the reality is the agent will go off and do some work like an intern and come back to you and say, “Hey, what do you think?” And you're like, “Ah, I wanted more like this and more like that.” And it'll go off and do it again, right? To do that in teams and collaboration, I can give you some examples.

We showed a demonstration at one of our keynotes that came from a real-world example. In Confluence, you have a really powerful whiteboard feature, and that whiteboard is obviously connected to the Teamwork Graph. So all the knowledge you have from your organization, ranked with an amazing search engine, can come back—all permissioned, data-resident, FedRAMP-compliant, all the things you need it to be.

In the whiteboard, we have a brainstorm agent. You can say, “I want to brainstorm about a topic,” and the better you define the topic, the better the brainstorming will be. It'll go and search your Teamwork Graph, stuff in Microsoft Teams, stuff in Google Docs, stuff in Jira, Confluence, et cetera. It'll do the brainstorm for you, and it'll start filling in the sticky notes on the whiteboard. It's really good. Again, to your point about coding, it looks magical. You're like, “Oh, my God, look at this. This is amazing.”

What's much better, though, and what we showed in the demo, is when the agent has written the brainstorm, the team comes in. Five or six people come in, and they start adding stickies and voting, and they say, “No, this is wrong.” They have discussions, either audio-based discussions in a meeting—Zoom, Teams, whatever—or text-based discussions. They're adding signal to that brainstorm.

Then someone else can go away and take the human signals, the discussions, and the brainstorm to create what starts to be net-new content, right? They write it up as, “What do we need to do in this circumstance?” A different agent can come in on the whiteboard and draw flowcharts, write a document, and spit out a Confluence page. You can do anything you want at that point, right?

Then you might Loom over the top of it. You might record yourself talking to the team and say, “Hey, as a result, I've written this document,” because when I'm recording a Loom, I am adding net-new knowledge. I'm taking what I'm reading and what's in my head. I'm taking the knowledge—AI can't just sap all of our brains. Most of the stuff was never written down; it was communicated in a meeting by 2 people.

So now I've audio-recorded my thoughts on top of the document that came from the brainstorm, but it's another loop of human-AI collaboration. We keep going back and forth. Then I might send the Loom out to my team, and someone might say, “Summarize this Loom for me because I don't have time to watch it, and tell me whether I should watch it.”

That's a task AI is really good at. It's 20 minutes, and that person talks a lot. Can you just give me the CliffsNotes? Give me the 5-minute summary. We can chop a little piece of audio out. All this is great.

What we've done there is taken the knowledge of our organization, summarized it onto the whiteboard, then taken the knowledge of the people we have today and changed the ordering and voting. Then we've used AI to help us write that amazing memo about this task. I've then created a video, so now I've put more knowledge into the system. It's tracked, so if a new person joins tomorrow, they can watch the video, and we're getting this tribal knowledge categorized.

We're using AI and humans to collaborate on improving whatever it is we need to do, rather than the idea that, “Oh, yeah, it'll all happen in some agent.” And don't get me wrong: at each of those loops, the AI will keep improving, the models will keep improving, and our graph will keep improving in its density and speed and quality and breadth. That will all let Rovo give you better and better answers every quarter, as we've done for the last few years.

I just don't think we'll ever reach the point that it disappears. Maybe that's a noncontroversial view. I think in a lot of parts of the world, it's quite controversial that humans are still going to be in charge and needed, and a core part of the collaborative loop to create any new value.

9. AI and Junior Developers

Well, I think it'll definitely be controversial in Silicon Valley right now. So that's great. I guess one thing that I think is starting to get documented, and definitely in the zeitgeist, is that it's harder to get a job as a junior developer. It does kind of seem like some of the stuff that a junior developer would do seems to be getting automated.

From my perspective, we continue to hire junior developers, but we see that it seems easier to hire them right now. The demand seems to have rotated toward more senior folks. Are you seeing that? I mean, obviously, we need a pipeline of developers. We need entry-level positions to have a vibrant developer ecosystem.

Look, I think there are 2 comments, or 2 views of the world, that I disagree with. One is that all developers are going to disappear, or large numbers of them. I think we'll have more developers in 5 years' time at Atlassian than we have today. I spoke with Matt Garman at AWS at an event, and he said exactly the same thing: “I agree with Mike. We're going to have more developers at AWS in 5 years' time than we have today.”

I think the second part of the view is that it's only going to be senior engineers, and I don't agree with that. I don't think that's going to be the case. I can give you a few rational thoughts, although we're all going to have to see how the future plays out. I might be completely wrong.

The rational thoughts for me are a few things. Firstly, the nature of what a senior developer and engineer does has kept evolving, and I think it will continue to do so. There's no doubt that skill plus knowledge plus wisdom plus experience gives you a better engineer, and that has to be gained somehow. Those senior engineers do keep evolving, right?

We used to have a lot of senior engineers who were really good at building on-premises software. 15 years ago, we started the cloud, and we had nobody who was very good at it. Now almost all our senior engineers would be extreme experts on cloud and service-based development. They've learned new skills along the way. One of the exciting things about being in the technology industry is that we're always learning new skills because the technology world keeps improving.

I do think what doesn't change about senior engineers is that they cost more than junior engineers. There is always going to be a case where you say, “You know what? I'm going to pair 1 senior, experienced, wise person with 4 or 5 more junior, less experienced, less wise people, and then they get experience.”

I don't think the idea that AI is just going to replace that makes any sense, because the idea is that only the senior people could use the AI. I'm like, wait, don't I want junior people—graduate, first-year graduate developers—to come in and perform way better than graduates did 10 years ago? Why? Because they've got AI coding tools.

Now, I need the wisdom. I believe I need the senior engineers to look at their code and say, “Hey, mate, it looks like you just used Claude Code to spit out a bunch of stuff and committed it.” Developer accountability is low, right? We spend a lot of time on developer accountability. If you commit code, you're accountable for it. I don't care—there's no “Rovo wrote that” or “Cursor wrote that.” Those are not excuses that you're allowed to use.

You're accountable when you commit it. The same goes for approving a pull request: you're accountable for the reviews. You can't say, “I looked through it, and all the security agents seemed to say it was fine, so I ticked the approved box.” The senior developer needs to talk to them about human accountability and developer accountability for their code.

I would also contend—it's interesting—we've seen this in Loom. I have lots of data points from Loom. I don't know if I have as many in the engineering sense yet. What happened in Loom was that graduates new to the workforce were much more video-centric, probably because they'd been Snapchatting and FaceTiming their lives for their teenage years.

When they came into the workforce, they were like, “Why do we all sit in a meeting? It's a synchronous operation with a bunch of people and 1 dude talking. Why am I wasting my hour?” I'm not sure they thought about it as systematically as this, but that's effectively what happened.

You saw a lot of Loom entering businesses. The juniors who were used to opening a window, recording a little video like this, and sending it to someone were like, “Sweet, I didn't need a meeting.” This comes in, and then people in the organization go, “Oh, the kids are onto something.” That was pretty efficient. I liked just watching that, and I liked not turning up to that meeting.

20% of meetings are useful. 80% of them don't need to happen. Whatever—you can pick your own number in your own business. But this was brought in by the younger folk, let's just say, who then changed the nature of the organization. It wasn't that the senior person didn't understand it; they just had no experience. They were busy. They were doing their work. Once they see it, they can adopt it.

10. Product-Led Growth and Business Strategy

Slightly switching gears, there's something I really want to ask you. I've had a board member at Weights & Biases for a long time, Jay Simons, who I think was an executive of yours, and he told me a lot of stories about you. You had contrarian views on a lot of things, like not having a sales team and not discounting. These are really interesting. I feel like you're maybe the first company to really do what they call product-led growth now.

One of the stories that was memorable to me is that apparently you or your executive team, in a board meeting, were like, “Hey, we don't want to grow too fast here. We want to steadily double or something like that, and not necessarily grow the top line as fast as we possibly can.” That caused some consternation. Is that an accurate story of something that happened?

I wonder what your thoughts are, because now there's such a premium on fast growth. I feel like there are so many posts about how a company went from $1 million to $100 million in revenue in 2 years or something. It's almost like a competition of speed that I've never seen before. I'm curious if you have a take there.

I have a lot of takes there. Firstly, a lot of the fast-growth numbers we hear are amazing. It's never been easier to build a fast-growing business and get from $0 to $100 million ARR. When we first had the inkling that maybe we could go public, around 2010, we were probably 8 or 9 years old as a business. I think we were doing, call it, $50 million in revenue and probably $20 million in profit, growing 50% a year.

We thought, “Geez, maybe we could go public.” That was never a dream. It wasn't like we sat there in Sydney and said, “Going public is the thing I want to do.” It was more like, “That's a possibility.” At that time, you needed about $100 million in revenue to go public. That was sort of the line for a public company for a while.

Things shift. We had billion-dollar companies; now we have trillion-dollar companies. There's a bunch of trillion-dollar companies. Part of it is just the natural shifting of things. Secondly, there's no doubt that between AWS and cloud computing, payment systems, SaaS, and the ability to distribute via app stores, there are all sorts of reasons why we can distribute great software faster. We have much more knowledge of charging for it, so this is all awesome.

I think we have a success bias in technology around celebrating the people who went from $0 to $100 million faster. There are a lot of companies out there that go from $0 to $0. I don't know that there are any fewer of those statistically; we just don't talk about them. It feels like everyone is doing it, and then it creates this mental-health stress. I see people saying, “Man, I didn't get to $100 million in revenue in 2 years. I must suck.”

I'm like, “Geez, it's tough to be a founder nowadays. That's rough. Are you building something? Are you solving a problem? Do you have customers who like your thing and a reasonable model for growing? Slow down, mate. Start there.” Don't count yourself out because you're not on this crazy journey.

There are a lot of those companies from my era—I would say the early 2000s, and even, you might argue, the 2010 range, 2008 to 2012 or 2013. A lot of great businesses were founded that were growing fast, and they're now just iconic companies that we don't think about. I would tell those founders: just build things that people need, figure out a good model for distributing them, and grow their business.

Secondly, yes, for all time, or a lot of the time, we don't try to grow as fast as we can in any given time period. That is not, I don't think, a smart business goal for maybe any business. It's not a smart business goal for us; I just talk about us.

As I said, we wanted to be a multidecade company from the start. We want to grow longer, not grow faster. That's our sort of weird goal, and it always has been. We just finished our last quarter. We grew revenue 20-and-change percent—21%, I believe. Our cloud business, which is our largest business, grew 26%.

Our RPO, our remaining performance obligations—the future revenue that we have contracted but has not yet come into the 12-month revenue—grew 40%. We're a $5.6 billion business, and that was more than a billion-dollar-and-change quarter. I think you'd argue we're still growing strongly as a business. But I still don't want to maximize next quarter's revenue growth.

Now, any investors out there freaking out, let me explain why: I don't think that's a smart thing that investors should ask for.

I think no founder should look for that. What you want is sustainable, long-term growth. Any great business has to have a sustainable, long-term growth model.

Which means, if you have some amount of resources in your business, play the $10 game. You have $10 worth of resources to put toward something this quarter. You could put all $10 toward maximizing revenue for the next quarter, but then what are you going to do? It's really hard. You're not going to invest in the architecture that will allow you to survive the AI disruption. You're not going to invest in all these other things.

So, you always have to create a balance. At some level, it's a truism. The problem is when you get to that line-ball decision: short-term revenue growth versus continued growth, right? I want to build durable businesses that will grow at north of 20–30% 5 years from now. That's what I want people thinking about, because it's going to mean we're a long-term-thinking company.

It's going to mean we're evolving and growing. We're also making the hard decisions today that are probably short-term disruptive. If you continue to do that, if you take that and keep repeating it, you build an amazing business. I think if you look at most of the amazing businesses out there, that's actually how they think.

Amazon is one of the canonical examples. They're the best at amazing business: investing in infrastructure, investing in warehousing and logistics, investing in lots of strategic things for a long-term period, because they want to think, “How am I going to grow 4 years from now, and where's it going to come from?”

I think sometimes we get very short-term in the founder sphere. Even “$100 million in 2 years”—it's like, well, tell me where they are then. Do we think they're going to be a real multibillion-dollar business in 10 years? That's far more impressive to me than looking at the systems thinking that goes behind the logic of how they'll get there.

I've been lucky enough to meet arguably many of the best entrepreneurs of my generation. Many of them are friends of mine. A common trait among all of them is something like that: They generally don't care much about money. They generally have a delayed-gratification gene in a business sense.

They wanted to build a really great business, but “great” to them is solving distribution, solving business-model, architecture, engineering, and R&D problems, solving customer problems, and doing all that in a way that, in 2 years' time, we have a better way of solving the 4-year problem. It becomes a sort of second-derivative problem that they end up solving, almost whichever discipline they're in.

I think that's all Jay's saying: He was a large part of architecting this thinking. So, it's kind of ironic. As our president for a decade or more, he buys into this too, right?

11. The Impact of AI on Business Workflows

I think one reason people focus on revenue is because it's so easy to measure, and it's kind of a way to create accountability. One thing that you said earlier that I really liked, but I didn't want to cut you off, was measuring monthly active users. That's something we do, too, because it's closer to the question, “Is somebody getting value out of what we're doing?”

Are there other core metrics that you look at to know whether you're having sustainable growth, or leading indicators that you're able to grow revenue over a long period of time?

Look, there are none that are that simple, I would say. We track religiously. We have many, many orders. Even just tracking MAU, I would argue, by itself, there are many second- and third-order metrics inside of MAU.

We look at MCU, which we call monthly collaborative users. I actually don't know what it stands for; we just call it MCU everywhere. If you think about Confluence as a system, I might have—I'd have to look up Weights & Biases' numbers; they would have been more interesting—but I might have 500 people in a given company. It's a 1,000-person company, and they have 1,000 seats. Great. I might have 500 or 600 MAU every month. That's a pretty good ratio, to be honest. That's awesome: a 60% MAU ratio to seats. The company's doing well.

Inside those 600 people, though, I think, “What are they doing?” A lot of them are coming in and reading content. A lot of them are coming in and writing content. They're creating new pages for other people to read. Somewhere in the middle is collaboration: They're adding comments, inline comments, and page comments; they're reacting to it; they're linking to it from somewhere else; and so on.

Even inside MAU, you'd be like, “Okay, cool. We just get more readers.” And you're like, “Well, that's actually not going to help us, because we need to create the content in a system like Confluence. It's going to be different in a workflow system like Jira, and different in Loom's case.”

You're trying to understand: What is a core user of the product? Who is the person creating new content? Are they creating it and sharing it? This gets to a viral-loop notion. I would argue that in any product, you need to think about who your core users of the usage value are.

Then you need to think about the people we look at in terms of the deployment and distribution angle. In our world, in the enterprise, you have a lot of gatekeepers. You might have IT professionals whose job is to say, “Is this secure enough? Is this compliant enough? I'm not going to roll it out.”

It's not just people finding an application and adopting it. We've got to think about whether the IT fraternity is happy with us in terms of security, compliance, governance, controls, and rolling it out. Do we give them analytics and usage numbers? We try to look at the different core groups. It's not just a 1,000-person company; there are a lot of subgroups, even inside MAU, that we need to care about.

Obviously, any business has some form of a funnel. Product-led growth is easy to measure through that funnel: How many people came to a site, clicked some sort of trial button, and did that turn into usage? We have 7-day usage, D30, 2D30—whatever numbers you want to look at. We've got all of them in different spots.

Basically, you're looking at some funnel and asking, “Did they come back?” Those are really important numbers. I think inside the sales world, there are also a lot of these other numbers, right?

We talk about pipeline at a generic level. Pipeline is how many people are interested in our products in the future. It's a good example of growing faster or growing longer. Does your sales team spend more time thinking about the multiyear pipeline, or do they spend more time looking at this quarter's numbers?

Arguably, this quarter's numbers came from the multiyear pipeline from 2 years ago, but you can't change that now. Where do you put your ratio, and how does your reporting work on the longer-term number? There's pipeline for next quarter, and then there's pipeline for next year. You want to arguably spend time with your future customers and make them happy. That's the best way to plant those seeds that you can then grow.

One of the things my co-founder, who retired last year, was very keen on is that you've got to manage, in any business, the difference between seeding and harvesting. The obvious farming analogy is that you spread out your seeds once a year, and then you harvest them, and then you go into an empty field. I don't know.

You're generally seeding in some areas. You're trying to have multiple crops or multiple parts so you can spread your revenue out. If you harvest continually, or if you're in a forest—if you're logging or something, hopefully sustainable logging—but if you're doing some sort of logging, cutting things down, you're cutting down more trees than are growing. You're going to run into trouble, right?

There's a really awesome book called A Short History of Progress, which is all about humanity and groups of humans and their challenges: Are they living off the interest of whatever resources they have, or are they living off the principal? Do they even know when they flip from one to the other?

That's a really applicable business lesson, I would argue, for seeding versus harvesting. Whatever metrics you're getting, are those metrics measuring whether you're seeding future growth, or are you harvesting growth from seeds that someone else planted?

It's very easy to measure the harvesting: How many tons of wheat did I collect today? Let's just harvest some more. At some point, you realize the fields are barren, and you say, “Great. Who seeded it?” And then, “Well, nobody did. We didn't do that.”

A lot of these business metrics would arguably be trying to measure the source of the funnel, or the seeding work, and treating that very carefully when it's not related to your revenue outcome, and then having clear connectivity through to the revenue outcome. In an ideal world, you have perfect clarity.

Usually, humans come in with a lot of intuition to say, “I'm just really worried, guys, that we're not focused enough on this area.” Maybe AI will just replace us all. I just don't think so. I think AI will generate a lot of reports. Humans need to interpret them and then go back and collaborate, and we're back in the same loop.

12. Staying Creative in the Tech Industry

All right. Well, Mike, I'm getting pinged by your team to wrap this up, but we can end on that note. Let me ask you another one I'm curious about. You should probably be quick because I'm told to wrap it up, but how do you—you're 20-plus years in, and I was just curious—how do you stay creative and curious at this point in your career, or is it effortless?

I wouldn't say it's effortless.

At the same time, I don't think it's a massive amount of effort. I think if you want to be in the technology industry, curiosity, change, asking the right questions, and creating things—that is the fundamental nature of our industry, right? It's a very organic industry.

Totally. Great way to end, man. Thanks, Mike. Really appreciate it.

Pleasure.

Thanks so much for listening to this episode of Gradient Descent. Please stay tuned for future episodes.