Velocity over everything: How Ramp became the fastest-growing SaaS startup ever | Geoff Charles

1. 0:00 – 4:49

   Geoff’s background

   1. GCGeoff Charles0:00

      So when I joined, we were about, you know, 10-ish folks, about eight engineers and in three months we built a competitor to Amex. Six months after that, we built a competitor to, to Expensify, you know, both publicly traded companies. We hit 100 million in annual revenue. I think we were under, at that point, 50 total in the R&D department, less than 40 engineers and three PMs. And then we started expanding into accounts payable. It was three engineers, one designer, one PM, three months, and, and they hit it out of the park and, and, and that product is moving in billions of dollars a year. And I think, you know, the, the recipe for all this is...

   2. LRLenny Rachitsky0:31

      (instrumental music) Welcome to Lenny's podcast, where I interview world class product leaders and growth experts to learn from their hard won experiences building and growing today's most successful products. Today my guest is Geoff Charles, who is VP of product at Ramp. This episode is a unique glimpse into a startup and an approach to product that optimizes for moving quickly, thinking from first principles and empowering individual team members. If you're not familiar with Ramp, they are the fastest growing SaaS business in history, getting to over $100 million in annual run rate in two years, which is just wild. And as you'll hear in this episode, they did this with 50 people. In our conversation, Geoff shares how they operationalize a culture of velocity, how they do a lot with few people, how they organize planning, how they define strategy, how they interview product managers and keep a very high bar for talent, plus also avoid burnout in a very fast moving culture, and so much more. My advice is to seriously study how Ramp operates because there's a lot to learn from their success and their approach to product. Enjoy this episode with Geoff Charles after a short word from our sponsors. This episode is brought to you by Ezra, the leading full body cancer screening company. I actually used Ezra earlier this year, unrelated to this podcast, completely on my own dime because my wife did one and loved it, and I was super curious to see if there's anything that I should be paying attention to in my body as I get older. The way it works is you book an appointment, you come in, you put on some very cool silky pajamas that they give you that you get to keep afterwards. You go into an MRI machine for 30 to 45 minutes, and then about a week later you get this detailed report sharing what they found in your body. Luckily, I had what they called an unremarkable screening, which means they didn't find anything cancerous, but they did find some issues in my back, which I'm getting checked out at a physical next month, probably because I spend so much time sitting in front of a computer. Half of all men will have cancer at some point in their lives, as will one third of women. Half of all of them will detect it late. According to the American Cancer Society, early cancer detection has an 80% survival rate compared to less than 20% for late stage cancer. The Ezra team has helped 13% of their customers identify potential cancer early and 50% of them identify other clinically significant issues such as aneurysms, disk herniations, which maybe is what I have, or fatty liver disease. Ezra scans for cancer and 500 other conditions in 13 organs using a full body MRI powered by AI, and just launched the world's only 30 minute full body scan, which is also their most affordable. Their scans are non-invasive and radiation-free and Ezra is offering listeners $150 off their first scan with code Lenny150. Book your scan at ezra.com/lenny. That's ezra.com/lenny. This episode is brought to you by Coda. You've heard me talk about how Coda is the doc that brings it all together, and how it can help your team run smoother and be more efficient. I know this firsthand because Coda does that for me. I use Coda every day to wrangle my newsletter content calendar, my interview notes for podcasts and to coordinate my sponsors. More recently, I actually wrote a whole post on how Coda's product team operates, and within that post they shared a dozen templates that they use internally to run their product team, including managing the roadmap, their OKR process, getting internal feedback, and essentially their whole product development process is done within Coda. If your team's work is spread out across different documents and spreadsheets and a stack of workflow tools, that's why you need Coda. Coda puts data in one centralized location regardless of format, eliminating roadblocks that can slow your team down. Coda allows your team to operate on the same information and collaborate in one place. Take advantage of this special limited time offer just for startups. Sign up today at coda.io/lenny and get $1,000 starter credit on your first statement. That's coda.io/lenny to sign up, and get a startup credit of $1,000. Coda.io/lenny.

2. 4:49 – 6:20

   An overview of Ramp

   1. LRLenny Rachitsky4:49

      Geoff, thank you so much for being here. Welcome to the podcast.

   2. GCGeoff Charles4:53

      Thanks, Lenny. It's great to be here.

   3. LRLenny Rachitsky4:54

      So you are head of product at Ramp. For people not familiar with Ramp, could you just give us a brief overview of what, what it is that Ramp does?

   4. GCGeoff Charles5:04

      Yeah. Ramp is a finance automation platform and corporate card solution for small and medium-sized businesses. So we help businesses essentially automate most things across expense management, card payments, bill payments, and accounting. And, uh, we've helped, you know, 15,000 of such businesses automate a lot of their back office to focus on what truly matters, which is growing their company and providing value to their customers.

   5. LRLenny Rachitsky5:26

      Okay. So what you didn't mention is some of the most, uh, interesting stats about Ramp and the business and the growth, kind of, story of Ramp. So could you just also share some stats about just the, the success of Ramp and a sense of just, like, how rare the, the story of Ramp has been?

   6. GCGeoff Charles5:42

      Yeah. I mean, we were one of the fastest growing fintech and, and B2B SaaS companies of all time. I think we've hit 100 million in, in annual revenue for the first two years. And we've continued to grow significantly since then. I think every day about 1,000 users join, join our platform. And, you know, this year we're going to hit 600 million in, in savings, uh, and 8.5 million hours saved for our customers by, by controlling spend and, and automating a lot of the manual tasks. So, uh, we'll con- continue to grow fast and, uh, and, uh, in terms of just raw transaction volume, you know, we have crossed 10 billion.... and analyze spending on the platform than just getting started.

3. 6:20 – 8:50

   The importance of velocity at Ramp

   1. GCGeoff Charles6:20

   2. LRLenny Rachitsky6:20

      You glossed over that stat of just Ramp is essentially known as the fastest-growing SaaS business in history, and also FinTech business. Like, in two categories, the fastest ramp to, to $200 million, right, in run rate.

   3. GCGeoff Charles6:34

      Yeah.

   4. LRLenny Rachitsky6:34

      Okay. So for that reason and many other reasons, there's a lot of interest in just how Ramp operates and how y'all approach product. And we actually previously collaborated on a newsletter post on how Ramp builds product, and that newsletter post is now the eighth most popular post on my newsletter across hundreds of posts that I've written, and even more than, uh, how Figma builds product and how Snowflake builds product, and all these other incredible companies. And so clearly there's a lot of interest in how you operate, so I'm really excited to get into the meat of how y'all work. And if anyone read this post and has any sense of just how you all operate, there's this one word that immediately comes to mind when people think of how Ramp operates, and that word is velocity. So I want to start there. Can you just talk about how important velocity is to how you work and where that came from and how that actually looks day to day at- working at Ramp?

   5. GCGeoff Charles7:27

      Yeah, absolutely. So you mentioned it. Um, you nailed it. Velocity is everything at Ramp. It's, it's how we design our product development process, it's how we incentivize teams, it's who, uh, we want to hire, it's who we want to promote, and it's everything around, you know, how we make decisions and how we organize, uh, the organization. And I think, you know, it, it came from the fact that during the pandemic we started with a very small team and there was a huge market opportunity ahead of us, and it wasn't so much, you know, which path we wanted to pick, but rather how fast we were able to execute on that path. And so velocity was kind of engraved from the early days on just building, shipping, and iterating, and I think it's a, it's a decent metric for, for how companies and teams perform. You know, you might, you might say, "Well, you know, what's the impact of that velocity?" But realistically, teams that have high velocity are able to actually get to that impact over time by iterating. It's also a great way to have positive selection in terms of, like, talent, 'cause (...) wants to join companies that ship fast, and a lot of people who, uh, join Ramp, I ask them, "You know, why are you interested in joining the company?" And they, they often say, "Well, it's because you guys are actually building things and shipping things and, and I want to know what that feels like." And it's also a great way to just de-risk decisions, uh, in decision-making. If, the cost of that decision is really low then you're able to, to, to essentially simplify a lot of decisions.

   6. LRLenny Rachitsky8:44

      To build on that, there's a, there's a lot of companies that say they move fast, that talk about moving

