Velocity over everything: How Ramp became the fastest-growing SaaS startup of all time | Geoff Charles (VP of Product)

27:03I want this 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 market of residential prize. And you ask the COA, 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 limitation to that. So the thing I would amplify is be very clear with the trade -offs that you need to make 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 which one would you pick?

27:40Give them a menu of items and you'll see that you're able to execute much, much faster on four things rather than eight at the same time. That's your job. Your job is to basically communicate those trade -offs that oftentimes are not well communicated to executives out of fear of looking like you're pushing back. You're actually not pushing back. You're increasing the velocity. 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? 100%. You can't ask for velocity and not have empowerment and not trust and not eliminate process and not increase the focus.

28:19And that requires some serious trade -offs that oftentimes leaders, especially those coming from more traditional industries, are not comfortable with. And it was the biggest breath of fresh air when I joined Ramp was how committed the team was. The last thing I'll say is there's nothing more motivating than like a leader just commenting like this is awesome on a random project channel, at a random design crit. I know that our founders are just reading the projects that they actually care a lot about and the engineers know that. And so there's just a general excitement on just building great cool shit.

28:58And engineers just feel that and they're also highly motivated by that. So that's another piece of advice is just like being able to stay plugged in to give engineers the opportunity to present to those leaders, present in the all hands. That's also a great way to amplify the culture. So good segue to this idea of burnout, hearing a team operate incredibly fast and velocity velocity, makes you think about our people burning out, are they enjoying 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.

29:38I think that the bait around working hard in burnout kind of misses a key point, which is all about how much impact and how good you feel about the work that you're doing. And I think that for me, when I felt burnout, it was actually at the time where I had the lowest amount of velocity. But 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 a way to potentially avoid burnout. I'm not asking people to work, unless hours a week. I'm asking people to get out of their own way and to focus on what truly matters, which is building great products for our customers.

30:18And I think you do that, if you do that, if you get into a flow state, if you get into a cadence, where everything becomes easier, where work can really become thrilling and I think sometimes organizations, especially as they grow, make that really hard. 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 asking for your attention and grabbing for attention. And another parallel of this is the running. The best runners are the ones that love running. And they feel like running is in the chore, work is in the chore.

30:54And I think 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 work doesn't feel like work. I find the same thing. I find that when I think back to the times that I had the best experience, the most fulfilling work that I've done, it's often I was working in sane hours. It was just like this, a 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.

31:29I think the key is what you said is that you have to actually be proud of it and ask to be something that's meaningful to you because you could work long hours on something that you have no interest in and that does not help and that does lead to burnout. So that's the key. And you said something there, which is like meaningful to you, right? So not meaningful to your boss or your boss's boss, your boss's like meaningful to you. And I think that's the role of management is to make everyone in your team feel like it's their goal. And the way to do that is to again, align on that goal and give it to them and to problems of salt.

32:04If everyone feels like it's their team, it's their company, their mini company, then 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. 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 because the more you do, the more things happen, the more you get done, everything's happening. And the other end also, it also feels a bit chaotic.

32:39And I'm curious how you find that balance between, okay, we're not gonna 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. Yeah, I was like, like when new joiners come at ramp, I intro myself and I talk about our product strategy and I add in the meeting with an apology, I say, 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, well, ship things that don't work, we will 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.

33:26And I think that it's kind of an expectation and people are welcoming of that because they understand that the tradeoff is that we don't move forward, that we don't, that we don't actually innovate, that we don't continue to provide value for our customers. I think 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 that accuracy. And so the things for us are large market moments where we have products, marketing, and sales, all coordinating these big moments.

34:08And those typically happen maybe once a quarter, once every six months, basically your marketing calendar, we need a plan for that, for sure. But it's oftentimes 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 accuracy and confidence on when specifically certain features will be live. It's much better to spend whatever time you would spend trying to create accuracy and creating velocity.

34:48I love that you said expectations very clearly upfront, 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 fire site chat with Cheryl Sandberg once at Airbnb, and somebody asked her just like, how do you deal with change? Things are just re -organ every six months. People are believing in coming and teams are shifting and priorities, they're always adjusting and she's just like, this is the problem you want.

35:22You want to be going through this because that means you're growing and you're going through hypergrowth because 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. I would say so. I mean, oftentimes people use that excuse to not have a very strong strategy. And then I think that for us, we've always been from the start, the spam agent platform that helps you spend less or strategy, I share an annual newsletter around what we did and what we're gonna do next year.

