Robinhood's CFO on Refounding & the Art of Capital Allocation | Shiv Verma

0:00We cut about 40 % of the company from 4 ,000 people to about 2 ,500. Surprisingly, it allowed us to go faster. It seems really counterintuitive. By having less people, you have less bureaucracy. Capital allocation is something I obsess about. It is one of the most important goals for the CFO and also the CEO. And so we think about it in a couple different ways. The first, the macro, and then the micro. At the macro level, there's only three things we can do with our capital. We can do organic growth, we can do M &A, or we can do shareholder return. No loss leaders. Every single product has to have positive unit economics.

0:33Now, we're okay working for thin unit economics, but I don't believe in, oh, we're going to lose money on this product, and then we'll make it up on somewhere else. That is a recipe for disaster. I heard you say you don't like variable costs. Where does that philosophy come from? I will put it even stronger. I hate variable costs. And so I say this to investors. I say this to our employees. The reason I don't like it is if you scale a business, which is our whole goal, it increased your cost base. Is this thing on? Yesterday's price is not today's price.

1:12Welcome back to Run the Numbers. Today I'm joined by Shiv Verma, the CFO of Robinhood. Robinhood today looks very different from the company that went public a few years ago. And one of the things I wanted to understand was what actually changed. Shiv calls that period Robinhood's refounding, a fundamental rethink of how the company operates. We get into why they significantly reduced headcount and actually started moving faster, why they replaced some committee decisions with directly responsible individuals, and why Shiv himself is the final decision maker on all headcount. But what I found especially interesting is how that operating philosophy carries into capital allocation.

1:50Shiv walks me through how a new idea earns investment at Robinhood, why products need to stand on their own economically, the logic behind their 100 million business threshold, and why some teams are measured on market share instead of revenue or profitability. We also get into forecasting a business exposed to everything from interest rates to crypto, what happens inside Robinhood's monthly operating reviews, and naturally, what Shiv learned working for the Oakland A's during the Billy Bean Moneyball era. There's a ton in this one. Let's get into it. Here's Shiv Verma. Shiv, thank you so much for joining me on the podcast today.

2:26Thanks for having me. Excited to do it. I've been a longtime fan of Robinhood, not just the company in the sense of what it does, but how you monetize the product, its business model. I wanted to start out with maybe looking back a bit because you're now part of the S &P index. You have a market cap of roughly, call it$100 billion, depending on the day. But looking back four years ago, you described the company as going through a refounding. And I thought that was a pretty remarkable thing to say for a company that had already gone public and had so much success. What did you realize needed to fundamentally change then?

2:59In 2022, we had been public for about a year. And what we realized is some of the magic of Robinhood we had lost and through a whole variety of different things. We had been in hyper growth mode. We had done a ton of hiring. We had some macro events that happened. And when we looked at 2022, when we were in hyper growth mode, the old beauty of Robinhood was we grew really fast, but we never burned cash and we shipped incredibly fast. And in 2022, for the first time ever, we started burning a little bit of cash or shipping velocity had slowed down and we looked around and we didn't recognize the company.

3:33And I give a lot of credit to Vlad, our CEO and co-founder. We were public. We were in the spotlight. Our stock had IPO at 38 and we were down to sub$10 for a few times trading at cash value. And we made the hard decision to redo the company. And so what did that mean? The first thing is we looked at our customers. A lot of our most engaged and active customers actually were the least happy. And that was counterintuitive because we had stopped building for them. So we said, okay, we're really, really going to focus on those customers, in particular, the active traders. Second, our shipping velocity has slowed.

4:04And one of the things was we had just gotten too big. We had 4 ,000 people across multiple different functions. And we went to a GM model, which has been fantastic. And so each of the GMs now control their engineers, their product managers, designers, ops, compliance, etc. We got rid of as many centralized teams as we could. And that really accelerated the product velocity. One question we get asked a lot is, how do you ship so much? And this is one of the reasons we have great GMs and great engineers, but then you stay out of the way. And so that was one of the things we did. We did really painful reductions.

4:35So we cut about 40 % of the company from 4 ,000 people to about 2 ,500. Surprisingly, it allowed us to go faster. It seems really counterintuitive by having less people, you have less bureaucracy, more DRIs, and you can really focus. And so we did all of that in 2022 and 2023. And it was the best thing we ever did. Now, the painful thing is we were public. So we were doing it while public and trying to navigate all of that. But if I look back five years, there's no way we'd be where we are today if we wouldn't have made those really painful changes. And so I give a lot of credit to Vlad, the entire leadership team, all the employee base.

5:10It was 18 months of change, but we came out on the other side stronger than ever. So many things to unpack there. So I'm a huge metrics dork. And one metric that I have this love-hate relationship with is NPS, Net Promoter Score. You mentioned how looking at customer love and their satisfaction was a big component to this. Can you just touch on NPS and if you thought it had value? Oh, yeah. So we're huge fans of NPS. Actually, the NPS function is under my team and it's all done by data science. It's extremely quantitative. It's all automated. We think this is one of the best ways to talk to your customers.

5:44Now, it's not the only way. You should be doing customer research, and there's a lot of metrics, but NPS is a really good overview. And so a couple of things we do. One, we survey customers daily. So given our 28 million plus customers, you can send out a couple thousand or 10 ,000 surveys every day, and you start to get continuous feedback. We slice it across products, across geographies, new customers, existing customers, all that's automated. And then what it does is it goes to the relevant team. So if you're in the brokerage team, at the end of the week, you'll get, here's your top customer pain coins.

6:12Here's what people are complaining about. Here's what's changing. It's all in dashboards that myself or the other leadership team can look at. So we use it in a lot of different ways, and it's incredibly powerful. To your question on 2022 specifically, when we did NPS surveys, what we found out was our most engaged customers, our active traders, were actually the least happy. They had the lowest NPS, which seems really strange. These are the ones who love your product and are using it daily. And what we had found is we had stopped building for them. when we were really growing fast, we were known for building for everybody, the novice investor.

6:44And we did it with low cost, easy to use, great designs, no jargon. But the product became so good that the active traders started using as well. But we didn't engage with them. We didn't understand their pain points. And so when we looked at the NPS surveys, all we did is we went through each of the pain points one by one. And as soon as you get through the first 10, you go to the next 10 and then on and on. And what you see is over time is as the NPS goes up, the training activity goes up, customers usually more engagement goes up and revenue starts to follow. And so it's a really powerful tool to talk to your customers.

7:16And I would encourage all companies to try to use it. So I just want to tease out something I heard there. Did you say that measuring NPS sits within the finance org that you own kind of that functional area? We have a team called Benchmarking and NPS. And so Benchmarking, competitive intelligence came from Amazon and NPS is in the same way. So we followed that. My predecessor, Jason Warnick, who came from Amazon, brought it here, where NPS also said in finance, and we do the same thing, I think is really powerful having in finance because it's a horizontal view. You can look at it unbiased, you can consolidate it.

7:48And our view in finance is to help support the GMs and the other product and engineering leaders. And so this is one of the tools we use. We have a lot of different data science and metrics that's in finance. But yeah, NPS and benchmarking both sit in the finance order. I love how you're taking such an analytical view to it because I think a knock that NPS has on it sometimes is it's more of like a marketing thing that we just want to brag about this score and it's not really used with a ton of rigor. So I was just having lunch before this and I pulled out my phone. I was checking my bank balance in Brex and I actually got served in NPS for the first time where it said one to ten are you likely to recommend this.

8:24Obviously I clicked ten. I love it. It's not like they sledgehammer me with that every day. So there's some sort of thought that's being put into this of we shouldn't serve this to everyone all at once and we should hit them probably after a compelling moment within the app so we get feedback that's realistic. Yeah. So there's kind of two ways to do it. One is evergreen. And so of the 28 million customers, you know, maybe five to 10 ,000 customers are getting surveys every week, just kind of evergreen to see what's going on. Then we'll do something very specific. If we have a new product out, we might send something there.