4. 8:50 – 13:20

   Single-threaded goals and how to keep teams away from distractions

   1. LRLenny Rachitsky8:50

      fast, that say, "We're like... Velocity is really important. Moving fast is really important to us." But I feel like Ramp is different. It's very different from that where you... It's actually incredibly, incredibly fast and it's actually something you come back to again and again, this idea of, "How do we move faster?" Can you just share an example or two of what velocity actually looks like at Ramp and, and what, what the reality of that is?

   2. GCGeoff Charles9:12

      Yeah. So when I joined, we were about, you know, 10-ish folks, about eight engineers, and in three months we built a competitor to Amex. Uh, six months after that we built a competitor to, to Expensify. You know, both publicly traded companies. We hit 100 million in, in annual revenue. I think we were under, at that point, 50 total in the R&D department. Less than, less than 40 engineers and, and three PMs. And then we started expanding into accounts payable. Uh, we basically gave a team, you know, goal of, of building a competitor to Bill.com. It was three engineers, one designer, one PM, three months, and, and they hit it out of the park and, and, and that product is, is, is moving in billions of dollars a year. And I think, you know, the, the, the, the recipe for all this is, is constantly, you know, small teams, have single-threaded, uh, focus, um, give them the, the resources they need to execute, big lofty goals, very tight timelines, and then, like, shield them from the chaos that is the rest of the organization. So basically don't bother them and don't even tell the rest of the company that you're doing these things until they find product market fit, until they actually find that early traction and then they can bring in more resources. So sort of like gravity, right? And, and you let gravitational pull do its thing.

   3. LRLenny Rachitsky10:24

      Okay. I want to double-click on some of these points you just made. So what you find is important to help teams and people move fast within Ramp is, uh, you talked about single-threaded teams, shielding them from other people trying to pull them in different directions, lofty goals. There's a couple more things. Let's talk about the single-threaded piece a little bit. What does that, what does that actually mean? What does that look like?

   4. GCGeoff Charles10:47

      There are very few people who are able to execute extremely well more than one thing, and it's especially true for, for individual contributors. And so what I mean by single-threaded is, like, there's only one goal, one thread that they're, they're waking up in the morning, uh, uh, to focus on. And in order to remove that, you basically need to remove anything else that they're being asked to do, to just focus on that thing, whether it's, you know, any type of research or any type of, of production engineering or any type of process that's outside of that single goal. And, you know, it almost goes as far as, like, you're just, like, saving a, a room in the office just for them and they are just in that room all day every day just working on that one thing.

   5. LRLenny Rachitsky11:30

      What's an example of that, either some- maybe someone's working on now or in the past that's, like, a good example of a single-threaded goal or team?

   6. GCGeoff Charles11:37

      Yeah. So for example, we, we launched a flex product, uh, over the, the last summer. That was a single-threaded team. We just focused on e-commerce companies and their needs with, uh, more cash flow conversion and, and cash flow smoothing. And so we kept that team, again, just purely focused on just shipping that product and, and hitting that goal. And if they were ever distracted by something else, I don't think we would have hit it.

   7. LRLenny Rachitsky12:02

      How do you, as a leader, avoid distracting them, knowing there's so many things you need to do and there's constantly this, like, "Oh, if we just fix this one bug, this one customer's going to be so happy," and, "Okay, if I just ask this one PM to work on this for a day..." I know there's not gonna be like, "Here's the rule, step one, two, three," but how do you actually approach shielding teams from, from things that just are constantly on fire?

   8. GCGeoff Charles12:25

      So we have, for example, on, on bugs or issues like that, we have, we have, uh, individuals that are protecting those teams from those issues. So, you know, we have a rotational program on production engineering, for example, where our engineers are protecting the core team from escalations, from bugs, from issues. We have product operators that are protecting the PM from the chaos that is, you know, documentation, and, and escalations, and release management, and, and enablement, uh, customer requests. So we, we have layers of p- of protective tissue to core teams. But I would say, like, for any of these, like, big bets, you basically have to pull folks from different teams and reorganize a sub- a sub-team, and that team typically doesn't have responsibility on any existing product, because these are all fairly new products. I think it gets more challenging when you go from one to two, rather than zero to one.

   9. LRLenny Rachitsky13:15

      You also mentioned this idea of lofty goals, and that's something I've seen a lot. Uh, at Airbnb, there is a- it's very known

5. 13:20 – 15:17

   Setting lofty goals

   1. LRLenny Rachitsky13:20

      for lofty goals. Brian was, uh, famous for going to meetings where people present their goals and their plans, and he's like, "How do we 10X that? What do you need in order to, for- to 10X that goal?" And then that ends up being your goal and often works, shockingly. Sometimes burnt a lot of people out. How do you think about just finding that balance and is, I don't know, is there an example of just, like, here's a really ambitious goal and ... or maybe the question is just how do you find the balance of ambitious, but not just, like, impossible?

   2. GCGeoff Charles13:46

      Yeah, so the first thing is, you know, we have market comparables, which is very exciting for us. So when you look at, you know, Bill.com, right? They're a publicly traded company, Expensify publicly traded, or Concur or Coupa. These are all, like, large players that are actually very motivating and largely de-risk some of the business decisions you're making. Um, that's existing markets. We've also been able to create markets. Spend management was an actual market before, before, uh, before we and other competitors kind of jumped into it. So that's what- that's motivating. Go attack that market and go, go drive that revenue is very motivating. We also use designs as a way to motivate teams. So we spend a lot of time with designers crafting out what the future of this thing could look like, and, and that's also extremely motivating. So we ha- we constantly go back to these cornerstone Loom walkthroughs of, of Figma prototypes that, uh, that design has spent a lot of time talking through and I think that's a big part of the, of the motivation. And so both of those things combined, I think helps us stay motivated. I think there's a constant pushback to, like, "Okay, what can we actually achieve?" But you're able- you're able to move super, super fast if, if you have those two things in mind, the market and the revenue goal, because we're very revenue-driven as a company and the, the designs that, that can really keep you anchored on, on what this could look like.

   3. LRLenny Rachitsky15:11

      I know another important ingredient to how y'all operate is you really like to empower product

6. 15:17 – 17:37

   How Ramp empowers teams

   1. LRLenny Rachitsky15:17

      teams and give them a lot of control over how they operate and what they build and how they set goals and things like that, versus micromanaging them. I think you have this concept of context over control. I'm curious how you actually operationalize that. A lot of people love the idea of empowering their teams and then they do that and then the team, they just do, they do the wrong thing or they take too long or they set the wrong goals. So how do you actually make that work, uh, and create empowerment within your teams?

   2. GCGeoff Charles15:43

      Yeah, it was, it was one of the biggest cultural differences, I think, in Ramp versus other companies that I was a part of, where, you know, my boss, the, the CTO, Kareem, was extremely hands-off in terms of, of the actual product decisions, because we were extremely aligned on the goals themselves. And so that's, that's where you really just start alignment is, what is the goal that you're going after? What is the hypothesis that you have to reach that goal? What is the data by which you're, you're coming up with that hypothesis? And then what is the potential solution to test that hypothesis? And oftentimes, you know, more junior leaders, and I was certainly in that camp earlier on, kept focusing on, on the solutions and debating the right solution, when in fact you should really be debating upstream of that. You should be debating the interpretation of data. You should be interpretate- debating the, the, the hypotheses and the different ideas that you have there as to what's really going on or you should be debating the goals themselves. And so whenever s- uh, things went wrong at Ramp, it was when I was being prescriptive with regards to the solution without actually explaining and aligning upstream on the goal, the hypothesis and the data. And if you do that, you realize that, that the solutions actually can come much better from teams that are much closer to the ground. I think that's the biggest goal that I have now in, in my role is to continue giving context so that teams focus on the right goals, come up with the right hypotheses and focus on the right data points, and I spend most of my time just repeating myself. Uh, most of my time just sharing the context that I, I think they might be missing, especially given that I'm in certain meetings or certain groups and certain forums that they're not a part of and my responsibility is to represent them and then share back the context for them to do better, uh, make better decisions over time.

   3. LRLenny Rachitsky17:27

      That touches on a phrase that's come up a couple times on this podcast that a leader's job, you're essentially the repeater-in-chief, reminding people of strategy, vision, things

7. 17:37 – 19:55

   How Geoff’s management style has evolved at Ramp

   1. LRLenny Rachitsky17:37

      like that. It feels like to move fast, you need to do what you're talking about, which is empower your teams to just move. Otherwise, it's not scalable, and I'm curious just to make it even more real, either is there a version of something you did at your previous work versus at Ramp that just shows what that looks like when you're empowering your team and not in the weeds? What's, like, most different there? Is it the product reviews, you're not as involved in design iterations? Like, where do you come in to actually give feedback? How does that actually look like working at a Ramp versus another company?

   2. GCGeoff Charles18:12

      I think that the contract between me and the team is really their strategy and their roadmap, and as long as we are aligned on, on the strategy and we, we can get into that and aligned on the roadmap and the timing, that's their contract. And so then at that point-My goal is to continue giving them context to execute on that, and to coach them through that by getting firsthand data on how things are, are going that they might be missing. And their role is to highlight risks and highlight one-way decisions that they need my input on. And, and again, it didn't use to start that way. I mean, when, when we first started, it was just me and another PM. I was fairly micromanaging in some, in some areas. I think you build trust over time, and you start having these contracts. And so as, as folks get more senior, they're basically publishing out the API by which they interact with me, and we basically align on, on what's, what's most important on a, on each one-on-one. So I, I basically have teams, all my directs post their goals every week, first thing Monday. The goal there is to also have them review each other's goals. I have a one-on-one template that I basically use to keep, uh, track of, of how progress is being made. But I certainly don't spend the time in the one-on-one going into that. I spend the one-on- one-on-one just focusing on what they need from me. And then, uh, on a biweekly basis, I have a, a teamwide meeting where I share context that, that everyone is missing and we go deep on, on the most important topics of the day.

   3. LRLenny Rachitsky19:44

      What about the product experience itself? Is there design interview that happens? How do you stay on top of just like, "I'm proud of this product that we're shipping as a team?"

   4. GCGeoff Charles19:52

      I'd say we're, we're iterating. I think when the first couple years