35:59It'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 quarterly scopes, all these things, yes, like it changes. But what you want to avoid is the thrash of people waking up 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 build, most of the code that we were in is in the customer's hands and hasn't been ripped away. And I think that speaks a lot to velocity too.

36:33Awesome, that was a good addition. And it means to say it's if you're a place of chaotic, it's no problem. It's that side effect of growth and hyper growth as things are gonna be pretty chaotic. This episode is brought to you by ATIO, 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. ATIO is different. It allows you to quickly build a CRM that matches your unique workflows and data structures. Within minutes of connecting your email encounter, you'll have a CRM that's already set up, complete with customer profiles and automatic data enrichment.

37:14You'll also have real -time dynamic reporting at your fingertips. No more slow deployments, outdated user experiences, or tedious manual data input. With ATIO, you can build and adapt your CRM on the fly no matter your business model or company stage. ATIO is the CRM for fast -growing startups. Get started today and get 15 % off your first year at atio .com slash Lenny. That's attio .com slash Lenny. So you've talked about strategy a couple times and as I wanna dig into that a little bit. So there's a couple directions. We can go one as you talked about this contract. Do you create with teams of a strategy?

37:51So maybe let's just go there. What does that actually look like? What's part of this contract? And is there like a document you put together to leave us out? Strategy means a lot of different things. In my mind, strategies about how do we get to our goals? And 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 what are the goals, what do you wanna see in the world? Then the hypothesis, why do you think this will work? Figure out why we're uniquely positioned as a company to get after that goal, figure out the metrics by which 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.

38:31So these are kind of the bullet points of the contract essentially of a strategy document? Correct. And now every Todd basically spends time writing that doc for themselves. So the pods are basically organized against outcomes. So they should be very clear on their goals and they publish these things out. And then what I typically do is take all these documents and make sure that they're aligned with our high level product strategy, which is a bit more long -term thinking than the individual pods and that they are also aligned with our financial strategy which we can get it to. But that's a little bit how you also create a culture of empowerment where each team is thinking about these things, thinking like you.

39:15And the more as a leader you make teams think like you, the more leverage you get over time and the more you can start thinking ahead on other ways of operating. How long does planning roughly take and how often do you do this strategy kind of rethink? We've gone through iterations good and bad, I think. For a period of time at Ramp, we created OCRs with financial goals and quotas to some extent for different teams and that led to just taking a long time to plan because people were trying to make sure there was the right metric, trying to make sure that it was achievable and it became very political, very annoying and largely our entire R &D team was like, look, we're just gonna execute on the roadmap.

40:01Screw the OCRs. And so we moved from quarterly, very expensive quarterly planning, which took one month every three months, so basically 33 % of the time was planning to a buy annual one -pager on these are the company priorities and it's much more smooth and much faster. Related to that though, we have a strong financial plan that we execute on and each row or a lever of that financial plan has an owner. Oftentimes 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. 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 Yorktown where how you describe why you're uniquely positioned to win at that?

40:55One of the biggest values I think of software is how do you reuse the components that you've built to increase again velocity and impact. So why we were interested in bill payments as an expansion of our corporate platform was, we saw a bill as just 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 having a liability. It was all about processing that liability into in terms of the financial event and moving the money, moving the money between the company, between the company and the employee or between two companies.

41:39So we believed that we were uniquely positioned to get out of that space because we already had money movement. We already had some type of liability. We already integrated with the accounting systems and we had a pretty strong risk process that can govern all that and the employees that were requesting to pay these bills were already on the platform. So that's an example of a right to win and I think that if you continue to focus on where you're uniquely positioned to win, you'll increase velocity because you already have a lot of components to the expertise. I love that. It's not something you really see in teams' docs of just like why we have the right to win this.

42:18So 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 the post that we worked on. So folks are trying to write down notes of all these little bullet points. We're willing to a doc that has all these things. What do you think of OCRs and how do you approach OCRs as a part of this planning? I largely stay away from OCRs from the product perspective. I think that, again, strategy, financial plan roadmap. I think where we landed on with OCRs were really around more cross -functional things in nature.

42:56So for example, we'll have an OCR around winning a specific market and we'll have CRs that are cross -functional across different teams. But again, an OCR is just a method to measure an objective with metrics. And you can use them at various levels of granularity. I stay away from them from a product perspective because again, I want to focus on velocity, which is just output, which is your roadmap. But they're pretty strong at more of the cross -functional side of things as well as the financial side of things. I don't even know what separates an OCR from not an OCR. I feel like OCRs are just a goal with some high -level statements of things we're trying to accomplish.

