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

“I don't worry about being replaced by AI. I worry about being replaced by someone who's really good at using AI.” Atlassian has 10,000+ engineers currently split-testing the world’s top AI coding tools, from GitHub Copilot and Cursor to Claude Code. In this episode, Co-Founder & CEO Mike Cannon-Brookes joins Lukas Biewald to share what their data reveals about the world's best AI tools today. Hear how 24 years of building a tech giant and a massive internal study on AI productivity have shaped Mike's vision for the future of dev jobs. Connect with us here: Mike Cannon-Brookes: https://www.linkedin.com/in/mcannonbrookes/?originalSubdomain=au Atlassian: https://www.linkedin.com/company/atlassian/?viewAsMember=true Lukas Biewald: https://www.linkedin.com/in/lbiewald/ Weights & Biases: https://www.linkedin.com/company/wandb/ 00:00 Trailer 01:08 Introduction 03:11 Connecting Technology and Business Teams 07:22 The Impact of AI on Business Workflows 13:26 Developer Productivity and AI 21:03 Measuring Developer Efficiency 25:41 Future of AI in Development 34:59 Legacy Technology and Code Changes 39:29 AI's Role in Developer Productivity 47:40 AI and Junior Developers 52:30 Product-Led Growth and Business Strategy 01:00:29 Core Metrics for Sustainable Growth 01:06:56 Staying Creative in the Tech Industry

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  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.

• 0:09Lukas Biewald?

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

• 0:15Speaker 00

  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 going to disappear rather than if I think about it as a flow chart, I'm going to use a GenTek 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

• 0:59Speaker 00

  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.

• 1:08Lukas Biewald?

  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-Brooks, 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.

• 1:37Lukas Biewald?

  All right. Well, so like, you know, one of the things that made me really excited about this interview is it's rarely you get to talk some of the creative tools that you've used for like over a decade. So I'm intimately familiar with some of your products. And I mean, just to get right into it, 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 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 maybe they don't change. But like, what do you think about like, in an AI assisted, AI assisted workflow, are there parts of the tools that you think are going to become obsolete?

• 2:18Lukas Biewald?

  Are there like, big new blocks of features that like, might be necessary to support, you know, people working with like, actually, you have an AI developer assistant, or there's explosion of them right now?

• 2:30Speaker 00

  Uh huh.

• 2:33Speaker 00

  Uh, look, that's a big question. There's a lot in there. 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

• 2:46Speaker 00

  a biased view in the world, maybe of what we actually do. I like to say since the start, we've solved, we solve people problems. We don't solve technical problems, right? We don't really have anything that knows what languages you're writing in, or anything else. And developers are a relatively tiny portion of our audience. Technical teams are a less than half of our total audience of, of active users, if you like, of technology teams. But that's important because it comes to the nature of your question, which is firstly, what we do is we try to connect technology teams with business teams to run, let's call them business processes. It's a big word workflows, whatever you want to call at a broad level. Turns out, as most businesses nowadays are technology driven businesses,

• 3:30Speaker 00

  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 their technical business teams is really important. That's the core of what Duran Coffins has done for 20 years. And in fact, it's as, as we've grown. There are far more business people in most companies than there are technical people, broader possible, you know, product managers, developers, all them put together.

• 4:02Lukas Biewald?

  I'm sorry, wait, can I back up for a second? That's, I'm sorry that 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, I think of Jira, at least as it's like heritage coming from like a technical ticketing system product. Is that true or was it kind of always for a broad base of users?

• 4:22Speaker 00

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

• 4:32Lukas Biewald?

  Congrats.

• 4:33Speaker 00

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

• 4:37Speaker 00

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

• 5:20Speaker 00

  and it became what I guess you would term an issue tracker. So this is like 2002. What's it been 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. You have way more programs saying in a roadmap, like what sorts of things are we going to build next year and this year? And 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. So huge amounts of our customers use Jira for no part of software development whatsoever.

• 5:52Lukas Biewald?

  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?

• 6:00Speaker 00

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

• 6:05Lukas Biewald?

  I see.

• 6:05Speaker 00

  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. It doesn't mean we don't love technology teams, that can be wrong. Our point is you need to get these two groups of people in your company working together. That is the essential ingredient of what we do.