8:53Or if there was a moment, either positive or good. We might send something there. Or if there's a GM who's looking at one of their metrics and they're noticing something is changing, we'll do some surveys there. So I think the best way to do it is a combination of just straight evergreen. You have a baseline, you can see what changes, but then you can also use it as a diagnostic tool to kind of see what's moving around either positive or negatively. That's sage advice right there. Okay. I'm a lover of NPS again. So Shiv, I want to touch on the redesign. You mentioned moving towards a general manager model.

9:22I'm going to ask the stupid question on behalf of the audience. What's a GM model? Many companies, in particular, when you're smaller, everything is centralized. So you have a COO, you have a CPO, engineering, product, ops, they have centralized leaders. And so that's really good when you're in hyper growth mode, because you have a core group of folks who can see the entire thing. Now, some companies maintain that even as they get bigger. But especially when you get to our size, you know, we now have 13 different products with 100 million of ARR, multiple distinct business lines across brokerage and crypto and our banking products now international.

9:56If you start to have everything centralized, what happens is you have blockers. Because you have cross-functional dependencies. If you're trying to build something, you need the CPO to look at all the different products. You need the CTO to help rationalize between the different things. But if you do a GM model, you have one person who's in charge of either a specific product or a business unit. That allows a couple different things. One, you can work on multiple things at the same time. And so the brokerage team is not dependent on the crypto team and vice versa. And so we do all these different product events.

10:27And one is active traders and one is wallet share and one is crypto is one is international. That's not possible without the GM model. You have to have everybody who can focus on their things. The second thing is it allows you to ship really, really fast. So the whole point of the GM model is to reduce dependencies. So if I want to build something, I'm not dependent on this other team. and I can allocate my resources and go there. So that's one way that works. Now the cons are you can get a little bit disorganized in the app. So one of the things we get feedback now is, hey, you're shipping so many products.

10:55How do you know where everything is? How do I discover it? Vlad calls it the super app enigma. You get to this point and how do you discover it? So what we do is we have one horizontal team that's not in GM. They're a growth team. Their view is to help each of the different products grow and the GMs and Vlad and myself work with them for cap allocation. They're also responsible for running experiments, making sure the app is clean and it has similar surfaces. And so while most of the teams are distributed within the GMs, there's a couple that you keep horizontal. Growth and marketing are one of them.

11:24For a while, we kept design horizontal. Now we've actually put it into the GMs. We wanted to keep it horizontal because you didn't want to lose the feel of the app. But we're actually to the stage now where you can have it within the different GMs, but then you can have someone who sits at the top and making sure it looks good there. And then a couple of things that it doesn't make sense to have redundant teams. So customer service, infrastructure, core engineering, those are all horizontal teams that can support the GMs. But I'm a big proponent of as much of the business you can put into the GMs fantastic.

11:53That allows them to control their own destiny. It holds them accountable and it lets you go really, really fast. How does it change the role of the finance team and how they interact with the GM model? So within the finance org, we now have divisional CFOs or business partner CFOs that all sit within finance. but then they support their business unit. So there's someone who supports brokerage, someone who supports crypto, someone who supports banking, international, et cetera. While they live in finance, they're responsible for controllership, but they're also responsible for business enablement.

12:21One thing I'm a huge fan of, and this again comes from the Amazon model, finance is not just bean counters. You're not just there to say no or to keep score. You're there for business enablement. Now you have to do controllership. That's a priori, that's part of the job, but the best finance leaders can balance both. With the GM models, even though they sit in finance, they're basically part of the team. So the person who supports brokerage or brokerage finance, they're basically embedded in brokerage. They go their off sites. They're part of the planning. They're part of the learning. But then when we do the full roll ups, we come back and we do our forecast.

12:52They sit within finance. So it's a really good hybrid. What you have to do is find people that can do that balance between business enablement and controllership. If they get too close to the GMs or the product, then they stop focusing on the controllership. But if they're just focused on the controllership, they can't help the GMs move fast. And so we're constantly trying to find that model. But I think the finance partners love it. They feel like they're part of the team that's building the products. I bet all the finance business partners feel like they are part of that P &L, right? Like they have to come back to HQ to report on what's going on and help budget there.

13:23But you're truly ingrained in the business and you're working with these leaders day to day to bring a core product to market. I know it's succeeding when we have a decision meeting and the GM says, I want my finance partner there. That has been a cultural shift. You know, when I joined eight years ago, we were, we didn't have a finance team. We're building it out. And then over time, they build trust. But where we are today now is every decision meeting, we're going through annual planning, we're doing product design, finance is embedded from the start. I think that's really powerful culturally.

13:52And it's what allows the teams to go really fast because you're not trying to build something and say finance, go approve it. Finance is building with them. So by the time I look at it or Vlad looks at it or other members looked at it, we know what's been vetted, they're following our pricing principles, and then we can help people go really fast. I've gone back and forth with structures like this, as well as where RevOps should sit in the org. If it's a typical sales structure and there's field sales, do you put that sales ops person within the office of the CRO, or do you put them within finance?

14:21There's always this give and take of, hey, do you have a fox in the hen house? They're almost too close to the metal on this. Or that's actually a great thing because they're going to know the rhythm of the business better than anybody else? I think it's less important for where you embed them, but that they know what their role is. And we don't have a big sales function, but we do have a couple businesses that are B2B. The sales leaders tend to sit within the business unit, but then they have a finance partner that they work with and they design what the quotas are and make sure it all goes together.

14:47But I think what I've learned is if you set the principles and both the GMs and the finance partners know they're responsible for controllership and business enablement, you get to the right spot. It's a failure if we're just saying no to everything, on the controllership side, but it's also a failure for saying yes to everything. And so that's kind of the natural tension that you're trying to get to. Remember when pricing was simple? One product, one subscription, one invoice every month. Those days are over. The AI economy is changing how everything gets bought and sold. We're seeing usage-based pricing, hybrid contracts, and something called a credit.

15:21The finance systems built for vanilla subscriptions weren't designed for this. This isn't just a rev rec problem anymore because outdated revenue architecture can kill a great pricing idea before it ever reaches the market. RightRev lets you recognize revenue in whatever shape it comes in. Whether you're launching consumption credits or testing entirely new commercial models, RightRev gives finance the flexibility to support whatever pricing model comes next. So product teams can keep on innovating and finance teams can keep pace. If you're architecting revenue for the AI economy, learn how RightRev can help.

15:54Visit rightrev.com slash cj. That's me. That's rightrev.com slash cj. A wise man once told me that every startup is really just a loosely functioning disaster. Ain't that the truth? If your startup needs a little extra support, and let's be honest, who doesn't need a little help now and then? You're in for a pleasant surprise with Fidelity. Fidelity Private Shares helps early and growth stage companies stay investor ready with cap table, data room, and scenario modeling all in one place. A messy or missing cap table might not just slow you down. It could cost you your next fundraising round. VCs are flooded with pitches, and if your equity is confusing or missing, they'll move on fast.

16:33Fidelity Private Shares gives founders the structure and simplicity to focus on what actually matters, building your company. If you stay investor ready, you don't have to get investor ready. Check out fidelityprivateshares.com to learn more. That's fidelityprivateshares.com. I got news for you. The ERP category is finally getting disrupted. And if you haven't heard of Rillit yet, please pay attention. It's the AI-native ERP built specifically to replace NetSuite. And it's already won over hundreds of finance teams. Their mission is to make the zero-day close a reality. And they're actually doing it.