43:40I don't even understand when people say that use OCRs are don't, what that even means anymore. There's a recurring point on this podcast, another post, they're just like people are weary of just being obsessed with, like, here's the metric that we're going to hit and that's all that matters. And there's a fear they lose sight of, the bigger picture with they're trying to accomplish. But I think in the end, it's just like, here's what you're trying to do, here's some goals we're going to hit. Because I don't know care, I don't know. I think that's right, I think that's right. And at the end of the day, the contract is your product roadmap.

44:08And that's the contract you have to 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 a system by which I've aligned with each team on why the roadmap is going to hit the goals. And so you essentially need to point back to the leader in that regard. But I can't ask every team to try to manipulate OKRs to fit their roadmap. So that's just completely exhausting. We've aligned on what we need to do. Let's get it done. Something that comes across pretty clearly in the way you think in the way ramp operates is this idea of thinking from first principles.

44:47And 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 culture to think from first principles. But it feels like you 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 within ramp and new product or an idea that was very clearly from first principles? 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.

45:23We're also a payments company because we move money to businesses. We're also a software company because we deal with fixed 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 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.

45:59And that means you need to hire people who can think from first principles and be okay putting aside their experience. And that's a tough pill to swallow for some folks who will come in and will say, I'm the subject matter expert on XYZ, 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, my past company, XYZ. No, I'll just hear that. No one wants to hear that. And so, and surely I thought I was coming into ramp and I was gonna apply the best program out process.

46:39And I had to shift that process entirely because the process was predicated on a B plus engineering team and I was faced with an A plus engineering team. And so my entire, I had to go back to first principles about how products 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 copy paste, start from the first principles that we're sharing. An example of that is 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 quote just posted on all those channels.

47:16It's a failure. And the product works perfectly. No one should ever have to contact our support team. And what better way of holding the product team accountable for our support other than having support report into product. And the second piece was that we believe that a lot of our value to our customers, because it was gonna come from deeply understanding them, deeply listening to them and moving on that feedback. And so we, instead of hiring, you know, people who were focused just on resolving the ticket, we incentivized people to actually like decrease number of tickets over time, or decrease deflection, or increased deflection.

47:57And 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 could have easily just pattern matched, look at comparables, hired people who've scaled large support teams and just use 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 agents that's under under 30. It's a pretty crazy ratio to think about. That's wild. I missed this new one. So the support team reports into you and the product team.

48:37Yes. Wow, I've never heard of that. That's cool. Okay. So I'm going to change course a little bit. And I'm going to talk about writing. So we worked on this post together on how ramp operates. And I was just incredibly impressed with your attention 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 crystallized 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.

49:14So 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. Throughout the years at ramp, I was often faced with a problem or a question that I couldn't answer off the bat. And I had to go back to first principles. And the best way to do that is to shut down your laptop, 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. There were a ton of questions over time.

49:53For example, how do we, and it was all skillability problems, that a few companies have actually done successfully. And so you have to start with your own thinking. How do we scale decision making? How do we, instead of us, teams to work together? How do we do headcount planning? How do we allocate headcount in a fair way? How do we avoid politics as first hand as data goes away? How do we make decisions on doubling down versus pivoting? All these things are really tough. And I found myself, you could read things, and that's helpful. But I don't think that reading makes you necessary to think better.

50:37It makes you more wise, but the best way to increase your capacity to think is to actually do the thinking. And so that's where 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 a COVID where 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 my brand and ramps brand in terms of the space that then led us to hire better people over time. So all these things are going to work out, but it does require you to block out time and to, again, focus on how you think about problems rather than try to Google the answer.

51:24After you thought through it, then go out and read. And you'll fine tune your thinking, and you'll identify new questions to ask yourself afterwards. 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 plan, and think ahead, because they're not required to build code all day in design. 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.

52:04And just this really important point of just spending the time to think it, not just constantly try to discuss things in meetings, or like you said, just Google around for answers that ends up being quite all be important. And 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 concept of deep work and how valuable that is to creative work and knowledge work.

52:35How do you do that for yourself? How do you block out time and not get bugged all day? Because we're really anti -meeting at RAMP, I had time in my calendar. And so what I would basically do is the Friday before I kind of clocked out, I would look at the next week. I would look at the top questions that I needed to spend time thinking about, and then I would block out that time. I also work on one day of the weekend in terms of deep work. I find that hanging out outside and do a living on my piece of paper, some thoughts is actually really refreshing because it doesn't feel like work. It feels like just me just philosophizing about something.

