What a $42B Software Co. Really Spends on AI Tools

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.

Well, sorry, wait, can I back up for a second? Then I think of Jira, at least as it's like heritage, coming from like a technical ticketing system product.

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 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 gonna disappear.

Rather than if I think about it as a flowchart, I'm gonna use agentic 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 Ru- 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 Dissent, 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. All right, well, so, like, you know, one of the things that made me really excited about this, um, interview is it's, uh, rare that you get to talk to some of the creative tools that you've used for, like, over a decade.

So I'm intimately familiar with, uh, with some of your products. And I mean, just to get right into it, I I was thinking about your, you know, the developer tools that you make, like, you know, Jira and Confluence and Bitbucket, you know, the ones that I think I'm most familiar with. And, you know, I was thinking, like, okay, like, wow, we're in this moment where AI is really changing the developer workflow. And I'm sure you're thinking about, like, how those tools, you know, might change, or or maybe they don't change.

But like, what do you think about, like, in a, in a AI assist AI assisted workflow? Are there parts of the tools that you think are gonna become obsolete? Are there, like, big new blocks of features that, like, might be necessary to support, um, you know, people working with, like, um, yeah, actually, you have an AI developer assistant, or or, or there's explosion of them right now.

Hm, hm, uh, look, there's a big question. There's a lot in there. Um, firstly, most most of our tools don't really work with developers, so it's a little bit of an interesting thing. We have a a h- a biased view in the world, maybe of what we actually do. Um, I I like to say since the start, we we've solved we solve people problems, we don't solve technical problems, right? Uh, we don't really have anything that knows what language you're writing in or anything else.

Uh, and developers are a relatively tiny portion of audience. Technical teams are a less than half of our our total audience of of, uh, 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 wanna call, at a broad level.

Um, 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 how they connect with business teams is really important. That's the core of what Jira and Confluence have done for 20 years. Uh, and in fact, it's as rep as we've grown, there are far more business people in most companies than there are technical people, broadest possible, you know, product managers, developers, all them put together.

Um,

Well, sorry, wait, can I back up for a second then? So that's I'm sorry that I I don't realize that. I think I thought I knew your company better than I did, but I guess I have, like, a technical lens on it. Like, eh, I I think of Jira, at least as it's like heritage, coming from like a technical ticketing system product. Is is that true, or was it kind of always, uh, for a broad base of of users?

no, that's no, that's definitely true. The it depends on the time frames again. Uh, we've been around twenty, almost twenty four years now, twenty three. I ke- I keep saying twenty three, but it is almost twenty four. Congrats. Um, uh, yeah, look, we're surviving, so tick. Um, we always said, uh, 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. But every ten 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 in an interview, You've succeeded in that? And I'm like, No, we haven't. I'm like, I guess we kinda have. We don't think of that. We're like, you know, we're not done by any means. But, uh, yeah, so Jira, the very first version of Jira, was actually a bug tracker, which was definitely for, uh, far more technical parts of technical teams, so generally software developers, product managers, et cetera, to store bugs.

Uh, as that got more and more workflow, um, and it became what I guess you would term an issue tracker. So this is like 2002, um, what's the difference between a bug tracker and an issue tracker? For me, an issue tracker is not just bugs, but it's like feature requests. You start to look at future roadmaps, so you have way more programmers saying, in a roadmap, like, what sorts of things are we gonna build next year and this year?

And as well as, hey, this thing's broken, we need to fix it. Um, 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.

And did you say more than half, or is that more than half? Use are you saying more than half of your customers? There's no technical development in their Jira use case?

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

I see.

So if you take product managers, designers, developers, network analysts, system engineers, machine learning engineers, you know, take a take a big swath of a company and call them technical teams at a broad level, and everybody else, so finance, HR, et cetera, call them business teams, non-technical teams, service teams, HR teams, finance teams, sales teams, marketing teams, et cetera. More than half of our users are in non-technical teams, uh, and have been for well over a decade.

Um, it doesn't mean we don't love technology teams, don't get me wrong. The 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. Um, I in Jira, obviously, in a projects and issues and workflows, whether that's in product discovery type ways or in in Jira. So, I know you guys at at Atlassian Balance is right, a big, uh, Jira Service Management customer for service-driven workflows.

Those can be technical or non-technical. Is that a IT DevOps team, or is it an HR or finance team? Um, you know, the same thing. You have a piece of work that comes in, you have a queue, you need to manage the service alongside it. Um, conflicts, obviously, of content. So, you know, we have we have a broad range of users, but I I will go back to your question. It is a really interesting question. Um, I think it's worth setting that context, because if you think about what Jira, 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. Uh, by AI agents, LLMs, uh, 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.

Uh, there are massive numbers of business processes that are gonna be made better with AI. I don't know, there are a huge number of business processes that are gonna completely disappear. And that's weirdly a controversial thing to say. A business is based on a number of people, their brainpower is still important. They are gonna have to get together and track things. Um, we've built a series of features recently for, uh, assigning work to agents, either our robo-agents or, uh, agents that come from other agentic platforms.

Be that, um, you know, Salesforce or or Google agent space, uh, or be that from, I don't know, Cursor or or, uh, 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, um, you know, a 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 gonna come back, it's gonna add a file, it's gonna send me a link, it's gonna 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 to send it out to the world or do something. Um, these business workflows and processes are what I think is the most fascinating part of how AI is gonna optimize things.