17:06We're talking teams closing the books at 1.35 p.m. on the first day of the month. Companies like Windsurf, Mercore, and hundreds of others run their entire finance stack on Rillit. Revenue recognition, close management, multi-entity, native Stripe and Salesforce integrations. Woo! Everything a scaling company needs. They've got 5.0 stars. 5.0. Wow. 5.0 stars on G2. They're backed by A16Z and Sequoia. Heard of them. And CPA-led implementations that get you live in 45 days. That is simply unheard of in the ERP space. If your books aren't running as fast as your business, check out Rillit. Book a demo at Rillit.com slash CJ.

17:44That is R-I-L-L-E-T dot com slash CJ. That's me. You mentioned decision making a couple of times and you mentioned the DRI. So you've moved away from some committee based decisions. This book I was reading over the weekend, it said a committee is a cul-de-sac where decisions are lured down to be strangled and die, which I thought was funny. But you moved away from this centralized decision making process to directly responsible individuals. I'm curious what kinds of decisions benefit from having just one clear owner. In 2022, when we did the reorg, one thing we did is we went through and we said, let's look at every committee or working group we have internally.

18:24And is it needed? And if not, who can be the DRI, the directly responsible individual? I think we had something like 80 different committees and working groups, and we just meticulously sliced them down. A committee, to your point, it's usually something for CYA. It's not always the actual making the decision, there's usually one or maybe two people that are in charge. And so what we did is we said for each individual thing, who is the DRI? You are responsible. Now, that doesn't mean you don't talk to people. I think that's the misnomer we get. They say, oh, you killed committees. It's actually the opposite.

18:56If you were the DRI for something, you need to talk to everybody. You need to understand it. And then you make the best decision you can with the data you have. But similar to how we were saying before, if you want to go fast, this is one of the main blockers that we found. Or if you don't want to make a hard decision, people rely on committees. Oh, I have to go to committee. I don't know. Well, it's much just easier saying, no, we can't do this. Or yes, we're absolutely going to do this. And so it's a little bit of creep over time. So every year we do a similar exercise. And you'd be surprised.

19:26Committees pop up all over the place or people call them something else or it's a working group. You have to be trimming them. If you let them go, that's how you get bureaucracy. Now, there are some places where it's important. So for some regulatory things or for being public. We do keep some of those. But for the most part, you can find the DRI and then just train them and say, go get the information, either async or by talking to people and then make the decision. And we found it really, really helps with the shipping velocity. The committee I've always liked the most is the party planning committee from the office.

19:56If you've ever seen that one. I don't know if we have an official committee, but our workplace team is awesome. And they're always making sure employees are having a good time. I heard, I don't want to be apocryphal here, that you were directly responsible for headcount. You're the DRI. And I've heard that even Vlad doesn't overrule you on that. Why was it important to establish that level of clarity around headcount decisions? I am internally known as the headcount police or the marketing dollar police. I still approve every headcount and every marketing dollar personally, even at our scale of 5 billion plus ARR.

20:25I think it's really important for discipline, for people to know these are sacred resources. Now, we're a software company at heart. Our people, our talent are what drive us. And so that's our biggest line item. So you have to know where it's going. This is capital allocation 101. Like if you were building a factory, you need to know where all your different pieces are in a software company, where your engineers are working, where your products are working, your overall headcount. That's your most valuable resource. And similar to what we were saying before, that doesn't mean I don't talk to people.

20:53We have a streamlined process. I'll get the inputs from either the finance partners, the GMs, the products. Luckily, we have great analytical tools where I can see everything internally. So what's your shipping velocity? What's your commits? Are your KPIs? Are you on track? Are you off track? And then you can make really fast decisions. And so that was one of the benefits. And, you know, internally, people make fun of me as the headcount police, but people actually do a good job themselves. They know if they're going to come to ask the finance or myself that they really need to do it. And so some of it's now kind of colloquially or funny, but I think teams have learned that we want to run lean and discipline, but we want to move fast.

21:28How do you find that balance? I think you have to have a great relationship with the CEO to be able to do that. I know what Vlad's priorities are. He knows what our budget is and we work together. And obviously, if there's something that's super important to him, we're going to find a way to make it work. But by taking him out of the equation and saying, hey, you need to not only make sure you have product alignment with Vlad, but you need to have alignment with Shiv and the finance team on resources, you get to a really good spot where you can make decisions fast and hold the leaders accountable.

21:54Well, Shiv, what it also does is it trains people to, for lack of a better term, come correct when they have to build a business case. And it's a consistent experience. I think the worst thing is when you put all this work and hope into getting new headcount, but it becomes this wishy-washy committee-based thing where you don't know if you're going to get it or not. You don't know how to plan for your teams. I mean, I kind of look at finance in many ways as a customer support org for the rest of the company. You're giving them a consistent experience and expectations. Yeah, 100%. All people want to know is what are the rules and what is it that we need to do?

22:27And we push our teams hard. We ask them to go fast. We have really aggressive goals. And there are times where you need to add you the resources, whether it's headcount or others. One thing this did is, if I go back a couple, maybe more than that, four or five years ago, if a project was behind, people would come and ask for headcount. And normally to catch up, you would do it. Now it's actually the other way. If you're going to ask for headcount, it's usually because you're ahead. It means you're shipping, you're doing well, and you want to go faster. We have a new priority. If you're missing your goals and your deadlines, that is not a good reason to ask for headcount.

22:57It actually should be the opposite. What's the blockers? Did you find product market fit? Is something not working well? Do you have a dependency? Let's solve those first. If you can fix those, then you can ask for headcount. You know, oftentimes when people come for engineers because a product is not missing its shipping dates, when you dive deeper into it, what you find is the bottleneck is somewhere else. Oh, I'm sure a designer. Oh, I didn't have a user researcher. or there was a dependency on this other team. And so it forces you to look in those. What's your commit velocity? What are your goals?

23:25Where are your engineers allocated for? If all of your team is humming at performance, you're above the median, you're on time for shipping and you're asking for more headcount, that's usually because there's a new strategic priority or we're asking the team to do something else. That's fantastic. Conversely, if you're behind intervals, if you're blockers at the red, you're missing your KPIs, folks aren't shipping, that's usually a flag that something else is broken downstream. And usually not even the product or engineering team's fault. It's just what can we fix? And so it's a little bit of changing the framework.

23:53If I'm going to ask for headcount, it needs to usually mean because I'm trying to accelerate, not because I'm behind in my existing goals. That's counterintuitively brilliant. A lot of times, and I just want to flag this for listeners, when team members come to asking for more headcount because they're behind, it's actually a leading indicator, I guess a lagging indicator, that something else in the process is broken. And you actually may need headcount, but it may not be for that team. that maybe because there's a bottleneck being caused somewhere else. One of our favorite books internally is The Goal.

24:22It's an old book from the 70s that shows about how teams build. And we gave it to all of our leadership team a few years ago. And that's exactly what we find in the software development cycle. Like nine times out of 10, when teams are looking for engineering headcount, if you dive deeper, it's usually a bottleneck somewhere else. And so this process also forces people to kind of do that investigative work instead of just throwing humans at a problem. The other thing we really try to teach people internally is let's automate and do things up front rather than throwing humans at the problem. It takes more time and you have to make more investment if you're going to automate a process or a workflow, but it pays dividends down the road.

24:58And so it's really, really easy to say, oh, let's just add some more headcount and throw humans at that. It'll make you go faster in the short term, but the long term, you're going to regret it. And so it's trying to find a balance between that as well. It sounds like the engineer is the atomic unit for planning. 100%. We are a software company at heart. Engineers are atomic unit. Everything is ratioed off of that. And so you always start with how many engineers are on a product and then you work your way outward. I used to say at the last company I worked for, and it differs based on what you're building.

