Gokul Rajaram on Defensibility, Scaling Companies & Hiring for “Spikiness"

Hi! This is one of my favorite times of the year to meet with this great group of founders. I'm looking to this group and the group of talented AI engineers and engineers broadly in Asia, India, and beyond to hopefully lead the way and take what Deepseek has done and bring it to the, to the next level. I think one thing that a lot of questions— I speak at a lot of events and talk to a lot of founders What is the number one implication of DeepSeq? The number one implication of DeepSeq is that AI is now democratized in a way that we didn't really imagine even 3 months or 1 month ago. And so every lab— I think a few weeks after DeepSeq, we saw here in the US somebody replicated DeepSeq for $50. So you're going to see a massive cost lowering of API access or building AI models. And capital is no longer a moat. In AI. What is a moat then? The challenges for all of us who are investing in and building companies, what is a moat in AI? The only enduring moat is to invest in R&D and product development and keep building product because the reality is the foundation model companies are realizing that API layer is no longer going to be a viable business model. They're all coming up the stack. You might have seen that there was a leaked screenshot from OpenAI's presentation which showed a sales agent that OpenAI is building. So for all of us who are building agents of different kinds, Anthropic, OpenAI, and others are going up the stack. They're most definitely going to come after agents. So the best moats are probably data that is not crawlable publicly, not available publicly, and is private so that the foundation models cannot crawl it. Second, workflows that are complex and interconnected where you need not just one agent, but six agents working in tandem to make something happen. And then third, domain of vertical expertise, maybe even systems integrator implementation expertise to make it work for an enterprise. So the more complex interconnected the workflows are and harder to implement they are, and the more data that is private that they are trained on, the bigger moat we can get. But again, these are just temporary. I think every moat in software is going to be broken down, is going to be crossed. The only real moat is innovate. I actually feel that you've got to innovate 6 times and have 6 fundamental innovations for you to be an enduring company. I've done this math a few times using Google, Amazon, et cetera. If they had just stopped at one, they would not have succeeded. You need 6 different things. So I think even in the AI models, companies have stopped after model 1. If OpenAI had stopped after GPT version 2, they would be dead at this point. They had to go to 4 or 5 to be one of the top 2 companies left. And even then, obviously, they're going to be one of the survivors. But they had to do 5 or 6 foundational things in order to survive. And so each of you, you've got to make 6 foundational product things in order to actually build an enduring company. One is not going to be enough. That's very clear. Anyway, let's get to scaling companies, and we'll discuss some of these through the presentation. So this— I wanted to also talk about how quickly technology is moving. A month ago, I got a note that a company I'd invested in that had reached $35 million in revenue was shutting down, basically. And it was zero to everybody at the company. And I had made the intro to DoorDash, and they— Dodo was a $2 million account for them. I was like, Dodo is making $2 million, $35 million. They're not going to die, are they? And they truly asset sale essentially. And I won't name the company, but the reality is if you're not innovating, if you basically have a single product which is ultimately going to be commoditized, you're not going to build an enduring business. So just because you have $10 million revenue, $30 million— I have a company at $125 million revenue, that I've written off at this point. So I think every moat, every revenue scale is susceptible to cannibalization. And the good news is you're all small, so you can all cannibalize the big guys. No moat is safe. No castle is safe at this point. That's the point I wanted to make. Quick recap. Some of you might have been here last year, but there are 3 stages of company, I think. There's a startup stage. There is the early growth, which is the stage you're going to talk about. And then there's a scale-up stage. Startup, the 3 things that matter— actually, the one thing that matters the most is finding product-market fit, figuring out how to get— figuring out who your customer is and how to serve them better with a remarkable product and in a way that gets them to retain. So retention, I think, is the number one metric to focus on, getting a small group of loyal customers that retain and use your product and love your product. Usage, love, and retention. And then culture is the second thing. The first 10 people you hire are going to most likely set the template for the rest of the company. So it's very important that you handpick the 10 people. In fact, I think Max Levchin said this, that it's actually OK to have it be a monoculture. In other words, it's actually important maybe for the first 10 people to be very, very, very similar in their backgrounds, worldview, et cetera, so that you're all aligned on what to build and don't get into tiffs around other things that are not around the customer and the product. So it's actually good to have— maybe from the same school or same background, whatever the case may be, but you want them to be as unified, uniform as possible. And then finally, a startup is characterized by generalists, especially even engineers. Engineers are generalists. Definitely the non-engineers are generalists. Almost the first— you know, Niraj at WhatsApp is probably the best example, who basically is the ultimate generalist. He was, I think, one of the one or two business people at WhatsApp till the time of acquisition, and he did everything from signing the leases to making offers to engineers, to negotiating the corp dev with Meta, everything. And so generalists, that's what startups are. Scale-up, which is the third stage, is when you have executives. You have real executives who come bearing big titles and are managing managers and 2 or 3 levels. You actually think about org structure much more. And there, the org structure, there are some important decisions to be made. A lot of companies think about, should we go to a GM-like model, a BU-like model? Where you have product design, engineering, and other functions reporting to a person. You have multi-product come into play. And then much more predictability. Of course, as you go towards an IPO, 2 or 3 years before the IPO, you've got to start operating like a public company. You've got to start having internal quarterly forecasts and really understand if you missed it, why did you miss it? If you beat it, why did you beat it? And then keep revising the forecast. So a lot of predictability in cadence and so on. The middle is where— I think many of you are, and hopefully many of you will get to. So that's what we'll spend our time on here. So there are 3 pieces, scaling the product, scaling the GTM, and scaling the org. I won't belabor scaling the GTM. We'll focus a lot more on scaling the product and scaling the org. Scaling the product, 3 things to think about, outcomes, habits, and optimization. Focus on outcomes versus output. What are the right habits to build as a product team? And then how do you think about optimizing versus innovating. Most importantly, a lot of companies get into— after you have product, get to product market fit, a lot of companies get into the trap of building up, becoming a feature factory where you're just launching feature after feature after feature. And you ask the PM or the founder what the product roadmap is, it's simply a list of features. And if you ask the question why, nobody can truly understand why this feature exists, what it adds, what value it adds to customers, et cetera, et cetera. So one of the most important things I try to encourage companies to do is to stop orienting around features and start orienting around outcomes and train our teams to orient around outcomes. What that means is every feature you launch should be directly tied to changing a customer behavior. In fact, I would argue that a feature shouldn't exist in a product unless it changes a customer behavior. And customer behaviors or customer states, as I call them, can be anything from not a customer state to becoming a customer, becoming an initial customer to become a loyal customer, going from a churned customer to a reactivated customer, et cetera, et cetera. All these states of customers, and we want to make sure customers move from one state to the other. And if we can't articulate why a feature changes a customer behavior, we should not be thinking about the feature. And in order to get to even customer behaviors, we have to map— what happens is a lot of founders live in the world of, revenue and output outcome metrics at the company level, and then the engineers and product teams sit at the feature level. There's no connective tissue between revenue and profit and features. And customer behaviors are actually the glue between business metrics and features. Customer behaviors are essentially things I outlined. One of the most important customer behaviors is new customers. And so how How does a customer, how does an entity go from becoming not a customer to becoming a new customer for the first time? And then how does a new customer go to becoming an active customer after that, right? There's a new customer when they sign up, register, and maybe place their first order or make their first transaction. And then an active customer is somebody who actually is engaged and loyal. There's multiple states here. And what happens is a lot of the burden for this is put on the sales and marketing team. The product team doesn't really engage with this very, very, very important flow of the customer. Maybe the founder engages, but really it's not a— so one of the things I try to advise companies very early on is, can we put a product squad, which is product, engineering, design, analytics, to work on this very, very important thing, not just delegate it to marketing? And you'll see your marketers, your sales teams will immediately embrace, and they'll be so much more productive if we just put some product brainpower and horsepower behind this very important state transition. Because companies cannot grow unless they get new customers. Obviously retention is super important. At PMF, we prove retention, but we've got to— as demand gen is extremely challenging today, especially it's extremely hard from just SDRs to cut through the noise. You need a lot of product-led demand gen, a lot of inbound marketing techniques, and product can turbocharge that. So coaching teams on how to solve backwards from outcomes. The two things I look for, for any role at any company, problem solving and agency. Can they solve a problem? Given a problem— and the more senior they are, the more open-ended I expect the problems to be. If you're the CEO or CXO at a company, I expect you to solve company-level problems. If you're mid-level, I expect you to solve product-level problems. Given a customer outcome, tell me 6 different ways that you can accomplish it. Compare and stack rank why you will use one versus the other. But we've got to coach people to solve problems. And second is agency. Agency, as you know, is basically a better way of saying being proactive. Not being reactive, not being told what to do, but taking initiative, seeing that something is busted or broken. And I think we've got to— it's very hard because many of us have grown up— I grew up being told what to do. My first software engineering job, I thought I'd done a great job. I got to meet expectations of my manager. I was like, why? He said, well, you didn't take agency. You didn't take ownership. I was like, what does that mean? He said, well, I expect you to basically tell me what is to be done and do it versus me telling you what is to be done. And I think that's what we want our people— our people should be telling us what's not working and then fix it versus pointing out things. So it's a good lesson for me around agency. And then the third bullet is around validating hypotheses. Just like I said, a feature doesn't exist in my brain until it moves the customer needle. I think a feature is actually an experiment to validate a hypothesis. A feature is an experiment. What that means is you should never celebrate launching a feature. Never, ever. So many companies— think about the last celebratory email you sent around the product. It is very likely it was sent around launching a product or launching a feature. Who the hell cares? Who cares if a feature was launched? What we care about is did the customer behavior change? What does it do for the customer? A feature is very company-centric. It's about me. Instead, I want to see what it did for my customer. Think about the OKRs and goals you've set. How many of them are about launch feature X? I want all of you to look at every single OKR and change every OKR to be from the angle of the customer. Be from the angle of the customer. Change it to be customer-centric, not you-centric. And I think when you say— one of the questions I always ask PM candidates is, tell me about a situation. If I gave you zero engineers, zero engineers, and you had to test this hypothesis, how would you build this product? And in today's day, there is no excuse. For a PM to be able to build a product— to be able to not build a product without engineers. Why? Because there is so many prototyping tools now. And so I would challenge you and urge you that if you're hiring product managers, make sure that they are capable not just of creating great presentation but of creating prototypes. Give them an AI prototyping question. Make sure that they can validate hypotheses and get something on the web that you can then send a few people to, maybe with paid marketing, and see. —without zero engineering resources to see if they validated the hypothesis and only launch a product. DoorDash, I think, is the perfect epitome of that. At DoorDash, no feature is— the feature only launches when it validates the hypothesis. It launched to 3% or 5%. And then when it launches to 100%, the team will say, well, it launched to 100%. That's a launch. That's it. And more importantly, this is what it did. This is what it accomplished. It changed DashPass retention from X to Y. And yeah, there are some features, but no one really cares what the features were. What matters more is what it did for the customer. So that's outcomes. Training the company around outcomes, making your goals around outcomes, praising and celebrating outcomes, and figuring out how to go from business outcomes to features, which is the intermediate glue of customer outcomes. Habits. Continuous discovery is very important. What it means is you cannot have only salespeople and customer success people interfacing with the customer. If your product teams are not engaged with the customers on a weekly basis, you're going to fail. They're not going to live in the shoes of the customer. So you've got to have discipline around each product team, in my opinion, should meet with at least 1 or 2 customers a week. And they don't need to necessarily, in many cases, meet with them in person. You can do a Zoom. You can do whatever the case may be. But they should listen to a customer call. They should shadow CS. They should shadow sales. They should figure out how to engage and hear from customers in their own words. Sitting with customer support people and seeing how they answer tickets is one of the most clarifying experiences for a product manager or engineer, because you realize how broken your product really is and how much people are struggling to use it. It really gives you empathy for customers when you sit. So we forced every PM at Google— every company I've been to basically sit with customer success for 1 hour a month. Just 1 hour a month. Go in, and you've got to schedule it. I'll ensure you've done it. And you just come out of it saying, I didn't realize my product was that broken. That bad. And then experiment versus feature mindset, I talked about this. Every feature you should have— you have to think of a feature as an experiment. It is not a feature. Who cares? It is an experiment to prove a hypothesis. And then another— the other thing, I think the important thing about customer discovery is— so there is observing customer. How do you interview customers? I think a lot of PMs over the last 10 years— I was not an analytics-trained PM. Very customer story trained PM. But over the last 10 years, because analytics tools have become so good, a lot of PMs have become data jockeys. They basically know how to run the spreadsheet and how— they've become data scientists. But if you put them in front of a customer, they don't know how to extract insights by talking to customers. But so it's very important to figure out how the hell to train our product and engineering teams to extract insights from our customers. Because customers can't tell you the solution, but you can damn well get the problem out of them. You can get the problem out of them, and you've got to observe how they're using the product to get problems. So one of the good examples I use is Square Capital, where Square Capital was a product— Square was a payments company for a long time, for 3 or 4 years. After that, we started seeing that one of the reasons in the customer success tickets, a lot of things, people wanted their money faster to be sent to them, and we built the faster money feature. But the reason they wanted the money fast is they wanted to invest in working capital. They wanted to invest in working capital, and we said, OK, that's really the problem they're trying to solve by getting money faster, because these people are living literally on each payment cycle. They would pay essentially their landlord and other things. So we said, is there a way that we can build a working capital product for them that we already have a bunch of signals, which is the payment data we have there? We actually collect their payments. We have their bank account. Can we use that to underwrite them better than anyone else can? It turns out we could. We launched Square Capital. And the same happened with almost every product I've been involved in after the first one that the company launched has been by observing something about the customer behavior, understanding the root cause, and then building a product to address that root cause. And that's how you build a series of interconnected products. That's how you build defensibility. Your defensibility is not going to come from product 1 alone. That's remarkability. Defensibility is going to come from product 2, 3, 4, 5 that are going to surround the first product and make it really hard for a competitor. I think ServiceTitan, which a lot of people criticize when they went public because their revenues, et cetera, forget all that. It's a great example, right? They took— if you look at the ServiceTitan S1, the public document, it's a great document because they have built, I think, every single product needed by the field service agents that are their target customer. And they've grouped them into buckets, but they have truly served every single need where they have made sure their customers are using them top to bottom for every single need. And that happened over 10 years. But that's the kind of thing that's going to be very hard. Even now, I see some services company trying to displace ServiceNow. It's very hard because you try to displace one product, but the company, their customers are using 7 different products, and you can't displace one product. So building an ecosystem of products is going to be one very important thing that you need to do as you grow. And this is exactly— I think 2 years ago or 1 year ago, I would say, oh, you get to $10 million ARR, et cetera, then you launch a second core product. Now, I think you probably need to launch it as soon as you get PMF for the first one, you need to start planning your second one because that's your defensibility, that's your core R&D you've got to do. And what is the second core product? Be honest with yourself. It's not a feature. It is second core product which unlocks meaningful distinct budget than the first product. Meaningful distinct budget than the first product. Or meaningful differentiated value in case it's not a paid product. It doesn't matter even if it's a paid or a free product because Again, companies get very confused. If you have 6 products, which one should I charge for, which one you shouldn't? The reality is it's okay to not charge for some of them. Some of them can purely be retention products. Capital, for example, doesn't make that much money for Square, but it's okay because turns out once you use Capital, you're hooked. You're not going to leave the company. You're not going to leave Square. It's okay to not make profit. So be careful about figuring out which products are your profit pools versus which are retention drivers. You'll have a suite of products, some will be return— Gmail is a great example. Why the hell does Google have Gmail? It makes some money through ads, minimal, but reality is the retention driver. It gives them a lot of data for training purposes. Once you use Gmail, you have a Google account, and they have a lot of things they do with that, but it's not a profit pool. So it's okay to have profit pools and retention drivers. Not every product you need to suck all the money out of it. But regardless of that, need to launch a second core product sooner than ever before. That is going to be your moat. That really is the moat. The ability for a company to launch products, waves of innovation over time. And then innovation, how do you actually generate ideas? Every company I've been at, hackathons have resulted in at least 2 or 3 core product ideas. I think engineers, product, everyone, even non-product engineering functions love the opportunity to get out of the silo they are in and come together as a company for a week, a day, or something like that, once a quarter to hack on products. And you could even have thematic hackathons, which I've seen work really well. For example, you could say, "We want to solve problem X for our customer. Let's come up with ideas and let's build products." By constraining the time, you make sure that people are just building very, very rapidly, basically prototypes. And then you can see people vote on it. You see which are the top 3 products. Some of the things I've seen as prizes for the top performers, they just present to the board or they get a $100 gift certificate. More than that, they just love being recognized and love the opportunity to work together. And this also allows you to identify talents because if you find that there is somebody, an engineer or PM or even a salesperson who grabs together 6 people and they build a prototype for a really compelling thing, guess what? That might be the seed team for your next product. And you could basically pull them from what they were doing earlier and get them to work on this product instead. So hackathons. And then again, you are at this point where your core product is important to scale. But you do need to have some resource allocation framework. And you can use two— there's multiple— Google had 70-20-10. There's another thing called Horizons. You need some way to allocate resources between your core product and your new product. And so the core product still needs to be the main thing, but your new products need to get to, say, 20% over time. And at some point, the new products will graduate to becoming core product, at which point you fill the 20% bucket with another new product, et cetera. And then most importantly for the new products, It needs a single-threaded leader. You'll see that the core— once the core is starting to move, the core always resists any attempts for other products to take resources away from it. So you as the CEO or the founder have to be really, really strong and make sure you're giving space for innovation. Otherwise, the core always threatens to choke off all innovation. At Square, 50%— more than 50% of gross profit and revenue comes from a product called Cash App, which is the largest fintech app in the US. But for several years, the Square part of the company tried to kill Cash App because it wasn't making any money. It was burning money. It had some of the best people at the company working on it. So people were like— and we were going to go public. This was about 8, 9 years ago. People were like, why the hell are we funding this thing? We have to go public. We have these numbers to hit for the street. Why the hell are we putting 100 people on something that's not making any money, actually burning a ton of money through our referral program? And Jack, our CEO, stood in front of the company, defended it every day. Every week at all hands, and thank God he did, because otherwise the company would be half the size it is today. So these things take a while to get going, and you've got to defend it. Obviously, that doesn't mean you defend it illogically. You've got to treat them like startups. You've got to, just like your VCs treated you like startups and gave you metrics, you've got to constrain them from a funding point of view. Don't overinvest in them. Give them a small team, get them to hit a certain metric, again, PMF, scale, et cetera. And then you fund them. Do not overfund these things. Constraints breed creativity. So that's basically the scaling the product piece, outcomes, habits, and then innovation. Optimization you'll do, but really innovation is the more important thing. And then scaling the GTM. Number one thing, demand gen. Demand gen is going to be something you have to think about every day. And there are many, many different ways to do demand gen. And you're going to find your own thing based on— Many, many different— here are 4 different examples. Many of the legal AI companies are using events as demand gen. If you're involved with legal AI, so it turns out there's hundreds or thousands of, at least in the US, regional events that lawyers go to. So it's become a good way to generate demand. Zapier, famous for using SEO. Slack used product-led growth. You get 1%, they share it across the company. Replit uses social and brand and promotions a lot. So different folks, different kinds of companies use different. Consistent with your customer base, how they use the product, how they find it, how they make decisions, et cetera. But you've got to pay attention to figuring out how to scale. And ideally, you have one golden channel. You have one golden channel. You always will be testing smaller channels. But if someone asks you how you do generate demand, if you give 5 answers, that means you really don't have one. You really don't have one. You need one that's like your core bread and butter that's doing 80% of the demand. And then the remaining 20%, you're testing things out. But you need one thing. Thing that's 80%. You need one thing that's 80%. If you don't have one thing that's 80%, you need to keep working on making that one thing 80%. The second thing, the number one difference between fast-growing and slow-growing companies is sales cycle. Simple. That's it. Sales cycle. And sales cycle doesn't mean you're selling. It means how quickly from the time your customer sees the product do they become customers. That's why self-serve companies grow so fast because there's no one to touch. Customer lands on website, signs up, and grows— becomes a customer and pays you. So from the time of salesperson touching your customer to the first payment, what the time is, the faster you can cut that time down, the faster you will grow. And so many companies get stuck in that fourth and fifth bullet, $300K for 6 months. I have a $500K client. It's going to take 6 months. There's a POC, then there's some other thing, then InfoSec, et cetera. They are dead. That's over. Definitely the $1 million in one year, they're dead if that's their first customer. Suggest as a scale-up startup you stay in the first 3 rows. First 3 rows. Cut your ACV. Cut your ACV by making a simpler product. So many times when I see startups with a $500K product, I'm like, I don't want to see this crap. Make it a $50K product. Cut 90% of the functionality out. Make a lightweight product. Make a lightweight product that instantly goes in and takes 3 weeks to sell instead of 6 months to sell. If it takes 6 months to sell as a startup, you're dead. Because you don't get any feedback. You have no idea what's going to happen. 6 months is a lifetime. You have no idea what's going to happen. The number of companies I have lost personally that had 6, 9-month sales cycles and just somewhere along the way something happened, decision maker went away, some POC died, they just died. They just died. So please try to see if you can cut your, simplify your product. And you can upsell. You can upsell. Of course you can upsell. You can upsell. But start with a small lightweight product. I would much rather see you hit $200K with 10-20K customers than 1 million with 2-500K customers. I don't care about the 1 million, 2-500K customers. I would rather see you with 10 customers at 200K because I can see that you have some muscle you've built, you've been able to get to 10 customers using it. With 20K, hopefully there's some retention, I can see that. With 2, what do I know? It might be your brother's friend or your buddy from college who's using it. I have no idea. It could be completely random. I have no data points. 2 is 0 data points to me. 10 is more. I'm OK with low ACV. In fact, I want to see low ACV because then your NRR will also look really good. That's the beautiful thing about low ACV. Your NRR looks really good when you upsell. If you have high ACV, then you can't upsell. Strange. And then I think the most foremost important metric to track as CEO, I think, it's for new customers, what percent of reps are hitting quota, and what's your pipeline coverage. Pipeline coverage, as you know, is, OK, if you want to hit $1 million in new ACV or new ARR this quarter, How much pipeline do you have entering the quarter? You better have $4 million to $5 million. 3x no longer cuts it. You better have $4 to $5 million pipeline entering the quarter. And then you better have at least 70% of reps hitting quota, if not 80%. If it's less than 70%, I would say you don't have product market fit, or you've not trained your sales team well, you've not hired well. And then existing customers, I'm looking at both gross revenue retention and net revenue retention. I think NRR is not enough by itself because NRR can be influenced with one or two customers. You might have massive churn across the base, But then 2 customers are driving up an ARR and, oh, 150%. Turns out GRR is like 50% or something. So I want to see GRR of pretty high because it shows me the product is actually valid and valuable to customers. And then some of them are expanding. So both of them are important. Here are the 4 things I think you should use when you think about the GTM, in particular, a sales team. Again, I understand some of you might not have a sales-led approach. They should have sold at a price point in their earlier jobs. They don't need to be in your domain, but they should have sold. Sold at your price point. They should have hit or exceeded quota in your earlier— one of the biggest things is people don't look at their prior— you've got to understand, did they exceed quota or not? You've got to get their commission sheet. You've got to get their comp sheet and see, did they exceed quota or not? Maybe you can ask— if they don't want to share it with you, they can share it with the recruiter. But they need to show— you've got to know that they were not an underperformer in the prior role. Can they generate their own leads? Can they generate their own leads? A lot of folks at midsize companies come in expecting, oh, A demand gen operation is fully set up. You're going to feed me leads. I'm going to close them. Turns out when you're silly young, you don't have enough leads to feed all mouths. So you need salespeople to generate their own leads at least a little bit. You need them to be able to generate their own leads. And then you can't train them for 6 months and say, I'm going to put up points on the board 6 months from now. They've got to start putting up points on the board within a couple of months, ideally even in month 1. I want to start seeing them close deals. And then your sales leader at this stage should not be a VP. They should be a player coach. At least 20% of them, if not more, should be showing, modeling, closing deals, and going on deals and closing it themselves. So you've got to hire them. This is one of the most challenging things to get right. Forget the VP of sales. I mean, most people get— you're hiring and firing AEs till you get the right fit. It's so challenging. And then scaling the org structure. Right now, I would say we are still in the generalist mode. Remember, in the startup phase, we are in generalist mode. And in scale-up, we're in specialist. We are slowly starting to make the transition of being generalists to starting to hire our first specialists in some areas. Do not hire managers. One of the most interesting things that has happened over the last year is that companies, even the largest companies like Meta, have started saying you're either a manager— manager is a full-time role, which means that you can manage 20 people— or you're an IC. OK, if you're managing 3 people, that's not a full-time manager role. So they're basically cutting— that's called span of control, which is how many people you're directly managing. So if you have roles which are managing 3 or 4 people, they better be also doing like 50% IC work. And so I think that's what you should demand. Either people managing 20 people or they're ICs. Or if they're managing 4 people or 5 people or 6 people, they better be doing IC work in addition, unless their org is going to grow to 15 people or unless they're going to manage 15 people in the next few months. That's— I think increasingly, I don't think managing 6 people is a full-time job is what people are saying. And it's right. I've managed 8, 10 people, probably could have taken easily another 10 people. And so I do think there is some push towards having flatter orgs and having basically people with large spans of control and having more ICs. I should have made it even stronger. I should say flatten your org more. Flatten your org more. Try to avoid fewer middle managers. Few middle managers who are managing 3 people, and then each of their reports managing 5 people, that's 15. Hang on, why do you need 3 people managing 3 people? You should just flatten the org, remove the expensive middle managers, make them ICs, or make each of them 2 ICs each, and then have 15 people reporting to your head of function X. And then the other one is create initiative-focused cross-functional pods. I gave the example of new customer acquisition. I think the new customer acquisition works only if there's a group of people who are dedicated to it from product, design, engineering, analytics, marketing, maybe sales, etc. They all work together and they're all— they all think of themselves as part of the new customer acquisition pod. I think every company can benefit from removing these silos and having people work in pods that include not just product, engineering, design, but other go-to-market functions also, because then they're all united. They work together. In one goal. One of the biggest challenges that CEOs face is they feel that go-to-market and their product functions are working at odds with each other. They have no idea what the other is doing, and the CEO is the one who's doing coordination between them. The way to avoid that is to blow it all up and make sure the pods are created and they all feel they're part of this pod or this group or this team, whatever you call it, XFN, whatever you call it, but you need to create cross-functional pods for the most important initiatives at the company. For the most important issue of the company. Planning, hopefully this is the time when you're starting to do plans, which really means setting goals and then figuring out each team, each pod figures out their way to hit the goal. So if you're very young, I would say weekly, when you start out, hopefully you did weekly goals. You're probably at a point where you're doing monthly. You're probably somewhere between monthly and quarterly. And I would say quarterly maybe is too hard for companies because Things change too fast in a quarter, things change too much in a quarter, so monthly might be the right cadence till you get to 30, 40 people, and then maybe you move to quarterly. At public companies, obviously there's annual, quarterly, half annual, and various things, but I think monthly or quarterly, and then you need to have an annual plan to start with. I'm sure your investors are already telling you, you need to have a forecast, a plan, but you need to be able to edit it. So hopefully you have a good finance and strategy person, can be worth their weight in gold here. So again, as a founder, if that's not your strength, hire a person who can be a finance and strategy person, not just an accounting person, but somebody who can help you manage your capital allocation, manage a bunch of things around creating plans and whether you're hitting plans or not. So make sure you have the right help there. And then you need to have a set of— this is what is your cadence of execution? What is your cadence of execution around which your teams execute, you hold them accountable, et cetera? So there are 3 things I think that— 3 kind of processes you could think of instituting. One is weekly business reviews. I talked about initiatives. Every company, I think, is essentially a collection of initiatives. In general, when you think of a company execution, you'll probably in your mind think of initiatives. And each initiative has a cross-functional team with one person being the DRI, or the directly responsible individual for that team. So what you want to do is you want for some of those initiatives, you want weekly business— actually, no. Weekly business reviews is a is done once at the company level. So the weekly business review, the only goal of the WBR, which was started at Amazon, is to figure out, am I hitting the quarter or not? Am I going to hit the month or the quarter? Am I hitting the quarter? If not, what can I do right now to hit the quarter? And so finance is a very important part of this. What resources can I move to hit the quarter? Many times it's budget, it's people, It's something else. So literally, it's a decision-making meeting on figuring out how to bridge the gap from where we are to hitting the quarter. And so if you run it seriously, then the CEO and every exec who can drive execution shows up at this meeting with a small group of people who figure out what does the company need to do to hit the month or hit the quarter, and what is the gap? What do we need to move? Why are we not hitting it? And then more importantly, brings force to bear on the most impactful thing we can do to hit the quarter. Initiative reviews are the reviews that you'll conduct at the initiative level. And the frequency of them depends on how urgent and important it is. Some 2x2 matrix of urgency is important. Obviously, with some things, you could do a daily initiative review, with some you do weekly, some you'll do fortnightly, and some you'll do monthly. So it depends. And then you have to demand that every initiative sends you a weather report. I call it weather report. That's a DoorDash terminology. It needs to send you a weekly status report. And you should figure out what the right format is, and everyone needs to follow it on a certain day of the week, probably on a Friday or a Monday. They should talk about it, and it always needs to start with goals. What is their goal for the time period, say month or quarter? Where are they in that goal? How far are they? And then what's the gap? What's the gap and what are they doing to fix the gap? And what's working well? What have they done so far? And then most importantly, What help do they need from you, from the execs, to help bridge the gap or to make sure they're working well? So this is a very important thing because by email, it keeps everyone apprised as to what is going on in addition to the initiative we do. Because especially if the distribution— in general, these weather reports can actually, and I think should actually, go out to the whole company even if possible. Because turns out, many times when you send it, a lot of ideas and sparks emerge if something is not doing well. Then someone else at the company might have an idea. Oh, I didn't know it was not doing well. Why don't— have you tried this or have you tried that? And ideas can come across the company. So you want to make sure that this is a way to get transparency across the company as to what things are working and how they're working. And then I think people— I talked about what I look for in hiring, problem solving and agency. The other thing I say is hire for spikiness. What I mean by that is typically you'll have a panel of people who interview somebody. And they'll give scores between, say, 1 and 5. If somebody gets all 3s and all 4s, don't hire that person. Don't hire that person. I would much rather hire somebody who has 2 1s and 2 5s than somebody who has all 3s and all 4s. If they have 2 5s, I know they're excellent at something. And maybe they have 2 1s if it was something else. I would rather lean into their strengths and make sure that— obviously, that depends on what the 5s are for. But if the 5 is something that's a strength we could use, I would rather hire them and really lean into their strength versus trying to cover up their weakness. 3 and 4 means people are good, but no one's really pounding the table. No one says they're going to raise a bar in a certain area. But a 5 means they're excellent and they're bar raisers. If they're 2 5s, that's very rare in theory. And I would hire somebody with 2 5s all day over someone who's 4 4s. And then titles, I always have to put my obligatory pitch around avoiding director and VP title for as long as possible. I'm proud to say that— Indian company, Whatfix. Actually, it's a global company. It's not an Indian company because most of the employees are— they've switched to descriptive titles last year. There are more than 500 people, and they're the largest ever company that rolled back their SVP, EVP, VP, director, senior director titles completely, and they have no titles anymore at the company. Again, it was founder-driven. I was like— I told them when they came to me 2 years ago, they were like, we read your post. We want to implement this thing. I was like, you're too late. You shouldn't try this because you're going to have to— there's massive discontent that's going to happen because there are hundreds of people that they're taking titles away from. It's easier to not have something than to take away something, as you know, loss aversion and all that. But they were like, no, we're going to do it. And it took them a year, but they did it. And they have zero titles. Especially India is a very, very title-centric society. And the fact that they already have titles pulling away, absolutely incredible. Absolutely incredible. So describe that as long as possible. I'm telling you, I know it seems, oh, this person is going to join. They just want the director title. Once you give the director title to this person, guess what? Every other person in your company is like, okay, got it. That's fair game now. They're going to all come and ask for director. The first VP title you give, everyone else in the company is going to ask for VP title. I'm telling you, it just opens a Pandora's box that you don't want to open. Now obviously, maybe once you're at the scale-up stage, you give it, but avoid it till you are 200 people or something, or hundreds of people if possible. And then performance, you need to have— Your people need to have some idea of how they're doing. They need to have some idea. So yes, you don't need to do crazy performance reviews, but at least if a manager is managing someone, part of their management responsibility is to give them feedback, is to have conversations with them on a regular basis and to let them know how they're doing. A lot of people just suddenly fire somebody without ever giving them notice. You're like, I'm packing my bags without— I didn't even know I was doing poorly. And then you need to have, especially for engineering and sales, You need to start having ladders. Those are the two functions which have the most number of people. So people need to know, am I growing in my— how am I getting promoted? So you need to have some internal levels where you get them promoted. Because again, if you have 20 or 30 people in a certain function, you need to start thinking about ladders, which is the internal promotion thing. And then one-on-ones, hopefully people are doing small group meetings. Your job, once you get to 40, 50 people, it's going to be hard for you to meet everybody one-on-one. You should try to at least once a quarter go into your direct reports' meetings and sit in on them and see and invite a conversation and questions and just see how they are being run. I think it'll be tremendously helpful. Hopefully you're all doing all hands on a regular basis, fortnightly, if not weekly. And then I recommend that every CEO, if possible, sends an email out to the company once a week or once every 2 weeks. I think it's very, very important. Number one question in employees, Minds is, what is my CEO thinking? What's on their mind? Because they all want to help you, but if you don't tell them what's on your mind, they don't know what's on your mind. So if you just tell them, again, just search for weekly CEO email with my name and you'll see some examples. A lot of companies again have started this over the last few years and have seen tremendous engagement. It's a great employee engagement tool. And that's basically it. That's basically it.