53:21And so yeah, blocking out that time, finding a space where things are less busy, where you're not in the critical path either early mornings or later afternoons, or a day on the weekend is the best out for it. What do you do if someone wants to actually schedule a meeting with you or reach out and put some of your calendars there? You have a kind of a policy there to protect that time. I think that I should never really be in the critical path of anything. So largely, I am not available, but if you don't have to, they really need to get to me. They have my phone number. Cool. The thing that I found really valuable is just on Wednesday mornings and Friday mornings, I just have this huge block called Deeper Time.

54:00If you book a time, during this time, I will slap you. And I don't know if I'm allowed to put that into meeting calendar invites anymore, but that actually worked really well. Nobody really booked meetings in that slot. And I didn't know Zoom had a slap feature that bitch just came in. It was a Google, it was in the calendar. It was like the calendar invite. And I also worked usually at least one day weekend. I found that to be really effective. And I know a lot of people don't want to be doing that, but I found that really important to have great success. One other question along these lines around just optimizing for processing and getting stuff done and Deeper Time.

54:38Do you have any other brush practices for just being organized and staying on top of stuff, knowing there's just stuff coming at you all day every day? If you're a manager and like me, you're impact magnates from 10 to 6. It's very easy to be completely overwhelmed with a share amount of stuff you need to do. And so I've invested over time in just a very robust, but fairly simple test 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 does. And I would write them down to like as clearly as possible, not like some vague thing, but a very clear thing.

55:17And 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 page long thing of all the things I need to get done, 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 tactical versus the strategic, the important versus the less important. I group also what other people owe me, and I slack them what they owe me and I put a reminder on Slack for like, you know, when they owe it to me by. And that was just out of sight out of mind.

55:50I think that the high level theme is, I try to create or free up headspace for processing, not memory. And so I just basically spend very little time memorizing anything and I write everything down. That is hard when you're trying to remember a specific date or remember something that someone said. But you have a system by which you can pull these things up very, very quickly. In the Google space, you can pull up any document and search a bunch of documents very, very quickly. So that's what I would do is just spend a lot more time on the process saying, the extremely good, I just task management and then grouping things.

56:27And 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 walking out that additional space. I feel like you and I are very aligned on a lot of things. This is exactly how I approach parties. Have you read Getting Things Done by David Allen? I don't read a lot of nonfiction actually. Okay, so what you're describing is very aligned with this approach to processing and taking to do's. And it's kind of what I built my approach on. And so you naturally merged at a bigger head.

57:02I love it. Let's move on to talking a little bit about your team and hiring things like that. And there's just gonna be kind of a grab back set of questions. What does your current PM team look like? Either number wise or just ratio and distribution wise? We're about 13 p .m .s. A ramp would probably over 100 engineers. So I try to keep Miss, they want to, want to 1 to 1 to 15 depending on the team. Obviously B2B is slightly more complex because you're dealing with pretty strong marketing team and pre -nossed Trump sales team and pre -demanding customers that you have relationships with. So I've seen ratios be a bit lower than the BDC space.

57:40But yeah, that's a little bit of the team today. And they're organized by those teams by those customer pain points. And I have this note from before you said that you reached 100 million error. And that's a run rate, not recurring revenue at that point. I imagine rate. Yep. With 50 people, which is incredible. And so just kind of on that point, how do you do so much with so few p .m.?s especially? Do you have anything that you figured out that ends up being really important there? I think that by eliminating or reducing the size of the team, we've forced other people in the company to think like p .m .s.

58:15And I think it's been a huge value add to our culture. You know, when I say product, often people think about product management, but I actually think product is anyone that actually reports into our CTO. And that's product engineering, product design, product managers, product data scientists. So making everyone feel like a p .m. is a great way to get leverage as a p .m. And that means basically empowering the designer to think about the actual specs and priorities and scopes more than you or empowering the engineer to take something that's fairly lightweight in terms of a spec or direction. And actually thinking through it deeply and come back with some great questions that the p .m.

58:55hasn't thought through. So that's one thing. The second is that we invested early on in product operations, which was a team that also reports to me that basically focuses on the operational functions of product. That's everything around whether it's project management or issue management or release management or enablement and content, beta and customer research. They basically are tasked with a lot of the work that needs to get done to continue shipping products and scaling product development. And then lastly, just cutting as much of the low leverage work that p .m .s often gets sucked into.