• 6:47Speaker 00

  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 Bytes and Balances, right? A big 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? You have the same thing, you have a piece of work that comes in, you have a queue, you need to manage the service alongside it. Conference 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. I think it's worth setting that context because if you think about what Jira or what Confluence do, they handle at a high level business processes, right?

• 7:31Speaker 00

  Large parts of those business processes are going to be automated, quickened, more efficient, more accurate, higher quality by AI agents, LLMs. We see large numbers of our customers doing that already. I would argue in small ways today, but you can obviously see it's going to grow. The question is, does that entire category disappear? I think that's a question where we largely disagree, right? Or we don't disagree, but like, we disagree with the world, or what the world seems to believe at the moment. There are massive numbers of business processes that are going to be made better with AI. I don't know there are a huge number of business processes that are going to completely disappear. And that's weirdly a controversial thing to say.

• 8:16Speaker 00

  A business is based on a number of people. Their brain power is still important. They're going to have to get together and track things. We've built a series of features recently for assigning work to agents, either our robo-agents or agents that come from other agentic platforms, be that, you know, Salesforce or Google Agent Space, or be that from, 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.

• 8:57Speaker 00

  So if I have a marketing project and I assign something off to, you know, a writer or one of these startups that can do interesting things at certain domains, awesome. What happens when that work is done? In a business, it's going to come back. It's going to add a file. It's going to send me a link. It's going to add a comment, a piece of text. Maybe another agent picks it up, maybe a human being picks it up. And maybe that needs to be approved or authorized or sent to another department to print it or to send it out to the world or do something. These business workflows and processes are what I think is the most fascinating part of how AI is going to optimize things. I think we're in a world where people go, oh, well, the whole process is going to disappear. Rather than, if I think about it as a flowchart,

• 9:39Speaker 00

  I'm going to use agentic technologies from probably lots of people and LLMs and AI and whatever technology we want to talk about at different points in that process to get rid of this box or that box. And then maybe a whole branch. That is, 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 very similar across both.

• 10:04Lukas Biewald?

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

• 10:41Speaker 00

  Yes, for sure. I think this gets to this question around software development and I think, I suspect what we might end up doing is separating the nature of software development from the nature of creating technology. And this gets kind of blurry, right? If you think about what a lot of kids do with their iPhones nowadays, you'd argue they're kind of making technology in a lot of ways. But we don't think of them as software developers. Vibe coding, if we take a definition being a largely non-technical person, that can be a product manager that's a little bit technical, it can be a finance professional that's completely, you know,

• 11:22Speaker 00

  that has never written code, can use AI-driven technologies of various forms to create,

• 11:30Speaker 00

  effectively to write some code and then run some code and create an application, or a surface area, or a dashboard, or whatever it is that they want. And there's obviously a huge spectrum of what they can create. I don't think that makes more software developers in the world in and of itself. I don't think suddenly the finance professional who vibe codes something that spits out a big bit of Python, that does some analysis and spits out a dashboard, like, they're not really writing software. They don't think about it in their head. They're solving a problem. They have an issue they need, and 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

• 12:13Speaker 00

  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 five coding their jobs like um so i- i- it's going to change how businesses run in a huge way and it's it's going to be based on the frameworks, right? The problem when you're in the enterprise is you have permissions, you have compliance, you have governance regulations, you have auditing requirements, you have all sorts of standards you have to live to. And so you're going to have lots of these frameworks that aren't about can

• 12:56Speaker 00

  I make a website and put it on the internet uh and advance and 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 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 that the data layer underneath in a in a really interesting uh and deep way.

• 13:26Lukas Biewald?

  You know, so I wanted to ask, you you have rovo, which which, you know, looks like a um like essentially like a augmenting development application. But 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 longstanding products work?

• 13:57Speaker 00

  Massively, yeah. I mean, rovo like uh maybe we should step back and explain what we've built, I suppose. Um, so w- we think about ourselves as handling um I'm listening to potential of teams through those workflows and business process exists 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 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

• 14:40Speaker 00

  important to someone, they've connected to the Jira issue or put it into this conference 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.