8. 19:55 – 21:19

   The product design process at Ramp

   1. GCGeoff Charles19:55

      it was more asynchronous, an ad hoc process. And once you hit, you know, 10, 15 PMs and, and 20 or 30 different mini pods shipping constantly, I think you need a, a bit more of a, of a process by which you have high-risk decisions that are being surfaced. So we, we've, we're iterating. I think where we're landing now is any large rock that, that we have on the roadmap needs to be brought into, into the product review process, where myself and the head of design are, are present and, and giving feedback. But it needs to be structured in a way where you're asking specifically for what type of feedback you need and you're highlighting the key risks and, and trade-offs that you're making, uh, implicitly in, in that review. So that's, that's one way we were able to scale. But I would say largely, people ship and it's the difference between a beta and the GA, that- that's where we really get plugged in. When we make the decision to go live to the rest of the customer base and asking sales to start selling, that's where I'll really come in and stress test the, the hypotheses and, uh, and the decisions. It's- it's further downstream, so it's high, you know, more risky. But because we move so fast, you don't waste that much time if you have to pull it back.

   2. LRLenny Rachitsky21:07

      Yeah. That came up actually, I just had a chat with Nicole Forsgren, who's a world expert on developer productivity and developer experience. And they've done all this research on quality and

9. 21:19 – 23:07

   Ramp’s system for sharing feedback

   1. LRLenny Rachitsky21:19

      speed of engineering in pro- in the engineering team. And they find that quality goes up as your engi- as your product velocity goes up. You'd think it'd be the opposite. The faster you move, the lower quality unzipping. But exactly to your point, because you can fix things really quickly and you can get things out the door and there's not this like huge chunk you have to wait for people to review and release and break things, ends up being higher quality. So it's very much aligned with our experience.

   2. GCGeoff Charles21:45

      Yeah. And, and you have to create a system by which those folks are getting that feedback, right? And so we, we've really focused on, on what are the control mechanisms that ensure that your high velocity doesn't, doesn't tank the business. And so examples of that is we have a voice of customer processes, where every single negative review that is shared on to, to our products is shared back to the he- the tech lead, the, the PM, and the designer on a monthly basis. We report back NPS and CSAT. We report back operational overhead, meaning the percentage of tickets that come from your product area normalized by the number of users that are using that product. And, and that's a, a core contract that the team has to, to maintain, uh, a low or lower part of, of operational burden. We also have, you know, bugs and issues being directly assigned to the engineer that's on call. So they feel, they feel that pain and then they can con- can, can continue, to your point, leveraging velocity to solve those problems. Velocity is just, is just a magnitude. It's not necessarily a, a specific direction.

   3. LRLenny Rachitsky22:55

      With these bugs that are coming in and quality issues versus a team's goal and their KPIs that they're trying to hit, how do you recommend teams balance those two things?

   4. GCGeoff Charles23:06

      We don't have a

10. 23:07 – 24:15

    How Ramp handles bug fixes

    1. GCGeoff Charles23:07

       bug backlog. We've, we've, we fix every bug once they're surfaced almost.

    2. LRLenny Rachitsky23:11

       Wow. Okay.

    3. GCGeoff Charles23:12

       Uh, so it's, it's, it's part of the production engineer's job really just to, to fix those things. I think where we get to nuance is like user experience improvements. The metric there that I really look at is how many support tickets come in that were due to a customer being confused. So we track that. And if that number is, uh, slightly elevated, we're basically saying, "You, you can't ship any new features. You need to fix, you need to fix these things." And so yeah, there's just these types of controls, but, but basically trying to standardize across the teams this is your percentage of operational burden, this is your CSAT, this is your NPS, and this is the, you know, the number of customers that are confused. As long as you maintain those metrics, you can do whatever you want. But the moment that these things are in the red, you can't ship new features and you need to, to revert back to me.

    4. LRLenny Rachitsky24:03

       Something funny that happened after our post on how Ramp Builds product came out, someone on LinkedIn, a product manager posted half-jokingly that her CEO came to her and every PM CEO came to them after that

11. 24:15 – 29:29

    Advice for PMs who want to move faster

    1. LRLenny Rachitsky24:15

       post, and they're just like, "How do we prioritize velocity? How do we move faster? Look at this, this culture of velocity that Ramp's got. Why don't we have that? What do we need to create this culture of velocity?" And I worried a little bit because it creates this additional pressure on product managers.... that already have a really hard job with al- already a lot of pressure. So it was like, oh man, we're creating this, like, new pressure-

    2. GCGeoff Charles24:36

       Mm-hmm.

    3. LRLenny Rachitsky24:36

       ... that this one company is doing things really well and now everyone has to do it this way. So, I guess my question is just what's your advice to product managers who are getting this push from leaders to move faster as a result of how you guys operate?

    4. GCGeoff Charles24:49

       Yeah. Well, o- well, I'm sorry. Um, look, I- I- (laughs)

    5. LRLenny Rachitsky24:52

       (laughs)

    6. GCGeoff Charles24:54

       Y- y- it goes without saying that PMs, we can't do anything by ourselves. We're very useless. We're a force multiplier. And so, the, the one thing that I'll highlight is, like, behind Ramp's velocity, i- i- is a lot less like the culture that, that I try to amplify, a lot more the quality of the engineering and design talent, candidly. All right? And so I'm just standing really o- on, on their shoulders here. And so, like, advice number one is ensure that from the top down there's an investment in R&D as a first class citizen, that you're paying upmarket, that you're hiring the best, that you're focusing on your engineering and, and tech brand, that you're bringing people who want to work there because they want to be empowered. And then you have a culture of empowerment. And what that means is ... and it's, it's hard, it's hard to get right ... what that means is the CEO has less say in the product that, that is built, and the engineers have a lot more say into it. And so, it's something that, you know, I've s- I've seen done really, really well at, at Ramp where the CEO sets the vision but is much less opinionated about the specific sequence by which we get there, and trusts a tech organization that is ??? empowered. The second thing that, like, you know, I would say is the biggest waste of time is meetings and status updates. And I think that oftentimes CEOs would say or leaders would say, "Hey, we got to increase velocity, therefore let's just add these status meetings and let's add this, all this process and all these documents and all these ways to hold teams accountable." And that's just a huge way to demotivate people. And so, you know, I've never had a status meeting. I've never scheduled a status meeting.

    7. LRLenny Rachitsky26:35

       Mm-hmm.

    8. GCGeoff Charles26:35

       Statuses are done async. They are done in the systems by which they operate, and largely they should be in real time. And meetings should be all about collaboration, ideation, decision-making, et cetera. So just look at your calendar and just kill as many things as possible and kill, uh, uh, just, uh, unimportant process. And the last thing that I would say is oftentimes, you know, leaders say, "I want to move super, super fast." But they'll say, "I want everything under the sun. I want this and that and that." An example of that at Ramp is always, like, the debate between adding more products to one segment or going to a different segment, right? SME versus a market of res- enterprise. And you ask the (laughs) CEO, "Hey, which one should we do?" And they would say, "All of it," because they think that the more goals you have, the faster you'll be able to execute, and I think there's just a, a, a limitation to that. So the, the, the thing I would amplify is be very clear with the trade-offs that you need to make and, and present those trade-offs back to your leadership team. So, "Here's what we're doing and here's what we're not doing and why." And, and, and, "Which one would you pick?" Give them a menu of items, and you'll see that you're able to execute much, much faster on, on four things rather than eight at the same time. Uh, that's your job. Your job is to, to, to basically communicate those trade-offs that oftentimes are, are not well communicated to executives out of fear of, of looking like you're, you're pushing back. You're actually not pushing back. You're increasing velocity.

    9. LRLenny Rachitsky28:02

       What I'm hearing from kind of a meta point you're making is use that ask as leverage to change the way things are operating. Is that right?

    10. GCGeoff Charles28:09

        100%. You can't ask for velocity and not have empowerment and not trust and not eliminate process and not increase the focus. And that requires some serious trade-offs that oftentimes leaders, especially those coming from more traditional industries, are not comfortable with. And it's, it was the biggest breath of fresh air when I joined Ramp was, was how committed the team was. The last thing I'll say is there's nothing more motivating than, like, a, a leader just commenting like, "This is awesome," on a random project channel at a, at a random design crit. Uh, like, I know that our, our founders are just, like, reading the projects that a- they actually care a lot about and the engineers know that. And so there's just a, a general, like, excitement on just building great, cool shit. And, and engineers just feel that and they, they're also, like, highly, um, highly motivated by that. So, that's another piece of, of advice is just, like, being able to, to stay plugged in, to give engineers the opportunity to present to those leaders, present in the all hands. That's also a, a gr- great way to, to amplify the culture.

    11. LRLenny Rachitsky29:17

        That's a good segue to this idea of, of burnout. Hearing a team operate incredibly fast and velocity, velocity, velocity makes you think about are people burning out? Are they enjoying