I think we're in a world where people go, Oh, well, the whole process is gonna disappear. Rather than if I think about it as a flowchart, I'm gonna use agentic technologies from probably lots of people and LLMs and AI and whatever technology we wanna talk about at different points in that process to get rid of this box or that box, and then maybe a whole branch. Um, that is, uh, that is largely how 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 are very similar across both.

Uh, one of the things that we see at Weights and Biases is, um, a lot of our customers are more interested in in creating their own interfaces. Like, it seems a lot more possible to kind of vibe code, like a quick and dirty, you know, dashboard that's sort of outside of our own, our own product. Do do you see that as a trend? Like, we've been thinking a lot about how do we make, like, you know, APIs, maybe MCP servers, or, you know, these types of like interfaces to support customers in that way?

Is is that something, do you also kind of agree with, or do do you feel that trend also?

Uh, yes, for sure. Um, I think this gets to this question around software development and 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.

Um, vibe coding, if we take a 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 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 there's 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 would require programmers.

It doesn't mean the programmers and developers disappear, that they're suddenly just vibe coding their jobs. Like, um, so it it, it's going to change how businesses run in a huge way, and it's it's gonna be based on the frameworks, right? The problem when you're in the enterprise is you have, uh, 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 gonna have lots of these frameworks that aren't about, can I make a website and put it on the internet?

Uh, 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? Um, we have a lot of frameworks that 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 the data layer underneath in a in a really interesting, uh, and deep way.

You know, so I wanted to ask, you, you, you have Rovo, which, which, you know, looks like, uh, um, like, essentially like a Aug- augmenting development application. But I I was curious with, like, that, you're kind of more traditional applications like like, say, Jira are. Do you feel like AI has opened up a space of new features that you're excited about? Like, does it does AI cause you to kind of, like, rethink any of the ways that your kind of like, long-standing products work?

Massively, yeah, I mean, robo like, uh, may maybe we should step back and explain what we've built, I suppose. Um, so w- we think about ourselves as handling, um, uh, unleashing the potential of teams through those workflows and business processes exist in every team, right? We're a collaboration company. We help your organization collaborate on tasks, on content, on everything. Um, we've always been very profligate with other SaaS applications. We, um, I have a 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 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. Um, 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 twenty some apps, collected in maybe five or 16 collections, they all have a central cloud platform. We track billions of links to other applications. Be it Google Doc, be it a Figma mockup, be it a a pull request at GitHub, uh, uh, be it a Salesforce customer record. Um, these links we started to assemble into a big graph.

Uh, 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. Um, 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.

Um, 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, et cetera. That initiative has a spreadsheet. Like, so, the 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.

Um, then we add semantic search over the top. That's the core of what we've built into Rovo. So, um, 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, um, 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, uh, you know, the Datadog or Big Panda or 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. Um, call it three years ago when long-term LLMs, we have a superpower change moment because we have a graph of all of the objects in your company, your 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, uh, definitions, right? We have a a feature that's super popular, where you can select any word in Confluence or 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, stereodust or alchemists, because they're like, What the fuck is this internal code word mean? And we can give you a full history, and then you can start chatting to it with with robo chat. So obviously, the graph and 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, as a, 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, in your, uh, you know, of your product features. If you if you do doing, uh, backlog management, for example, it's the same graph that Confluence uses to say, Hey, there's some related content you might wanna go read the spreadsheet. Um, it just turns out that AI lets us do, uh, very new things in interesting ways. Those features from Rovo already surface in Jira in lots of different ways.

So, uh, you know, we said on our last earnings call, we've passed 3.5 million AI. MAU, um, 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, 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 not how many seats people have purchased.

Uh, the gap, what I call the shelfware gap, is if someone's bought 100 seats and they have five. MAU, we're in trouble, like they're not gonna keep buying 100 seats, maybe they buy 20 seats, right? So we care about activity, hence in AI, we always say we don't wanna market AI, we wanna 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 three. That was a while ago now, 3.5 million, uh, users every month that come and use our AI features and products. And yes, they can be coming to robo chat to ask a question, you know, hey, how does this? Uh, what is the history of this piece of the organization? It might be coming to search and getting AI answers to an a question that may come from a Google Doc.

It may come from anywhere in the 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 wanna assign this issue to an agent. I wanna do all of these things. So I think the um, sorry, this is a long answer. I don't think that we're gonna end up with kind of AI products and non-AI products.

I think we're just gonna end up with products. They're all gonna 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 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, et cetera.

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, uh, changing the way that they can work, right, in terms of these integrated processes across, um, across your SaaS landscape.

Well, sorry for the the focus on developer productivity, but this is like sort of my background and and something I feel like passionate about. I I saw you, you know, I saw you recently, uh, bought a company called DX, which is like kind of measures developer productivity. And, you know, and and then on your website, you talk about measuring, uh, like AI enabled developer productivity. I thought that's really interesting because, you know, I feel like I've I've been really wondering, you know, for myself and my team, like, is AI making us more efficient?

You know, there was like a recent study, I think, where they asked people, Do you think you're gonna be more efficient? And people said yes. And then after they used the AI, I asked, Were you more efficient? And that was like highly correlated with thinking they were gonna be more efficient, but it was actually uncorrelated with actually being more efficient. And I it made me think, like, Wow, I should not probably trust my own. I do feel much more efficient with AI, but, you know, that got me thinking, like, am I actually more efficient?