25:25Hey, for every eight engineers, we need one PM. And for every 16 engineers, we need two designers or something like that. Yeah, we have we have ratios for everything. And so you start with engineers and then you ratio product managers. Best in classes, you can kind of get 10 to 1 PM to designers. Some newer projects might be seven to eight, some might be higher, but on average, it's about 10 to one. And then designers are ratioed off of PMs. Typically, one designer can support two PMs, although in some projects, and in particular, because we're really design focused, you might even have it one to one PMs to designers.

25:58User research, you can usually have multiple PMs supported by one user researcher, and then you go up like that. The other thing we look at is at the macro level, what percentage of the firm is engineers? If you go to smaller startups, hyper growth mode, they're probably you can get to 40 to 50 % engineers. At companies our size, if you can get to 35 to 40 % engineers, I think that's a sweet spot. If you have less engineers than probably a third of your workforce, you're not a software company, you're starting to get bogged down and all these other things. If you start to push 40, I don't think you have enough support network and you're probably going to have your engineers not as productive as they need to be.

26:33So that's kind of one we look at there. We then look at for all of the non engineering functions as a percentage of the total headcount. What are they? So HR, what percentage is it? Finance, legal, et cetera. And so then when you build it up, you say, okay, engineers are 35 to 40%. Then I ratio PMs, design, user research, some operational functions. Then I make sure I have a fixed cost ratio of finance, HR, legal. You get to your good spot. The last bucket in there are what we call volume-based teams. So volume-based teams are just headcount that go through an RPM model. So if you have more user tickets that come in through customer research, or if you have certain products that have operational needs and they ship fast, those we don't say, okay, this is the ratio.

27:13It should just be as the number of customers come in, we need, you know, one customer service agent for X thousand number of people. And you kind of ratio it like that and you put it all into the hopper and that's how you grow. And the last piece is when we go to annual planning funding, everyone comes in for their new seed funding. A typical Tiger team is usually three to four engineers, one PM and one designer to start, sometimes a little bit more, sometimes a little bit less. If we see a request come in for 10 or 15 people for seed funding, that's usually a flag that something is too off or the complexity is there.

27:42if somebody says they can build it with one engineer, that's usually a sign. It's not a product. It's a feature that should be embedded in somewhere else. But the Tiger teams, you know, call it five folks is a good starting point. Sometimes you just got to give the man the ball and let them cook. That was truly amazing. Can you just touch on again, was it called RPM teams or functions? Because something people always ask me is, okay, I get I should be more efficient, but I feel like there are certain areas of my business that do grow linearly somewhat with revenue? Yeah. So RPM, it's revolutions and it's an old thing from, again, kind of a factory model, but it's what's your throughput.

28:18As more folks go through, you're going to need more head count. And so customer service before you start using AI is the classic example. And so what we start to do is you say, OK, for a number of tickets per week, so tickets per wow, how many customer service agents should I have? So as wow grows, if you're getting more people coming in and more tickets, by default, you should have more people. What you try to do is though, you try to build automation and tooling so that your tickets per while can increase. And so for example, if one customer service agent can support X number of tickets per day, how do I increase that?

28:51That's the more important piece. And you can actually go down to the minute, what's your handle time? So okay, each agent can have X handle time. If I can make my handle time 10, 15, 20 % more efficient, that will then go to the top line. And so what we try to do is because we're in growth mode, you want to have your efficiencies at least keep up or outstrip your growth. So let's say you expect customer service volumes to increase 30 % next year just because of growth. Can you make the team 30 % more efficient? That means you can go into annual planning and actually not need to fund them. The ideal scenario is you can actually have efficiency outstrip your growth.

29:26So you can actually bring down the number of resources over time by automation. So those are some of the things we look at. Customer service is a great example. There's a lot of internal workflows that are based on this as well. Recruiting, for example. Recruiting is just a function of how many people do you expect to hire? How many recruiters do you need? And so if you can make each recruiter more efficient, you can actually hire more people with less bodies. IT is another place. Same thing. How many tickets do you expect to get? And so it's a lot of external metrics, but there's also a lot of internal metrics, these are the last things you do at planning.

29:58First, you figure out what's going on, what you're building, what they are, and then you work backwards and try to see, okay, based on our growth levels for these particular volumes, how many people do I need to staff on each one of these teams? You know, a lot of people, myself included, have used efficiency as a plug at the end of the day to get their annual model to kind of work the way they want to. And now we're going through this exercise with AI where you actually can be more efficient and you should expect that out of tools. It's different than saying, oh, you know, we got 10 more Salesforce licenses.

30:28You should just be more efficient. It's like, no, now you can actually go faster with less. What I kind of heard there is you tie it back to department or functional specific metrics of what the job to be done is, right? You can't just measure everything as revenue. A lot of it has to go back to tickets or whatever the value metric for the job to be done is. At the top level, we'll say, OK, we want to fund an efficiency goal for next year. Pick your number, 5%, 10%, etc. And that's going to help us fund our new product initiatives when we go into planning. But then you have to go to each department and then down to each cost center and say, how are you going to be more efficient?

31:05To your point, it's not fair to just say to every team, you got to be 10 % more efficient. If you give them a goal and we generally have some mental heuristics for how much each team can get efficient each year, just just with general productivity and the new toolings and things like that, then you can actually start to build it out. It is different for every team. An engineering team is going to be very different than a GNA team and a marketing team. But you need to know what their functions are and how how can you do it. A couple of the tools we have. And again, we took this from Amazon is we have a Lean Six Sigma team internally.

31:32It actually also sits in the finance or very similar to the NPS function. and their whole job is to go into different teams and help them do Kaizen events to optimize their workflow. So they might go spend a week with brokerage operations, map out a very specific workflow. They go through every single step. You get all the stakeholders in the room and you say, wow, we can cut out these 15 steps out of the 100 process workflow and that'll make you 15 % more efficient next year. Then when we go into annual planning, we measure it. We say, okay, we cut out these 15 steps. You've had three months to do this.

32:03Are you being more efficient? generally it actually maps pretty pretty close to what you found in the kaizen event then we go into planning we can say okay we helped you save 15 of your time for this workflow when we add it all up we think you can be 10 to 15 more efficient so it's really really easy to sit in the ivory tower and say hey be x percent more efficient it's much more powerful to actually go help the teams do that and then use those savings to fund new initiatives that's amazing i want i want to connect this all to the art of capital allocation and hit on how how you think about deploying resources within the company.

32:35Maybe to tie it back to the refounding, how did that shape the capital allocation framework that you use today? Capital allocation is something I obsess about. It is one of the most important goals for the CFO and also the CEO. And so we think about it in a couple different ways. The first, the macro, and then the micro. At the macro level, there's only three things we can do with our capital. We can do organic growth, we can do M &A, or we can do shareholder return. I like to say we can proverbially have our cake and eat it too, meaning we can do all three of those buckets. So we make sure we're investing for growth.

33:06We do use M &A to augment things. Typically, F &L can accelerate us 18 to 24 months and it fits our M &A criteria. And then the last thing is we return capital shareholder. We're now spitting off multiple billions of cash flow a year. And so during periods of market volatility or to keep our SBC in line, we also buy back our shares. On the organic growth side, there's really two buckets you can put dollars into, headcount or marketing. That's why I like to approve both of them. Now, there's a whole bunch of other things, but those are our biggest cost buckets there. On the headcount side, one of the things we realized is, and every company still does this and we're trying to learn, is we were doing too much.

33:42And so we would see way too many new projects and we get over our skis and we weren't doing any of them super well and we got a little distracted. And so when we got back to 2022 and now we have this model of here's how many engineers should be performed and here's how much we can afford. And what it does is it makes you really, really focus on what you want to do. And so we put things into three different buckets. One is the core business. This is like our equities business, our crypto business, now our banking business. You have to be investing in these areas. If you don't, your competitors are going to get there.