• 14:53Speaker 00

  We started maybe six, I think, 2019, building what we call the teamwork graph. So that is because our applications have many, many links in them to each other and to many other apps, right? Across our 20-some apps, collected in maybe five or 15 collections, they all have a central cloud platform. We track billions of links to other applications. Be it Google Doc, be it a Figma mock-up, be it a pull-requested GitHub, be it Salesforce customer record. These links, we started to assemble into a big graph. It's now a massive graph. It's north of 100 billion objects and connections, and it's going up at like,

• 15:33Speaker 00

  I think it's growing like north of 50% quarter-on-quarter at the moment. The reason for that is, the most essential part is how are all these objects floating around in your world connected? We've put all those into the teamwork graph. That seems like a simple challenge at the start. Turns out it's very complicated because you have to understand the type of the link. In a technical scenario, if I have an issue in Jira connected to a pull request, I can infer something about that. That pull request is part of a repository. That repository is part of a project. That project is part of a business initiative, et cetera. That initiative has a spreadsheet. Like, so the types of content are really important in the teamwork graph. And obviously, all of that in enterprise has permissions. So I need to be able to navigate

• 16:14Speaker 00

  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 Rover. So we call it for customers, often an enterprise search engine. It's probably one of the biggest, if not the biggest, enterprise search engine in the world at the moment. And I would also argue it's the best because we spend a lot of time, we have a lot of knowledge, to give you great ranking and context on that information. Now, 2019, when we started on teamwork graph, that was because we needed it to connect our workflow applications with all the other SaaS things you were doing. You're starting to use Figma diagrams over here in product management, and you started to see IT teams connecting, you know, the Data Dog or Big Panda or Splunk reports. And you started to see marketing teams

• 16:58Speaker 00

  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. Called three years ago when long come LLMs, we have a superpower change moment because...

• 17:13Speaker 00

  We have a graph of all of the objects in your company, your organizational knowledge. That's now become your organizational memory. Why does that change? Because now we can understand the content of the document, right? We can use the L L M to get out concepts, definitions, right? We have 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 Stereost 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 RoboChat. So obviously the graph and organizational memory is a large scale,

• 17:58Speaker 00

  permissioned knowledge base of your organization across hundreds of SaaS apps. That is at the core of what Robo 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're doing a 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 A I lets us do very new things in interesting ways. Those features from Robo already surface in Jira in lots of different ways. So, uh, you know, we said on our last earnings call, we've passed three and a half million A I Mao.

• 18:44Speaker 00

  And I still think we're the only public company that's giving out this number. Because in our world, like we, again, we solve collaboration problems across our platform. Collaboration doesn't happen unless someone's using it. Like collaboration without activity doesn't make any sense to me. So we've always tracked monthly active users as our number one metric. It's not how many customers we have, it's how many seats people have purchased. Uh, the gap, what I call the shelfware gap is if someone's bought a hundred seats and they have five Mao, we're in trouble. Like they're not going to keep buying a hundred seats. Maybe they buy 20 seats, right? So we care about activity, hence in A I. We always say we don't want to market AI, we want to ship it. And a lot of people are giving great demos and shipping things and talking about things.

• 19:27Speaker 00

  But they're not actually getting people to use them in organizations. We now have north of, that was a while ago now, three and a half million users every month that come and use our AI features and products. And yes, they can be coming to Rovo Chat to ask a question, you know, hey, how does this? What is the history of this piece of the organization? It might be coming to search and getting AI answers to a question that may come from a Google Doc. It may come from anywhere in their organization. But a lot of them are inside of Jira saying, hey, I want you to summarize this issue for me. I want you to tell me what's going on here. I want to assign this issue to an agent. I want to do all of these things. So I think the, I'm sorry, this is a long answer.

• 20:10Speaker 00

  I don't think that we're going to end up with kind of AI products and non-AI products. I think we're just going to end up with products. They're all going to be infused with AI. I think you need to think hard about a lot of these elements, like the data structures underneath them. What access to information do they have? Because Jira, that only has access to Confluence data, is nowhere near as useful a workflow and business process engine for a company in project work or in service work. As soon as it has access to Figma and Slack and Google Docs and Microsoft Teams and Zoom and all of the history of your organization, all of your Salesforce records, customer records, 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,

• 20:54Speaker 00

  but also changing the way that they can work, right? In terms of these integrated processes across, across your SaaS landscape.