Are these developers i in in my organization, you know, more efficient? And and I was kind of wondering, um, I don't know, like, it seems like you would actually have like hard metrics on this stuff.

yeah, I mean, for sure, like, we look, we have the advantage of sitting on arguably the biggest data set of developer efficiency and development team engineering team, R and D team efficiency. So I think we sometimes get there's two issues here. Well, there's many issues here. One is we talk about developer efficiency as how quickly can I write a 20 lines of code? And I'm like, that is a very poor way to measure developer efficiency. What we should be measuring is how much sort of customer value am I shipping per week as an organization across developers, designers, analysts, product managers, all the people involved in this equation.

Are we getting out higher quality and 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 like coding question, um, which is again, there's lots of studies. It's about a third of a developer's week. Our our data would reflect this as well. Again, tens of millions of technical teams show up to use our applications every week. And so we have a huge data set of being able to understand trends and how these things are changing.

Um, there is no doubt, I would argue, coding speed is improving rapidly. Now, you might argue if you look back 20 years, it has been doing for a long time. And so if you could graph it, there'd be a step change. Why is that? Well, go back 50 years, we're all writing assembly. It was really, really slow to write some unit of functionality to ship it. Now we have, you know, Node and and higher level languages and JavaScript and TypeScript and everything.

So languages itself, coding AI, sorry, uh, AWS, I can spin up a million machines, I can be more efficient. And so wait, just AI allows to clarify me to do it.

though. So when you say coding speed, you mean like delivering value to customers, or or something else?

I mean, I have to start with an idea or a an issue, a task. I turn that into a piece of code, that's actual physical characters. Uh, that code then needs to be sort of 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 the how quickly can I take the task I'm given and turn it into, let's call it committed code, or tested code, or secure code, or something.

And that is a measure of code speed, maybe, rather than team speed, which is like, did we build the right thing? Is it good quality? Um, did customers like it? Did we able to get it deployed, et cetera? So there's a lot of those questions.

And so you're saying that code

Do you?

speed has been improving for the last 50 years, like you just see the steady I would argue, improvement.

as we've built better languages, coding speed has improved, we've built better tools, right? I, I, um, you know, knew the the Jet Brains founders really well. We started in the Java kind of world in in the early 2000s, which is dating myself 25 years ago. And, uh, you know, I wrote a book on open source Java programming when I was a teenager. Um, and you know, Jet Brains brought along a new IDE, right, called IDEA. And oh my god, it changed my coding.

It wasn't a new language, but the the speed, the the way it did auto complete, the way they built these language models, like IDEA was absolutely amazing. It was a complete step change, right? And versus codes come along. So we have lots of language improvements, tool improvements, and other things in the development world for the last 50 years that you would argue if you could kind of plot some notion of this development speed, right? Has just keep increasing increasing.

Um, I would say we are hit. We've hit an inflection point with obviously code generation, GitHub Copilot, that's now become like robo dev and cursor and Claude code and all the things that that generate code. They are massively changing the speed with which we can turn, uh, task into code. Uh, that is awesome, that's great, right? Internally, we use all five of those tools a lot. Um, we really wanna do this. But you then run into a separate problem, which is, um, which is what DX is trying to solve.

Is that perception of value actually there? And you're also paying a lot of money for it this time around. So when we move to VS Code or, uh, even IDEA wasn't very expensive, I think it was like 50 bucks a head kind of thing. Um, now I have the potential to spend thousands of dollars per developer in token costs across lots of tools. And I'm like, hey, now I really need to know if that's important and working for me, because suddenly I have real bills, right?

Um, tens of millions of dollars that would be spent every year by us 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. Uh, again, uh, fantastic company. What they do is they look at qualitative and quantitative measures of engineering team efficiency. So that's a developer to a team to the whole organization. And when we say qualitative and quantitative, it's really important to combine both.

Historically, that's, uh, Dora metrics and all sorts of of of numbers like that. They have a a scheme called DX4, 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, they're quantitative measures of pull request cycle time and things like this. You need to combine that with qualitative metrics, uh, thoughtfully put together, researched surveys of your engineering base that are then relative. You take qualitative and quantitative, you can find action points, right?

You ask people, you can look at numbers. We seem to be going faster, and you ask people what sucks about working here, and they're like, the build system is horrible. It takes hours. You get enough of this as responses, you can be like, you know what? I think we should fix the build system because everyone seems to complain about it. Turns out, if you just ask people what sucks and fix it, it's probably a better thing for developer productivity than anywhere 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 great task. It's a creative profession where you are most productive when you're joyful. You feel in the flow. When you're an engineer, you're like, Man, I just crushed today. Like, I built some amazing things. The builds are working, the tests are going smoothly, like I'm shipping value.

I found you as you're really joyful in that creative task. You are there. When you are unproductive, you are incredibly unjoyful. The build system's breaking, 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 like, hey, I put more sugar in the cupboard, or I doubled the number of pool tables we have, right? Like, these are not really measures of of true joy and satisfaction in your job.

If you got into this job because you wanna create software, great, the more software you're creating, the more joyful you'll be. AI's 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. And you're like, Wait, how come these things have become disconnected? And I think that's just cause we, as as humans, are going through this learning cycle about these technologies.

