← The MAD Podcast with Matt Turck
The MAD Podcast with Matt Turck
Inside Canva’s $3B ARR AI Design Rocketship — CTO Brendan Humphreys on Magic Studio & Canva Code
00:56:38
Loading summary
Transcript110 lines
- [00:00]
A
We've invested enormously in putting a platform abstraction over a lot of the third party AI like OpenAI, and that allows us to rapidly switch out models and experiment. When new models come onto the market that do something exciting, we can get them in front of users in really cohesive experiences very, very quickly. Canva code is an interesting feature that went from kind of first idea through to production in about three months and was now serving to 100 million users and climbing.
- [00:30]
B
Welcome to the Mad podcast. Today we're sitting down with Brandon Humphries, the CTO of Canva. Many people know Canva, the immensely popular visual communication platform, but not everyone realizes how incredible a business it has become in a few short years since it was founded in 2012. The company just announced that it now generates $3 billion in annual recurring revenue. Brendan has a knack for being part of fantastic companies. He joined Canva in its early days as one of its first 12 employ after spending several years at the other breakout Australian tech company, Atlassian. This is a great inside look at building a rocket ship and deploying generative AI at scale. Please enjoy this great conversation with Brandon Humphries. Brendan, welcome.
- [01:15]
A
Thank you.
- [01:15]
B
Thanks for doing this. I thought a fun place to start would be to share a few metrics about the company because obviously people know that Canva is a fantastic company, but I don't know that people have quite internalized how fantastic a business it is that you all have built over the last 10 plus years. So in terms of numbers, you announced literally yesterday in a press release that your annual recurring revenue is now surpassing $3 billion, which means that your growth rate is around 40% to 50% and actually accelerating at scale. And on top of that, you're doing so profitably. You've been consistently profitable for the last seven plus years. You have 230 million monthly active users, including 24 million paying subscribers in 190 countries. And and your customer base, especially as you've been pushing into The Enterprise, includes 95% of the Fortune 500 with teams at Atlassian, New York Stock Exchange and HP. So incredible stats, incredible business all around.
- [02:12]
A
Yeah, it's an amazing journey to be on and a fantastic. We're at a fantastic point right now. Absolutely.
- [02:18]
B
How does that feel? You've been on this rocket ship for over 10 years. Do you sometime get to take a step back and realize how incredible a you'll have built? Or is that a succession of fire drills from the inside?
- [02:34]
A
It does feel a little surreal, but I do recall when I joined the company when I made the decision to join. I could really understand that there was multiple pathways to revenue. It was a really simple idea that was very, very captivating. I'd actually tried to build something similar in my spare time. And so I really believed it was very easy to believe in the business model. And that made it very easy to kind of like get on board 100%. And I think I've been there ever since.
- [03:06]
B
The original idea of Canva was simple design in the browser in 2012, was it?
- [03:14]
A
That's right, yes. So Mel recognized that the entirety of the design process involved so many different tools that each of them had a steep learning curve. There was often real friction between the tools and. And that kept the barrier to entry really, really high. So she saw this opportunity to consolidate it into a platform that was web based. You know, the source of our success, that. That great insight.
- [03:40]
B
And you joined in 2014 when the company had only 12 employees?
- [03:46]
A
Yeah, something like that.
- [03:46]
B
You were the 12th employee.
- [03:47]
A
I. Something like that, yeah, something like that, yeah.
- [03:50]
B
And you joined from Atlassian, which at the time was already a. An incredibly successful company. What was process and perhaps to generalize it, how does one, as an up and coming engineering leader, pick the next company to go to? Because clearly that was an incredible pick.
- [04:13]
A
How do you. How do you pick the winners? Yeah, it's. Look, I've been very lucky. I joined atlassian back in 2007 through an acquisition. Atlassian bought my company. And around about the time that I. Well, 2014, I was. I kind of recognized that I was in a little bit of a rut. I had certainly enjoyed the ride at Atlassian. They'd gone through their own hypergrowth phase and they were just leading up to ipo, But I really wanted to get back down to just building something. And I met. Through a friend, I met Mel and Cliff and I instantly fell in love with the business model. I don't think I have great advice on how to pick winners.
- [05:01]
B
Perhaps less picking winners, more. What do you optimize for? I mean, it sounds like you optimize for the founders and believing in the mission. Some people may optimize for. Well, that's a famous company. Therefore, I will learn to grow as an engineer because it's scaling, so I'm going to see scale.
- [05:20]
A
But.
- [05:20]
B
But you deliberately chose a small company.
- [05:22]
A
Right. So there was a combination of things that were really attractive from the first time I walked in the door. Certainly Melcliffe and Cam are really impressive founders, both with the expansiveness of their ambition, but also they're Just really nice people and that helps a lot. The engineering team back then was four other engineers, the CTO and the first engineer that was hired, Dave Herndon, ex Google engineer. Just a prodigiously talented engineer, very, very smart, very zen engineer. I would describe him as the engineer's engineer. And meeting him and chatting to him, I realized this is someone that I could learn from, someone I could partner with. And that combined with that goodwill in the founders, the ambition in the founders, I thought, yep, I'm going to take a plunge here.
- [06:17]
B
And you mentioned that you joined Atlassian through the acquisition of your company. How has having been a founder helped you as a engineering leader?
- [06:29]
A
I think it helps create agency. I think that any organization that grows beyond a handful of people, the bystander effect is a real problem, that it's too easy to think you come across a problem and you think, that's not my problem. But when you own a company, everything's your problem. And so having that kind of high agency when you're, when you're attacking problems doesn't mean you're going to solve every problem, but you recognize the problems and you're very engaged and you're happy to cross over the swim lanes a lot. Certainly at early stage companies you've got to be doing that a lot. You've got to be really a bit of a generalist. And so I think that's a really powerful thought that you really get ingrained when you're kind of on the line, on the hook for everything, when you're running your own company and everything.
- [07:23]
B
On that, how was your progression from employee number 12 or whatever the number was, to today getting from such a small company to a company at this level of scale? It means that you've done very different jobs across the years. What was your journey and how did you scale yourself up as the business itself scaled?
- [07:48]
A
So at Atlassian, I had worked my way up into, I guess, middle management. I had spent some time there looking after a bunch of teams and then I realized I really wanted to get back on the tools. So I kind of fought my way back down into engineering and was a principal engineer there for a while and then jumped across to Canva as an engineer. And I worked at Canva for a good three or four years just primarily on the tool, just writing code. As we started to double in size every year in our engineering org, there needed to be some management of that kind of horde of engineers. And because I had that experience, it was very natural for me to kind of step away from the tools a little bit and find myself more in a management role. And I've always tried to keep myself active in the tools. As we've grown, we've continued to double in size. Now we have about 2,300 engineers. It's extremely difficult, but so you do.
- [08:50]
B
That on weekends or try and.
- [08:53]
A
Try and quarantine some time to play. And certainly the AI tooling helps with my rusty coding skills, but I actually find a lot of intellectual enjoyment out of solving different intellectual problems, like problems of organizational complexity. Figuring out how to organize an organization to get a particular problem solved. That's actually Quite interesting challenge.
- [09:24]
B
2,300 engineers is a high number relative to the total size of the company. I don't know what the total number is.
- [09:32]
A
5,000 employees.
- [09:33]
B
Yeah. So that's almost half. Which for a company at this scale presumably speaks volumes to the innovation pace of the company, how much you're constantly building.
- [09:43]
A
I think it speaks to the ambition of the founders. You know, this broad mission to empower the world to design it has meant that the product is quite expansive. And as the feature sets expanded, we've had to expand engineering to stand up teams that can own these features and operate them in production.
- [10:01]
B
And you were saying right before we started recording this that you're based in Sydney, but the team is still largely distributed, working from home with some hubs. Talk to that a little bit. Where, where are folks and what's your in office or out of the office stance?
- [10:21]
A
Yeah, so we do predominantly also. Our origins are Sydney, Australia. We have a large office there. In fact, we're building a new one. That's very exciting. We have, we. We have a hybrid working culture so people can come into a local hub and work. We have, we set up hubs when there is a. A large enough number of people in a particular geography. Through Covid, we were still doubling in size in our engineering org every year and we kind of realized that we can keep that pace and hire people that are just time zone compatible. So that meant that we spread up and down the eastern seaboard of Australia, across to Perth, across to New Zealand. Through acquisition, we have acquired engineering teams. So we have about 400 engineers right through Europe through our acquisitions.
- [11:15]
B
Any lessons learned managing people in a bunch of different time zones? One of the key questions of the moment. It feels like everybody went remote during COVID It feels like the pendulum has swung the other way. And now there's very much an office culture, at least in some pockets of the tech world. But you're, you're clearly showing that it's possible to scale globally. How do you do it?
- [11:42]
A
I will say it's not without challenge. The key is to find ways for teams in kind of incompatible time zones to be autonomous, as autonomous as possible. Usually that means just finding the right seams in the product so there's real ownership in these locations. And that's what we've strived to do. There will be the occasional need for a meeting and when you have to meet between Sydney and say, Prague, that's. That's not a pleasant. Someone's going to get the short end of the stick on that one. Right. An early morning or a late night every now and then is going to be needed. But where possible we want to do. We focus on a lot of technical, written technical communication, a lot of async communication. So we just minimize that face to face, the need for face to face contact.
- [12:31]
B
And do you have regional leaders, VP Eng in different locations? How does that work from an org chart perspective?
- [12:38]
A
We have leaders, we have geography leaders. They just tend to be kind of general manager types. They're not engineering specific. All of engineering reports up through me in Sydney.
- [12:52]
B
And for that collaboration and the async part that you mentioned, what's the stack? Are you a slack shop? Are you Jira, what do you use?
- [13:02]
A
Canva is an enterprise tool, so it has a full doc suite, so you can use it for sharing and collaborating on docs, presentations, whiteboards, and that's a very, very effective tool for asynchronous collaboration.
- [13:16]
B
All right, let's switch to AI. Each time a big lab releases an AI feature, especially a visual one, there's somebody somewhere on the Internet that says, well, that's going to be terrible news for Canva. And it seems that one, it hasn't been much of an issue so far given the growth of the company. And two, in general, you guys seem to have a very different stance on that. So how do you all think about AI as an opportunity or possibly a threat? Have there been any moments where despite being bullish on AI, you all look at each other and say, oh, this one actually might be a problem.
- [13:56]
A
We're certainly alert to the rise in visual AI, but we feel we're actually really well positioned. We can use third party models when they become available, integrate them into our platform very, very quickly and provide a really rich, cohesive experience. We can facilitate collaboration, we can let you organize your content, we can provide brand kit controls, all of these tools that perhaps your average AI centric startup can't. And indeed we have a very rich API layer that is available for third party developers. Our ecosystem, offering a lot of niche AI startups are finding is a fantastic distribution channel. So they've got their niche product, they can come and build a rich integration into Canva and then suddenly they get distribution, they get a lot of users. We've had a lot of success and that's a win win for us and for them.
- [15:07]
B
Oh, interesting. So there's some. Beyond the models and the sort of infrastructure part, there are actual products which are effectively OEM through Canva.
- [15:14]
A
Well, they're literally apps available in an App store that we provide.
- [15:18]
B
Oh, the App Store. So the App Store.
- [15:19]
A
Okay.
- [15:19]
B
Distribution through the App Store. Okay, got it. We got it. Okay. You have been using AI and deploying AI for quite a bit. And just to provide general context, I think the first feature was a background remover or maybe there was an acquisition. Talk to this. How long you all have been thinking about AI? Even as far as I can tell, before ChatGPT really appeared on the scene.
- [15:47]
A
So we've certainly. Cliff likes to say we've been talking about AI and dabbling in AI long before it was cool. We've stood up our own machine learning team many, many years ago. Like 2017 I think was when we first had a serious crack at building an ML team. And that was all about propensity modeling and building recommendations, engines. We have a vast library of content that we want to serve to users and we want to be able to understand their intent and then be able to serve exactly the right content for the right context so that we have quite sophisticated ML models that help with that. We did acquire Kaleido. Kaleido was actually integrated through our App Store as removed bg and we loved their product. Their product was so popular on the Canva platform. We loved it so much. Then we met the team, we loved them, we acquired them. We've since brought all of their expertise in house. We've continued to build a lot of in house AI expertise. We have over 200 machine learning engineers on staff. We've just started to form our own or coalesce a lot of that expertise into more or less a standalone research organization that is kind of protected somewhat from the product cycle. And we'll continue to build on the great work that both research teams in Canva and inside one of our more recent acquisitions, Leonardo, have been doing, which is more based around foundational model work and deeper research.
- [17:24]
B
So that's very interesting. So it's 200 machine learning AI folks, and so you're saying there is a central lab that does R and D research.
- [17:34]
A
Yeah. So we take a hybrid approach there. We certainly have teams that are dedicated to more foundational research, but we also have embedded folks embedded in product teams who are doing research and they tend to be on shorter product cycles and they tend to, you know, their output is usually a prototype which product will look at and make judgments about. And then we'll see if we want to turn that into something that's a production feature and we'll try to turn those around very, very quickly. We've invested enormously in putting a platform abstraction over a lot of the third party AI that we use, whether that's kind of like base layer infrastructure like Bedrock or SageMaker, or whether it's third party AI providers like OpenAI. And that allows us to rapidly switch out models and experiment with different models. It allows us to augment models with our own proprietary tech and it allows us to really iterate very, very quickly. When new models come onto the market that do something exciting, we can get them in front of users in really cohesive experiences very, very quickly. So we were able to, for instance, Canva code is an interesting feature that we've just launched just back in April. That's a feature that allows users to build little intelligent interactive widgets in their designs that went from kind of first idea through to production in about three months and was now serving to 100 million users and climbing.
- [19:11]
B
Fantastic. You anticipated some of my questions, let's unpack some of it. So let's start with features you just mentioned. Canva code. You guys had a very impressive last 12 months in terms of shipping velocity and I wrote down Matic Studio, Dreamlab, Canva AI, Canva code, Canva sheets. Maybe give us a little bit of a tour of what those different things do at a high level. Magic Studio to start.
- [19:45]
A
Yeah. So Magic Studio is a collection of AI powered tools, both text and visual. There are text based tools that allow you to, for instance, modify text to be in your particular voice or in a brand voice, which is really powerful. There's text summarization, text expansion. We've got a whole suite of image editing that's really powerful, whether that's infill or outfill. We've got Magic Grab, which is an amazing feature which basically allows you to treat a rasted image as something that you can decompose. You can pick objects up and move them around. Magic Arrays uses similar technology to be able to remove and then infill in a very smart way. We did launch a Sheets product in April. That's our take on a spreadsheet product. It is designed to be very, very easy to use, fully integrated into the visual communication experience of Canva. And it will be our kind of data backbone going forward. So when we want to do more data driven products, we'll be using Canva Sheets as the kind of data source for that.
- [21:02]
B
It does feel from the outside as a significant expansion, going from a visual suite to starting getting into effectively data infra but is the goal ultimately for the company is just like all around productivity, starting with design, but then expanding to just about everything.
- [21:21]
A
We see ourselves at the intersection between productivity and creativity. And we think that increasingly in the workplace visual communication's just coming to the forefront. And so we have been rounding out our feature set. We have a Docs product that allows users to create online documents, collaborate on them, but do so in a really visual way. So they can embed rich visuals, they can embed graphics very easily and they can change different doctypes within the one design. So you can have a quite text heavy document on one page and then you can have on the next page you can have a whiteboard where you can be doing some collaborative whiteboarding. You can have sections of a presentation in the same design and that's an amazingly powerful way to collaborate on a particular project because different contributors to a project need different assets and normally it's quite hard to organize all those assets and here they're all just in one design space.
- [22:21]
B
What about Dreamlab and Canva AI? What do those do?
- [22:24]
A
So Dreamlab was our first integration with Leo. So Leonardo we acquired last year. They're an amazing Australian based AI company. Visual AI company Dreamlab is prompt based image generation and using its own foundational model.
- [22:46]
B
And all of those products work in a copilot kind of experience where you interact with the software and the platform, asking the product to do something for you.
- [22:58]
A
So we do have a chat interface, Canva AI and we are expanding that at the moment. There are some features within Canva that are powered conversationally, but others that are just more of a traditional software experience.
- [23:14]
B
And where I'm going with this is the inevitable question of 2025 around agents. To which extent do you have agents? Do you currently plan on having agents where some of those design functions could be outsourced to an AI coworker?
- [23:32]
A
Yes, certainly we are paying attention to the current excitement around agents. I think there's a bit of a definitional problem at the moment as to what exactly an agent is we certainly, yes, I have my own idea around what agents are, but maybe we don't get into the definitional. We certainly have behind Canva AI quite sophisticated orchestration that you could call an agentic solution. It's inferring intent at a very abstract level from a user prompt and then planning a course of action and then executing on that action internally. We have Agentix solutions deployed for instance in our customer support. But we're using a lot of agentic solution there where first line support, when a query comes in from a user that goes through an agentic flow and quite often we can handle user requests purely with that agentic flow, but within the product itself, yes, we're definitely looking at that. We're also thinking about a future where access to CANVA might be mediated by some other agent. And so we're looking definitely at model context protocol. We have our own model context protocol that we've stood up just internally and we're certainly talking to the big vendors about interactions there that are possible.
- [24:59]
B
And you view this both as an opportunity but also something to be potentially concerned about in double clicking on what you just said, where canva could be a part of somebody else's chain as opposed to people coming to Canva logging in. Having a Canva experience, is that something that you're worried about?
- [25:24]
A
It's not actually a concern. We see Canva as a destination. If you are doing any kind of visual communication, then there are going to be natural limits to a conversational interface and people are going to want to be able to collaborate, they're going to want to be able to control for brand, they're going to want to be able to organize their content content. There are going to be limits to how you want to interact with the design conversationally. So we think a future that we see is that if you, if you are, if you do have your personal chatbot and you want to do some design, you might get a one shot design there that then you can be transported into a Canva experience where you're actually able to stop talking about the design or asking a machine to do something and actually just play with it as you would normally with a mouse and picking things up and moving them around. I think that that is the essence of kind of human creativity and I think that that's not going to go away.
- [26:21]
B
That's an incredibly impressive list of product and features around AI that was shipped literally over the last 12 to 18 months. How do you guys do it? How do you manage to have this kind of velocity, especially at this kind of scale. And is there something different about shipping AI features versus regular features?
- [26:43]
A
So thank you for saying we have high velocity. I'll take that compliment. It certainly feels like breakneck speed at times. The technology Org we're very focused on really thinking hard about the domain model that we are implementing and then building a set of composable components with powerful APIs internally that enables product teams to move very, very quickly because they're sitting on top of a rich set of functionality. It takes real care and diligence to build out that internally consistent set of surfaces and services that back those surfaces, keeping control of the domain model so the domain model doesn't just explode into this kind of combinatorial explosion of complexity. And so we spend a lot of time thinking about that. We want the service teams to be thinking very carefully about how do we APIs, do we provide product teams so that product teams can move very quickly? With AI, it's more of the same. It's thinking very deeply about what's the AI platform layer that we can provide. Product teams can be getting the benefits of AI without necessarily having to go deep on the technology. Having said that, we are very focused on this kind of democratization of knowledge around AI in our technology Org. We think that once upon a time in software teams you'd have a DBA on the team. But now a DBA is not really a skill anymore because everyone the abstractions above databases are such that you don't really need that deep skill unless you're dealing with very, very specific circumstances. We like to think of that. But the same is going to happen with AI technologies and we're seeing it now with the tooling that's out there. It's a real democratization. A lot of engineers who have no formal training in AI are picking up these skills and figuring out how to use these tools and then being able to build AI first features very, very successfully. So we want to enable that and we invest a lot in education of our engineers, lifting them up to understand how these LLMs work, how to interact with them, how to effectively build product around them, which is not intuitive. Always a lot of things that you have to wrap your head around, particularly the non determinism, is a tricky thing. I think a lot of software engineers are trained, particularly the more senior engineers are trained in wanting to write a whole set of unit tests based on a deterministic system. But when you've got a non deterministic system, you have to kind of move your mindset to now we're going to test with evals, which are much more probabilistic. So it's a little bit of a mind shift. There's a lot of other shifts you have to make as a software engineer, but we're very much about empowering engineers to understand the technology, firstly to help in our product, but also, and we might be, maybe we're going to go in this direction in the conversation to understand that their jobs have changed now that these AI tools, tools in the coding space are so powerful. Their jobs have essentially changed. So we really want to enable that learning and that rediscovery and let each engineer have their moment of realization that, oh, wow, I now have a different way of working and it's a more productive way of working because I have these very powerful tools in the loop.
- [30:21]
B
You wrote on LinkedIn a blog post a couple of months ago where I wouldn't say that you were necessarily super excited about the concept of Vibe coding, if that's a fair way of putting it. So maybe walk us through how you think about AI tools. GitHub, Copilot, Cursor, Vibe coding, where that fits in the organization or not.
- [30:48]
A
Firstly, some definitions. So when I wrote that blog post, I was referencing perhaps a very tight definition of Vibe coding. This idea of giving into the vibes, it very much suggests that you only focus on the prompts. In effect, the prompt becomes the source of truth. In the same way that when you write source code today and you feed it to a compiler and you don't really worry about the compiler output, Vibe coding seemed to suggest that, well, now the prompts are the source code and the actual generated source code is something you don't have to worry about. We don't think the tools are there yet. I'm not sure the tools will ever get there, but at the moment they're certainly not there. That's not to say that they aren't powerful. They're extremely powerful. And we have deployed them at scale At Canva and in my travels talking to senior engineers within Canva, you couldn't pry these tools out of their hands. They are far more productive with these tools. But we have a very important rule that you need to own the output of the tool. That means you have to understand it as if you'd written everything yourself. Because ultimately the generated source is the source of truth. And it's going to go into the repository under your name. It'll go via peer review. We have a strong culture of peer review. And so another human's going to have to read it and understand it. I'm very excited by the productivity lift that we've seen with these tools and I think we've got a ways to go.
- [32:25]
B
So it's real. You're seeing a real productivity lift in terms of.
- [32:30]
A
Yes. Well, we could probably spend an hour talking about how do you measure productivity in engineering teams. But we certainly are seeing in some metrics that we measure that we consider to be good proxies for productivity, we are seeing a significant, like a double digit percentage increase in productivity.
- [32:47]
B
So without getting into the definition, but in this case defined as speed to product, just producing more faster.
- [32:55]
A
If there's any canva engineers listening, this is not how your performance is rated. This is a number of PRs merged in a week. You know, we're seeing about 30% more PRs merged for from engineers who are using these tools predominantly and for peer review.
- [33:16]
B
Is AI generated code as easy to review as human generated code or is there a question of volume that just more of it. Therefore it takes longer to review it.
- [33:30]
A
I think this is the real challenge with a peer review culture is that it's very easy to write a relatively small prompt and end up with volumes and volumes of code. We are seeing some success with AI assisted code review. I think that is inevitable. That author with AI superpower will be matched by reviewer with AI superpower. I think that's an inevitable path that will go down at scale. There are anti patterns that we see. We did have one enterprising engineer who vibe coded his way to I think a 50,000 line pull request and then lobbed it over the fence to reviewers. Good luck. Yeah, good luck. We have a guideline that we really want to see PRs in the order of hundreds of lines of diff, not 50,000 lines, which is not an easy task for anyone to review in any reasonable amount of time. So there's challenges there. But I think again, if you've got AI on one side in the authoring, then I think you can certainly have AI assisting and guiding a reviewer. Then I think that works at scale as well.
- [34:35]
B
Does the productivity jump impact your hiring plans in any way?
- [34:41]
A
That's a good question. We have slowed down hiring a little bit for a number of reasons. We are looking at, you know, we wanted to just take a pause and understand where the market's going with these AI tools. We are still hiring, but it's not hiring as fast. There's a challenge for our industry in that we do see kind of slightly bipolar results for these tools in the hands of a senior Engineer who can tell good code from bad code. They're very, very powerful. But for graduate engineers, for junior engineers, they can be quite dangerous because they just don't know what they're looking at when they've generated a bunch of code. I think there's a challenge for the industry. We do have a graduate intake program. We will still be taking grads in at the beginning of the year next year, but we're just taking a pause now. I think the way that I'm thinking about it personally is that engineers are more productive. If you've got a lot of work to do, then why wouldn't you want more productive engineers to throw at that work? So I think we've got room to grow our engineering org.
- [35:46]
B
And after the pause, how do you think about that problem of junior engineers? That will be vibe coding or whatever the better term is, sort of natively. Do you need to have an internal program where you train them on some core logic that they will just not naturally know?
- [36:07]
A
I think so. I think there's this kind of, I read somewhere, this kind of advice. What do you do if you're graduating? I just focus on critical thinking. But critical thinking is something you can't really teach. It's something that you need to build around a domain of knowledge, and the only way you get a domain of knowledge is to work in that domain. So I think at canva, we'll be focusing on probably just more careful onboarding, more careful peer review of grads. We will be more picky. We will be looking for the grads who bring deep first principles, thinking strong, really strong CS fundamentals, but also show us some of those human qualities. Empathy and engineering is a vastly underrated skill. And it is a skill. It's not a talent. It's something that you can teach engineers.
- [37:00]
B
How does that manifest? What is empathy in engineering?
- [37:04]
A
So empathy, I think it's got this kind of wishy washy, softy, soft, fluffy feeling to it when you say empathy. But really it's about getting in someone's head and understanding when you're having any kind of collaboration with someone, what's their point of view? Why are they saying the things they're saying? Why are they acting in the way that they're acting? In a large engineering organization, it's absolutely essential that we have productive collaboration. And a key to productive collaboration is being able to empathize with your collaborators so that you can very quickly get on the same page and then all be running in the same direction. Just to mix my metaphors. So we teach skills internally around this. We teach. There's a great improv trick to keep a conversation going, which is just the rhetorical device of saying yes and when you're contributing to an argument so that you're not shutting your mind off to possibility, continuing the conversation, opening your mind to what's been said, but also with the. And allowing you to add more context. We also educate people about techniques like Steel Manning. That is listening to someone else's argument that may be different to yours and then being able to restate it in its. In the strongest possible terms with genuine intent. You know, one of two things happens when you do that. You may change your own mind when you've been able to. When you've forced yourself to take on board all of their context and then restate their argument in the strongest possible way. That might convince you that their way is actually correct, but at the very least it will build genuine trust with the person that you're collaborating with. And if they're doing it back to you, then it's a very, very productive way to resolve differences. You know, technical differences come up all the time. It's a great way of resolving those technical differences. Related is the principle of charity. You know, just really taking people, understanding that most people are reasonable and want to do the right thing. They just have different context and different incentives. So. So building empathy for their context and their incentives again will help you be productive in a team setting.
- [39:21]
B
It feels particularly important in the setting that you were describing having. What Was the number? 4,200.
- [39:29]
A
No, 2,320.
- [39:30]
B
300 engine in the context you describe having a 2,300 engineer organization spread across multiple locations and continents. Very fascinating. Going back to AI behind the scenes at Canva. So you mentioned some elements of the stack. So let's start with models. So it sounds like you're using some OpenAI and Anthropic for some things. And then you have your own foundation model efforts through Leonardo and others. How do you think about the build versus buy?
- [40:05]
A
We have an engineering value, strive for pragmatic excellence and. And so we are ruthlessly pragmatic in whether to build versus buy. And that goes across all elements of functionality I'm a huge believer in. I think it was Jeff Bezos who came out with that famous saying of don't spend time on undifferentiated heavy lifting. Certainly we want to leverage best of breed models. If they're third party and they're available via an API, then we will. If they're third party open source models, then we can host them ourselves. Then we will do that. But we do provide a platform, as I said, we put a platform abstraction over that so that we can chop and change quite quickly. We are investing heavily in our own model development. LEO has given us a great foundation for that, no pun intended. And we have billions of very unique opt in data points around design creation, design intent, ingredient selection. We're mining to produce real insights into how to improve people's designs, how to help people in their design activities.
- [41:10]
B
As in a data flywheel of reinforcement learning where positive actions or any action indicates how people use the product and whether they like the outcome or not. Okay, Leonardo that you mentioned was an Australian company that had what, 150 people or something like that?
- [41:30]
A
Yes, don't quote me. Yes, I think around about 150 doing.
- [41:33]
B
Foundation models for visual stuff. Interesting. And so the decision to acquire was to continue build foundation models, which there is certainly a current of thinking in the current AI landscape where people say, well stop building your own models. It makes no sense because the foundation models, by becoming ever more general are going to do a lot of things that any kind of specialized model does. But that's, you know, not everybody agrees with that. But clearly you guys want to maintain at least independence through your own model. How do you think about it?
- [42:15]
A
So Leonardo's got a very successful end user product in market and so we're keeping that running as well.
- [42:24]
B
Independently.
- [42:25]
A
Yeah, we primarily acquired LEO for their research capability though their research capability's phenomenal. They've managed to build a world class research team that's spread all around the world. On the question of foundational models, I don't think that race has been won certainly. And we again we're radically pragmatic there. LEO have just shipped an amazing set of features that uses Google's VO3 model. It uses the latest flux models. So we're using, you know, even Leo's using third party and internal models. We do think we are uniquely positioned to be in that foundational model space. So maybe that advice of kind of like don't be in the foundational model space is good general advice, but we think that we are in a quite unique position in terms of the data that we have to pursue that particular avenue.
- [43:25]
B
Do you use any open source model?
- [43:27]
A
We do, we use metas, we use models from stable diffusion segment. Anything is an open source model that we use. I know we've tried Llama. So yeah, we have certainly looked at those models.
- [43:45]
B
How about the tooling layer orchestration? All the things, any tips, recommendations, things that work, don't work, that you've tried, that you like, that you don't like.
- [43:55]
A
So we have our own proprietary platform layer that sits on top of tools like Vertex from Google or Bedrock from Amazon. I think certainly Vertex or Bedrock, really impressive inference serving. We don't have a strong preference. We try and maintain footprint across both to give us flexibility. And we have our own model serving capabilities internally which are part of that AI platform that I mentioned.
- [44:33]
B
And you mentioned eval a few minutes ago. How do you go about it? Same thing. Do you use third party tools? Do you do your own evals for the specific job to be done here?
- [44:44]
A
We use weights and biases for our evals and we have our own eval framework that we've built.
- [44:51]
B
How do you think about hallucinations and AI being stochastic and not deterministic, which perhaps you could argue for creation of visual matters less, except you all made a big push in the enterprise, so presumably when it comes to things like brand guidelines, you need to be pretty accurate. So yeah, how do you think about hallucinations and then guardrails and that kind of stuff?
- [45:18]
A
Yeah, it's an interesting question. It's an unsolved problem. If a model gets it right 90% of the time, then 10% of the time it's getting it wrong right. That's going to be acceptable in some cases and not in others. For some of our AI implementations we decompose the problem and use much more orchestration that's based on heuristics with elements that are sold by LLMs. That gives us much more determinism and much more control. So if it's really important, that's the way we're going to solve it. There'll certainly be AI in the mix, but it's not like hand the problem to the AI and then hope for the best for other spaces, as you said. When it's more creative, then perhaps you can do that. Yeah, the hallucination problem is interesting. It's minimized, but it's still there and I'm not sure it's going to go away.
- [46:07]
B
Is AI security something that you think about, you know, prompt injections and.
- [46:13]
A
Absolutely, we think very carefully about prompt injection. We are very, very careful. We have a world class security team that has rapidly upskilled on security as it applies to AI. So we're very careful in that regard. Very sensitive to being in that enterprise space.
- [46:30]
B
Talking about enterprise, that seems to be one key strategic initiative that you've had over the last couple of years in particular, was there anything specific other than what you would imagine around security and sort of enterprise grade feature that was part of that push? We have a number of companies that we all work with as VCs, early stage startups that at some point graduate from that early kind of PLG inbound motion to being outbound and enterprise focused. From an engineering standpoint standpoint and product standpoint, any sort of tips and tricks about what took longer than you thought or was harder than you, you would have thought would have imagined.
- [47:11]
A
Catering to an enterprise market, it certainly pulls the product teams in different directions. Enterprise customers want sophisticated admin controls, they want sophisticated auth, they want data residency. These kinds of considerations, if you haven't baked them into your product early, they become quite expensive to retrofit. Very early in Canva's architectural journey we put a quite good abstraction in over our AWS infrastructure. But I do think back now and wonder, ooh, we could have just spent a little bit more time really abstracting region based storage. It would have been cheap to do then, we have got it now. But it was a massive engineering effort. You know, back when it was 10 of us and a few services and a few databases, it would have been relatively cheap to kind of build that culture in there, build that kind of tax, if you like, on every product that you have to think about what region shard you're going to store the data in. Having to retrofit it across hundreds of teams, hundreds of services was a monumental lift.
- [48:27]
B
Any other sort of scalability lesson, you know, going from that 1012 person team to the scale today in terms of architectural decisions, technical debt, anything that you know, in retrospect you wish you had done earlier.
- [48:44]
A
Technical debt is, I mean it's a dirty word, it shouldn't be a dirty word. Technical debt, Debt is an extremely useful thing when you're a startup. And we had the high interest credit card of technical debt for a few moments in Canvas history and I'll tell you about two of them. One was our original editor, we call it E1. It was a JavaScript kind of jQuery big ball of mud that was kind of hero coded by a few people and it got so big and so unwieldy that it became very, very difficult to add new features without kind of non deterministic behavior cropping up in it. I mean it was an opportunity cost. You know, we could have re engineered that, but we were busy building essential services that were going to power the next generation of features that we were trying to get to market. By the time we were ready to rewrite it, we did have to pay a lot of technical debt down. We went through a huge RE engineering effort, two years to rebuild this editor without adding really much of any new features. Well, we did get collaborative editing out of that, I should say. But it was, I think, an example where we, we just ran up the technical debt to get this critical mass of functionality built around the product. And we could see that this thing was groaning under the weight of, you know, just basically poorly architected front end code. But we were willing to take that on. And then we found product market fit, we got a revenue stream and that gave us a lot more Runway to then go back and do the big RE architecture. I think we made the right choice. It was pretty scary, but I think we made the right choice there. And we've got a number of examples where we've done that, where we've kind of really run up technical debt. I think the important thing is to, as an engineering team, recognize it, like, see it, make intentional decisions around it. And that goes to our engineering value of striving for pragmatic excellence. You know, it can be a pragmatic choice to be expedient in engineering quality, to take shortcuts to get to market quickly, because you just have to. And as long as you are intentional, you're making really good engineering decisions and then you're keeping the receipts so that you can come back to product and say, well, now we need time to go and re engineer it properly, then I think that can be quite powerful.
- [51:15]
B
And in the same vein, and not from a technical debt perspective, but from a. How fully baked should a feature be? How do you all think about the tension between shipping stuff quickly, which again, you've done admirably, particularly in the last couple of years, but on the other hand, having hundreds of millions of monthly active users that expect some level of consistency and quality, that tension as you scale between going fast and being reliable.
- [51:48]
A
Yeah. Wow. Look, everyone at Canva, everyone from product right through to engineering, everyone is a product owner. They really own the product. They care about the product, they think deeply about the product. And so there's a lot of internal dogfooding culture at Canva. When we do ship something, we will. If it's a. If it's a big new feature, we will always put it through some kind of beta testing with a select group of users. We will have the feature behind a feature flag that allows us, for instance, to just expose it to staff and have staff, dog food it. We have the advantage that the product is. Our product is very applicable to our work. So we use it every day. And there is that constant feedback loop between the product teams who are building it, the entire company that's using the features and we have good pathways of communication that collect that information from that dog feeding and feed it back. Look, it's a tricky balance. We don't always get it right. But I think the key there is just the passion that engineers have for shipping quality product that they really want to ship something awesome. So they sweat the detail.
- [53:00]
B
Fascinating conversation to zoom out maybe to close next few years at Canva. What's on the roadmap? What does success look like? What's your ultimate ambition as a team?
- [53:14]
A
So Mel has a two step plan for Canva which is to create the world's most valuable company and then do the most good in the world that we can. And I have to say that really helps me get up in the morning and keep coming into work. I think it's a really noble mission that is something different from a lot of companies who just focused on commercials, practically speaking. I think we've got such a long way to go in building out the product vision that is in Mel's head and I'm really excited to go on that journey. I think AI is really, really exciting. I think from a ways of working point of view, I'm looking forward to a new era of productivity. I don't think software engineering goes away. I think software engineering changes to actually a much more fun job where a lot of the mundane kind of plumbing of software engineering is handled for you and you're able to orchestrate software with these agents helping you and become much, much more productive. So I would expect our productivity as an engineering org to lift significantly. Still, you'll see that I can't tell you too much about what's coming down the pipe in terms of features, but actually there's an announcement coming out this week which is pretty exciting actually. I probably can tell you about that. We are integrating VO3, which is Google's new amazing video generation model, natively into Canva. So that will be exciting to put into the hands of users. We've got a host more AI features that are coming down the pipe around the October timeframe and then into next year. There's so much more, but I'm not going to mention any of that because I will get in trouble.
- [55:05]
B
Incredible. And since you mentioned it, just to double click on it quickly, that's one of the things that makes Canvas even more of an incredible company is precisely this commitment to doing good in the world. So we. We can't cover everything in this discussion. But. But quickly. I believe the founders pledged their ownership in the company to charity, and that's.
- [55:31]
A
So there is the Canva Foundation. They've given the vast majority of their equity in the company to the foundation. And the foundation does. Supports charitable causes all around the world.
- [55:43]
B
Yeah. And then there is a commitment to do the right thing across the board, including in AI, where I believe you have a fund for creators or content.
- [55:55]
A
We do have a creator's fund. I think it's $200 million, and it's designed to reward creators. We recognize that it's a challenging environment for creators, but we want to see creators recognized as contributors to these AI models. So that's how we're doing that.
- [56:13]
B
Wonderful. Brendan, thank you so much. This was terrific. Really appreciate it.
- [56:16]
A
My pleasure. Thank you.
- [56:19]
B
Hi, it's Matt Turk again. Thanks for listening to this episode of the MAD podcast. If you enjoyed it, we'd be very grateful if you would consider subscribing, if you haven't already, or leaving a positive review or comment on whichever platform you're watching this or listening to this episode from. This really helps us build a podcast and get great guests. Thanks and see you at the next episode.