34:14You're not serving your customers. So you have to make sure enough of your resources are there. The second bucket is what we call scaling. These are things we've built probably in the past 12 to 24 months. They don't need as many resources when they first did. They're actually coming down the curve, but you have to make investments. One of the things we realized in 2022 and 23 was we would ship all the stuff and then we'd move on. That wasn't a great process either. You know, it's really easy to go the shiny new object, but you have to make sure that the things you scale, they're still investing in.

34:40So take Robin Hood Legend, for example. We shipped that two or three years ago. It's awesome. It's our web product. But every year we keep adding more and more to that. And so that goes into the scaling bucket. The third is what we call new seeds. So this is when we go into annual planning every year. The teams come and they say, this is what I invest in and this is what I'm going to build. And so you have to make sure across all three of those buckets you're allocating properly. If you put too much into the core business, in the short term, you'll feel good because you'll generate a lot of cash flows.

35:08But in three, five, 10 years, you won't have made enough investments. Conversely, if you put too much in the new seed bucket, you're not generating enough cash flows from your core business to fund those. And then you're going to start to burn cash. And so it's how do you balance between all three of these? And there's no magic numbers. And we have good heuristics for what we think each of them should be. But in general, when we look at those three buckets, that works well for us. Every company is going to be slightly different. But the main thing we learned in 2022 is you have to invest in all of them and you have to measure it.

35:34You have to be really, really deliberate about where you're putting your capital. It's so funny because we were talking to Aurelien Nolfe, who's the CFO at Navon. He was formerly at Lyft. Before that, he was at EA and he had given us a framework that was 70-20-10. And it was pretty much the same thing where you have the core business, You got to keep the lights on. You got to make sure the main thing is the main thing. Then you have 20-ish percent to dedicate the stuff that is maybe like what you'd call a series B or C investment within the company. And then you have these moonshots that you said 10 % went to.

36:06And he took us through what they went through at Lyft, where they basically went 100, 100, 100. And that's never good. So to your point, I don't know if there necessarily are hard and fast numbers, but you do have to think of the sizes of the bets. You know, in general, we don't put two draconian guidelines like it has to be 70-20-10. But I think those are really helpful frameworks. There's some old HBR studies that have looked at this and, you know, they looked at industrial businesses over the past 30 to 100 years, even have some software companies in there. And they said what companies did best based on these allocations.

36:39And what you get to is roughly 60 to 70 percent you should be doing your core business. That's kind of, I think, a nice mental heuristic. You can go as probably as low as 50. I think if you're below 50, you're not investing enough in your core business. So it'll move around from time to time. Between the scaling and the new seed buckets, those ones play around a little bit too. There may be time where you need more investment in scaling, or there'll be other times where there's a new technology comes and you want to invest more into the seed bucket. But yeah, in general, I would say 50 % to 70 % in your core business is probably a good heuristic.

37:09And then the remaining 30 % plus into those other two buckets. So I'd imagine those seeds eventually grow to become one of those 13 or more product lines that you have that make over$100 million. How does someone come to you and say, Shiv, we should fund this as an idea? It starts during annual planning. And what we do is Vlad, our CEO, he builds a vision doc. We actually just did an offsite for a whole leadership team a few weeks ago. And that vision doc is updated every year. We actually do a 10-year vision now. We used to do five years. A couple of years ago, Vlad actually said he wanted to start doing 10.

37:40and so we build out a full 10-year vision doc. Then myself and the members of the finance team, we translate that into one-year plans. Okay, we have the vision. This is updated. Here's all the new things we want to build. Here's all the three buckets that I mentioned. Here's the straw man list for what we want to build and the KPIs for each of them. Now, to get to that point, we spend a lot of time with the GMs on, okay, this is Vlad's vision. What do you want to build next year? How do we put it in there? We also start to do some straw man KPIs, okay, from the finance standpoint, what do we want to do?

38:09And then we have our initial framework. And so that then goes to the entire leadership team. We then share it with the whole company. And then we officially kick off annual planning, usually in September. And it goes until about Halloween. And then we do the readouts in November until Thanksgiving. And then it's done. And then you consolidate and you build the whole plan. And so when teams come to us during planning, there's a couple of things they need to address. First, which of the buckets of Vlad's vision are you building towards? It needs to make sure it maps to something. Two of our different key priorities for the next year, what are you building for there?

38:40And then you have to have all the resources I mentioned. So what's your P &L? How many engineers does it take? Designers, et cetera. This is my eighth plus year of doing annual planning at Robinhood. And each year we get better and better. I think a home run is if you make it as light a lift as possible for the GMs and product engineering leaders, but you cover it as in depth as possible for Vlad and myself to make sure we feel good about it. It is a hard process. There's a ton of people that go into it. But what you come out with is a really good idea of what you want to do and why. A couple years ago, when you mentioned the refounding, the other thing we did is we killed OKRs.

39:14We used to do annual planning through OKRs. And what we found is we were terrible at them. We didn't know how to write them. We didn't follow them. And so we spent a lot of time with Vlad and myself on the finance team. We said, what do we want teams to actually come with? And it boiled down to what are you going to build? Who's the customer for it? when you're going to ship it by and what are your KPIs it's similar to an OKR we call them goals but it's not trying to force something into this is the result this is how you do it's just what are you going to ship for who by when and what are the metrics you're going to move by so that's the general thing people try to strive for and then there's a much more detailed P &L behind it and what resources you did so that's kind of the broader plan and then there's ad hoc things that come all the time they tend to come inter-corridor or other things and so last week I was flying back from New York and I joked, I got three headcount requests on the plane after not getting many for a few weeks.

40:05Everybody knew I was God as they were trying to hit it up at the same time. But teams were really good. It was okay. We just met with you and Vlad. You said this is a strategic priority and come back with what do you need to accelerate it? Here's what I can do to accelerate it. Here's how many resources it would take. If we don't approve it, that's okay. But here's what the KPIs would look like. And then you could go in and see if you want to do it. So it's a combination of kind of that full annual planning process and then reviewing things intracurter as needed. You are what your gross margin says you are.

40:33Sorry, my kids are tired of hearing me yell that at the kitchen table. Dad, I'm two. I don't know what cloud costs are. Well, I do. And cloud infrastructure is the second largest line on most tech P &Ls. And yet, most finance leaders couldn't tell you how it's priced. And as a CFO, I understand there's a non-linear impact to your company's valuation when you improve your gross margin. And the path of least resistance is through your AWS or GCP bill. Because like anything you buy, cloud gets cheaper when you buy it in bulk. In fact, you can get the rate down by 20%, 30%, even 60 % in some cases.

41:08The flip side is getting saddled with a bunch of capacity you never touch. Happened to me once, I think I still got some megawatts in the kitchen cupboard somewhere. That's exactly what cloud capital solves. Cloud capital underwrites the risk so you can realize the same savings of a deep long-term commitment sands the downside. Oh, and it takes no engineering work. Bingo! I've known Edward since back when he was just starting the biz, and it's incredible how much they've saved customers on their cloud bills. That could be you too. So head over to cloudcapital.co, that's cloudcapital.co, and find out how much you could save.

41:44Every decision a company makes is inherently a financial decision. Folks, I've been trying to tell you that for 300 episodes. So it's wild that most finance teams have to spend a week on what already happened. While my favorite movie is Back to the Future, we'd be living in the past. Speaking of movies, here's a terrible plot. Tired accountant chases down a receipt from March and then polices a$20 Anthropics subscription, starring the accountant Ben Affleck. So stop living it. You don't have to play defense on what already happened if you get your system sorted. And Brex's intelligent finance platform clears the backward-looking work.