Um, and y- you know, you had, uh, you had one of my friends and, uh, uh, uh, competitors, I guess, on on, uh, uh, recently in Arvind from from Glean, um, and he, 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, we adapt it into our daily lives, and it becomes just the default, and we all kind of learn and grow as a species.

That was no different when we had the, you know, we we we came out with the plow, uh, the ax, uh, you know, the laptop, the phone. Like, we adapted our whole lives around these technologies and we 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.

Like, 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 have to now rebuild the mental model. So you end up reviewing a lot more code, whether it's in your IDE just been written for you, or whether it's as the actual code review, than writing code. And that requires a change in our, in our mental shift, right?

So we have to do that. What DX does now is tracks not only, you know, the all the metrics quantitatively, but also the amount of, like, money and time you're spending in different coding tools. So we can tell internally which of those four tools, uh, between, like, robo dev, Claude code, cursor and GitHub copilot, of which we have all four, uh, for for engineers here. Um, which of them are better and worse ROI wise, cost wise, which of them are getting used more and less?

All of them have thousands of MAU at Atlassian, so we have, you know, R and D orgs is over 10,000 people, so we have lots of statistical data on them. And then which ones are actually getting different productivity, and also in which areas? Because I don't know there's like one coding well, tool, tell her what right? It's

you've learned. You have like, I mean, can you share some of the the insights? This sounds just incredibly practical, like, in what situations would I?

well, it look, it depends on on a lot of different things, and I think what you're gonna see is is models actually merging as well, right? So you're gonna end up seeing a lot of different things as people learn from each other. So I I if you think about robo dev, right, our, uh, coding agent, if you might say, and we we call it a software agent, cause our job is we wanna take Jira issues and make them into pull requests that are approved.

So a merge pull request is a great data signal in a machine learning sense that this code is good. Um, what? What we've started doing in the robo dev team quite a lot is work on self-reflection. So coding tools are gonna make mistakes, just like engineers. How do you get the right data in an organizational sense, which is different because we have different, you know, we have thousands of repositories, right? And lots of different pieces of of of, uh, of code, old code, new code.

It's not this lovely green field world all the time. It's like, look, I started with nothing, and I set it on an app that's like Uber and spat out a mobile app, and I'm done. Like that in the real world is is really hard. So you need a way of all these coding tools to help them self-reflect, to to self-improve, to avoid similar mistakes in future, which weirdly is exactly how we teach graduate developers, right? The code review process is really important, right?

Um, some of the tools, uh, and Robo dev is is very strong at this as an example. Uh, it sounds like I'm speaking my own book, so I can talk to the other tools are, um, much better at finding, uh, bugs and maintainability issues and security issues, right? So this the writing of new code tends to be better in certain tools, and again, it depends on the context that you have. So one of the reasons Robo dev does really well, um, is because of that teamwork graph I talked about beforehand, right?

So, for example, we know all your pull requests, all of your issues, all of your repositories in the graph, the technical part of the graph. That means when you ask us to go solve, uh, an issue or a problem, it, um, it can use prior solutions to other issues in other repositories as a way of learning, right? If it's got all of that context, that turns out to be really important from the technical point of view.

So how to actually write the code in the style that your company wants. There is the second issue, which is how does it get the data context? Well, that usually comes from Google Drive and Confluence and 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. Um, a lot of these things use each other's models.

So 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. And we're at the application layer, so we're like, way above all these layers, trying to deli deliver customer value. But our AI gateway has, I've lost count now, it's north of 75 models running in it in production. And Robo dev to do a general task will probably use two or three models on most, like most turns of the conversation from different people.

A lot of times it's using Claude Code as a model, for example, it's using Gemini. Um, 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, uh, a task. Um, I'll tell you another thing that's maybe interesting, that I think is underappreciated. And 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 five years ago. It's running, it's in production, 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 came up with microservices, so we have lots of services that contact each other to do all sorts of things, identity, logging, you know, media storage, whatever.

Awesome, it's good cloud platform. Now I wanna make a code change. Uh, it's very hard for tools to look at the entirety of Atlassian's codebases and make that code change. That 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, this is a really powerful for existing running businesses solution set. We have tons of examples internally where we use that quite a lot.

Um, so, uh, as an example, we had an internal service that changed its shape and location. Uh, I'm trying to think what the service did, I forget now, but let's just assume it was a it was a rest kind of endpoint. And someone's changing the URL, I think, and they're, but not 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 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, depend on how they use the thing. That is a great task to put AI coding agents into, which is very different than what we traditionally think about. How we did that, uh, is using Robo dev and agents of Jira and things, um, and I think it mostly used Robo dev was to write a few examples of how this worked.

So maybe one in JavaScript, maybe one in Java, and to commit those examples, and then you get the examples into the graph. Now you can say, go find me any other place you think I should do this, and it comes back, but it requires, I think, the other learning is we have a model wh- where we think about human-AI collaboration as the way the world is gonna evolve. AI is not going to replace human beings. It is a force multiplier for human creativity.

It is an accelerant, not a replacement, right? It is, um, I don't think, you know, I'm. I'm not worried about Ru- 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, that is the fear that that I have that, oh man, someone will come on, they're just better at using AI to get better results. It's not like some robot will show up and just be like sending out emails or whatever.

Um, the the technical version of that is 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's lots of ways you could say, just go write the code, and it'll give you back 500 pull requests.