• 21:03Lukas Biewald?

  Well, sorry for the focus on developer productivity, but this is like sort of my background. It's something I feel like passionate about. I saw you, you know, I saw you recently bought a company called DX, which is like kind of measures developer productivity. And, you know, and then on your website, you talk about measuring like AI-enabled developer productivity. I thought that's really interesting because, you know, I feel like I've been really wondering, you know, for myself and my team. Like is AI making us more efficient? You know, there's like a recent study, I think, where they asked people, do you think you're going to be more efficient? And people said, yes. And then after they used the AI, I asked, were you more efficient? And I was like highly correlated with thinking they were going to be more efficient. But it was actually uncorrelated with actually being more efficient.

• 21:44Lukas Biewald?

  And I, it made me think like, wow, I should not probably trust my, I do feel much more efficient with AI. But you know, that got me thinking like, am I actually more efficient? Are these developers in my organization, you know, more efficient? 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.

• 22:03Speaker 00

  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 like, that is a very poor way to measure developer efficiency.

• 22:27Lukas Biewald?

  Totally.

• 22:29Speaker 00

  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.

• 22:54Speaker 00

  Which is, again, there's lots of studies, it's about a third 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. And so we have a huge data set of being able to understand trends and how these things are changing. 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 higher level languages and JavaScript and TypeScript and everything.

• 23:39Speaker 00

  So languages itself, coding, AI, sorry, AWS, I can spin up a million machines. I can be more efficient.

• 23:46Lukas Biewald?

  That's a way, just to clarify though, so when you say coding speed, you mean like delivering value to customers? Or or something else?

• 23:53Speaker 00

  I mean, I have to start with an idea or an issue, a task. I turn that into a piece of code. That's actual physical characters.

• 24:03Lukas Biewald?

  Uh huh.

• 24:03Speaker 00

  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, etcetera? So there's a lot of those questions.

• 24:41Lukas Biewald?

  And so you're saying that code's speed has been improving for the last 50 years? Like, you just see this steady?

• 24:46Speaker 00

  I would argue, as we've built better languages, coding speed has improved. We've built better tools, right? I, um, you know, knew that the Jepbrains founders really well. We started in the Java kind of world in, in the early 2000s. Just 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, Jepbrains 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 autocomplete, the way they built these language models, like, Idea was absolutely amazing. It was a complete step change, right? And VS Code's come along.

• 25:29Speaker 00

  So we have lots of language improvements, tool improvements, 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. Um, I would say we are hit, we've hit an inflection point with, obviously, code generation. GitHub Copilot, that's now become like Groovy 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 a task into code.

• 26:04Speaker 00

  That is awesome. That's great, right? Internally, we use all five of those tools a lot. We really want to do this, but you then run into a separate problem, which is, 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 moved to VS Code or even IDEA wasn't very expensive. I think it was like 50 bucks a head kind of thing. 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?

• 26:47Speaker 00

  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. Again, 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 DORA metrics and all sorts of numbers like that. They have 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.

• 27:29Speaker 00

  These are numerical, they're 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. 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.

• 28:12Speaker 00

  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.

• 28:31Speaker 00

  You feel in the flow when 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've 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 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,

• 29:15Speaker 00

  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 because we, as humans, are going through this learning cycle about these technologies.

• 29:32Speaker 00

  And, you know, you had, you had one of my friends and competitors, I guess, on, recently, in Arvin from, from Gleam. 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, 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, the axe, 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.

• 30:16Speaker 00

  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, then... 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 between like rovo dev,

• 30:59Speaker 00

  Claude code, cursor and GitHub Copilot, which we have all four for for engineers here. 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 Mao 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 if there's like one coding tool.

• 31:26Lukas Biewald?

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

• 31:36Speaker 00

  Well, it look, it depends on on a lot of different things. And I think what you're going to see is 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. So i- i- if you think about rovo dev, right? Our coding agent, if you might say, and we we call it a software agent because our job is we want to take jury 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 that's coded good.

• 32:04Lukas Biewald?

  Totally.

• 32:06Speaker 00

  What what we've started doing in the rovo dev team quite a lot is work on self reflection. So coding tools are going to 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 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 said, I want 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.

