Lenny's Podcast: Product | Career | Growth
00:27:22 · S1, Andrew Ambrosino
[00:27:22] S1: What does your team look like on the Codex team? How many engineers, designers, PMs? What's kind of the makeup of the team right now? [00:27:29] S0: Every time people ask me how many people are on the Codex team, do you remember my answer to this? I'm like, "It's somewhere between 10 and a few thousand." I mean, it's like a fake answer, but it's real in that we do see this as the culmination of what everybody works on here. Everything that goes into model research, everything that goes into how models are good at CUA and browser use. Everything about how model personality. All of the product work around front end infrastructure, all of the user, all of it is this product. At the same time, we are not accepting PRs daily from thousands and thousands of people on whatever they want. So we got a team, double digits of engineers, probably half that on the design side. A few product people, although product here is kind of more of a zone defense play. And I think one thing that is very common among everybody on the Codex side or on the desktop side is agency and taste, right? A lot of former founders or people who were at larger companies doing founder shaped things. A lot of people with immense taste. At OpenAI, we let teams get very large. So we haven't said, "Hey, there's no management," but the teams are quite large. It's mostly ICs and I think that's good.
00:27:29 · Andrew Ambrosino, S1
[00:27:29] S0: Every time people ask me how many people are on the Codex team, do you remember my answer to this? I'm like, "It's somewhere between 10 and a few thousand." I mean, it's like a fake answer, but it's real in that we do see this as the culmination of what everybody works on here. Everything that goes into model research, everything that goes into how models are good at CUA and browser use. Everything about how model personality. All of the product work around front end infrastructure, all of the user, all of it is this product. At the same time, we are not accepting PRs daily from thousands and thousands of people on whatever they want. So we got a team, double digits of engineers, probably half that on the design side. A few product people, although product here is kind of more of a zone defense play. And I think one thing that is very common among everybody on the Codex side or on the desktop side is agency and taste, right? A lot of former founders or people who were at larger companies doing founder shaped things. A lot of people with immense taste. At OpenAI, we let teams get very large. So we haven't said, "Hey, there's no management," but the teams are quite large. It's mostly ICs and I think that's good. [00:28:47] S1: You use this term zone defense for product work and that's really interesting. It kind of maps to the design kind of shift also, just like you're there to manage and coordinate. Talk a little bit more about what that looks like. What does zone defense look like for a product person?
00:28:47 · S1, Andrew Ambrosino
[00:28:47] S1: You use this term zone defense for product work and that's really interesting. It kind of maps to the design kind of shift also, just like you're there to manage and coordinate. Talk a little bit more about what that looks like. What does zone defense look like for a product person? [00:29:00] S0: Yeah. And I have had a lot of conversations with Alexander about this analogy, which is that if two product people are working too closely, that's often not a good signal. And that you kind of want, as a product org, you sort of want to do this force directed activity. Where you're like, "Where are the gaps?" Especially in this new world where curation and steering and alignment is a lot of things. Where you're like, "There's a ton of chaos happening on people throwing ideas all over the place." The whole top down, year long planning thing, not going to work. And so now it's like we need the taste makers to guide things from inception to what the product should be. And that means you basically want company coverage. And so you spread out and you say, "All right, who's best at what? Let's create some space between us so that we got full coverage." And that's kind of how it goes. And then you fill in the gaps and you're like, "Look, we want to hire engineers who are product-minded." We don't want it to be that we've got a bunch of people writing a bunch of code that needs full team reviewing it for product coherence. We want everyone to have these skills, but I think what people go deep on has to change.
00:29:00 · Andrew Ambrosino, S1
[00:29:00] S0: Yeah. And I have had a lot of conversations with Alexander about this analogy, which is that if two product people are working too closely, that's often not a good signal. And that you kind of want, as a product org, you sort of want to do this force directed activity. Where you're like, "Where are the gaps?" Especially in this new world where curation and steering and alignment is a lot of things. Where you're like, "There's a ton of chaos happening on people throwing ideas all over the place." The whole top down, year long planning thing, not going to work. And so now it's like we need the taste makers to guide things from inception to what the product should be. And that means you basically want company coverage. And so you spread out and you say, "All right, who's best at what? Let's create some space between us so that we got full coverage." And that's kind of how it goes. And then you fill in the gaps and you're like, "Look, we want to hire engineers who are product-minded." We don't want it to be that we've got a bunch of people writing a bunch of code that needs full team reviewing it for product coherence. We want everyone to have these skills, but I think what people go deep on has to change. [00:30:14] S1: This is definitely a thread I've been noticing over and over with talking to folks like you. Is the most valuable person right now, one of the most valuable, is someone that could take an idea from idea to done with the taste to know this is great. [00:30:28] S0: Yeah.
00:30:28 · Andrew Ambrosino, S1
[00:30:28] S0: Yeah. [00:30:28] S1: Just shepherding throughout, this obsession with making it awesome. This kind of high agency, high taste person exactly as you described. Is that kind of the way you think about here's who we're hiring, here's who's going to do really well in this new world? [00:30:40] S0: Yeah, I think that's the core piece right now. And it also speaks to how I sort of see IC versus management, which is that it's not that management is going away. It's not that everyone's an IC, but everyone's kind of both now. If you are an IC, you're not typing code out character by character. You are managing something. You're managing agents. You are managing work that is happening that comes together to do a certain thing. If you're a manager of teams, you're doing the same thing just at a different granularity. I generally look for obviously command over the discipline, but then the taste to say, "Hey, you're going to have unlimited tokens and we can't just be doing slop." You need to be able to determine what signal, what's noise in a world of just infinite content. [00:31:38] S1: Mention planning. At the pace things are moving, it's become very hard to plan roadmaps. I imagine, especially in your world. [00:31:47] S0: People are very frustrated with me all the time on this. Yes. [00:31:50] S1: Because things are just constantly shifting, things are changing. How do you plan on your team? How far ahead are you thinking and what does a plan look like? Is it a spreadsheet? Is it MD file? What's the output of a plan?
00:32:00 · Andrew Ambrosino
[00:32:00] S0: Yeah, I don't think we do anything revolutionary on that. We're not clever about planning. I think the basic gist is, the shorter term something is, the more detail it needs. And then it's not that we don't plan for nine months out. It's that that just has to stay very hazy. Because any amount of precision that you add to a nine-month plan right now is false precision and you're just going to waste time. You can say stuff, but nothing that we planned. I think research is different. So I'm not speaking for research here, but on the applied side when we do product, anything that you could have planned in November may have been true for December, but isn't what happened. So it's hard. It is really hard to do planning. We generally need to know what do we think models are able to do on what timeline? And my last company, I kind of saw this shift where we were starting to use the models to drive features. And the product process fell down. It basically had to be like, "Let's list out all of the things that we think we are interested in doing for the next year or two." Let's prototype all of them, decide which things are ready now, and then just let the others sit and bake. And then every time there's like a new leap in models, let's try that thing again with it swapped out. Because the whole premise of whether features were good or not were based on whether they were smart enough, not the shape of them. So this is a great story about the Codex app. I am very confident that the Codex app that we released in February, if that had been ready in November, it would've absolutely failed in the market. And the only difference was the models between November and February. And I think there's a lot to that, that this product with the exact same shape, I think its outcomes were totally different depending on just a few months of timing. Yeah, I think we have a lot of that. I think sometimes the challenge is you have to be very clear again about what stage of the design process that's in. People still have this muscle memory of like, "Oh, I wrote the code for this thing, therefore we should put it out there." It's like, "No, no, no." That means you have an artifact now that we can test against for into future models. This happens with the in-app browser in the app that we have. We had a kind of a working version.