Now some human goes through them all. You're like, Oh, it's a play. I don't have the problem like, Ah, I worry about the AI code reviewer of the AI written code, with no human in the middle. That's kind of orienting, right? Cause if it's off by a few percent, and then you multiply it through, it's gonna be pretty, pretty tricky. And we've we've had our fair share of AI worm 1980s equivalents, where it kind of feeds on itself and goes off.

And if someone's like, Hm, we were one off at the start, but after a thousand loops, we're in trouble. Um, so I think those types of tasks where, you know, we talk about it as code maintenance, it's a pretty naff term. S the the analogy, maybe to gardening, is the easiest one, or or some sort of term like this, where it's like, most of the the code creation is where you're saying, Oh, look, I want a waterfall over there, and I wanna put down some rocks, and I wanna move around.

Like, plant a big tree, and it's give this is this is landscape architecture. A lot of the day-to-day work is mowing the lawn, taking out the weeds, like, you know, putting the 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. All of these things are gonna be done in in a loop with the AI, um, and I think there's gonna be lots of coding models to to do that.

So, yes, DX is gonna really, really help organizations understand their productivity, both qualitatively and quantitatively, but more importantly, come back with, uh, actions of where to improve that, right? Um, and 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 like that. We've done a lot of work about like things like accessibility and translation, any of these large-scale tasks, we need to do them across massive codebases.

That is where it's really, really, really helpful.

Do you think there are other ways where, like, because you know, you're, you know, you're you as an organization are spending a lot of time thinking about, you know, developer productivity, developer joy, and and like measuring it rigorously. Do you think there's other ways that you're using AI differently than, you know, someone like me, where I'm not actually, like, rigorously measuring it? I'm just kind of operating off of a general intuition.

Um, that's a good question. I'm not sure. I I think like I come from a school of thought that AI can't create. I have to put this phrase this carefully. Um, AI generating net new knowledge is a pretty tricky thing now. Arguably, all knowledge is generated from other knowledge, right? But the idea is, um, all businesses, 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 go 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? Um, I think that that's one of the reasons why you'll see, you know, more developers in five years than today. I don't think you'll see this mass layoffs of people like everyone's worried about with this sort of AI efficiency argument. I'm in the optimist. I think you'll see, uh, that AI applied to creativity to help me do my job better rather than doing it, but it still requires me as a human.

We've gotta keep the humans in that loop, not because I want to, like, keep humans employed, but because I think that's where we are actually best. That's what will probably end up happening. So, you know, people talk about, for example, AI writing the memo for them, writing the document for them. I I think we spend a lot more time thinking about how do we use AI to help me write the best memo? Because it's unlikely that memo, most pages written in Confluence or whiteboards, or, uh, you know, any our blog, whatever it is, even if it's an announcement, that it's just.

I took all the knowledge I already had, and I kind of rewrote it in some other. I transformed it and I spat it out again, and this is a great outcome like that, it can do very, very easily, right? We have all these writing tools and everything else, and in Confluence today, it's 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 it.

This is awesome. You add the teamwork graph and your entire organizational memory, uh, you add your personal memory, the everything you've done, and and you know, in the browser world now, you've got everything that you've seen, um, you add all that. It can do amazing things, but it's still not gonna create raw source knowledge, right? Insights and source knowledge without your help. So I think the thing that we always would say is it's about the human-AI collaboration loop, um, and that that is very different than just sort of whether that's a workflow or a business process, whether that's a creative or a a new process.

The loop between humans and AI is where we should all be looking to accelerate the progress, competitiveness of our business. That is where I don't believe in this, 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 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 want it more like this and more like that, and you'll go off and do it again, right? And to do that in teams and collaboration, um, I can give you some examples. We we showed a uh, a demonstration at one of our on in one of our our keynotes that came from a a real world example. Which is in Confluence, you have, uh, 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 to come back, all permissioned, data resident, FedRAMP compliant, like all the things you needed to be. And in the whiteboard, we have a brainstorm agent. So you can say, I wanna brainstorm about a topic, and the better you define the topic, the better the brainstorming will be. And it'll go and search your teamwork graph stuff in Microsoft Teams, stuff in Google Docs, stuff in Jira, Confluence, et cetera, and it'll do the brainstorm for you.

And it'll start filling in the sticky notes on the whiteboard, and it's really good. And again, to your point of the coding, it looks magical. You're like, Oh my god, look at this, this is amazing. What's much better, though, and we showed in the demo, is when then the agent has written the brainstorms. Now the team comes in, the people, five or six people come in, and they start adding stickies, and they vote, and they say, no, this is wrong.

And they have discussions, either audio-based discussions in a meeting, Zoom, teams, whatever the um, or they have text-based discussions. They're adding signal to that brainstorm, then someone else can go away and take the human signals and 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? And a different agent can come in on the whiteboard and draw flowcharts and write a document, spit out a Confluence page.

You can do anything you want at that point, right? And then you might loom over the top of it. So you might record yourself talking to the team and say, Hey, as a result, I've written this document. Because when I'm write, when I'm recording a loom, I am adding net new knowledge. I'm taking what I'm reading and my own what's in my head. I'm taking the, you know, the knowledge. Like, AI can't just sap all of our brains.