• 32:50Speaker 00

  The code review process is really important, right? Some of the tools, and Robo Dev is very strong at this as an example, it sounds like I speak in my own book, so I can talk to you, the tools are much better at finding 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 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.

• 33:31Speaker 00

  That means when you ask us to go solve an issue or a problem, it

• 33:39Speaker 00

  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 a 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. 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 deliver customer value.

• 34:24Speaker 00

  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.

• 34:48Speaker 00

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

• 35:22Speaker 00

  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 a good cloud platform. Now I'll make a code change.

• 35:37Speaker 00

  It's very hard for tools to look at the entirety of Atlassian's code bases 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. So as an example, we had an internal service that changed its shape and location.

• 36:10Speaker 00

  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'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 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 is using RoboDev and Agents Adira and things. And I think it mostly used RoboDev was to write a few examples of how this worked.

• 36:54Speaker 00

  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 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, right? It is, um, I don't think, you know, I'm, 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.

• 37:38Speaker 00

  That is, that is the fear that, that, 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.

• 37:50Speaker 00

  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 out of the problem. 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 going to be pretty, pretty tricky.

• 38:30Speaker 00

  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, hmm, we were 1% off at the start, but after a thousand loops, we're in trouble.

• 38:44Speaker 00

  So I think those types of tasks where, you know, we talk about it as code maintenance. It's a pretty naff term.

• 38:51Speaker 00

  The analogy maybe to gardening is the easiest one 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 want to put down some rocks and I want to move around like, plant a big tree and it's good, 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 going to be done in a loop with the AI.

• 39:26Speaker 00

  And I think there's going to be lots of coding models to, to do that. So, yes, DX is gonna really, really help organizations.

• 39:36Speaker 00

  Understand their productivity, both qualitatively and quantitatively. But more importantly, come back with

• 39:43Speaker 00

  actions of where to improve that, right? 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 where you need to do them across massive codebases. That is where it's really, really, really helpful.

• 40:04Lukas Biewald?

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

• 40:39Speaker 00

  That's a good question. I'm not sure. I think

• 40:46Speaker 00

  like I come from a school of thought that AI can't create. I have to put this phrase this carefully.

• 40:56Speaker 00

  AI generating net new knowledge is a pretty tricky thing. Now arguably all knowledge is generated from other knowledge, right? But the idea is

• 41:06Speaker 00

  all businesses or 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?

• 41:22Speaker 00

  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 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 got to 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.

• 42:05Speaker 00

  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,

• 42:19Speaker 00

  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 of that, 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 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, this is awesome. You add the teamwork graph and your entire organizational memory. 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. You add all that, it can do amazing things, but it's still not going to create raw source knowledge, right? Insights and source knowledge without your help.

• 43:05Speaker 00

  So I think the thing that we would say is it's about the human AI collaboration loop.

• 43:13Speaker 00

  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, 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 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, I can give you some examples.

• 43:56Speaker 00

  We showed a demonstration at one of our, in one of our keynotes that came from a real world example, which is 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 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 want to 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.

• 44:40Speaker 00

  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. Or they have text based discussions. They're adding signal to that brainstorm.

• 45:11Speaker 00

  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 flow charts and write a document, spit out a conference 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 right, 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.

• 45:52Speaker 00

  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 the 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 five minute summary. We can chop a little piece of audio out. All this. Great. What we've done there is I can the knowledge of our organization, summarize it onto the whiteboard. Then the knowledge of the people we have today and kind of change the ordering and voting.

• 46:35Speaker 00

  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 that is tracked for a new person joins tomorrow. They can watch the video and we're getting this tribal knowledge 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 age. 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.

• 47:19Speaker 00

  I just don't think we'll ever reach the point that it disappears. Maybe that's a non controversial view. I think it's 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, to create any new value.

• 47:35Lukas Biewald?

  Well, I think it'll be definitely controversial in Silicon Valley right now, so that's great.

• 47:41Lukas Biewald?

  I guess one, 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 stuff that a junior developer would do is getting, you know, seems to be getting automated, you know, from my perspective, we continue to hire junior developers, but we see actually that it seems easier. You know, to hire them right now, like the demand is seem to rotate, you know, towards more senior folks. Are you seeing that? Does that? I mean, obviously, you need a pipeline of developers, you need kind of entry level positions, you know, to have, you know, a vibrant dev ecosystem.