12. 29:29 – 32:33

    Why velocity and impact can help protect against burnout

    1. LRLenny Rachitsky29:29

       their work? How are they sustainably gonna last at Ramp? I'm curious just what that's like and how you think about avoiding burnout for folks that are just constantly shipping, shipping, shipping.

    2. GCGeoff Charles29:38

       I think the, the, the bait around, you know, working hard and burnout kinda misses a, a key point which is all about how much impact and, and how good you feel about the work that you're doing. And I think that for me, you know, when I felt burnout, it was actually at the time where I had the lowest amount of velocity. It was when I felt like I was putting a lot of effort into things that weren't actually moving. And so I actually think velocity is, is a way to potentially avoid burnout. I'm not asking people to work, you know, unless hours a week. I'm asking people to get out of their own way and to focus on, on what truly matters, which is building great products for our customers. And I think you do that if, you know, you, you do that if you get into a flow state, if, if you get into a, a cadence where everything becomes easier, where work can, can really become thrilling. And I think s- sometimes organizations, especially as they grow, make that really hard. (laughs) They make it really hard to just be in that flow state with a ton of distractions, a ton of meetings, a ton of cross-functional teams that are all, you know, asking for your attention and grabbing for attention.... and, and another parallel of this is, you know, the running. The, the, the best runners are the ones that love running and they feel like running isn't a chore, work isn't a chore. And I think, you know, as, as a, as a runner I tried to, try to emulate that whenever we're doing something hard that's challenging, that's exhausting. If you love what you do, you feel much better about the amount of effort you're putting into it and, and work doesn't feel like work.

    3. LRLenny Rachitsky31:08

       I find the same thing. I find that when I think back to the times that I had the best, uh, experience, the most fulfilling work that I've done, it's often I was working insane hours, it was just like this very long stressful project. But ends up looking back you're always like, "Wow, that was so much... that was so cool. I learned so much, we shipped so much interesting stuff, made so much impact." I think the key is what you said, is that you have to actually be proud of it and it has to be something that's meaningful to you 'cause you could work long hours on something that you have no interest in and that does not, does not help and that does lead to burnout. So that's the key.

    4. GCGeoff Charles31:42

       And, and you said something there which is like meaningful to you, right?

    5. LRLenny Rachitsky31:45

       Mm-hmm.

    6. GCGeoff Charles31:46

       So not meaningful to your boss or your boss's boss, your boss' boss, but meaningful to you. And I think that that's, that's the role of management is to make everyone on your team feel like it's their goal. And the way to do that is to, again, align on, on that goal and give it to them and take problems to solve. If everyone feels like it's their, it's their team, it's their company, their mini company, then they, they will radically avoid burnout. But if they feel like the work is being pushed onto them, they feel like they're not aligned on the goal or they don't feel empowered with the solution, then the burnout will absolutely happen.

    7. LRLenny Rachitsky32:22

       One of my favorite quotes that you have shared is, "Any second you spend planning is a second you don't spend doing." And on the one hand, I love that 'cause the more you

13. 32:33 – 37:54

    Planning vs. doing

    1. LRLenny Rachitsky32:33

       do, the be- more things happen, the more you get done, everything's happening. On the other hand also, it also feels a bit chaotic. And I'm curious how you find that balance between, okay, we're not going to spend all this time planning, we're just gonna go, go, go, go, go. And just how you think about that balance and how it actually ends up working out at Ramp sounds like not spending a ton of time planning.

    2. GCGeoff Charles32:54

       Yeah. I would say like when, when new joiners come at Ramp, I, I, I intro myself and I talk about our product strategy. And I ad in the meeting with, with an apology. I say, "You know, you, you, you sign an implicit contract joining Ramp. It's one where we prioritize velocity over almost everything else. What that means is it'll be somewhat chaotic. We'll ship things that don't work. We will, um, change our product without necessarily fully enabling you. And you'll have to constantly be on your toes whenever you load up a demo instance." And I think that is kind of an, an expectation and people are welcoming of that because they understand that the trade-off is that we don't move forward, that we don't, that we don't actually innovate, that we don't continue to, to provide value for our customers. I think there's, there's certain things that we plan for. And so the question really is like, because accuracy has cost, make sure that you're only increasing the accuracy of planning for the things that have high value of, of that accuracy. And so those things for us are, you know, large market moments where we have products, marketing, and sales all coordinating, um, these, these big moments. And, and those typically happen maybe, you know, once a quarter, once every six months, basically your marketing calendar. We need a plan for that, for sure. But it's oftentimes a, a low percentage of our total R&D focus. And so it's totally fine for each team to be somewhat autonomous, somewhat chaotic within their pod. They're extremely clear, but for the outside in, might be very chaotic. But be very accurate on the things that truly, truly matter. The rest actually doesn't matter. You don't need a lot of, of accuracy and confidence on, on when specifically certain features will be live. It's much better to, to spend whatever time you would spend trying to create accuracy in, in creating velocity.

    3. LRLenny Rachitsky34:48

       I love that you said expectations very clearly up front. That seems really important to be successful at a company like that. It also just makes me remember every successful startup is extremely chaotic. As much as it may not feel like that on the outside, it's insanely chaotic. Things are constantly changing. I was at a fireside chat with, uh, Sheryl Sandberg once at Airbnb and somebody asked her just like, "How do you deal with change? Things are just... we're reorging every six months. People are leaving and coming and teams are shifting and priorities are always adjusting." And she's just like, "This is the problem you want. You want to be going through this 'cause that means you're growing and you're going through hyper growth 'cause the alternative is much worse where you're not growing and that's much more painful." So I think it's just a good reminder that if you're working at a place that's chaotic, it's often a good thing.

    4. GCGeoff Charles35:37

       I would say so. I mean, oftentimes people, people use that excuse to like not have like a, a very strong strategy. And, and I think that, you know, for, for, for us, we've always been from the start the spend management platform that helps you spend less. Our strategy, you know, I share like a, an annual newsletter around, you know, what we did and what we're gonna do next year. It's, and it's oftentimes pretty spot on in terms of the goals. Again, the goals and the value and the problem and the vision, that's consistent. The specifics, the timing, the, the quarterly scopes, like all these things, yes, like it changes. But what you want to avoid is the thrash of people waking up and, and feeling like they're working at a different company or that leaders are constantly changing their minds. We've been extremely consistent from the start and I think most of the products that we built, most of the code that we- were written is in the customer's hands and hasn't been ripped away. And I think that, that speaks a lot to velocity too.

    5. LRLenny Rachitsky36:33

       Awesome. That was a good addition. I didn't mean to say it's, uh, it's if your place is chaotic, it's no problem. It's that, uh, side effect of growth and hyper growth is things are gonna be pretty chaotic. This episode is brought to you by Attio, a new type of CRM that's powerful, flexible, and built around your data.Traditional CRMs were built for a different era, with totally different speed, scale, and data demands. Attio is different. It allows you to quickly build a CRM that matches your unique workflows and data structures. Within minutes of connecting your email and calendar, you'll have a CRM that's already set up, complete with customer profiles and automatic data enrichment. You'll also have real-time dynamic reporting at your fingertips. No more slow deployments, outdated user experiences, or tedious manual data input. With Attio, you can build and adapt your CRM on the fly no matter your business model or company stage. Attio is the CRM for fast-growing startups. Get started today and get 15% off your first year at attio.com/lenny. That's A-T-T-I-o.com/lenny. So you've talked about strategy a couple of times, and so I want to dig into that a little bit. So there's kind of maybe a couple directions we can go. One is you talked about this contract you create with teams of a strategy. So, maybe let's just go there. What does that actually look like?