Most of this stuff was never written down, it was communicated in a in a meeting by the two people. So now I've got the loom. Well, now I've sort of audio recorded my thoughts on top of the document that came from the brainstorm. But it's another loop of human-AI sort of collaboration, we keep going back and forth, and 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, that person talks a lot. Can you just give me the cliff notes? Give me the 5 minute summary. We can chop little pieces of audio out, all this great. What we've done there is taken the knowledge of our organization, summarized it onto the whiteboard, then the knowledge of the people we have today, and kind of change the ordering and voting. Then we've used AI to help us write an amazing memo about this task.

I've then created a video, so now I've put more knowledge into the system that is tracked for a new person that joins tomorrow. They can watch the video and we're getting this tribal knowledge sort of categorized, but we're using AI and humans to collaborate on improving whatever it is we need to do, rather than the idea that, like, oh yeah, I'll just 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, our graph will keep improving in its density and speed and quality and breadth.

That will all let, you know, 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 a non-controversial view. I think it's in a lot of parts of the world, it's quite controversial that humans are still gonna be in charge and needed and a core part of the collaborative loop to to create any new value.

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

From my perspective, we we continue to hire, um, junior developers, but we see actually that it's it seems easier, um, you know, to hire them right now. Like, the demand seems to rotate, you know, towards more senior folks. Are are you seeing that? Does that? Um, I mean, obviously, we you need a pipeline of developers, you need kind of entry-level positions, you know, to have, um, you know, a vibrant dev ecosystem.

Uh, look, I think there's two, two comments that maybe I I I disagree with, or two two views in the world. One is all developers are gonna get this beer, or large numbers of them. I'm like, I I think we'll have more developers in five years time at Atlassian than we have today. I sat on a, uh, I I spoke with with Matt Garmin at AWS at an event, and he said exactly the same thing. He said, I agree with Mike, we're gonna have more developers at AWS in five years time than we have today.

Um, I think the second part of the view is that it's only gonna be senior engineers, and I don't, I don't know, I agree with that. I don't, I don't think that's gonna be the case. Um, and I can give you a few rational thoughts. We're all gonna have to see how the future plays out, right? Uh, I might be completely wrong. The rational thoughts for me are a few things. Firstly, our 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 skill plus knowledge plus wisdom plus experience gives you a better engineer, and that has to be gained somehow. Um, those senior engineers, though, they do keep evolving, right? We used to have a lot of senior engineers who were really good at building on-premise software. 15 years ago, we started the cloud. We had nobody that was very good. 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 we're always learning new skills, cause the technology world keeps improving. I do think the what doesn't change about senior engineers is they cost more than junior engineers. So there is always gonna be a case where you say, you know what? I'm gonna pair one senior, experienced, wise person with four or five more junior, less experienced, less wise, yet people, and then they get experience. I don't know the idea that AI is just gonna 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, grad, first-year grad developers, to come in and perform way better than grads did ten 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 like robo dev wrote that cursor wrote that. These are not an excuse that you're allowed to use. You're accountable when you commit it. Same if you approve a pull request, you're accountable for the reviews. You can't say, oh, I looked through and all the security agents seemed to say it was fine, so I tick the approve box. The senior developer needs to talk to them about human accountability, developer accountability for their code.

I would also contend it's interesting. We we've seen this in Loom, I have lots of data points from Loom. I don't know I have as many at the in the engineering sense yet. What happened in Loom was graduates new to the workforce were much more video-centric, probably cause they've been Snapchatting and FaceTiming their life, you know, for the teenage years. So when they came into the workforce, they were like, why do we all sit in a meeting?

It's like a synchronous operation with a bunch of people and one dude talking, and I'm like, why am I wasting my hour? Like, I'm not sure they thought about it as sort of systematically as this, but that's effectively what happened. You saw a lot of Loom entering into businesses, the junior who are used to popping open a window, recording a little video like this and sending it to someone. Like, sweet, I didn't need a meeting. This comes in, and then people in the organization go, Oh, maybe the kids are onto something like that was pretty efficient.

I like just watching that, and I like not turning up to that meeting. 20 of the meeting is useful, 80 of them don't need to be happen. Whatever you can pick your own number in your own business, but this was B brought in by the younger folk, let's just say, who then changed the nature of the organization. And it wasn't that the senior person didn't understand that, they just had no experience. They were busy, they were doing their work.

Once they see it, they can adopt it.

well, okay, so, like, slightly switching gears here. There's something I I really wanted to ask you, which is, um, we had. I've had a board member at at Weights and Biases for a long time, Jay, uh, who I think was an executive of yours. And and one of the s, and he told me a lot of stories about you. And and like, you know, kind of, you had contrarian views on a lot of things, like, you know, not having a sales team, like, not, you know, discounting.

I mean, these are really interesting. I feel like you're maybe the first company to really do what they call product-led growth now. But, uh, one of the stories that really, um, I don't know, just like, was memorable to me is apparently you or your your executive team in a board meeting was like, hey, like, we don't wanna grow too fast here. Like, you know, we wanna sort of, like, steadily double or something like that, and not like, you know, necessarily, like, grow the top line as fast as we possibly can.

And that caused some consternation, like, is that like a, is that an accurate story of, like, something that, um, that happened? And then I wonder, like, what your thoughts are? Cause now there's such such a premium on fast growth. I mean, I feel like there's so many posts of like, you know, wow, this company went from like one to 100 million in revenue, you know, um, in two weeks or something. Almost like a competition of speed, like I've never seen before.