• 48:26Speaker 00

  Look, I think there's two, two comments that maybe I disagree with or two views in the world. One is all developers are going to this beer or large numbers of them. I'm like, I think we'll have more developers in five years' time at Atlassian than we have today. I sat on the, I spoke with Matt Garmin at AWS at an event and he said exactly the same thing. He said, I agree with Mike, we're going to have more developers at AWS in five 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, I don't know why I agree with that. I don't, I don't think that's going to be the case. And I can give you a few rational thoughts. We're all going to have to see how the future plays out, right? I might be completely wrong.

• 49:09Speaker 00

  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.

• 49:28Speaker 00

  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.

• 49:36Speaker 00

  Fifteen 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 because the technology world keeps improving. I do think that what doesn't change about senior engineers is they cost more than junior engineers. So there is always going to be a case where you say, you know what, I'm going to 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 going to replace that makes any sense, because the idea is that only the senior people could use the AI. I'm like,

• 50:20Speaker 00

  wait, don't I want junior people, grad, first-year grad developers to come in and perform way better than grads did 10 years ago? Why? Because they've got AI coding tools? 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, RoboDev 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 ticked the approve box.

• 51:04Speaker 00

  The senior developer needs to talk to them about human accountability, 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 I have as many in the engineering sense yet. What happened in Loom was graduates, new to the workforce, were much more video-centric, probably because 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

• 51:46Speaker 00

  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 were used to popping up in 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, ah, the kids are under something like that was pretty efficient. I like just watching that and I like not turning up to that meeting. Joining instead of meeting is useful, 80% of them don't need to be happened, 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. 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.

• 52:30Lukas Biewald?

  Okay. So like slightly switching gears here, there's something I really wanted to ask you, which is, um, we had, I've had a board member at Weights of ISIS for a long time, Jay, uh, who I think was an executive of yours. And one of the, and he told me a lot of stories about you 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, it's really interesting. I feel like you're maybe the first company to really do what they call product led growth now. But 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 is like, hey, like, we don't want to grow too fast here. Like, you know, we want to 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.

• 53:15Lukas Biewald?

  Like, is that like, is that an accurate story of like something that, um, that happened? And then I wonder like what your thoughts are, because 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 a hundred million in revenue, you know, 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.

• 53:40Speaker 00

  I have a lot of takes there. Um,

• 53:44Speaker 00

  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 a hundred million ARR.

• 53:53Speaker 00

  And again,

• 53:56Speaker 00

  When we first had the inkling that maybe we could go public somewhere in the 2010 range, we're probably eight, nine years old as a business. I think we're doing, call it 50 million in revenue and probably 20 million in profit, right, growing 50% a year.

• 54:14Speaker 00

  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 we're like, going public is the thing I want to do. It was more like a possibility, right? At that time, you needed about a hundred 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?

• 54:34Speaker 00

  So, you know, things shift, right? We had billion dollar companies, remember? Now we're trillion dollar companies. Now there's a bunch of trillion dollar companies. So a part of it is just the, the natural shifting of things. Secondly, there's no doubt with, between AWS and cloud computing and payment systems and, and SaaS, 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.

• 55:02Speaker 00

  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 a hundred million dollars faster.

• 55:15Speaker 00

  And there's a lot of companies now that go from zero to zero.

• 55:20Speaker 00

  So I don't know if 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 in the past, people like, man, I didn't get to a hundred million dollars in revenue in two years. I must suck. And I'm like, geez, 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, like just don't count yourself out because you're not on this crazy, crazy journey.

• 55:54Speaker 00

  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 20, 2010 sort of ranges, 2008 to 2012, 13. A lot of great businesses founded that were growing faster than us now, just iconic companies that we don't think about. So.

• 56:13Speaker 00

  I would tell those founders, don't, don't just build things that people need and figure out a good model for distributing them and growing their business. Secondly, yes, we have for all time or a lot of time. 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.

• 56:40Speaker 00

  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 20, 20 and change percent, 21% I believe. Our cloud business, which is our largest business, grew 26% and our RPO, our revenue performance obligations, so the future revenue that we have contracted but not yet come into the 12th and 13th year grew 40%. And we're a five, six 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.