14. 37:54 – 40:55

    Ramp’s strategy documents

    1. LRLenny Rachitsky37:54

       What's part of this contract? And is there, like, a document you put together to lay this out?

    2. GCGeoff Charles37:59

       Strategy means a lot of different things. In my mind, strategy is about how do we get to our goals? And it's not a, it's not a roadmap and it's not a vision. It's something right in between that. So the first thing you need to do is align on, on what are the goals? What do you want to see in the world? Then the hypothesis. What do you... Why do you think, you know, this will work? Um, figure out, you know, why we're uniquely positioned as a company to, to get after that goal. Figure out the metrics by which, you know, you would, you would measure whether we reach that goal, and then talk about the initiatives, talk about the risks, and talk about the long-term outcomes.

    3. LRLenny Rachitsky38:31

       So these are kind of the bullet points of the contract, essentially, of a strategy document?

    4. GCGeoff Charles38:35

       Correct. And now every pod basically spends time writing that doc for themselves. So the, the pods are basically organized against, against outcomes, so they should be very clear on, on, on their goals. And they publish these things out, and then what I, what I typically do is, is take all these documents and make sure that they're aligned with, with our, our high-level product strategy, which is a, a bit more, uh, long-term thinking than, than the, the individual pods and that they are also aligned with our, our financial strategy, which we can get into. But that's a little bit how you also create a culture of empowerment, where each of... each team is, is thinking about these things, thinking like you. And the more that, as a leader, you make teams think like you, the, the more leverage you get over time and the more you can start thinking ahead on, on, on other ways of operating.

    5. LRLenny Rachitsky39:25

       How long does planning roughly take, and how often do you do this strategy kind of rethink?

    6. GCGeoff Charles39:30

       We've gone through, through iterations, good and bad. I think for a period of time at Ramp, we created OKRs with financial goals and, and quotas to some extent for, for different teams. And, and that led to, uh, just taking a long time to plan because people were trying to make sure there was the right metric, trying to make sure that, you know, they... it was achievable, and it became, like, very political, very annoying. And largely, like, our entire R&D team was like, "Look, like, we're just gonna execute on the roadmap. Screw the OKRs." (laughs) And so, uh, we moved from, like, quarterly, very expensive quarterly planning, which took one month every three months, so basically 33% of the time was planning, to a biannual one-pager on (laughs) these are the company priorities. And it's just... it's much more smooth and, and, and much faster. Related to that though, we have a strong financial plan that we execute on. And each, you know, each, uh, row or lever of that financial plan has an owner. Oftentimes, it's, it's marketing and sales. For anything that's product-led, it's product. So that's one contract. And then we have our roadmap. That's the second contract.

    7. LRLenny Rachitsky40:43

       One of the bullet points you mentioned is this idea of being... what are we uniquely positioned to do? Can you talk a bit more about that and maybe what's an example of some of your work done where... how you describe why you're uniquely positioned to win at that?

15. 40:55 – 42:46

    Finding your unique positioning

    1. GCGeoff Charles40:55

       One of the biggest values, I think, of, of software is how do you reuse, right, the components that you've built to increase, again, velocity and then your impact. So, you know, why we were interested in, in, in bill payments as an expansion of, of our corporate card platform was we saw a bill as just a, an invoice to the company and an expense was an invoice to the employee, and so there was a lot of parallels between these two things. It was all about, you know, having a liability. It was all about processing that liability into... in terms of, of, of the financial event and moving the money. Moving the money, you know, either between the company, between the company and the employee, or between two companies. So the... we, we believed that we were uniquely positioned to get after that space because we already had money movement. We already had some type of liability. We already integrated with accounting systems, and we, you know, had a pretty strong risk process that can govern all that. And the employees that were requesting to pay these bills were, were already on the platform. So that's an example of, like, a, a right to win. And I think that if you continue to focus on, on where you're uniquely positioned to, to, to win, you'll increase velocity because you already have a lot of the components and the expertise.

    2. LRLenny Rachitsky42:12

       I love that. It's not something you really see in teams' docs of just like why we have the right to win this, so I think that's a really interesting element. By the way, I should mention, we'll link to a template of your planning approach in the show notes, which we also had in, in the post that we worked on. So if folks are trying to write down notes of all these little bullet points, we're... we'll link to a doc that has all these things. What do you think of OKRs and how do you approach OKRs as a part of this planning?

    3. GCGeoff Charles42:39

       I largely stay, stay away from OKRs from, from a product perspective. (laughs)

    4. LRLenny Rachitsky42:43

       (laughs) Go on.

    5. GCGeoff Charles42:44

       Um, I think that, um... Again,

16. 42:46 – 44:53

    OKRs

    1. GCGeoff Charles42:46

       strategy, financial plan, roadmap. I think the... where we landed on with OKRs were really around...... more cross-functional things in nature. So, for example, we'll, we'll have an OKR around, you know, winning a specific m- in a specific market, and we'll have KRs that are, that are cross-functional across different teams. But again, like an OKR is just a method, it's just a method to measure, uh, an objective with, with ro- with metrics. And you can use them at, at various levels of granularity. I stay away from them from a product perspective, uh, because again, I want to focus on velocity, which is just output, which is your roadmap. But they could ... they're pretty strong at, at, at more of the cross-functional side of things as well as the financial side of things.

    2. LRLenny Rachitsky43:30

       I don't even, like, know what, uh, eh, what separates an OKR from not an OKR. Like, I feel like OKRs are just, like, a goal with some high level statements of things we're trying to accomplish. Like, I don't even understand (laughs) when people say they use OKRs or don't, what that even means anymore. There's a recurring point on this podcast and other posts of just, like, people are weary of just being obsessed with like, "Here's the metric that we're gonna hit and that's all that matters," and there's a fear they lose sight of the bigger picture, what they're trying to accomplish. But I think in the end, it's just like, "Here's what we're trying to do. Here's some goals we're gonna hit." Like, is that an OKR? I don't know.

    3. GCGeoff Charles44:02

       I think that's right. I think that's right. And, and at the end of the day, you know, with the, again, the contract is your, is your product roadmap. And that's the contract you have to the sales organization. Marketing can take that product roadmap and create market moments. And ultimately, if your product roadmap doesn't actually hit the goals of the company, then I'm accountable, right? Because I've created, I've created a, a system by which I've aligned with each team on why the roadmap is gonna hit the goals. And so they, you know, they, you, you essentially need to point back to the leader in, in that regard. But I can't ask every team to, to try to manipulate OKRs to fit their roadmaps. That's just completely exhausting. We've aligned on what we need to do. Let's get it done.

    4. LRLenny Rachitsky44:41

       Something that comes across pretty clearly in the way you think and the way Ramp operates is this idea of thinking from first principles, and it's kind of a cliche term. It feels like everyone's always trying to talk about how they're thinking from first principles and it's important to their

17. 44:53 – 48:53

    The importance of first-principle thinking

    1. LRLenny Rachitsky44:53

       culture to think from first principles. But it feels like you, you guys actually do it. And so I am curious just where that emerged for you and/or for Ramp, and is there an example of something that emerged, uh, within Ramp, a new product or an idea, that was very clearly from first principles?

    2. GCGeoff Charles45:11

       The most important thing to talk about here is that Ramp is a very unique business. I mean, we're a credit card company, which is all about risk management and underwriting. We're also a payments company 'cause we move money between businesses. We're also a software company because we, we deal with expense management and expense management, accounting. We're building for SMEs, so we have PLG, but we're also building for enterprise, so we are sales-driven. We're everything. And so it's really important when you're dealing with something that hasn't been done before to think from first principles. And the- and, and, and what I mean by that is you don't pattern-match from your past experience, but you go back to the fundamentals of what we're trying to do and you think through them very, very deeply. And that means you need to hire people who can think from first principles and be okay putting aside their experience. And, and that's a tough pill to swallow for some folks who, you know, will come in and will say, "I'm the subject matter expert on X, Y, Z, and I know what's best." And they come in and they get a reality check about the complexity of our business, and how also you can't influence teams by saying, "I've seen this before." That's just like an anti-pattern. Like, you can't say at my past company, "X, Y, Z."

    3. LRLenny Rachitsky46:30

       No.

    4. GCGeoff Charles46:31

       Um-

    5. LRLenny Rachitsky46:31

       No one wants to hear that. (laughs)

    6. GCGeoff Charles46:34

       (laughs) No one wants to hear that. And so ... And, and surely, I, I, I thought I was coming into Ramp and I was, I was gonna apply the best product development process, and I had to, I had to shift that process entirely because the process was predicated on a B+ engineering team, and I was faced with an A+ engineering team. And so my entire ... I had to go back to first principles around how a product should be developed and built. So again, like all the advice I'm sharing here, you know, don't just take it and map it and, and copy-paste. Start from the first principles with ... that, that, that we- that we're sharing. An example of that is our, our support team. So support reports into me, and the first principle there was saying, "Well, every support ticket is a failure of our product." We literally have that as, you know, a, a quote just posted on, on, on all those channels. It's a failure, and if our ... if the c- if the product works perfectly, no one should ever have to contact our support team. And what, what better way of holding the product team accountable for support other than having support report into product? And the second piece was that we believe that a lot of our, uh, value to our customers were ... because it was gonna come from deeply understanding them, deeply listening to them, and moving on that, on that feedback. And so we ... instead of hiring, you know, people who were focused just on, on resolving the ticket, we incentivized people to, to actually, like, decrease number of tickets over time and de- decrease deflection or increase deflection, and that required hiring a different breed of people that then became, you know, leaders in different parts of the organization as well. So again, we, we could have easily just pattern-matched, look at comparables, hired people who've scaled large support teams, and, and just used, like, benchmarks in the industry, but we've started from first principles. And the outcome of that is, you know, we have an extremely low contact rate. We have, you know, over 400,000 users on our platform and a team of, of agents that's under, under 30.

    7. LRLenny Rachitsky48:27

       Wow.

    8. GCGeoff Charles48:27

       Um, and it's a pretty crazy ratio to, to, to think about.

    9. LRLenny Rachitsky48:30

       That's wild. Uh, I missed this nuance. So the support team reports into you and the product team?

    10. GCGeoff Charles48:37

        Yes.

    11. LRLenny Rachitsky48:38

        Wow. I've never heard of that. (laughs) That's cool. Okay. So I'm gonna change course a little bit, and I wanna talk about writing. So we worked on this post together on how Ramp operates, and I was just incredibly impressed with your attention