I'm just curious if you have a a take there.

Ooh, I have a lot of takes there. Um, uh, look, firstly, on a lot of the fast growth numbers we have, it's amazing, right? It's never been easier to build a fast-growing business to get from zero to 100 million ARR. Um, and again, when we first had the inkling that maybe we could go public somewhere in the 2010 range, we were probably eight, nine years old as a business. I think we were doing call it $50 million in revenue and probably $20 million in profit, right, growing 30 a year.

Um, and we thought, geez, you know, maybe we could go public like that was never a dream. It wasn't like we sat there in Sydney and were like, going public is the thing I wanna do. It was more like, you know, possibility, right? At that time, you needed about 100 million bucks in revenue to go public. Like that was what it was, the sort of the line for a public company for a while, right? Um, so, you know, things shift, right?

We had billion dollar companies, where, man, now we're 1 trillion dollar companies. Now there's a bunch of 1 trillion dollar companies. So a part of it is just the the natural shifting of things. Secondly, there's no doubt with between A W S and cloud computing and payment systems and and S A, S, like the ability to distribute app stores, 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.

Um, I, I don't, I think we, and we, we have a success bias in technology of celebrating the people who went from zero to $100 million faster. And there's a lot of companies out there go from zero to zero. So I don't know there's any less of those statistically, we just don't talk about them, and so it feels like, and then everyone, it creates this mental health stress. I see whenever I'm out there, people are like, man, I didn't get to $100 million in revenue in two years, I must suck.

And I'm like, Jeez, it's tough to be a founder nowadays. Like, that's rough. Like, are you building? Are you solving a problem? Do you have customers that like your thing? And do you have a reasonable model for growing? Slow down, mate, start there. Like, l like, just don't count yourself out cause you're not on this crazy, crazy journey. Um, and you know, there's a lot of those that, in my era, I would say, the early 2000s and and even you might argue the 2020, ten sort of ranges, 2008 to 2012, thirteen, a lot of great businesses founded that were growing fast and are now just iconic companies that we don't think about.

So I, I, I would tell those founders, don't, don't just build things that people need and and figure out a good model for distributing them and growing that that business. Um, secondly, yes, we have for all time, or a lot of time, we we don't try to grow as fast as we can in any given time period. That is not, I don't think that is a smart business goal for maybe I could argue any business. It's not a smart business goal for us.

I'll just talk about us. Uh, we, as I said, we wanted to be a multi decade company from the start. We want to grow longer, not grow faster. That that is our sort of weird goal, and it always has been. We just finished our last quarter, we grew revenue twenty, twenty, change percent, uh, 21%, I believe. Our cloud business, which is our largest business, grew 26%, and our R P O, our revenue performance obligations, so the future revenue that we have contracted but not yet come into the twelve month revenue, grew 40%.

And we're a five, 6 billion dollar, you know, that was more than a billion dollar and change quarter. So I think we're still growing strongly as a business, you would argue, uh, but I still don't want to maximize next quarter's revenue growth. Now, any investors out there freaking out, let me explain why, because I don't think that's a smart thing that investors should ask for. I think no founder should 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 ten dollar game. You've got $10 worth of resources to put on something this quarter. You could put all $10 on maximizing revenue for the next quarter, but then what you gonna do, right? It's really hard. So you're not gonna invest in the architecture which will allow you to survive the A I disruption.

You're not gonna invest in all these things. So you always have to create a balance, and at some level, it's truism. Problem is, when you get to that line in ball decision, short term revenue growth versus continued, right? I wanna build durable businesses that will grow at north of twenty, 30% five years from now. And that's what I want people thinking about because it's gonna mean we're a long term thinking company. It's gonna mean we're evolving and growing.

Uh, uh, we're also making the hard decisions today, which probably are short term disruptive, right? If you continue to do that, if you take that and keep repeating it, you build an amazing business. And I think if you look at most of the amazing businesses out there, that's actually how they think. Amazon being one of the canonical examples, right? They're the best at, like, amazing business, investing in infrastructure, investing in warehousing and logistics, investing in lots of strategic things for a long term period, because they wanna think, how am I gonna grow four years from now, and where's it gonna come from?

And I think sometimes we get very short term in the in the founder sphere, right? Even the $100 million in two years, it's like, well, tell me where they are in ten, right? Do they do? We think they're gonna be a real multi billion dollar business in ten years? That's far more impressive to me and to look at the system thinking that goes behind the logic. They'll get there. Um, 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 on all of them is something about that. They have a, um, they generally don't care much about money. They generally have a delayed gratification in a business sense gene. They want you to build a really great business, but great to them is solving distribution, solving business model, solving architecture and engineering and R and D problems, solving customer problems, and doing all that in a way that in two years time, we have a better way of solving the four year problem.

Version of like, it becomes a sort of second derivative problem. They end up solving, Um, almost whichever whichever discipline they're in, and I think that's all Jay's saying is that he, he's kind of he was a large part of architecting this thinking. So it's kind of ironic, uh, as our president for a decade or more. Um, yeah, he he buys into this too, right? Um, Well, I but it's