42:19policy enforced at the point of sale receipts matched instantly close short in two days not weeks what's left is the forward-looking part where to deploy capital how fast you can move what next quarter actually needs because the defense is handled by brex it's time for finance to go play offense throw the ball deep thousands of companies including anthropic coinbase and DoorDash already run on Brax. Head to brax.com slash metrics to join them. That's brax.com slash metrics. If you work in finance, you know what time of year it is. I'll give you a hint. It's our Super Bowl. Budget season is here.

42:57Woohoo! So how many versions do you think you'll get up to this year? I once got to V147 in the good old Excel days. Beat that. Actually, please don't. This is when your planning software should earn its keep. You don't have to choose between either Excel or an inflexible ballooning platform that takes a consultant to change. Abacom brings you the dynamic capabilities you love from Excel while preserving the rigor and governance of an enterprise suite. I met Abacom's founder and CEO, Julio Martinez, more than three years ago. He and his co-founder, Jorge, came out of finance and they built a planning platform that can run a complex business without becoming another system that requires a babysitter.

43:37Abacum puts your actuals, forecast, models, and business context in one place. So you can update the plan, run scenarios, and answer why did this change. In fact, you can even ask it in plain English. You might not even have to spell it right thanks to AI. That's why I'm so excited about Abacum. Go to abacum.ai slash mostlymetrics. That's A-B-A-C-U-M dot A-I slash mostlymetrics. Or just tell Julio that CJ sent you. That'll probably work too. I really want to credit you and applaud you for saying that you weren't good at OKRs. I think many of us share that sentiment. I've never been able to nail them.

44:15And I think what makes it hard is it's often a proxy for some sort of underlying truth that you're trying to measure. I think if you just get rid of that and link it to the product roadmap and what the customer wants, to your point, it hits the nail on the head. It doesn't mean you don't have goals. Like, we obsess about goals. We have a ton of we measure hard. But to your point, do what's natural for your company. Like OKRs work for Google. Fantastic. John Doerr is brilliant. I love his book. Like I think everybody should read it. But you have to be true to yourself. And so for us, it was really simple.

44:46What's the customer pain point? We also obsess about how fast you're going to ship. So when are you going to ship it out and what metric are you moving? And that's it. So I would encourage every company to think about what are you really trying to move and then build your planning around that rather than try to force it into OKRs. You've said that every product has to stand on its own economically. What does standing on its own actually mean inside Robinhood? To answer it specifically, what it means is no loss leaders. Every single product has to have positive unit economics. Now, we're OK working for thin unit economics, but I don't believe in, oh, we're going to lose money on this product and then we'll make it up on somewhere else.

45:19That is a recipe for disaster, because if it doesn't happen, then all of a sudden you have to realize like, oh, this product is either not worth it or I'm subsidizing another product. So that's what we mean by standalone, positive unit economics. We then have a set of pricing principles that we put together a few years ago that goes to every finance partner and the GMs and the product managers when you're building new products. So first rule is positive unit economics. Second rule is it needs to be able to cover its fixed costs over some amount of time. It doesn't mean on day one you have to cover all your engineering costs and all your fully burden costs, but over some years you need to cover all your fixed costs.

45:54and then by year five generally you need to have a fully burdened pnl to show this is a good product so we give you multiple years to get there it has to have a positive irr and you have certain internal thresholds for where it needs to hit we look at payback period if depending on the the type of product it is in particular for marketing but even for some of the others and then minimize your variable cost and do as many fixed costs as possible and so when teams come to us for new things it's here's the unit economics here's the five-year pnl here's the irr here's what it looks like. Everybody has their favorite way of looking at it.

46:24Jason, the person who trained me from Amazon, he was really big on the five and 10 year P &L. That was the Amazon view. And I still love the P &L view, but everybody knew if you were sharing it with Jason, you got to see the five and 10 year P &L view. Conversely, if folks are coming to me, they know what's unit economics. That's the first thing I'm going to ask for. What does it look like? What is unit economics? And is it standalone profitable? The last thing we look at and what you mentioned before is we're at the scale now that it can pass all of those. But if this can't get to 100 million of ARR in some amount of time, it's not worth it.

46:56It's an internal time horizon, but there needs to be some years where we think this can be big enough to hit 100 million of ARR. We're actually now starting to look at can it become a billion dollar business as well, just given our size and how long would that take? And so those are some of the things we work into. And it's a fun process. And as I was saying before, similar to having DRIs, people just want the rules. If you give the product manager and the GMs and the finance partners the rules to build, they can go build. I can't look at every single product or feature anymore, just given our size and scale.

47:24But if people have the pricing principles and I can look at the output with the finance partners and the GMs, it allows people to go really fast. So something that you recently got into that's doing smashingly well is prediction markets. I'd imagine somebody brought that idea to you and you asked, what are the unit economics of this? This came about during the 2024 election. We've been looking at it and it wasn't on the roadmap. We were, you know, towards the end of the year, the elections were coming. I give a lot of credit to Vlad and the GMs, the product engineering team. There was a ruling that said this was actually allowed.

47:56And so we challenged the team if they could have the product ready for the November 2024 election. Now, Vlad has told the story before. They built this in probably two to three weeks. As you say, that's like in a month, though. It was incredible. It can't fail. It has to have the scalability because we expect it to be there. The product has to be beautiful. We moved heaven and earth. It destroyed a lot of the roadmap. That is the beauty of a founder-led tech company. There is nobody that could get that out there that fast. And besides CalShift, we were the only ones to have it. And that was their whole business.

48:26It found lightning in a bottle and a product market fit. This is where as the finance team, then you have to be nimble. We had to be okay with, you know what? We're going to need to add more resources. We're going to need to blow up some of the roadmap. This is something that has a moment in time and we're going to make a bet on it. And it worked. Then we went out and now we have the official process for, okay, how much more resources do we want to put in it? What's the right amount? What are we going to deprioritize? So it's only 18 months old. It continues to do really well. The other thing we did is we vertically integrated.

48:55So I'm also a huge fan of vertical integration. You control the technology, you can build a better customer experience, and you have better unit economics. And so once we found product market fit, we then said, what's the best way to vertically integrate? And we bought Rothera in a joint venture. That's the exchange. But big picture, we took the positive unit economics we got from being vertically integrated and we passed it back to the customer. The counterfactual would have been we just could have increased our take rate. But we said, you know what, it's really important for us. This is a growing space and we want to be the pricing leader.

49:24And so we took the technology, we took the better modernization, passed it all back to the customer without impacting our take rate. And so that allows us to grow even better there. Something else you recently launched was the ability to invest in private markets. Take me through your mindset when doing that, because you have to say, can this get to$100 million under some time frame? But you also have to look at each transaction. Can we be margin accretive there? What are you thinking when this crosses your desk? This one is fun because I personally get to lead this business. Also a little bit strange at Robinhood that some of the non-product engineering leaders help build some of the businesses.

49:59I give a lot of credit to the leadership team that everybody takes on different product responsibilities as well. But the vision for this one was, can we do for private markets what we did for public markets? That was the general thesis. One of the biggest inequities we heard was some of these massive companies, the Frontier Labs, are getting to the trillion dollar scale when they're still private. And the average customer couldn't invest. So we took that mindset. And then we said, what's the best way to do it? And there's these registered 40-act vehicles. They've been around for a long time. They're meant to hold private assets or income assets.

50:30So we work really closely with the SEC and we're able to actually build our second fund now. That's why I mentioned I was in New York last week and we were at the NYSE ringing the bell. And now we're able to give early stage access to customers in addition to the first fund, which was late stage. And so we looked at it and we said, first, what's the customer pain point we're solving? That's easy. They want access to private markets. Two, what are some of the features they wanted? They wanted daily liquidity and they wanted to be available even if you're not accredited. Those are really, really hard.