18. 48:53 – 51:46

    How to use writing to think through problems

    1. LRLenny Rachitsky48:53

       to detail, your ability to articulate, your approach to product. And as we were working on this, you mentioned that writing is really important to you.... as a way of figuring out what you think and to solve and crystallize problems, which is exactly how it works for me. And that's how this whole newsletter started. It was just trying to crystallize what I remembered and did so that I can remember it and share with people. So I'd love to just hear your insights and take on just what writing does for you and maybe what you'd recommend listeners do with this kind of approach of writing, helping them think.

    2. GCGeoff Charles49:25

       Throughout the years at Ramp, I was often faced with a problem or a question that, that I couldn't answer off the bat, and I had to go back to first principles. And the best way of doing that is to shut down your laptop, you know, take out a piece of paper, write the question as simply as possible at the top of the paper and just spend time just thinking about how to answer that question, and there were m- there were a ton of questions over time. For example, you know, how do we... And it was all scalability problems that few companies have actually done successfully, and so you, you have to start with, with your own thinking. How do we scale decision-making? How do we incentivize teams to work together? How do we do headcount planning? How do, how do we allocate headcount in a, in a, in a fair way? (laughs) How do we avoid politics as firsthand ex- data goes away? How do we make decisions on, on doubling down versus pivoting? All these things are, are, are really tough and, and I found myself, you know, you could, you could, you could read things and, and that's helpful, but I don't think that reading makes you necessarily think better. It makes you more wise, but the best way to, to increase your capacity to think is to actually do the thinking. And, and so that's where I see, I see writing. If you're able to write things clearly, you're able to think through things clearly. It was also a way for me to effectively communicate, especially during like a t- uh, COVID where like w- we largely grew up during COVID where everything was written, and it was also a way for me to get content out there to increase, you know, my, my brand and, and Ramp's brand in, in terms of the, the space that then led us to, to hire, you know, better people over time. Um, so all these things kind of worked out, but it does require you to, uh, block out time and to again focus on how you think about problems rather than try to Google the, the answer. You know, after you thought through it, then, then go out and, and read and you'll, you'll fine-tune your thinking and you'll identify new, new questions to ask yourself afterwards.

    3. LRLenny Rachitsky51:34

       I love this advice. You mentioned earlier that PMs can't really do much on their own, but I think this is the thing PMs can do is PMs have the time to think and to s- plan

19. 51:46 – 54:05

    How Geoff carves out time for deep work

    1. LRLenny Rachitsky51:46

       and think ahead because they're not s- required to, you know, build code all day and design. This is the, this is the advantage you have as a PM. I always think that PMs often don't really have any special unique skills. They just have the time to do the things that nobody else wants to do or can't or, yeah, doesn't have the time to do or doesn't want to do. And, uh, just this really important point of just spending the time to think and not just constantly try to discuss things in meetings or like you said, just Google around for answers, that, that ends up being incredibly important, and I, I just love this framework of just starting a doc with a little question at the top and just sit there and try to answer the question on your own before doing anything. I think that's a really good approach. I want to ask how you actually do that. How do you actually create these blocks of time? There's this, you know, concept of deep work and how valuable that is to creative work and knowledge work. How do you, how do you do that for yourself? How do you block out time and not get bugged all day?

    2. GCGeoff Charles52:39

       Because we're like really anti-meeting at, at Ramp, you know, I, I had time in my calendar, and so what I would basically do is, you know, the, the Friday before I, I kind of clocked out, I would look at the next, uh, week. I would look at the, you know, the top questions that I, that I needed to spend time thinking about and then I would block out that time. I also, you know, work on one day of the weekend in terms of deep work. I find that, you know, hanging out outside and, and, and doodling on my piece of paper, uh, you know, some thoughts is actually really refreshing because it doesn't feel like work. It feels like just me just philosophizing about, about something. And so, yeah, blocking out that time, finding a, a space where things are less busy, where you're not in the critical path either early mornings or, or, or later afternoons or, you know, a day on the weekend is, is the best, the best path for it.

    3. LRLenny Rachitsky53:34

       What do you do if someone wants to actually schedule a meeting with you or reach out or put something on your calendar? Is there... Do you have kind of a policy there to protect that time?

    4. GCGeoff Charles53:41

       I think that I should never really be in the critical path of, of, of anything. So largely, I, I, you know, am not available. But if, you know, if they really need to get to me, they, they have my phone number.

    5. LRLenny Rachitsky53:53

       Cool. The thing that I found really valuable is just on a morning, Wednesday mornings and Friday mornings, I just have this huge block called deep work time. If you book a time during this time, I will slap you.

    6. GCGeoff Charles54:03

       (laughs)

    7. LRLenny Rachitsky54:04

       And I don't know if I'm allowed

20. 54:05 – 57:15

    How Geoff manages tasks and stays organized

    1. LRLenny Rachitsky54:05

       to (laughs) put that into meeting calendar invites anymore, but that actually worked really well. Nobody really booked meetings in that slot and-

    2. GCGeoff Charles54:11

       Good. I, I didn't know Zoom had a slap feature that, that's, that's

    3. NANarrator54:14

       ... yeah.

    4. LRLenny Rachitsky54:14

       It was a, it was a Google... It was in the calendar. It was like the calender invite. And, uh, I also work usually at least one day a weekend. I found that to be really effective and I know a lot of people, uh, don't want to be doing that, but I found that really important to, to have great success. One other question along these lines around just optimizing for processing and getting stuff done and deep work time. Do you have any other best practices for just being organized and staying on top of stuff knowing there's just stuff coming at you all day every day?

    5. GCGeoff Charles54:46

       If you're a manager and, and like me, you're in back-to-back meetings from, you know, 10:00 to, 10:00 to 6:00, it's, it's, it's very easy to be completely overwhelmed with the sheer amount of stuff you need to do. And so I, yeah, I've invested over time in like just a, a very robust but fairly simple like task management process which is...... at the end of every meeting, I would write down the tasks that I owe and the tasks that someone else owes. And I would write them down to, like, as clearly as possible. Not like some vague thing, but, uh, a very clear thing and just, like, when I need to get this done by. I don't spend time just grooming. So at the end of the day I have, you know, I use notes. I have just a, a page-long thing of all the things that I need to get done and all the things people need to get done for me. And then I spend time grooming, which is basically just trying to group things together in, like, logical chunks. Grouping the, the tactical versus the strategic, the important versus the less important. I group also what other people owe me, and I, I Slack them what they owe me and I put a reminder on Slack for, like, you know, when they, when they owe it to me by. In that way, it's just out of sight, out of mind. I think that the high level theme is I try to create or free up headspace for processing, not memory. And so I, I just basically spend very little time memorizing anything, and I write everything down. That, you know, is, is hard when you're trying to remember a specific date or remember something that, that someone said. But you have a system by which we can pull these things up very, very quickly, you know, in the, in the Google space, you can pull up any document and, and search a bunch of documents very, very quickly. So, that's what I would, I would, I would do, is, is just spend a lot more time on the processing, be extremely good at just task management and then grouping things. And then the next day creating your calendar aligned to the goals that you've set for yourself the day before in terms of the tactical, where you group those tactical tasks together. And then the more strategic deep thinking, blocking out that additional space.

    6. LRLenny Rachitsky56:40

       I feel like you and I are very aligned on a lot of things. This is exactly how I approach priorities. Uh, have you read Getting Things Done by David Allen?

    7. GCGeoff Charles56:47

       I, uh, don't read a lot of non-fiction, actually. (laughs)

    8. LRLenny Rachitsky56:50

       Okay. 'Cause what you're describing is very aligned with this approach to-

    9. GCGeoff Charles56:55

       Right.

    10. LRLenny Rachitsky56:55

        ... processing and taking to-dos, and, uh, it's kinda what I built my approach on. And so you naturally merged out of your head.

    11. GCGeoff Charles57:02

        Nice.

    12. LRLenny Rachitsky57:02

        I love it. Let's move on to talking a little bit about your team and hiring and things like that. And there's just gonna be kind of a grab bag set of questions. What does your current PM team look like, either number wise or just ratio