59:36So for example, we never write a ticket. We don't spend much time in linear, which is our art ticket management system. We basically are contract as the vision and the priority and a very high level spec and everything else is 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 increases trust and moves things faster as well. That makes a ton of sense. Basically, you distribute the p .m.

1:00:12job that other companies put on the p .m. across other team members. So if you had to think about just what is the core product manager job at a ramp at this point, I imagine from what I've been hearing, it's strategy vision, lining the team. What else kind of plays into that? Just bullet point wise, a few things that come to mind. Team building. So building a culture within the pod because oftentimes your managers are no longer in your team. Engineers might report to different people. Designers might report to different people. People, p .m .s, whatever, people. So like, actually building a team culture within the pod is really, really important.

1:00:51And oftentimes it falls on the p .m. to create those off sites or to create 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 the actual focus areas and then protecting the team from stakeholders that might want to have an opinion or want to have an update or want to schedule certain meetings. So protecting that core team from that chaos and then being at the central point of contact, if someone has a question or needs something and then being able to bring in the right person the right time. So those are the different things that is also really important to mention.

1:01:33Going back to a note that I made earlier, you talked about how a lot of this advice you're sharing in the approach to product at ramp is kind of assuming that the team is A plus, the engineers are A plus, the designers are A plus, somebody listening to this, they may be wondering, are my engineers A plus or not? What comes to mind is ways that you could get a sense of 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. Great question. It's very hard to identify. A few things. One is does the engineer want to win in the market?

1:02:17Does the engineer really care about winning against competitors, winning the hearts and minds of the customer? Do they understand the business context in which they operate by which 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? They're asking you questions about the business outside of just 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?

1:02:57Are they the one actually setting the pace, asking you to keep up with your specs, keep up with your decisions, respond more quickly to the things that are blocking them, bringing more PMs or more designers to do more things. Are they being proactive in different channels where you think it's actually your job but actually jumping anyways. For example, we have different slack channels with a bunch of people sometimes asking questions or raising issues or having blockers and you have engineers who are just jumping in explaining how our feature works, like getting the feedback and fixing a bug proactively.

1:03:37And you may think, well, 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 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 improve, that accountability on their product. If their product isn't performing, if their product has feedback, are they doing it themselves or they need you to push them?

1:04:10So 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 engineering team that we built at Ramp versus versus others. And it's just a big part of the culture shift and the culture that we've been able to build. That is 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.

1:04:44Like, because they're just like, oh no, okay, here's what I think we should actually do with engineers of 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 -win to you a little bit, but I think that's a really unique culture and approach. And so that's an awesome answer. And look like 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 the designer or the PM and they push back on the designs or they disagree with you at the PM.

1:05:18But 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 but thinking and not actually thinking from their own perspectives. And it just, 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 it's maybe a bit harder to manage, but it'll make me think way deeper about what I'm asking them and what I think is important. And I'll grow as a manager much faster because of that. 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?

1:05:57What do you look for that you think is unique that helps you hire this A plus team? 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 when I was mentioning earlier in the chat, which was, you know, velocity leads to people wanting to join because they want to have velocity. And the best signal that is, you know, I'm leaving because things got too slow. Things got too bureaucratic. I missed the old days where we were just building and shipping and launching.

1:06:40I look for people who can think deeply. So I'll go super deep into a decision, a trade -off that they had to make. 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 tend to over emphasize those two skills rather than necessarily experience. Because experience, again, to the point around ramp is a unique business. It matters a lot less. You can have a lot less impact than your ability to be hungry and your ability to think deeply. Well, question. A lot of people listening to this want to get into product management.

1:07:24What's your advice? I'm sure you get to ask this a lot. How do you break into product management? What do you tell people? Yeah, so for me, you know, I went from college to consulting to my foreign to tech was really into more like solutions analyst. I think it was my title. I was basically trying to implement like a large B2B software 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 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.

1:08:12And so the my advice is for folks 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, product operations is a good one, business operations is a good one, more consulting the sales engineering or solution engineering is a good one. There are designers and engineers that can become PMs as well. Typically, it's folks that can do the job as well as the PM. And what we typically do is we give those PMs a shot, those folks a shot, so we'd give them like six months to go into a new area and try it out.

1:08:56And then we basically have the engineers they work with and designers they work with actually make the call as to whether or not they would want this PM versus another PM on the team. Is there anything else you want to share before we get to our very exciting lightning round? Yeah, I mean, first thing from first principles, don't take everything I'm saying face value. And second is back to talent that a huge part of our success was the early team that cream built on the tech side. And so I can write blogs all day on how we increase velocity. But if there's one thing to take away from this is that empowered and talented engineers and designers are the biggest reason why ramps was so successful.

