Lecture 20 - Later-stage Advice (Sam Altman)
Yeah, all right, all right. Uh, good afternoon and welcome to the last class of how to start a startup. So this is a little bit different than every other class. Every other class has been things that you should be thinking about in general at the beginning of a startup.
Um, and today we're going to talk about things that you don't have to think about for a while. In fact, you shouldn't. But since I'm not going to get to talk to most of you, uh, again before you get to sort of post product market fit stage, I wanted to just give you the list of things that you need to think about as your startup scales and the list of the things that usually, uh, founders fail to make the transition on.
So these are the topics we're going to talk about, but again, um, all of these things are things that are not writing code or talking to users, which means with a few exceptions that I'll try to note, you can ignore them until after you have product market fit. Most of these things for most companies become important between months 12 and 24, but it's really more about stage than anything else.
These are things that usually hit around 25 people, uh, and definitely post product market fit. So just write these down somewhere and look back at them when you get there.
So the first area we're going to talk about, uh, is management. At the beginning of a company, um, there is no management, and this actually works really well before 20 or 25 employees. Most companies are structured with everyone reporting to the founder. It's totally flat, and that's really good, and that's what you want.
Um, and at that stage, that is the optimal way, um, for product—that's the optimal structure for productivity. But the thing that tricks people is that when lack of structure fails, it fails all at once. And so what works totally fine at 20 employees is, from zero to 20 employees, is disastrous at 30.
And so you want to be aware that this transition will happen, and you don't actually need to make the structure complicated. In fact, you shouldn't. Um, all you need is for every employee to know who their manager is, and there should be exactly one, and every manager should know who their direct reports are. You want to ideally cluster people in teams that make sense, of course, but the most important thing is that there's just a clear reporting structure, uh, and that everyone knows what it is.
And if you want to make changes to it, uh, people understand how to make changes or to hire someone. Clarity and simplicity are the most important things here. Um, but failing to do it is really bad. So because it works in the early days to have no structure at all, and because it sort of feels cool to have no structure, many companies are like, "We're going to try this crazy new management theory and have no structure."
Um, what you want to do is innovate on your product and your business model. Um, management structure is not where I would recommend trying to innovate. So, uh, don't make the mistake of having nothing, but don't make the other mistake of having something super complicated. A lot of people fall into this trap where they think it's like, you know, people feel cool if they're someone's manager, and if they're just an employee, they don't feel cool.
So people come up with these convoluted circular matrix management structures where you report to this person for this thing and this person for that thing, and this person for that thing, but you know, actually this person reports to you for this thing. Um, that's a mistake too. So don't try to innovate here.
This is the first instance of an important shift, uh, in companies or in the founder's job. Before product market fit, your only job that matters is to build a great product, or your number one job is to build a great product.
Um, as the company grows, and at about this, you know, 25 or so employee size, um, your main job shifts from building a great product to building a great company, and it stays there for the rest of your time. And this is probably the biggest shift in being a founder that ever happens.
There are four failure cases we see all the time as founders become managers, um, so I want to talk about the four most common ones. The first one is being too hesitant to hire senior people. In the early days of a startup, hiring senior people is usually a mistake. You just want people that get stuff done, um, and the willingness to work hard and aptitude matters more than experience.
As the company starts to scale, and about this time when you have to put in place a basic management structure, it is actually valuable to have senior people on the team. You know, executives that have built companies, per—almost all founders after the first time they hire a really great executive and that executive takes over big pieces of the business and just makes them happen, the founder says, “Wow, I wish I had done that earlier.”
Um, but everybody makes this mistake and waits too long to do this. So don't be afraid to hire senior executives.
Um, the second mistake is hero mode. So, um, I will use the example of, say, someone that runs the customer service team. Someone runs the customer service team, um, they want to lead by example; this starts from a good place. It's—it’s the extreme of leading by example. It's saying, "You know what? I want my team to work really hard; rather than tell them to work hard, I’m going to set an example and I’m going to work 18 hours a day, um, and I’m going to show people how to get a lot of tickets done."
But then the company starts growing; also, they have the normal discomfort of assigning a lot of work to other people. So the company starts growing and the ticket volume keeps going up, and now they have to do like 19 hours a day and 20 hours a day, and it’s just obviously not working. But they won’t stop and hire people because they’re like, "If I stop, even for one day, we’re going to get behind on tickets.”
The only way to get out of hero mode in this case is to say, "You know what? We’re going to get behind on tickets for 2 or 3 weeks 'cause I'm going to go off and I'm going to hire three more support team