21. 57:15 – 1:00:30

    Why other roles share the PM load at Ramp

    1. LRLenny Rachitsky57:15

       eng- eng- PM wise?

    2. GCGeoff Charles57:17

       We have about 13 PMs, uh, at Ramp and probably over 100 engineers. So I try to keep mostly one to, one to eight to one to 15 depending on the team. Obviously B2B slightly more complex because you're dealing with pretty strong marketing team and pretty no- strong sales team and pretty demanding customers that you have relationships with. So I've seen ratios be a bit lower than the B2C space. But yeah, that's a little bit of the team today. And they're organized by, by those, by those teams, by those customer pain points.

    3. LRLenny Rachitsky57:47

       And I have this note from before you said that you reached 100 million ARR, and that's run rate, not recurring revenue at that point, right, I imagine, right?

    4. GCGeoff Charles57:55

       Yeah.

    5. LRLenny Rachitsky57:56

       Um, with 50 people, which is incredible. And so, just kind of on that point, how do you do so much with so few PMs especially? Do you have anything that you figured out that ends up being really important there?

    6. GCGeoff Charles58:06

       I think that by eliminating or, or reducing the size of the team, we've forced other people in the company to think like PMs, and I think it's been a huge value add to our culture. You know, when I, when I say product, oftentime people think about, like, product management, but I actually think product is anyone that actually reports into, into our CTO, into, and, and that's product engineering, product design, product managers, product data scientists. So making everyone feel like a PM is a great way to get leverage as a PM, and, and that means basically empowering the designer to think about the actual specs and priorities and scopes more than you, or empower the engineer to take something that's fairly lightweight in terms of a, a spec or direction and actually thinking, think through it deeply and, and come back with some, some great questions that the PM hasn't thought through. So that's one thing. The, the, the s- the second is that we, we invested early on in product operations, which was a team that, that also reports to me that basically focuses on the operational functions of, of product. That's everything around, uh, whether it's project management or, or issue management or release management or enablement and, and, and content, uh, beta and customer research. They basically are, are tasked with a lot of the, the work that, that needs to get done to, to continue shipping products and, and scaling product development. And then lastly, just, just cutting as much of the low leverage work that, that PMs often get sucked into. So for example, you know, we never write a, a ticket. Uh, we don't spend much time in, in, you know, Linear, which is, um, our, our ticket management system. We basically, our contract is the vision and the priority and a very high level spec, and, and everything else is kind of pushed on the engineering teams. And I think that's when engineers actually are also able to move even faster, because they can create whatever tickets they want. They can break down the work that they want. They are accountable for the projects that they're driving, and that, you know, increases trust and, and moves things faster as well.

    7. LRLenny Rachitsky1:00:09

       That makes a ton of sense. Basically you distribute the PM job that other, that other companies put on the PM across other team members. So if you had to think about just what is the core product manager job at Ramp at this point, I imagine from what I've been hearing it's strategy, vision, aligning the team. What else kind of plays into that? Just bullet point wise,

22. 1:00:30 – 1:01:46

    PM responsibilities at Ramp

    1. LRLenny Rachitsky1:00:30

       a few things that come to mind.

    2. GCGeoff Charles1:00:32

       Team building. So building a, a culture within the pod, because oftentimes your, your managers are no longer in your team, right? Engineers might report to different people. Designers might report to different people. PMs might report to different people. So, like, understand actually building a team culture within the pod is really, really important. And oftentimes it falls on the, on the PM to create those off-sites or, uh, to create those, those ideation sessions or to find ways to have fun as a team. The second is making sure that the team is humming in terms of, of...... the actual focus areas and then navi- and then protecting the team from, uh, stakeholders that might want to have an opinion, or want to have an update, or want to schedule certain meetings. So, so protecting that core team from, from that chaos and, and being the, the central point of contact if someone has a question or needs something, and then being able to bring in the right person at the right time. So, those are the different, different things that, um, is also really important to mention.

    3. LRLenny Rachitsky1:01:34

       Going back to a note that I made earlier, you talked about how a lot of this advice you're sharing and the approach to product at Ramp is kind of assuming that the team is A+. The engineers are A+,

23. 1:01:46 – 1:06:02

    Identifying A+ talent

    1. LRLenny Rachitsky1:01:46

       the designers are A+. For somebody listening to this, they may be wondering, "Are my engineers A+ or not?" What comes to mind as ways that you could get a sense if this is a team that can operate in this way versus, "No, we're never gonna work in this way and maybe we should shift the way we work or I should go work somewhere else"?

    2. GCGeoff Charles1:02:05

       Great question, is- yeah, it's very hard to identify. A few things. One is, does the engineer want to win in the market? Does the engineer really care about winning or- against competitors, winning the hearts and minds of the customer? Do they understand the business context in which they operate by which they, they need to do that? Are they curious about how the company makes money, about what customers love and don't love, about what the most important project is and why it's important? Are they asking you questions about the business outside of just the, the, the engineering domains? Are they able to execute on what they said they were going to execute without your help, or do you actually need to feel like you need to be behind them? Are they the one actually s- like setting the pace, asking you to keep up, keep up with your specs, keep up with your decisions, like respond more f- more quickly to the things that are blocking them, bringing more PMs or more designers to, to, to, to do more things? Are they being proactive in, like different channels where you think it's actually your job but actually they'll jump in anyways? For example, you know, we have different Slack channels with a bunch of people dif- sometimes asking questions, or raising issues, or having blockers, and you have engineers who are just like jumping in and like explaining how a feature works, like getting the feedback and fixing a bug proactively. And you may think, "Well, you know, that's not the priority. I need to control what the engineers are doing." That's not your job actually. That's not your job. Your job is to make sure that they're aligned with the long-term vision and that they can deliver what they've committed to. But on top of that, they can do whatever the hell they want. (laughs) And if they're taking on something that puts the things that they committed to at risk, they'll communicate that. So again, that proactiveness, that desire to help, that desire to, to improve, that accountability on their product. If their product isn't performing, if their product has feedback, are they doing it themselves or do they need you to push them? So th- that, tho- those are all like mentality and culture aspects. I'm not even getting into the technical rigor and the quality of their systems and the velocity of code, because I'm not a good judge of that. That's not really my role. But those are the things that I would immediately look at that I think is just fundamentally different in the, in the engineering team that we've built at Ramp versus, uh, versus others. And it's, it's just a big part of the culture shift and the c- the culture that we've been able to build.

    3. LRLenny Rachitsky1:04:35

       That was an awesome answer, and I think as a PM you often don't want your engineers and designers to have such strong opinions and to be so on top of everything, like 'cause they're just like, "Oh, no. Okay, here's what I think we should actually do," but the engineers have all these opinions. And what you're saying is that's what you want to lean into, assuming you trust that they know what they're doing and can actually get things done. And so it's kind of like a catch-22 a little bit, but I think that's a, that's a really unique culture and approach, and so that's an awesome answer.

    4. GCGeoff Charles1:05:05

       And, and look, like there- there's drawbacks to that culture, right, where you get to, like a radically empowered engineering team that thinks that they know the product better than, than the designer or the PM and they push back on the designs or they disagree with the en- the, the PM. But I- I'll take that culture any day compared to a culture where they're just, you know, taking things at face value and not challenging the thinking and not actually f- thinking from their own perspectives. And it, it just, it- it's sort of like, you know, I'll take someone on my team any day that challenges what I tell them to do or what I think is important and is maybe a bit harder to manage, but it'll make me think way deeper about what I'm asking them and what, what I think is important, and I'll grow as a manager much faster because of that.

    5. LRLenny Rachitsky1:05:46

       I love it. Two final questions, one around hiring. When you're interviewing people, what do you look for and what does Ramp look for that maybe other companies don't value as much as they should or maybe overvalue? What do you look for that you think is unique that helps you hire this A+ team?

24. 1:06:02 – 1:07:33

    The skills Ramp looks for when hiring

    1. LRLenny Rachitsky1:06:02

    2. GCGeoff Charles1:06:02

       We look for people who have a very strong desire to have impact, and the best way to assess that is the impact that they've had or the reason why they are switching jobs. So again, it goes back to that f- that- what I was mentioning earlier in the, in the chat, which was, you know, velocity leads to people wanting to join because they want to have velocity. And the best signal of that is, you know, "I'm leaving because things were- things got too slow. Things got too bureaucratic. I miss the old days where we were just building and shipping and launching." I look for people who can think deeply, so I'll go super deep into a decision, a trade-off that they had to make, um, and I'll really just scratch at that until I get to, to a deep understanding of how they make decisions and how deep they think about things. And in general, we, we, we tend to overemphasize those two skills rather than necessarily experience, because experience-... again, to the point around Ramp is a unique business. It matters, it, it, it matters a lot less. You can have a lot less impact than, than your ability to, to be hungry and your ability to, to think deeply.

    3. LRLenny Rachitsky1:07:20

       Final question. A lot of people listening to this want to get into product management. What's your advice? I'm sure you get asked this a lot. How do you break into product management? What do you, what do you tell people?

    4. GCGeoff Charles1:07:30

       Yeah. So for, for me, you know, I went from,