think like one thing that, like, you know, one reason people focus on revenue is cause it's so easy to measure and it's kind of a way to do accountability. Like, one thing that you said earlier that that I really liked, but I didn't want to cut you off was like, you know, measuring the monthly active users seems I mean, something we do too, where it's like, uh, you know, kind of closer to like, is somebody getting value out of, like, what we're doing?

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

Uh, look, there are none that are that simple, I would say that we track religiously. Um, we have many, many orders, even even just tracking. Mao, I would argue by itself, there are many, many second and third order metrics inside of Mao, right? We look at, uh, we look at M C U, right, which we call monthly core users, monthly collaboration users. Actually, don't know what it stands for. We just call it M C U everywhere, which is sort of like, if you think about, think about Confluence as a system.

I might have, uh, uh, I should have looked up what, what's advice is, um, it's sort of more interesting, but I, I might have, you know, 500 people in a given company, you know, it's a thousand person company, they have a thousand seats. Great, I might have 500, 600 Mao every month. That's a pretty good ratio, to be honest. That's awesome. 60% Mao ratio to seats, company's doing well. Inside of that 600 people, though, I think, well, 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 the other person to read, and somewhere in the middle is a collaboration. They're adding comments, inline comments, page comments, they're reacting to it, they're linking it to it from somewhere else, et cetera. So even inside Mao, you'd be like, okay, cool, well, we just get more readers. And you're like, nah, that's actually not gonna help us, cause we need to create the content in a system like Convo.

It's gonna be different in a workflow system like Jira, different in Loom's case. You're trying to, what is a core user of the product? What is the person creating new content? Are they creating it and sharing it? It gets to sort of a viral loop notion, right? And so I would argue in any product, you need to think about who are your core users of the usage value, then you need to think about who are your people that we we we look at in terms of the the deployment and distribution angle.

So, in our world, in the enterprise, you have a lot of gatekeepers. So you might have I T professionals whose job is to say, is this secure enough? Is this? I'm not gonna roll it out. It's not just people like finding an application and adopting it. Someone feel so we've got to think about, okay, are the I T fraternity happy with us in terms of security, compliance, governance, controls? And rolling it out? Do we give them analytics and usage numbers?

So we sort of try to look at the different core groups. It's not just a thousand person company. There are a lot of subgroups, even inside Mao, that we need to be caring about. Obviously, any business has some form of a funnel. Yes, product led growth is easy to measure that funnel. How many people came to a website, clicked some sort of trial, try button, did that turn into a usage? We have a, you know, um, seven day usage, D thirty, two, D thirty, whatever numbers you wanna look at, we've we've got all of them in different spots.

But basically, you're saying, looking at some funnel and did they come back? Um, those are really important numbers. Uh, I think inside the sales world, there's also a lot of these other numbers, right? We 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 your grow, um, grow faster or grow longer. Does your sales team spend more time thinking about multi year pipeline, or do they spend more time looking at this quarter's numbers?

Because arguably, this quarter's numbers came from the multi year pipeline from two years ago, but you can't change that now. But where do you put your ratio? And how does your reporting work on the sort of the longer term number, right? There's pipe for next quarter, and then there's a pipeline for next year. And you wanna, arguably, spend time with your future customers and making them happy, right? That that's the ar the the best way to plant those seeds that you can, then you can then grow.

Um, one of the things my my co founder, who retired, uh, last year, um, was very keen on is is you've got to manage in any business the difference between seeding and harvesting. So the the obvious farming analogy is you, you spread out your seeds once a year, and then you harvest them, and then you go into a empty field. I don't know, so you're generally seeding in some areas, you're trying to have multiple crops or multiple plots, so you can spread your revenue out.

And if you harvest continually, or you're in a um, uh, a a forest, if you're, if you're logging or something, hopefully you're sustainable logging, but if you're doing some sort of logging, you're cutting things down, then you're cutting down more trees. The faster than they're growing, you're gonna run into trouble, right? There's a really awesome book, um, called A Short History of Progress, which is all about humanity and groups of humans and their challenges. With are they living off the interest of whatever resources they have, or are they living off the principle?

And do they even know when they flip from one to the other? And that's a really applicable business lesson, I would argue, for seeding versus harvesting. And whatever metrics you're getting, are those metrics you measuring? Are you seeding future growth or are you harvesting growth from seeds that someone else planted? Because it's very easy to measure usually the harvesting. There's only tons of wheat I collected today. And you're like, let's just harvest some more. And at some point, you realize the field's the barren, and you say, great, who seeded it?

And then there's like, well, nobody did, like, we didn't do that. And so a lot of these business metrics would be arguably trying to measure the source of the funnel or the seeding work and treating that very carefully, where it's not related to your revenue outcome, and then having clear connectivity through. 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.

Um, and maybe A I again will just replace us all, and I just don't think so. I think you, A I 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. Alright, well, Um,

look, I'm getting pinged by your team to to wrap this up, but we can't end on that that note. So let me let me ask you another one. I'm curious about, so how do you? Uh, you should probably be quick, cause I I've, I've told to wrap it up, but how do you like? You know, you're twenty plus years in, and I'm just curious, like, how do you stay, like, creative and, um, curious at 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, creating things, that is the fundamental nature of our industry, right? It's a very organic industry.

Totally agree with it, and thanks, Mike. Really appreciate Thanks, your time.

Lucas, and Horace.

Yeah, pleasure. Thanks so much for listening to this episode of Gradient Dissent. Please stay tuned for future episodes.