1:09:41And it's something that requires a ton of focus. I mean, early on for the first year at ramp, Kareem or CTO was only focused on that. It was hiring the best talent. He was a lot less interested or focused on our product strategy or 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 the company of the team. 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 a ramp. That's incredible. And I gotta look at that.

1:10:20So there's an early compounding effect too that happens. Exactly. Well, with that, we reached our very exciting lightning round. I've got six questions for you, are you ready? Yes. What are two or three books you've recommended most to other people? So because I work a lot, I try to read things that are completely outside of work. I don't think I can get through any fiction book that's often recommended. So anything that will pull on your heartstrings and try to make you more human, when breath becomes air is a really good one that I often recommend. Amazing. Love that one. Favorite recent movie or TV show?

1:11:04Started watching the bear a few weeks ago. I think it's a great show around leadership around how a different industry operates restaurant industry, my dad on the restaurant. So I got a little bit into that. And all about teamwork and quality versus velocity. That's a personal and professional stress. That is a really good learning. Wow, that move that show makes me really think of ramp. That makes a lot of sense. It just, it feels very, everything is just crazy. Moving fast. I'm just so stressed watching that show. I haven't watched the second season yet. You should come to our office, probably very similar.

1:11:44Just delicious food sandwiches and the velocity. Favorite any request you'd like to ask candidates? Yeah, I asked, what's the hardest thing you've ever done? And I asked that because working at ramp is hard. 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 how much agency they had in overcoming that. So it's a really good sign around what is difficulty to them and how much work they put into overcoming that. What is a favorite product?

1:12:24You've recently discovered that you really like. So my partner bought me this whoop recently, wearing it, wearing it now. It gives you this real time like a stress signal. That's pretty helpful. But I think 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 your recovery score and how healthy you are for that day. And so it'll give you insights around how certain actions you take will have impact on your next day's health, which is all about hard variability.

1:13:04That was just a great way to continue to focus on your health. I think running a team has a huge impact on your physical health and your mental health. And I think you are an athlete at a high growth startup or even a small business or a large company and focusing on that health is really, really important. So any tools like the whoop to invest in thighs is great. Those are really good pitch for the whoop. I've 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?

1:13:42It's something I've changed is more something that our headed design Diego has changed. Basically having designers spend more time creating more visionary prototypes and then sharing those out in new videos. It just has just huge impact on how exciting work is and how excited the team are. And so just providing that clarity is massive and I think just again, Figma and Loom and prototypes that actually are interactive so people can actually play around with it. There's a huge way to unlock velocity. 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'd recommend to listeners that you haven't mentioned yet.

1:14:29Turn off notifications, quit Slack when you're doing deep work. Check your emails once a day and just like thoroughly go through them like five minutes, they're off the times, most of them are used. Let's check Slack only at the top of the hour. Use Slack's news or reminders. I mean, this whole other podcast we get talked about is Slack channels and how to organize that. But you know, just get really good at the tools you're using. I think the first year of consulting, 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.

1:15:09How to use your calendar, how to use Slack, how to use email, whatever the tool you've designed as the right tool for you. Be dramatic. I mean, what ramp is a tool at the end of the day and we're helping finance things more efficient. So let's let's talk through that and do that with our own tools. I think we've had just enough velocity in our chat. I think we're gonna hit 100 million downloads. I think we built an A plus team here, Jeff. Thank you so much for doing this. Two final questions, working folks find you online if they wanna ask you. Any other questions and second question, how can listeners be useful to you?

1:15:43You can find me on Twitter and LinkedIn, Twitter is Jeff and Tech. How can it be useful? Honestly, I mean, your attention is a gift. If you're interested in joining us here at ramp, we're obviously hiring incredible people. So if anything that I shared resonates with you and you wanna join the team, and we're hiring across product engineering design. But most importantly, be kind to yourself. I think I've been a huge listener to this podcast. It's not under me here. I know very little. Hopefully some of what I shared was meaningful to you, but keep the growth mindset, keep thinking from first principles, keep investing in that growth and be patient.

1:16:22It takes a lot of time. What a beautiful way to end it, Jeff. Thank you again so much for being here. Thanks a lot, and this was all a fun. Same, bye everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or a leaving review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at Lenny'spodcast .com. See you in the next episode.