50:5785 % of Americans are accredited. Most of these vehicles are illiquid. And so that's how we designed a product. Then the last thing is, how do we make it unit economic positive? This one was easy. It's something I love because it has all high fixed costs. There's very low variable costs. And it's easy to model. It's just a management fee on assets. But I love that we solved the customer pain point. We did it in an innovative way. And it's a really good business line for shareholders. Shiv, sometimes I'm like a dog with a bone. I heard you say you don't like variable costs. Where does that philosophy come from?

51:26I will put it even stronger. I hate variable costs. And so I say this to investors, I say this to our employees. The reason I don't like it is if you scale a business, which is our whole goal, it increase your cost space. If you do the hard work up front and you take a lot of fixed costs and you spend the time doing that and you minimize the variable costs, what happens is you can work for really thin margins. But then as it scales, all of it drops to the bottom line and your incremental margins are really high. So if you look at Robinhood's incremental margins, it's about 75 % goes directly to EBITDA.

51:59That's by design. So every time the team comes, we challenge them to positive economics, but also minimize variable costs. That is hard. It's really, really easy to throw headcount at the problem or throw operational processes there, but that doesn't scale. But if you do the hard things up front, build in the fixed costs and minimize the variable cost, that is a fantastic business. This is the Costco model, the Amazon model. These are businesses at scale. And so that's one of the other things I pay a lot of attention to when a new business comes up. How do you minimize the variable cost? We've said publicly before, 85 to 90 % of our costs are fixed.

52:34And so every time we look at a new product, we have to make sure we're staying as close as possible to that ratio so we can scale the profits for shareholders and then reinvest them in the business. It's funny because when you said that, I immediately thought of like Costco or Walmart or Amazon. That is the whole model and it works. And then you can pass on the value back to customer because you're not worried about adding variable costs. And so it's a brilliant flywheel. Do the hard things up front, have high fixed costs, generate value, pass that value back on a customer. It's exactly like you said, it's Amazon, Walmart, Costco, and we're trying to do the same thing in financial services.

53:07And it becomes a moat over time once you have scale. It's really, really easy for someone to come in and build it quickly with variable costs and high operational costs. It's really hard to do with the high fixed cost base. So the bigger we get, the more scale you have, the more of a moat you have. again, very similar to the e-commerce retailers. And now at our size and scale, I think it's one of our greatest moats along with being regulated in the customer base and the capital base that we have. And so that's why we spend so much time investing in it. We touched on bringing new products to market and how you eventually want them to get to over$100 million in revenue on their own.

53:39I've heard you say that some teams are actually gold on market share rather than just revenue or profitability. I'm curious what the thinking is behind that. The vast majority of teams are market share goals. We typically don't do revenue or profitability goals. It tends to be all market share. Why is that? A couple of things. One is market agnostic. A lot of our businesses are trading activities or market dependent. What happens is if the market's doing really well, teams can pat themselves on the back, but you didn't actually drive anything. Conversely, if markets aren't doing well, we can be too hard on the teams, but it's not a good precursor for are they building.

54:13But if you use market share, that makes a level playing field. Everything is market neutral. Are you gaining market share, whether the markets are doing well or the markets are doing poorly? And so that's one thing we spend a lot of time on. Now, you have to make sure that you put the pricing principles or the cost discipline on it. One way to grow market share is just give away the product for free. That's why the check metric is, you know, are you hitting your pricing thresholds and your IRR? It works really well. Again, you have that kind of push and pull. The GMs would love to just pour marketing dollars on it or make the pricing cheaper.

54:43And that's where the finance partners come in. But at the same time, we want to make sure we're growing market share. So we're willing to make those investments. And so every new product we look into, we always start with what is our market share? How big could this be? And in the P &L, if you build with positive unit economics and high fixed costs, that'll take care of itself. Because market share, I immediately thought of Uber in the early days. OK, well, I'll basically just give you a ride for free. And there is probably this growing up period with many two sided marketplaces where you have to subsidize one side of it in order to get a large enough base to interact with the other.

55:17right? You're kind of building two businesses at once. But just to reflect on what you were saying, it sounds like that's one pillar of it, but you also have to have these other sanity checks to make sure that it's margin accretive. Luckily, we're not in the marketplace, so we don't have to subsidize getting the supply and the demand side. But same concept, like upfront in your hyper growth mode, we might be willing to work for a slightly lower ROI, still positive unit economics. But then as you scale, we also make sure that it's a good return. But if you just go to teams on revenue, I think you'll make some short-term mistakes.

55:48You might charge too high or you might not be focused on the customer. But if you focus on market share, then you have financial discipline check metrics. We found it's a really good balance for building consumer products. How the heck do you run a forecast review process for this many business lines? First, we have a great team across finance and data and the product and end. So we spend a lot of time there. Our planning process, it actually starts now. This is what I've mentioned. We do our strategy offsite. We take Vlad's vision. We build the one-year plan. So between now and the end of the year, we'll build what we call OP1, operating plan one.

56:19Again, this is another Amazon model. This is what we think our forecast will be for next year. Everything is bottoms up. And so each individual team is building with their finance partners what they're going to do for both for this year and then for next year. The revenue side, I'm actually not as concerned about. That's actually not as hard to model as you would think. What we work on is really diligently getting every cost to make sure we understand what the costs are we're making our investments. And so we'll start at the top line and say, this is how much new costs we want to add to the business.

56:47This is how much revenue we think we can grow. Our sanity check, and this is what I tell shareholders, is profitable growth. We want to be growing, but we want to make sure we're growing profitably. One, it causes you to be focused, but two, it makes sure you stay financially disciplined. And so I'm okay putting all of the growth back into the business, but I want to make sure that we still have some cushion there. Then every quarter, what we do is we do our updated quarterly forecast, Q2E, Q3E, Q4E, the estimate, where we say, where are we in the quarter? And we update our annual plan. And so you're always looking both to your finalized annual plan called OP2 Operating Plan 2, and you finalize that in January with the board and the head of getting guidance.

57:22You then update every quarter and you mark to mark it. And you have to stay nimble. A quarterly update is great, but we also do what's known as R &Os, risk and opportunities. And so every few weeks, you're looking at things that are going up and down. And so even inter-quarter, I can say, here was our quarterly plan. And here's what I think is at risk. And here's what I think is an opportunity. And it kind of nets out. And that allows you to make quick decisions inter-quarter. The other thing we do is every single product or GM or business line has to give metrics twice a month. And so it's an async on Slack.

57:54And so we split it every week. And so you only have to read so many of them every week. But every Friday, there's probably 10 plus, maybe even 15 that come out where they give an update. And it's red, yellow, green across the metrics, what's going well. And so that's how you stay marked to market. Like I read those every Sunday. I go through all the plans, give people the feedback, and then you go into the next week. And so it's not enough to do an annual plan and just sit there. You have to do quarterly forecasts. You have to do R &Os. Then you have to be looking at the KPIs in real time. I find that there's such an art and a science to the cadence in which you check.

58:24because to tie it back to stock trading analogy, I don't like to look at my stock portfolio every day. I'll start to make conclusions that really aren't there just by like a 2 % or 3 % swing. How do you think about how frequently you should be looking at these numbers? On the whole, I think you should be looking at things in years, not in quarters. You should be making sure that you're not making short-term decisions. And one of our top KPIs is we said we want to grow net deposits 20 % plus per amp. That's our number one metric. Our customer's trusting us. that's what I guide shareholders on. Don't overreact to one month or even one quarter.