• 57:27Speaker 00

  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 $10 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 are you going to do? Right? It's really hard. So you're not going to invest in the architecture which will allow you to survive the AI disruption. You're not going to invest in all these things. So you always have to create a balance and at some level it's truism.

• 58:13Speaker 00

  Problem is when you get to that line ball decision. Short term revenue growth versus continued, right? I want to build durable businesses that will grow at north of 20, 30% five years from now. And 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. 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.

• 58:56Speaker 00

  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 four years from now? And where's it going to come from? And I think sometimes we get very short-term in the, in the founder sphere, right? Even the hundred million dollars in two years. It's like, well, tell me where they are in 10, right? Do they, do we think they're going to be a real multi-billion dollar business in 10 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.

• 59:38Speaker 00

  They have a, um, they generally don't care much about money. They generally have a delayed gratification in a business sense gene. They wanted 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

• 1:00:22Speaker 00

  as our president for a decade or more. Yeah, he buys into this too, right?

• 1:00:29Lukas Biewald?

  Well, I think like one thing that like, you know, one reason people focus on revenue is because 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, 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?

• 1:01:06Speaker 00

  Look, there are none that are that simple, I would say, that we track religiously. 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, we look at MCU, right? Which we call monthly core users, monthly collaboration users. Actually, I don't know what stands for. We just call it MCU everywhere. Which is sort of like, if you think about, think about Confluence as a system.

• 1:01:33Speaker 00

  I might have,

• 1:01:36Speaker 00

  I should have looked up the way it's in business, it would have been more interesting, but 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% now 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.

• 1:02:16Speaker 00

  So even inside Mao, you'd be like, okay, cool. Well, we just get more readers. And you're like, wow, 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, 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? This gets a 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 look at in terms of the deployment and distribution angle. So in our world, in the enterprise, you have a lot of gatekeepers. So you might have IT professionals whose job is to say, is this secure enough?

• 1:03:00Speaker 00

  Is this, I'm not going to roll it out, such as people like finding an application and adopting it. Someone feels, so we've got to think about, okay, are the IT fraternity happy with us in terms of security, compliance, governance, controls on 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 load 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?

• 1:03:39Speaker 00

  We have a, you know, seven day usage, D30, 2D30, whatever numbers you want to look at. We've got all of them in different spots, but basically you're saying, looking at some funnel and did they come back? Those are really important numbers. I think inside the sales world, there's 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 your 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?

• 1:04:24Speaker 00

  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 the pipeline for next year. And you want to arguably spend time with your future customers and making them happy, right? That's the best way to plant those seeds that you can then grow.

• 1:04:44Speaker 00

  One of the things my co-founder who retired last year was very keen on is you've got to manage in any business, the difference between seeding and harvesting. So the dog is farming analogy is 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 pots so you can spread your revenue out. And if you harvest continually or you're in a

• 1:05:17Speaker 00

  a forest, if you're, if you're logging or something, hopefully sustainable logging, but if you're doing some sort of logging, you're cutting things down. You're cutting down more trees, the faster they're 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 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?

• 1:05:46Speaker 00

  And that's a really applicable business lesson, I would argue, for seeding versus harvesting. And whatever metrics you're getting, are those metrics?

• 1:05:55Speaker 00

  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. How many tons of wheat I collected today? And like, let's just harvest some more. And at some point you realize the field's 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.

• 1:06:39Speaker 00

  And maybe AI again will just replace us all. And 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.

• 1:06:48Lukas Biewald?

  All right. Well, Mike, I'm getting picked 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. But how do you, it should probably be quick because I, I'm told to wrap it up. But how do you like, you know, you're 20 plus years in and I was just curious, like, how do you stay like creative and curious at, at this point in your career? Or is it effortless?

• 1:07:13Speaker 00

  Wouldn't say it's effortless. 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.

• 1:07:24Speaker 00

  Asking the right questions, creating things. That is the fundamental nature of our industry, right? It's a very organic industry.

• 1:07:32Lukas Biewald?

  Totally. Great with it, Ed, man. Thanks, Mike.

• 1:07:36Lukas Biewald?

  Really appreciate your time.

• 1:07:36Speaker 00

  Thanks, Lucas. Hey, Norris.

• 1:07:39Lukas Biewald?

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