From Startup to $500M CARR: How Braze Scaled a Growth and CS Team with Braze's SVP of Growth

Please welcome to the stage Spencer Burke, SVP of Growth at Braze. All right, thank you everyone. I'm really excited to be here. I've been a Saastr fan for a really long time, like many of you. I remember back in the day when Jason was on Quora, we'd be following him trying to search how to build a company, looking for all the answers from him. And so To be here on stage is, is really a treat for me, and I'm really excited to, to share a few things that I've learned in my career at Braze. I've listened to quite a bit of SaaStr content, and what I've tried to do today is model it on some of my favorite presentations. And those happen to be ones where we go through someone's career journey, reflect on some of the lessons they've learned, the trials and tribulations. And I'm gonna try to check a lot of the boxes for you in that. We're gonna have some metrics, we're gonna talk about headcount, we're gonna talk about scaling, we're gonna talk about IPOs. And we have the obligatory embarrassing picture. I've actually got two, but the reason I chose this one is my journey at Braze in many ways started here in London. Actually, this is being a tourist out at Windsor Castle. I, I was here living in London for a couple years. I studied information systems at the London School of Economics. And that really helped start a, a passion for me around technology and technology systems. There's one thing that really stood out to me from my time there, and, and that was this book. It's called In the Age of the Smart Machine. You could be fooled because this is a topic that's frequently in front of us right now, but this was written in 1988, so nothing to do with GenAI or LLMs or anything like that. It was focused on a different platform shift. Which was the rise of computing in corporate environments. So after the big mainframes that we saw that filled gymnasiums, when we started to see computers really take over the workplace for different aspects of both white-collar jobs, but then also in different parts of the industrial supply chain. And I, I still keep a copy of this book on my desk. If you haven't taken the time to read about the history of technology, not just this book, just generally any big platform shift, technology wave, the history of Silicon Valley. I highly recommend it, especially in a moment like today where we're just— the influx of noise that we have about AI and the future of work. And even here we're hearing the full spectrum of predictions. Is AI a copilot and all of our jobs are okay? Is AI going to take over everything and marketers and SDRs have not a hope in the world for for having employment into the future, it's really helpful to look back. We've gone through this before. Maybe it's a little bit faster this time, but there's a lot to learn from history. And one of my favorite case studies in this book was some work that she did looking at paper mills. And this picture is a really early industrial paper mill. She was actually looking more like in the mid-1980s. '80s as that wave of computation was starting to, to come into an industrial process like that. I'm guessing a lot of you aren't really familiar with paper mills unless there's someone here with like really niche vertical software. You never know these days, like that, that could definitely be the case. But what she found was that intuition was a really key part of the professional satisfaction and the role that the folks in the mill developed for themselves. They used their senses to understand the health of the system and operation. They'd literally be walking around on the floor of the mill and they'd walk by a machine or a vat like full of paper pulp, put their hand on it and feel. They knew what temperature it should be. The same as I have two little kids, so frequently just feeling the forehead of my daughter to and you can tell right away, is she hot, does she have a fever? And these workers would do the same thing. They would listen. If there's a sound that was out of place, they knew how it should sound. You know, similar, maybe, a parent who's really into cars and they know exactly what that engine should sound like. There's some knocking or some clicking or something, they know what it is right away. And that was the same for these workers. And that all got disrupted. We're going to talk more about that and connect that back into some themes, but I want to leave you with two, two thoughts on this right now. The first is that we've gone through historical platform shifts that have made big changes on work. So in some ways, this isn't new. It's happened again and again. And in this AI moment that we're all in, it's— you can internalize that, keep that thought. And the second thing is, even on a more micro level, there's many moments in scaling and building a company where you go from something that's really driven by the intuition, and this could be your founder who really intuitively understands a marketplace. It could be a salesperson who has a knack for selling, positioning, and building relationships. But over time, as you're scaling, you start to talk more about automation and dashboarding and being data-driven, and that also has consequences on work. And so take those two ideas, 'cause we're gonna fast forward a little bit. So another embarrassing picture of me. This is our second office. It's a WeWork in New York City. That's me in probably 2011. I left London. A friend of mine who I'd known for a really long time messaged me on MSN Messenger. That's what we used back then. That's one for the history books as well. But he said, "Moving to New York. I'm starting a company. Let's talk." Cryptic message led to a bunch of conversations, met the co-founder, some of the investors, packed up my life, moved to New York City, and was the second employee at Braze. This is a really exciting time for me and for the company, 'cause in 2011 you have to remember a couple things. We were really focused in the mobile space and the mobile ecosystem. The iPhone then was about 4 years old. Came out in 2007. The App Store wasn't part of the first iPhone. That was closer to 2009. So we were 2 years into this ecosystem that today in 2024, we take completely for granted. But if you remember the early App Store, what were the apps? Calculator apps, flashlight apps, soundboards. Anyone remember, like, using some of these before brands, before there was Deliveroo, before you could stream everything on your phone? That's what we were downloading onto our phones, and that's the time period this was in. It was also a really interesting time in the New York tech scene. It'd be a few years later, but we'd hired our first people in London as well, and I think everyone in Europe can probably relate to this to some extent. The tech scene was just very nascent back then. There were a couple companies people knew about, mostly in the consumer space. It was like Tumblr, probably have heard of them, had some trials and tribulations since then. Foursquare was a New York company out of this era as well. On the SaaS side though, there were a couple ad tech companies, not a lot. And I think parts of London and Europe were, were in a very similar state. If you were building a career in SaaS, building a SaaS company, chances are you're in Silicon Valley. But that was the time period that we were in. I was the second employee. Our 3 founders, iOS developer, and then me. Like a lot of the team, I was doing every job under the sun. Even our co-founder was choosing our health insurance, then ordering lunch for the office every day. It really was, like, if you're in that stage right now, it's incredibly fun. The whole team is rallying together. Everyone's doing everything. At times I was BDR, I was field marketer. Heck, I was even a product manager. So we'd hired a bunch of engineers, but we hadn't hired any PMs. It's just a lot of the conventional wisdom that you get being at an event like this and reading about how to scale teams, it just wasn't the same quality back then. And so we were really scrappy, doing a lot of different things. And one of the defining characteristics for me at this time was like we were trying to find product market fit. And as many of you know, that's really difficult. We had, when I started, we had no products, no revenue, no customers. We're just fighting to survive, iterating on the product, going to every event we could, trying to find those first beta customers. And again, like, none of the thinking, there wasn't like a customer discovery process you could go down those from some venture firm. There was no, like, the language around design partners that early-stage companies use now. None of that really existed. And so we were finding our way through that versus today when it comes to something like product market fit, even over the past couple months, Sequoia, First Round have released these incredible frameworks for thinking about phases of product market fit, how you have it. For us, it was one of those things where you knew it when you had it, but before that you're scared, you're fighting to, to keep lunch on the table and to keep the team growing. But there's a chart that I like. This is our, I think, from like early 2015. So this is like 3, 3 and a half years in through 2017, our revenue growth. This is basically product market fit. If you had any questions on what it is, it's just tremendous growth that's putting wind into your sails. And it's also really scary because you go from having no customers or a couple customers, really close beta partners, to this, and it's great, right? Revenue wins really fuel the team. But there's a lot of challenges that come with that. One thing you also— Jason talked a little bit yesterday morning about the triple-double as a formula for getting to $100 million as a SaaS company. You can see like the tripling in here, which is like part of our formula for success. And I think proving that pattern, the person who formulated that, Niraj Agarwal from Battery Ventures, He's one of our investors on our board, so you can see some of what he saw in the company around this time. For me, this was a shift from doing all these random odd jobs around the company, just going to wherever I could go solve a problem and, and feel useful, to a really deep focus on customer success and scaling the teams around CS, which for us was basically all of our product, our customer-facing product experts. And similar to the tech scene in New York at the time, you couldn't find a CSM. If you put out a job description like, I want a CSM with 7 years of experience in soft— martech, software as a service, you're not going to find anyone. Those companies didn't exist. Those people didn't exist. Maybe if you hired them in the Bay Area, you could. We'd see the same thing a few years later opening the office here in London. You could try, but you really would struggle to find someone with that specific experience. And I think this happens in a lot of new roles. You get excited, you're trying to hire it, but the thing you actually have to do is spend time thinking about what the skills you actually need for that role are. And, and I actually think that's a great exercise. Because we get lazy. If I'm writing a job description now for some completely standard role, I'm just— I'm searching some other things on LinkedIn or some site, looking at some other JDs, then I'm copying in. Yeah, okay, this is going to be about 3 years of management experience for this level, 8 years in the field. You're just copying and pasting. And frankly, it's just laziness. We get to be lazy. Taking shortcuts is a luxury that we did, and we didn't have that back then. So, we actually had to spend the time and think about, okay, what do we want a CSM to be? What are those skills? Is it technical? Is it customer-facing? Is it industry experience? How do we wanna make up that team? And so, it was actually a really good forcing function, and I think especially for small teams where every incremental hire really matters, it's actually worth being really thorough on that exercise. Throw out some of the things like the boilerplate. JD, and actually spend time thinking about the skills you want this person to bring to the table, how you're going to discover that in an interview loop, and cover some of those things, because it really does matter. And for us, this is headcount growth over time in the CS org. But these aren't all CSMs. For us, CS was this really big umbrella. And the early CSMs— I get to— I'm the first one down there. and then we're growing incrementally over time. This was a lot of jobs. It was CSM, it was onboarding, it was tech support. We were doing some sales engineering, which we called solutions consulting. And like I said, we were doing everything that was customer-facing that required product expertise. And over time, we would layer in some specialization. But that was also something that we really had to grow into. And I think actually, like, as a field we don't spend enough time on. Like, if you're listening to a lot of SaaS-ter, there's some incredible content on when to hire your first salesperson, when to hire the VP of sales, the ratio of salespeople to SDRs, like, when you should hire them, all those kinds of things. In CS, I think it's a lot murkier. Like, we talk very high level about when to hire the CSM, and usually the recommendation is hire the first one earlier than you think you need to. And then some rough rules of thumb on book of business to help you scale. But what actually happens— and I advise a couple of companies, talk to a lot of CS leaders— these early CSMs, it's very common to follow a similar pattern. You're doing a lot of jobs, but when you should split that out, how you should think about that, when do you invest in support, we just don't really have the same sophistication around yet. But I think it's an opportunity for everyone, and I keep that in mind. There's a lot of benefits to having these jack-of-all-trades CSMs early on. And actually, Sam, or no, yesterday with the Gong CEO, he talked a bit about how he expects AEs, SDRs, CSMs, these roles merge together, and maybe AI facilitates that. One of the benefits he talked about, which we experienced in the early days, is you get a lot of shortcuts and a lot of benefits to having a ton of ownership embedded in these roles. I would be out helping a salesperson pitch a deal, acting as sales engineer. I know that I'm gonna onboard that account. I know I'm gonna support them after the onboarding finishes. So I'm not recommending any, like, crazy workarounds or solutions that don't really fit the use of the product. There's no handoff. I'm not handing it off to myself. I'm— there's just continuity. The customer met me, they continue to know me. That doesn't really scale, but In that moment, there's a ton of value that you get within that process, and then you slowly have to unwind and unpack some of that as you layer specialization in. And so for me, as I was growing this team, I was also thinking on a personal level, and I, you know, I think for many early employees, it's challenging because you know the company, you've been part of scaling it, but you're trying to figure out like, what is that path for you? And I think there's almost like too common of a dialogue around people are a certain stage of companies. The sales leader, great VP of sales, but after the Series C, you're going to need somebody different. You're going to have to go find that CRO. So-and-so's a great marketing leader, but really a head of marketing for a Series A company. And, you know, I think for a founder, that's the right dialogue to have. You need to build your team. You need to have the top people. But more empathetically, from the position of an early employee, you're so excited about this company and you're trying to find the right path for you, how to continue to be impactful. And for me in this world, okay, career in a box. What's next for CS? Okay, Chief Customer Officer, maybe CRO. That wasn't a super typical pattern at the time. Thanks to people like Jason M. Lemkin, Nick Mehta at Gainsight, This idea at CCO had come pretty common and started to formulate as an industry standard. So I thought to myself, growing the team, excited about this, seems to be working. Sure, like that. There you go. That was it. And talk a little bit more, like obviously you can see that's not my title. I've done something a little bit different today. But I think this is a really important exercise to think about, and especially if you happen to be someone who's an early employee at an early-stage company, to start to think about what that vision is for yourself. And maybe if it doesn't fit into a box, how do you start to really shape those opportunities and add value, but do it in a way that energizes you? And for me, one of the things that I did, because I, I could start to see signs of this, but I was really excited about the specialization, the org design, and then thinking about how we could use technology to scale more effectively. And one of the first things we did, like I said, was we started to think about this early kind of do-everything CSM, a more specialized role, and then further specializing on that. And so the first stage for us was within the CSM department, we hired leaders to lead sales engineering, we hired tech support people. Those reported to me for a while, and that was, for me, get an opportunity to get re-entrenched in what I think of as a 0-to-1 building type mindset. The rest of the CSM function had a little bit of scale. So for me, it's like the 1-to-10 order of magnitude. But it's like, hey, we need our first support person. We need to build a ticketing system. We need to build this process. So getting re-entrenched in the 0-to-1 was really exciting. And so the specialization was also this opportunity to rethink this, build new process, bring in new tools. And we did all this within the CS universe. But then over time, we also started to see these roles weren't the end of the story, but also there was better alignment into other functional areas. And so we began this process toward the end of that 2017-ish timeframe where sales engineering, super aligned to sales, more common org structures for that to report into a sales leader. We made that change. CS also got a little bit simpler in the process. We were more focused on the customer post-sales. We were focused on retention, reducing churn. At the same time, we started to see how scaling tech support was really critical for our product, and our customers were asking for more responsive support, and we had a small team doing that. We brought in a leader from the outside, pulled that team out, and created its own technical support department. And we did the same thing with our onboarding team, which became the seed of our professional services group. But that evolution happened slowly over time. Again, we didn't have a playbook for that, but we were really careful about thinking that through. And I think that one of the advantages for me as like someone who'd been really invested in the company at an early stage, I wasn't an external leader coming in and typical trope. I want the biggest team possible. I'm going to build my empire. I'm a big experienced leader. I need all the headcount I can get. So all these teams, you have all these people, we're gonna keep them all together. For me, I just wanna do what's right for Braze. It's not about how many people I have, how big the org is, how big the budget is. If it's better here, if I go talk to someone who's really experienced in this space and they say, oh, we made this change around the same size, here are the benefits, collect that data, weigh the pros and cons and start to do that. And so that was the journey we went through. Like I said, I think this is a really overlooked part of scaling process, especially for these product, these customer-facing roles who really become your deep product experts. CS leaders that I talked to today, they're often, they're wearing a lot of these hats. They're trying to figure this out. I think the one area, at least from my own learning, that we underinvested in early on, in part because we're a somewhat technical product, even though we serve a marketing audience, we didn't invest enough in technical support. And so over time we had to play catch up on that. The CSMs are worried, uh, I've been the one nurturing these relationships and now you're just gonna ask the customer to open a ticket. They're not gonna like that. And then you do it and the reality is the customer loves it because these teams are optimized on things like first response, time to resolution, customer satisfaction. And a great support team is a machine that is super responsive to solving customer problems. Whereas often for CS, you're building relationships, you're helping guide strategy, you're driving product adoption, and that's a different motion. I, I, I think I encourage everyone to like look really carefully and like try to map that out for your org. The more you can look into the future on this stuff, I think the, the quicker you can be smart and make some early investments that really pay off. And I think especially for CS where you can tend to get pretty attached to how things are, you can get, a little bit overattached to your customers. Pulling us back to my historical analogy with the paper mill is it's the same process for the CSMs. They are driving adoption and account health through their intuition. We measure this, we call it sentiment. I'm sure like if you have CSMs, you probably have some kind of sentiment, red, red, amber, green, 1 to 10 score, something that's capturing CSM sentiment. That's them talking to the customer, updating a field in Salesforce, or Gainsight, or Catalyst, or something like that, and doing the same thing that these mill workers were doing, more or less, is walking around their book of business, feeling things out, talking. They had a pretty innate understanding of what the customer needed and how to respond to it. And then, what we tried to do is push them into this efficient process that's, data-driven and as automated as possible. And in the case study on the paper mill, these workers went through this experience of walking around using their intuition to sitting in a control room with a dashboard, like actual control panel with gauges, lights. And so they went from listening and feeling and seeing and sensing to All right, this gauge is at 7, this red light's flashing. What does that mean? They'd open a 300-page manual. There's no Notion or Confluence or anything. And they paged through and said, OK, that plus this. OK, now I need to go input this command and do this thing. And so it totally broke this intuitive work for them. And that's not to say the intuitive work was better. But in that moment of change, and in that moment of disruption, It's really fricking painful, 'cause they didn't know what to do anymore, and they used to know what to do just by instinct. And I think almost every sales, especially account management and CS team goes through this process where you're really driven on the intuition of the person in role, the relationship with the customer, and then you're like, "You know what we're gonna solve this with? Dashboards. Customer health scores." alerts. And so that job that was picking up the phone or getting on a plane and going to the customer's office is Monday morning, open up that dashboard, look at that report. You have 7 different dimensions of product adoption and usage and consumption and telling them the same thing. Look at those numbers, go pull up the playbook. Maybe it's a little bit more automated than that. Probably not. And then go reduce churn in your book of business. I think that is probably the right thing to do. And we see a lot of teams that do that successfully. But again, when you're scaling, going through that change of really deeply trusting everyone with the accounts that they have and intimately knowing them to trying to run a large team at scale that's closely monitoring usage, that's closely monitoring churn, is a huge change. And so I think just encourage everyone, again, like you can anticipate this with scale. It shouldn't be a surprise. I just think we're not as regimented or disciplined about thinking through these things. And also like the specialization, like I was talking about, I think that's an opportunity for every early CS team. I also encourage everyone to like really choose your tools wisely. It's a little bit different now, but like, We went through a, a whole saga of CSPs and different kinds of tools, CSPs that don't exist anymore, that probably none of you have heard of. I made the mistake of trying them. It's really important to choose your tech partners wisely. I think it's especially hard in the post-sales space because Salesforce or your HubSpot, whatever your CRM is, your RevOps team is probably configuring that really highly. For your sales team, and CS tends to be a second-class citizen in that ecosystem. So you think, sure, just plug in the CSP. I've got my own tool, solve all of my problems. Again, probably not. Encourage everyone on this front to really think through what problem are you trying to solve? I've talked to teams who chose a CSP because of its note-taking capability. I don't know if you wanna make that decision that it's better at note-taking than Salesforce. It's like build, re-platform your whole team around. But I've heard about that happening. I think too, what are you trying to solve? Are you trying to have a system that automates playbooks? Are you trying to present usage data to your team? Are you trying to create a health score? Do you just wanna have a better way to track sentiment? There's a lot of great things that exist in this ecosystem, but I think similar to being lazy on hiring and the need that you actually have for a role, I think the same thing can happen here where you can end up just really lazy. Okay, just plug in a CSP, then you have nobody to admin it. You don't actually know what you want to get out of it, and it delivers about that much value. In, in this time, I also got really excited about thinking about how the team scaled and ended up ditching the CCO aspiration. And we started this growth team at Braze, which for the last 6 years I've been managing. And I'm almost wary to show headcount here cuz it, it's not not totally the right story for us. The growth team at Braze, it's not about marketing, it's not about user acquisition. The customers I was working with at the time are really sophisticated ones, had started to take this idea of growth hacking, growth marketing, and they were building these really cool teams that were cross-functional, experimental, and data-driven. And so, I, hit the reset button on my career path, which I think was pretty essential in the end, in hindsight, to me staying. I'm not sure I would've scaled well into that CCO role. And took a small team of about 5 people, couple of the CSMs that I really liked that had started to do this kind of work with me, the 2 data people we had in Braze at the time, and then we hired an engineer. And so we took a combination of people that understood the customer, people that could build real reports, real automation solutions, and an engineer to actually, to give us independence to go get that done on our own. And we initially focused on all of the challenges we had in CS that we couldn't figure out how to scale. And I'm sure you've all seen this. Your CSMs have side projects. They're gonna make new decks, new templates. They're gonna build some automation. They're gonna work on the health score. Then there's a customer escalation. There's an EBR they have to fly to. There's a conference they need to go to. Those side projects, first thing to go on the back burner. Or you have some mythical 20% time philosophy and you think, OK, 20% of your time you're going to make the team better. Really hard to do that. Again, in any customer-facing role, side projects are not a recipe to scale, in my experience. And so we decided to make this investment. I was lucky enough that our, Leadership team agreed to do it and we pulled out the team and we started focusing on that. And over time, we don't have 80 people trying to help CS scale. That really wouldn't make sense. But we found in the DNA of this team, and as the company was scaling, is that we needed that kind of thinking across Braze. And so the team became the home of our business intelligence and data team. We built an engineering team focused on automation and internal tooling. We incubated several teams, and that's been part of what our team does. If we have a new idea or an experiment, my team's a great place to do it because that experimental approach that we have means that if it doesn't work, we're willing to shut it down. We've also helped many teams scale. We've taken small teams, grown them, and the same thing we did on CS with the specialization. So at a certain point, we knew this team belonged somewhere else. and we moved it out of growth. And for me, again, my success isn't dependent on the budget or the headcount. It's the company being successful. Love to talk to people more about this. It's, I think, somewhat of a novel approach, and I think there's a lot of opportunities for other SaaS companies to adopt this. I think especially around tooling and data, we really quickly indexed toward more of an IT-led approach than a product mindset. And for us at Braze, this has been part of what's helped us be successful. And because we love a good revenue chart disaster, this is the 2017 to 2021, right before we IPO'd, a phase of some doubling and some high growth. Couple things I'm really proud of in that timeframe. My team incubated and launched our certification program. We've certified thousands of people, employees, partners, customers. This is really cool because it is one of those things early on where you, someone's gonna look for the ROI, they're gonna try to understand that. And our team was a really safe place to get this going because we knew there was value. We benchmarked a bunch of great programs and we were able to launch this and achieve pretty significant scale. In this time period, we also went public. For us, this was November 2021. So Jason talked about HashiCorp and the closing of the IP window. We were a few weeks before them. Really lucky to get to be there. I'm over on the right side or the left side as you're looking at it. Huge moment for us, but it was also a big moment for our team because part of the IPO process for us was looking at things related to audit and compliance, and there was a lot of data and automation and considerations for that. Typically, that kind of thing, people either assume it's just going to be red tape and a pretty boring, terrible process. Don't get me wrong, there's aspects of that totally fall in that bucket. But one of the things that we found was the data and the way we had approached some of these things, like thinking about revenue recognition. I don't know if anyone else has had to deal with ASC 606. But when you're thinking about revenue recognition and the data that you need to put together for that and for your auditors, it's a very high bar. When we think about the complaints we often have on data for CS teams and for sales teams, garbage in, garbage out. You can't just have BS excuses like that. The data has to be perfect. And the level of QA, the quality, the modeling that goes into it was a really big forcing function for us. And what we were able to find is that producing data at that bar, at that level of quality, had tremendous benefits for our CS team, for our sales team, especially around things like consumption. And I think there's a great takeaway there, at least it was for me, that CS teams can really thrive on high-quality data. And it's not just for dashboarding, thinking about alerting, thinking about using automation to communicate that directly to the customer. And so you don't have to IPO to do that. But I think the rigor of being a public company and also holding your teams to that bar, especially when it comes to data that you want to run your business on, is a really helpful exercise. The last thing for us is it's also put us in a position to move quickly and be at the forefront of changes in AI. I think every company has reacted to this in different ways. But as soon as I started to use ChatGPT when it launched, experience that, I was finding Hacker News articles about how teams had trained and fine-tuned or done early versions of RAG on their documentation to start to deflect support cases. Before any of these products existed or these companies were founded, people were sharing and open-sourcing these things. I was sending this to my engineering team and we jumped on starting to experiment with some of this stuff. And I think it's a really important part of this shift in this platform change that we're in right now. You don't need to try to solve every problem with AI, but if you're not doing something and you're not paying attention and you're not present as the landscape shifting around you, it's really hard to learn. And that's the approach that we've take, which again, I think we benefit from being highly experimental, from being data-driven and being willing to, try new things that don't have any immediate ROI, but help our team learn faster and compound over time. So that's been a, a really fun part of what we've been able to do. And I think it's also a moment where our work is potentially changing, nature of some of these roles is changing. And so it's important to start to be present in that change and be a participant and not a victim of it where you can be. Last, really quickly, 'cause it's not a pitch, but I'm super proud of spending almost 13 years at Braze, the things we've built, being an early employee. I think it's a really incredible journey and obviously founders by design, you get to participate most of the time in that whole journey with the company. I think for many early employees, it's tricky to find that path and to stick around. Really proud of doing that and hopefully more people can find that same opportunity. Because I do think you can get put into a box and almost get scaled out of your role, even for a company you're passionate about. And if anyone's in that position or thinking about that, happy to talk to you later today or find me on LinkedIn. Couple quick takeaways, then we have a bit of time for Q&A. First thing is look really closely at these side projects. I, I'm pretty skeptical of customer-facing roles being able to really successfully do this at scale. There's absolutely incremental gains you can get. But if you're expecting a CSM with a big book of business who's really busy fighting fires to go radically change some process or improve efficiency, I think you're a little delusional. And so I'd be— I'd really carefully look at that and think about how you can actually measure that and who should be responsible. Because if you take all those little bits of 20% time, you might have pretty close to a a team to go do that. And so just think about what that time allocation and resource allocation looks like. Two, where you can, even as you scale, keep bits of that DNA, whether from being a small company, whether that's people on the team, whether that's building a team, it's creating some of that innovation. I think there's just a ton of value to that. You absolutely need to do the things at scale. You need leaders who have seen the movie before. Who know the big picture, who have scaled revenue massively. You need to do all the things for audit compliance, like everything in that book. But there are different ways to do this, and I think it, it's a really sad thing when a company loses the innovative mindset that helped get it where it is. Third, really think through your vision and what you're looking for, whether that's in a technology platform, whether that's in a data system, or it's in a role that you're hiring for. And then finally, I think there's just a ton of value here is try to learn from history where you can. The news, the whole cycle that we're in right now is super noisy. There's value there, like I said, for sure to be present, but be close to the technology. If you're going to spend time doing something in AI, don't like be listening to the talking. Try to learn it, get close to it, develop yourself rather than getting lost in the noise. If you want to learn about and spend time reading something, go back and look at some of the prior waves. There's a ton of great books, some of them much more practical than Paper Mills, maybe a little bit more relatable. Like Bill McDermott's book is great on the history of Xerox and the platform change from document management being about printing to scanning and being computerized, his experience at SAP. Go out there and look. Find something that really speaks to you, because it's definitely out there. And will help you learn and contextualize the change that are happening now, which could be that big macro change, or it could be a micro change of something you're experiencing as you scale. And with that, I'm a little over time, but we have a little bit of time for questions.