58:58Look at it on an annualized or multi-year basis. Internally, though, I need to be hyper paranoid every single day about what's going on, what were the flows, what were the ACAPs, what were the ACH. And this is just so you can mark to market. Now, I'm not looking to overreact. What I'm looking for is outliers. Did we break something? Did we run an experiment that's still working? Did something structurally change in the market? And so there's a fine balance between looking at the big picture, but also looking at the micro. Every product manager and business manager and GM is obsessing about their metrics daily.

59:28There's a few internally that I look at every single day and the product and GMs know what they are because I'm constantly hounding them on them. But it's trying to make sure you find that right balance. And so I think it depends on where you are and what role you are, but you can't get complacent, which is why we're looking at some of these on a daily basis. Shiv, I'm gonna take you into asking better questions brought to you by our friends at EY. So, you know, you're a successful guy. you're crushing it at Robinhood, but I ask every person who comes in the pod, what's something that you've screwed up on the job before?

59:56It could be here or a previous role. I'll give you one Robinhood one and one non-Robinhood one. In 2021, when we were hyperscaling ahead of the 2022 when we had to do the restructuring, one of the things I regret is we lost some of our financial discipline. And in hindsight, you could look at all of it. We were in hyper growth mode. We just went through the GME event. We were about to IPO. it went through COVID and everything was on fire. We were fixing problems by throwing bodies at it. We were getting away from the Robin Hood magic of automating and using engineering. And then I look back and, you know, at the end of the year, we've gone from 2000 people to 4000 people.

1:00:31And we had all these different teams and redundant teams. And then we had to do a really painful restructuring for employees, which I which I never want to do again. And so what it taught me is like, hey, doesn't matter what you're focused on. It doesn't matter where you are in the cycle. you have to keep your eye on the ball there. And again, I can look at the confluence of events that led to it, but I take responsibility for that along with Jason. And one of the things that we learned is, you know, we never want to put employees through that again. And so you have to make sure you maintain your financial discipline.

1:00:59A funny story I'll give you from my trading days, because before coming to Robinhood, I was on Wall Street as a trader. When I joined PIMCO, big asset manager,$2 trillion in assets, I was a portfolio manager and trader. My first week on the job, I broke my trading limit and also almost got fired. Your first week, when you join, you get an internal trading limit for how much you can trade every day. Typical first time traders come in around 25 million and then it scales up. And by the time I left, I think my daily trading limit was multiple billions. But I actually didn't know what my internal trading limit was on my first day.

1:01:28And I did a trade for one of the larger PMs and I broke my limit. The head of the desk had to go defend me to everybody. And luckily they said, OK, you got one more strike and that's it. But what I learned is you're responsible for your own destiny. It didn't matter that nobody told me what my trading limit was. I should have investigated or done it. But it was a it was a friendly reminder that if you don't take care of responsibility for your own things, bad things can happen. And so I always want to be hyper paranoid about making sure we're knowing all the rules of the game before you're moving money around.

1:01:55You're a true renaissance man or maybe you're the Dos Equis guy, the most interesting man in the world, because you started your career with the Oakland A's during the moneyball era. Is there like a takeaway or a story that has stuck with you? I love that. So I grew up in the in the East Bay and the Central Valley. Huge A's fan. I'm going to A's games. I was four years old with the Bash Brothers and Mark McGuire, Canseco and Dennis Eckersley. So when I was in college, I had the opportunity to to work for the A's. This is in their front office with Billy Bean and David Forrest and Farhan Zahidi, kind of the brain trust there.

1:02:25I was doing baseball analytics and I loved it. We were playing poker in the locker room with the players, watching batting practice. The main thing I took around is a lot what I use today. You got to be data driven and you got to be scrappy and hungry. Everything the A's did was measured. They were pushing the boundaries. They knew who they were, and they never got in over their skis. And these are still things I use today. The funny part is, you know, after I finished, I could have stayed there and worked for them. And I stupidly decided to go be a banker at J.P. Morgan. And my former boss, Farhan Zahidi, then went on to be the president of the Giants.

1:02:56And so my buddies like to joke with me, if I would have stayed there, I probably would have been a GM of a sports team by now. But I love it. It's the path not taken. but some of the best times I've learned and also really learned the value of data and being scrappy and hungry. Most importantly, how large were Mark McGuire's biceps? There were some very, very large, large men there. My favorite person ever to watch batting practice was Manny Ramirez. Oh, yeah. I'm a huge Red Sox fan. So I'm an A's fan. I respect the Red Sox. But there was just something about him. When the ball hit the bat, it was like nothing I've ever seen.

1:03:26I have this very distinct memory of watching the batting practice that it was just it was a beautiful thing to watch. It's a sight to behold. Shiv, if you could tell your younger self something, knowing what you know today, what advice would you tell them? First, and this is something that Jason taught me that I now share with the rest of the team is, when opportunity happens, just say yes. Like some of the best things I've ever done have just been coming yes. When I first joined Robinhood, my first job was actually the treasurer. It was building out the treasury team. And Jason came to me and he said, hey Shiv, I think you should run IR.

1:03:54I said, I don't know a thing about IR. He said, you're a former investor, you'll figure it out. I said no to him three times before I finally took it on. About a couple months later, he's like, hey, Shiv, I want you to build a finance team. I said, I don't know a thing about finance or FP &A. I got treasury, I got IR, I'm good. Said notes him a few times and eventually took it on. It was the best thing I ever did. And so if I look back at the moments in my career that I've done best, it was opportunity happened and I didn't know what it was going to be. And I just said, yeah. So that's one thing I would share.

1:04:20The other, and I'm going to steal this from Steve Kerr and Ted Lasso, is play with joy. Everything we're doing is important. Everything is fun. And in the moment, it's hard to remember that. but I feel so fortunate and humbled to be in this role and I never want to take that for granted. And so I love the mantra of just play with joy and enjoy what you're doing because life's too short not to. And if you put that together, I think you can have some really great outcomes. I can tell you love it. I love when I talk to people who just have a passion for the game. This is more of a technical one. Can you walk me through your finance software stack?

1:04:50What tools does your team depend on to get the job done? So we use Oracle and they're our main ERP and we use NetSuite and Fusion. For procurement, we use Koopa. We've been with them for a while and they have a nice integration there. Payment side, we use both Brex and Ramp. We use both of them. Think they're really good partners there. And then a lot of the rest of the stuff we build in-house. FP &A, we do use a couple of different ones, but we're still trying to figure out which one we'd like. On the treasury management side, we've had a couple TMSs and we've taken them out. And so I'd put kind of those as the big ones between NetSuite, Coupa and Brex.

1:05:24and then everything else is either built in house or kind of a compilation of some smaller vendors there as well. That's a good stack. Last one I got for you. What's the craziest thing you've ever had someone try to expense? Our chief legal officer, Dan Gallagher, is a very nice connoisseur of wine. So there are times where I will see some dinner bills with some very expensive wine and know that Dan G has been there. In case you were wondering, yes, they all got approved. He works incredibly hard and I think it is fun to celebrate with the team, but I have seen a couple of really nice bottles of wine come through over the years.

1:05:54Amazing. Shiv, thank you so much for joining me on the show. This has been a blast. No, thanks for having me. Great questions. I love your newsletter. I just started listening to your podcast. So I hope folks enjoyed it. And thanks for having me. Run the Numbers is a mostly media production. Yelling an intro by Fat Joe. Artwork by Meg D 'Alessandro. Nothing said on this podcast is intended to be business or investment advice. It's the sole opinion of me, a guy who feeds his dog way too much ice cream and has a history of net operating losses. LOL. If you like this podcast, hit subscribe and give us five stars.

1:06:26It will take like two seconds and our algorithm overlords love it. Drink water, call your mom and have a great day. Peace.