25. 1:07:33 – 1:10:37

    Advice for people wanting to break into product management

    1. GCGeoff Charles1:07:33

       from college to consulting to my foray into tech was really into more like solutions analyst. I think that was my title. I was basically trying to implement like a large B2B software in, in, in, in national banks. And how I got into product management was really around understanding deeply the customer and understanding deeply the product and being able to show impact on the combination of these two things. Typically, the, the folks that join product teams are the highest performers outside of product that either understand the customer really well and can advise product or understand the product very well and can serve customers. And so the- my advice is for folks that, that want to break into that is to find a role that is adjacent to product that enables you to have those experiences and to prove yourself. So for example, uh, product operations is a good one. Business operations is a good one. More consulting-y, sales engineering or solutions eng- engineering is a good one. There are designers and engineers that can become PMs as well. Uh, typically it's, it's, it's folks that can do the job as well as the PM. And what we p- typically do is, uh, we give those PMs a shot or those, those folks a shot. So we'd give them like six months to go into a new area and, and try it out. And then we basically have the engineers they work with and designers they work with actually make, mm, the call as to whether or not they would want this PM versus another PM on the team.

    2. LRLenny Rachitsky1:09:05

       Is there anything else you wanna share before we get to our very exciting lightning round?

    3. GCGeoff Charles1:09:09

       Yeah. I mean, first, like the thing from first principles, don't take everything I'm saying with, at face value. (laughs)

    4. LRLenny Rachitsky1:09:14

       Mm-hmm.

    5. GCGeoff Charles1:09:14

       And, and second is, you know, back to, back to talent that, you know, a huge part of our success was, was the early team that, that Kareem built on, on, on, on the tech side. And so, you know, I can write blogs all day on, on how we, how we increase velocity. But if there's one thing to take away from this is, is that empowered and talented engineers and designers are, are the biggest reason why, why Ramp was so successful. And, and it's something that requires a ton of focus. I mean, early, early on for the first year at Ramp, Kareem, our CTO, was only focused on that. It was hiring the best talent. He was a lot less in- interested or, or focused on our product strategy, our product market fit, or even our revenue. It was all about bringing in the best engineers and the best designers. And that has had compounding effects on, on the company and the team.

    6. LRLenny Rachitsky1:10:09

       And I think an important element there is the initial people you hire end up impacting the next batch and the next set because they see, "Wow, this person is working at Ramp. That's incredible. I gotta look at that." So there's an early compounding effect too that happens.

    7. GCGeoff Charles1:10:24

       Exactly.

    8. LRLenny Rachitsky1:10:25

       Well, with that, we've reached our very exciting lightning round. I've got six questions for you. Are you ready?

    9. GCGeoff Charles1:10:32

       Yes.

    10. LRLenny Rachitsky1:10:33

        What is, uh, what are three books you've recommended most to other people?

26. 1:10:37 – 1:16:24

    Lightning round

    1. LRLenny Rachitsky1:10:37

    2. GCGeoff Charles1:10:39

       Um, so I'm ... Because I, I work a lot, I, I try to read things that are completely outside of work. I don't think I can get through any like fiction or non-fiction book. Um-

    3. LRLenny Rachitsky1:10:47

       Yeah.

    4. GCGeoff Charles1:10:48

       ... that's often recommended. So anything that, that will pull on your heartstrings and, and, and, and try to make you more human. Um, When Breath Becomes Air is a, is a really good one that, that I often recommend.

    5. LRLenny Rachitsky1:10:59

       Amazing. Love that one. Favorite recent movie or TV show?

    6. GCGeoff Charles1:11:04

       Started watching The Bear, uh, a few weeks ago. I think it's a, it's a great show around leadership, around how a different industry operates, the restaurant industry. My dad owned a restaurant, so I got a little bit into that, and all about teamwork and, and quality versus, versus velocity, um, and balance of, of personal and professional stress. So I thought, I thought it was a really good, uh, learning.

    7. LRLenny Rachitsky1:11:29

       Wow. That mov- that show makes me really think of Ramp. That makes a lot of sense. (laughs) It just, it feels very ... Everything is just crazy, moving fast. (laughs)

    8. GCGeoff Charles1:11:38

       (laughs)

    9. LRLenny Rachitsky1:11:38

       I'm just so stressed watching that show. I haven't watched the second season yet.

    10. GCGeoff Charles1:11:41

        You should come to our office. Probably very similar. (laughs)

    11. LRLenny Rachitsky1:11:44

        (laughs) Just delicious food, sandwiches, and uh, velocity. Favorite interview question you like to ask candidates?

    12. GCGeoff Charles1:11:52

        I ask, "What's the hardest thing you've ever done?" Um, and I ask that because R- ramp ... working at Ramp is hard. Uh, I want to understand like what hard means for them. I want to understand why it was hard. I want to understand how they overcame that difficulty, how they worked with other people to overcome that difficulty and, and how much agency they, they had in overcoming that. So it's a really, it's a really good si- sign around, you know, what, what is difficulty to them and, and how, how, how much work they put into overcoming that.

    13. LRLenny Rachitsky1:12:23

        What is a favorite product you've recently discovered that you really like?

    14. GCGeoff Charles1:12:27

        Uh, so my partner bought me this Whoop, uh, recently. Wearing it, wearing it now. Gives you like this real-time like, uh, stress signal. Uh, so-

    15. LRLenny Rachitsky1:12:36

        Whoa. I didn't know that.

    16. GCGeoff Charles1:12:38

        ... that's, that's pretty helpful. But I think, I think it's, it's, it's a great product in terms of just actual insights. It's very data-driven, so it'll tell you ... You have like a daily journal of all the things you did that day and it'll correlate what you did that day to the, your, your recovery score and, and how, how healthy you were for that day. And so it'll give you insights around, you know, how certain actions you take will, will have impact on your, on your next day's health, which is all about heart rate variability. I thought it was just a, a great way to, you know, continue to focus on your health, I think.... running a team is, is, has a huge impact on, on your physical health and your mental health. And I think, you know, you are an athlete at a high growth startup, um, or even a s- a small business or a large company. And, uh, focusing on the health, uh, is, is really, really important. So, any, any, any tools like the WHOOP to, to invest in for that is, is great.

    17. LRLenny Rachitsky1:13:30

        That was a really good pitch for the WHOOP. I have never wanted one, but now I do. Okay, next question. What is something relatively minor you've changed in your product development process that has had a big impact on your team's ability to execute?

    18. GCGeoff Charles1:13:42

        It's not something I've changed. It's more something that our, our head of design, uh, Diego has changed. Uh, basically having designers spend more time creating more visionary prototypes and then sharing those out in Loom videos. It just has just huge impact on, on how exciting, uh, work is and how excited the team are. Um, and so just providing that clarity, uh, is massive. And I think just, just again, Figma and, and Loom and, and, and prototypes that actually are interactive so people can actually play around with it is, is a huge way to unlock velocity.

    19. LRLenny Rachitsky1:14:18

        Final question. I've already asked you about this a couple times, but I'm curious if there's any other productivity tip or tool that you would recommend to listeners that you haven't mentioned yet?

    20. GCGeoff Charles1:14:29

        Turn off notifications. Quit Slack, uh, when you're doing deep work. Check your emails once a day and just, like, thoroughly, uh, go through them in, like, five minutes. They're o- oftentimes, most of them are useless. Check Slack only at the top of the hour. Use Slack snooze, uh, or reminders. I mean, there's a whole other podcast we could talk about, like Slack channels and, and, and how to organize that. But you know, get, just get really good at the tools you're using. I think, you know, the first year of consulting, we just, we just got really good at, like, Excel and Excel shortcuts. And it was a big part of our training. And so just train yourself and train your teams on how to use their tools. How to use your calendar, how to use Slack, how to use email. Whatever the tool you've, you've designed as, as the right tool for you. Be dogmatic. I mean, what Ramp is, is a tool at the end of the day. And, uh, we're helping finance teams be more efficient, so let's, let's talk through that and, and do that with our own tools.

    21. LRLenny Rachitsky1:15:27

        I think we've had just enough velocity in our chat. I think we're gonna hit 100 million downloads. I think we've built an A+ team here. Jeff, thank you so much for doing this. Two final questions. Where can folks find you online if they want to ask you any other questions? And second question, how can listeners be useful to you?

    22. GCGeoff Charles1:15:44

        Uh, you can find me on, on Twitter and LinkedIn. Twitter is jeffintech. Uh, how can they be useful? Honestly, I mean, your, your, your attention is a, is a gift. If you're interested in joining us here at Ramp, um, we're, we're obviously hiring, uh, incredible people. So if anything that I shared resonates with you and if you want to join the team, uh, we're hiring across product engineering design. But, you know, most importantly, you know, be, be kind to yourself. I think, you know, I've, I've been a huge listener to this podcast. It's an honor to be here. I know very little. Hopefully some of what I shared was, was meaningful to you. But keep, uh, keep the growth mindset. Keep, keep, uh, thinking from first principles. Keep, keep, uh, investing in that growth, um, and, uh, be patient. It takes, it takes a lot of time.

Episode duration: 1:16:56