Ex-Meta VP Reveals His Top Lessons from 25 Years Leading Product Design | Jon Lax (Meta)

Teams would come to me with, we have to make sure there's delight in this product. And I'd be like, yo, you haven't even shipped anything yet. Like, you haven't even figured out, like, what your product is and you're busy trying to figure out the physics of the, like, easing curve of this, like, button press. And I'm like, that's no. Like, we don't even know what this product is yet. Like, and I've always really loved the idea that you first, first start with making something that's useful and necessary. Like, should this exist in the world, is it useful? Right? And if you can get that nailed down, okay, now make it beautiful. Like, now, like, take the time to really make it beautiful. Often designers will jump to the last part before doing the first, like, this thing. People can't even use this yet, or no one's using this yet. And it's not that the easing curve on the button is going to make it more useful. I can tell you with high certainty that a lot of the things that designers care about, the larger populations don't care as much about. That doesn't mean you should go make badly crafted products, but you have to figure out where you're spending your time and energy and when you're spending it there. I spent a lot of time in my career trying to get that last 10% and learning that often didn't add that much to people's satisfaction with the product. And I've actually dialed it back a lot and actually found I made better products faster. Because the thing is, it takes time to do all those things, and that's time that your product's not in market usually.

All right, welcome, everyone. My guest today is John Lacks, former VP of Design at Meta. John spent over eight years leading design teams on projects from Meta Reality Labs to events to Search. I'm sure a lot more. And before Meta, John ran his own design firm. For 12 years, I've been reading John's blog and he has many great hot takes that I excited to chat with him about. So, yeah. So welcome, John.

Hey, Peter. Thanks for having me.

All right, so let's start with one of your hot takes. So you wrote a blog post about how Vision Decks and North Stars have little value compared to solving known problems. Can you share more about that?

Sure. I think that if you are a designer, you've worked with designers, you've probably at some point in your career, or maybe multiple times in your career, seen these, like, North Stars Vision Decks, they go by a bunch of different names, but effectively what they are. An attempt to try to think about a product in the future and design it. You know, in the automotive industry, we have concept cars are kind of that idea, right, where they design, hey, one day we might build a car that does this. And in product design and in design in general, there are a lot of times where designers are asked to go and like, oh, go, build us a. Go design a North Star. And designers run off and they spend some time in a room and they did, you know, they design, oh, here's what our product will look like at some point in the future. And they are, I have to say, I'm going to caveat. They're super fun to work on. Like, in my career, I've done, I couldn't even tell you how many of these. And it is fun to just design without constraints, to imagine a future, to imagine, you know, what your product could be. And you just get to design these things. The problem is that they're not that effective. Right. Typically, once you design it, people look at that and go, that's really cool. And then they just go back to their job and there's, you know, like, they don't really go anywhere. And so I became increasingly disillusioned with these as an effective tool in terms of, you know, showing your engineers or your PMs, or even leadership, hey, here's what we should build. And there's a few reasons for why I don't think they're that effective. The first one is when you're going to go do a North Star or a vision. I think the question you have to answer is, okay, this thing that you're going to design, like, when might we be able to build this? Is this something that's like 10 years off or is it like a 12 months off? Right? Like, what timescale is it existing on? And often designers will go design these things that are like three to five years in the future. Like, sometimes technologies need to be invented for their design to even exist in the world. And that's really tough for those to become effective because it's like, okay, cool, you design this thing. Maybe when we invent all these technologies, or maybe when our product is more mature, we could build this, but we can't build this right now. So that's why engineers and PMs just kind of go back to doing whatever they're doing. The other thing, too, is the culture of the company that's showing it. In some cultures, these North Stars or these visions are more effective because there's something culturally that allows those artifacts to be internalized and used. But in more pragmatic cultures, especially I think in technology cultures, they sort of see these things like the organization, the company looks at these videos or these designs and they think, ah, yeah, this isn't really what we do.

Yeah.

And so they just ignore them. And so, you know, that's another reason why, you know, people just don't, they don't really work. And so where I started to, so what was happening with the design teams I was working with is that they would show up with these north stars or these visions and they just, they spend a lot of time, a lot of energy, a lot of emotional energy also, like not just time and energy, like, like emotional energy into these things and then like nothing would happen. And I just said, hey, let's just stop doing these. Let's actually like focus on things that are more like what do we have to solve right now? You know, what do we have to work through right now? What are the problems we can solve nearer term. And that actually was much more effective. Maybe not as fun, but more effective. And so I just didn't like them because I just didn't see them working.

So like, what is the right time scale to think about solving problems? Because if you. Or too tactical, you know, every quarter that's like too tactical, otherwise it's like too visionary. What's the right time scale here?

Yeah, so I, this is just the way I think about it and you can kind of break it up however you want. So I tend to think of different timescales. So the kind of nearest timescale is sort of zero to two weeks, right? Or maybe zero to four weeks. And in your, in whatever company you work in, you probably have a rhythm like whether it's a release schedule. So a lot of companies, at least in the software side, do like two week with these schedules. Maybe it's monthly, something like that. That's kind of the smallest timescale unit where you're just trying to get to the next branch cut or the next, you know, the next push. Then you kind of move out to the, you know, one. And that's sort of like work that's sort of four weeks, maybe as long as a 90 days. You know, you can kind of divide it however you want. And that's work that just takes a little bit more energy. It's not like for the next branch cut, it's not just a bug fix. It's a bit more substantial that you could do. And then you start to Move out maybe to a six month, you know, timescale, and you keep going out and you can keep going six months to 12 months, and then a year to three years, three years to five years. And so if you think about each one of those timescales and work this team down it, if a team is working just in the zero to two week timescale, they're just running to keep up, right? They're just trying to do like that. And the problem when a designer, especially a designer, is just working that close to the backlog is you're kind of working like with your head down. Like it's like walking while looking at your feet, right? Like you can only see a little bit in front of you. I think that as you start to work on longer timescales, right. So just going back to what we talked about in terms of these north stars, those tend to be things like, oh, in three years our product will be able to do that. Well, that's looking really far into the horizon. And that can be difficult as well because as I said, you start designing, you know, really far out and that can get a little untethered from the timescale. So what I like personally is I think for designers, most of your time is probably spent somewhere between zero to four weeks, maybe six weeks. So you're doing work that's probably going to ship inside of that time frame. So it's not just like, oh, what do I have to do today? Push it out. You can stretch out a little bit. I really like it when design teams kind of are operating a bit ahead of their engineering teams. So if your engineering team is just trying to get to the next branch cut, I want the designers to be maybe four to six weeks out ahead of them. Right. That I think is like a real sweet spot for teams because they're able to take some time, work through some concepts, but they're not so far out that they're doing work that's completely untethered from what the engineers are doing or the PMs are doing. I will say one caveat. If you're managing teams and you look at the work they're doing and all of the work, like you look at a design, you say, hey, what are you working on? And all of the work is actually in the zero to two week or even maybe behind the backlog, meaning the engineers have coded a thing and are waiting for, for like a front end, that's a bad place to be, right? Because your designers are just running to keep up with the work and if you, you know, if you're on a design, if you're a designer on a team where you're the only designer and there's like 20 engineers, they're going to, like, outwork you, right? You're just going to be, you know, running to catch up. And I think that, you know, a lot of us have been there, seen teams like, and if you're a manager, you're like, oh, geez, this team needs more designers. You need more capacity to get out ahead of the engineers a little bit. I do also, like, while the majority of the time that design team is working is kind of four to six weeks out ahead of, you know, the engineers, I do think maybe once or twice a year the design team should stop and they should do work that's maybe, hey, where do we want to be in a year? Right? Like. Like take a week or two and do not so much a North Star vision, but, you know, just lift your head up and look out a little further on the horizon and then go, okay, this is cool. What do we need to do now in the next four weeks to start to move towards that point on the horizon that I think is really healthy. And I've seen that work really well.

Yeah. Because if you look at a year from now, some part of that will probably still ship to customers. But if you look at like three or five years from now, it's purely like, it feels pure, like an exercise to convince to, like, impress the CEO or something, like vp. Yeah.

And I do want to, you know, I do want to say that, like, sometimes there is about a. In some cultures, in some instances, in some situations, a little bit of an executive theater is required. Right. Like, you do need to kind of get people excited about a thing. But I think recognizing that's what it is. Just like to use my example of the automotive industry, the concept cars. Right. The concept cars are there not because the car company actually thinks they're going to build that car. They're there to sort of excite the press, to create a moment to, you know, inspire a little bit, to show kind of what they're capable of. But the idea that that car is going to show up, you know, in the dealership 12 months later doesn't really happen.

Got it, Got it. So, along similar lines, I really like your phrase the three miracle problem. Like, I feel like a lot of companies use shiny thing, like shiny trend. They're like, they want to FOMO into it and never works out. So, like, can you talk about, what do you mean by the three miracle problem.

Yeah, So I was. This came up where I, I was. Teams were coming in, design teams were coming in and they were showing me they're like, oh, we're working on this problem. And the problem was often something like, okay, when our product has, hey, we're trying to design. Okay, let me give you a really good example. AR glasses, right? AR glasses is, you know, everyone knows that, that Meta Apple people are working on AR glasses. And it's pretty easy to imagine that in some future, if you're wearing a pair of glasses that can project UI or things into it, that there is a risk that will become very cluttered. Right. And so there's a lot of videos out there of like, oh, all these ads being pushed into my field of view and it's cluttering up. And so you'd have design teams coming in and starting to solve that problem and be like, oh, how would we do this? Or how would we do that? Well, hold on a second. We don't actually have a, like, we don't have a pair of glasses that work. We don't have any users for it. Right. We don't have the content at that density that would create that problem. So you actually need three miracles to happen before this problem exists. You need to create the glasses, you need to have content that goes into them, and then you need to have too much content that is crowding your field of view. Hey, let's go solve the first miracle before we worry about the third one. Right. And so the team was just jumping out ahead of itself, and I'm like, that's not a good use of time or energy. Right? Where. Where they're too far out on the timescale. They're trying to solve problems and there's a whole bunch of preceding problems that have to be solved before the problem they're solving can even exist in the world. Right. And so when I look at things, I'm like, hey, is this actually like a problem today or is this some potential problem that requires preceding things to actually exist before it's an issue? And if you see that, you got to stop that work. Because it's like, hey, this just isn't valuable work. Because the, the other thing too is the idea that the team has accurately predicted. Right. Each step in that, that they're going to get the right solution to that problem today is very low. Is very low.

Yeah, exactly. Like the first two miracles might not even come true.

Right, right. Or like, you'll see it in startups, they're like, oh, we have to, we need a design system and say, hey, you don't have a product yet, you don't have users, you don't have enough. Designers, like, design systems are meant to help you scale. Like that's a, like solve that problem after you actually like when you have it. Right. And. But they try to get out ahead of it too soon.

Yeah, I think a lot of it is kind of like this intellectual exercise where like, you know, if I'm a good designer, I need a design system, I need to have a three year vision. Like, it's a lot of like, it's like intellectual stuff as opposed to real problems.

Well, and you know, as an industry, and I'm speaking specifically with the design industry, our design industry sort of fetishizes all of that. And so as a designer, you get a lot of credit from other designers if you show up and say, hey, look at this design system I created, or look at this, you know, brand system, or look at this, like little, you know, micro interaction detail, isn't that cool? And other designers will go, man, that's so awesome. Because we all love that stuff, right? But it's often, it's not actually all that valuable to the product or to users in that moment. And I think that designers get, can get very distracted by those things and spend energy on them when it's not the best use of their time.

So then let's kind of skip to the probably your most controversial point, which is for designers at least you, you wrote this post called Delight Comes Last and it might sound crazy to a lot of designers. Maybe. Tell me more about that.

Yeah, so I mean, this is all kind of related, right? Like when do you solve, like what problems do you solve? When, right? Like everything is kind of a, I've also been this thing like everything's like a prioritization problem, right? Like, it's not that you don't want it. Like just quickly going back to the augmented, the AR glasses thing. Like, it's not that you shouldn't solve that problem, but when do you solve that problem? Right? And so delight is another one. I would sit in, you know, teams would come to me with, you know, designs for like I said small, like, oh, look, we have to make sure there's delight in this product. We have to make sure there's delight in this product. And I'd be like, yo, you haven't even shipped anything yet. Like, you haven't even figured out like what your product is and you're busy trying to figure out the physics of the like, easing curve of this, like, button press. And I'm like, that's no, like, we don't even know what this product is yet. Like, and so I've always really loved the idea that you first start with making something that's useful and necessary. Like, should this exist in the world, is it useful? Right? And if you can get that nailed down, okay, now make it beautiful. Like, now, like, take the time to really make it beautiful. But often designers will jump to the last part before doing the first, you know, you know, conditions like, like, hey, this thing, people can't even use this yet, or no one's using this yet. Why? And it's not that the easing curve on the button is going to make it more useful. So don't do that right now. And so once again, I think I would tell designers, like, this isn't the time to worry about this, right? Or the other thing designers do is I think that we have a tendency, because we really value those things to over invest in them and assume that everyone gets the same value out of those things. And I think that there is, you know, some. I can tell you with high certainty that a lot of the things that designers care about, you know, larger populations don't care as much about. That doesn't mean that they're not. That you shouldn't do some of them and that you, like, that doesn't mean you should go make badly crafted products. Like, that's not what I'm saying at all. But you have to figure out where you're spending your time and energy and when you're spending it there. And I do find that designers will do it too early, they'll do it too much. I spent a long, a lot of time in my career trying to get that last 10% and learning that often it, it didn't really matter in the, in the sense that it didn't matter that the product, it didn't add that much to people's satisfaction with the product. It didn't add that much to the usage. It didn't add that much. And I've actually dialed it back a lot and actually found I made better products faster. Because the thing is, it takes time to do all those things and that's time that your product's not in market usually. And that's not good.

Yeah, because if you're in the market, then you're learning at least, right? You are. But what about, like, I mean, there's this trade off, right? There's trade off between, I guess, quality, speed to market and Scope, Sure. And you have this definition of like MEP or you know, minimum level products. Like, like, I think you have a good definition of this. Like what, what is the right scope to delivering to the market?

So, yeah, first of all, if there was like a precise answer to that, life would be a lot easier. Right? Like, like the, the, the fact is that there is like, there is an art and a debate here about what is the right level. Right. So if you were to talk to some people, I'll call them PMs. But I don't mean to paint all PMs with the same brush. But you know, there are people who believe that get it out fast, iterate as quickly as possible. You don't have to be right, you just have to learn as quickly as possible and like, iterate the hell out of it and get it to be good enough. There's other people who believe, no, you should really craft it and only release it when it's at some level of quality. But at the end of the day, both of those are very subjective judgment calls, quite frankly. And I think that in either direction, it's bad, right? If you wait too long, it's bad. And if you push it out too early, it's bad. And finding the sort of Goldilocks moment is really, really tough. MVPs in our industry became a, I would say, on the side of pushing stuff out too quickly, MVPs became this like, excuse to do to put crappy things into market. And what I mean by that is, is you would look at something and say, oh, I don't know, this doesn't seem really good. And you'd go and challenge the team that they, oh, no, it's just an mvp. Don't worry, it's just an mvp.

Yeah, that's what PM say.

Yeah, yeah, yeah, like just mvp, right? And I got in the habit of saying, okay, what do you mean? Like, what do you mean by mvp? And they would say, oh, that's a minimum viable product. I'm like, well, I know what it stands for. Like, like, that's not what I'm asking. I'm asking, like, how do you define an mvp? And they would kind of give me a blank stare usually because they mean, well, it's a minimum viable product. We just need to, we just need to like, learn. Like there'd be some. And it was really just used as an excuse because a lot of PMs get rewarded for shipping. It looks like it's that classic, like, is this progress or motion? It was like. And it was mainly motion. I was like, look, we shipped the thing and of course designers were getting torn up about it because often what went out was not crafted at all. It was just kind of what could be built in that two week cycle or that four week cycle. And so what I said is, I said, look, like when you say mvp, like how do you define it? Mostly have a definition. I said, okay, well let me give you a definition. And my definition of MVP is a product that can be shipped to a statistically significant group of people that tests a single hypothesis, right? And either proves or disproves a single hypothesis. And it tells you what to build next. And inside of that definition. So if you take the. We kind of break it down really quickly. The first part is it has to be shipped to a statistically significant group of people. Meaning you have to put it out into the world and people need to actually use it, right? And you can't just like send it to 20 beta testers and like, oh, okay, like they loved it, you know, call it a day. Like that's not a typically S group of people. It has to have a, it has to have a hypothesis. It has to have a point of view. Hey, we believe this. And in using it, it's going to either prove or disprove itself. We have this thesis, this hypothesis, people want X or people have this need and when we give it to them, we're either going to see do they or don't they, right? And so it has to have that. This was another problem that we saw with MVPs. People ship MVPs. And I'd say, well, how will you know if it worked or not? And they had no idea. They were just trying to get into, like they thought somehow, miraculously they're like, like we. I saw products go out within without instrumentation, so there was actually no data. And I'm like, well, you rushed to get this out, you forced, you know, the designers to ship this thing and you don't even know if it's good or not, right? And so you need some sort of data. You need to ahead of time agree on whether, what usage will we see in the product that will tell us whether our hypothesis was correct or incorrect, right? And so that definition at least hopefully gets a team to agree upon what they're building, why they're building it, how they will know if they're building it. And the nice thing is that if you do this correctly and you put it in market, what you may learn is no one wants this, but you want to Learn that as quickly as possible, right? And the one thing this is Mark Rapkin, who's a VP of, he's. It comes from the engineering side and he always said about MVPs, which I repeat, I love this quote is he's like, hey, the one thing I know about MVPs is a shitty product performs shitty, right? And so, you know, I think that's really important. It's like, look, you can't release a shitty product and expect to learn anything from it, right? And I think that's really important. So I really push teams to first of all have a different, if you want to use the term mvp, totally cool, no problem. Does everyone agree on what an MVP is? Right? And often they don't. And often I think, well, we can talk also about minimum lovable products. Designers concept of an MVP is very different than maybe an engineer's or PMs or a marketing persons or you know, maybe even leaders. And I think that it's really important that when you go build anything, everyone has to kind of have a shared understanding and agreement on what we're building. And that often is missing. I think that what designers did was in order to counteract the kind of abuse of MVPs, like the they said, okay, well, going to create a whole other thing called minimum lovable product, right? And if you go online, you can see the diagrams of what that means and that I viewed as really an attempt to counteract the kind of, you know, bad behavior on MVPs. The reason I never loved minimum lovable product is because I actually think it's almost too high a bar for some of these things. Like a lot of products we use quite a lot, we don't really have to love them, right? It's. That's not a necessary condition for a product, you know, to exist in the world. And so I always found the lovable part just a little too high a bar to put on especially early stage products. And to my other point about delight comes last. I think some of those things come later in the process, right. And I think that if you burden something with that too early, it can bog a team down. You get in debates about how lovable is it, you know, and that's a hard question to answer.

Yeah, no, I think you're right. I think a lot of its designers reacting to like these other incentives that PMs have, like, you know, to try to get promoted or like, you know, try some number or like, you know, try and you know, you worked at Meta for so many years, you know, it's kind of switching gears a little bit, reflecting on your time there. You know, what were some traits that the best designers and PMs had, like, who kind of grew their career, the fast, fastest had. Is it just. I'm sure it's not just trying to like, hit some core metric each time, right? There must be some trace that you have observed.

So the number one thing I saw in high, in, in the highest performing teams is that they rode together. They were all rowing in, like together. If you've ever seen. That's the Olympics right now. So, like, if you watch the rowing team, right, like, the only way a rowing team can get there is if their strokes are exactly synchronized and together. And the teams that underperformed or had chaos, one person would be like, you know, rowing backwards. The other person would be like, each the engineer, PM design were all like. Because they all thought they were doing different things. They were not. They did not have a shared objective. They did not have a shared understanding. I often, I have a, on my site, I have a, an article, blog post or whatever you want to call it called the definition of done Right. Like, how do we know if we're done here? Like, do we have a shared, like, finish line? And almost without exception, the teams that did well, they. If I went and asked them, I'm like, what are you trying to do here? I'd get that answer. And then I went to the next person, said, what are you trying to hear? I would hear the same thing or pretty close to the same thing.

Got it.

On the teams that weren't functioning, I'd ask that question of eight people and I get 10 different answers, right? That's when you knew, like, okay, whoa, timeout. We need to get everyone together here. So I think the first thing for teams is, are they rowing together? Right? Are they rowing in lockstep? And I think that where the designers and PMs and engineering that triad, when those three people all had agreement on what they're each accomplished and they all went off into their own disciplines and then started to work towards that in unison. That was really great. And so PMs that took the time to talk to their design partners and say, okay, what do you think we're doing here? Or. And the designer saying to the pm, okay, what are you looking for? And okay, well, what about if we did this in an engineering contributing? And then they all kind of go, okay, great, you know, break. That was really good. I think when I first got to meta the. Actually the Aaron Carambula who's now at ebay. He was working on Profile and him, I could see him and his PM and Eng partner, they were at desks that were all, you know, basically side by side or kind of back to back. And they would constantly just turn around and be like, hey, can you look at this? What is this what you were thinking? And there was a, a continual communication and alignment going on. And it was sort of always, constantly course correcting. It wasn't perfect, but they seem to move forward in unison really well. And then of course, the teams that were dysfunctional and I think this really happened as we started to have more people in different places because now it becomes harder for everyone to collaborate, have shared goals. It became much harder to do it. And that's where I started to see things drifting or getting out of sync. And that's where problems really started to emerge.

When you say definition of done, is it usually landing on, like solving a customer problem together or like agreeing on what the metric is or I guess it depends, right? What the team.

How will we know if we're done right? So I think that let's use the MVP as an example. Let's for example, just say, okay, hey, we're building an MVP and you asked the PM on the team, okay, well, how will you know if we're done to ship this thing? Do they. Okay, well, I'd want to see A, B and C. And you ask the engineer, would they say the same thing or roughly the same thing? And with the designer, And I think that what often happens with definitions of done, designers want their definition of done. And it's different than maybe what the PM or engineering definition of done is. Right. So the designer wants the lovable product. They want the delay, they want all that. It'll be done when we have this well crafted, you know, really beautiful thing. The PM may be like, oh, no, we'll be done when we meet this branch cut. The engineer may want some sort of performance. You know, I'm not shipping this until we meet this objective bar performance. So each t. In that scenario, each person has a different definition of done. That becomes really hard. You have to figure out how those all align in order to do and who gets to determine what the definition of done is. Right. When is it done for and that's not completely done. When is it done enough for this milestone or this ship date or this launch date? And I think that a lot of teams just don't take the time to actually align on their definition of done. And it can be anything. Your definition of done can be like, as you said, it could be completely objective measures. Right? Like, oh, we're done when we ship it to a test group. Or the definition of done could be subjective. So for example, you know, I think at companies, I think Apple's kind of the classic one, the definition of done is when some VP says it's done.

Yeah, right, like you know, just big.

Event or something or yeah, or maybe the definition of done is it's done. What's done is what we can ship for, you know, WWDC or for a press event or something like that. And so I often, once again, when I'm debugging teams that aren't working, 8 times out of 10 it's because they don't have an aligned definition of done. They just think they're building something different. Right. Or, you know, they ship something and the designer is really unhappy because it's like, well, it wasn't done, it wasn't ready. It's like, well, okay, that's your definition. Was that this, like did they did not to put it on Zuck, did Zach have that definition or did the, the PM partner have the definition? And often that's not what's going on there.

Got it, got it. How about your framework for like, dude, there's all these crazy career ladders and boxes to check in these big companies and like, I think you simplify it down into, I think, autonomy and ambiguity. But I also want to ask you. There's also like, I feel like there's a lot of pressure for high performing ICs to like, hey, I, I, I need to manage like 10 data designers or I need to. So how do you, what do you think about all this?

Like how do you, yeah, so I think that, you know, at Meta, at the large companies, there's a very sort of sophisticated, complex performance management process, right? The, the PSC process is a lot of work and there's a lot of job ladders, there's a lot of expectations, documents, there's a lot of both written and unwritten things around managing your career. And in fact there's so much of it, it starts to eventually contradict itself and so it becomes really hard. And one of the reasons why designers think the only way to kind of move up that ladder is to just manage more designers is because headcount or how many like recursive management chains or headcount, that's a really simple like, oh, I have 30 people reporting to me and it kind of cuts through all of the noise of the expectations documents Any of that, right? So it's this, like, simple scorecard or scoreboard that people use. Because the alternative was, like, really confusing and hard to do. And so one of the things that I did was I said, okay, this is too confusing. If you distill it all down, everyone's career is kind of defined just by two axes, autonomy and ambiguity. Meaning how autonomous do you operate and how ambiguous a space can you operate in autonomously? So, for example, if you take an interim, right, someone who's in college, those people can't. You're not going to leave them alone for six weeks and then come back and see where they're at. Because you come back, they're going to, like, spun off the planet, right? And you can't give them a super ambiguous, you know, problem to go solve. You need to give them something that's very defined and say, okay, I need you to design this very specific thing and I'm going to come back in three hours and they're going to see where you're at, right? And so their ability to operate in ambiguity autonomously is quite low. You then take someone, you know, much more senior in their career and you can give them a really hard problem and leave them alone for a long time when you come back or when they come back to you, they've probably made a lot of progress on that problem. And I think that when I looked at all of the career expectations that I could pretty much distill it down to, like, how much ambiguity can you give this person and how autonomously can they work through that ambiguity? And if the answer to that is, we could give this person the hardest problem in the company that has no answer, and in eight weeks they will make progress, that's a very senior person. That's a person that you want to reward. And if you look at someone's impact almost in every situation, they worked with a lot of autonomy on a very ambiguous problem. Now, that could be a designer with high craft who's able to solve really complex problems, UI problems in novel ways. And they, you know, they did it on their own, right? They just went off and they figured it out, or they're off with a small group and figured it out. For a manager, it might be that they were able to drive their team to deliver something without, you know, banging on my door every two hours, right? I was able to, hey, go do this, Raise your hand if you need help. And they go and do that. And so I always kept going. And when I'd be in these psc, which Is our. Which at Meta is the performance cycle, like, things we'd be doing these meetings and the debates would be going crazy. I would often be like, time out, time. I. How ambiguous was this? And how autonomously did this person do it? Explain that to me. And it would just, you know, kind of focus everything down. And we were able to also compare, you know, people being like, well, okay, we heard this person, how they work through that problem is this other person's. Is that problem as ambiguous? More ambiguous, Less ambiguous. Were they as autonomous? More autonomous, Less autonomous. And, you know, that's it. And I think that when young designers come in, I would do orientation and I would draw, you know, that like, you know, autonomy, ambiguity, and then just a line that went like this, and I'd be like, you're here. You're the only way, like, your career is going to be up here. On the engineering side, John Carmack, if you don't know, is the. The, you know, legendary engine. He's an engineer, right? You could put that guy on the hardest engineering problems ever and not just leave him alone. He wants to be left alone. And he would solve them. That's why he was like the most senior IC engineer or one of the most senior IC engineers at Meta when he was there. Right. Design is the exact same. And so I've always found that a really helpful framework. I give it to people and it tends to work not just in Meta, but anywhere.

And how do you work with your manager leadership chain to. To go up on this curve? Right? I. I guess you got to prove yourself the problems that they're giving you, and then maybe you ask for more, like, difficult problems, or maybe the managers give it to, like.

Yeah, I mean, this comes down to. So in. In managing, you have to give people opportunities, right? And you have to kind of throw them in the deep end of the pool and see if they can handle it. There's two types of people. There are design. We're talking about ICs or managers.

Let's just talk about ICs first.

Okay. So. So for ICs, I think there's one class of ICs who literally seek out ambiguous problems. Like, they actually find them themselves. They're very proactive. They see something not being done and they're like, hey, why is no one working on that? And I would say that those ICs are incredibly valuable and will rise up very quickly because they find they kind of hunt down things. They see the things not being done before being asked. That is a real behavior of autonomy. That is a significant marker of autonomy. Then when they find the thing, whatever it is, can they make progress to take it from the ambiguous to the known. Right. From the unknown to the known. And those people are super valuable. They tend to get promoted very quickly. They find problems to solve. They solve them. They don't need a lot of hand holding. There's then. But that's not everyone. And. And nor should it be. There's then people that you have to, like, say, hey, I need you to work on this thing. And they go and they grab it and they go and they solve it, and they don't need a lot of handholding. And I think for managers, the art is getting out of the way of the people who proactively find these things and giving them the space and the opportunity to go and pursue them. Right. And then for the people who you think have more ability, more upside, you sometimes have to give those to them and say, hey, I need you to go solve, you know, this problem. And it's really hard. And so I think that both of those instances exist, but these are for managers. This is where you can really help people grow in their career sometimes by giving them those opportunities.

Yeah. Cause otherwise, if you just practically go solve it, especially in a big company, like, maybe some other team is working on it, but they're doing, like, a shitty job. And then you have to. There's like a bunch of, like, don't step on my toes kind of things. Right?

Yeah, I think. But once again, I think that's the art of the IC's ability to identify a problem. Like, I think the best ones find, like, hey, why is no one working on this thing? Like, you know, in large companies, even in small companies, so many things fall through the cracks. Like, there's just. There's more work to do than people to do it. And so I think good IC see those things and they grab them and they run with them. The thing you want to be careful as a manager is to grab things that aren't worth their time. There's a great. I don't want to go too deep in this because I know we're running out of time, and maybe we'll get a few more questions. But there's a Jim Barksdale who was the CEO of Netscape in the 90s. If you don't know what that is, go look it up. He was sort of known for a lot of pithy, kind of clever sayings. He had a saying which was, if you see a snake, shoot it. Like, and if. And the first rule is, if you see a snake, shoot it. Second rule is, don't play with dead snakes. And yeah, the point of that was it was like, hey, if you see a problem, like, get rid of it. But don't spend a bunch of time playing with the wrong problems or dead problems. Right? And so I think there's an art too for those ICs, but once again, ICs who do it well, who always identify the right problems to go solve. Super valuable, promote them, reward them, other people, get them to that place.

Got it, Got it. Okay, I just have two more questions to ask. So, you know, there's a lot of angst right now with figma coming out of AI tools and all this AI stuff that, like, you know, am I going to lose my job? Or like, is the industry going to collapse a little bit? And like, what do you have to say to those folks who kind of feel this angst?

So I have a theory and we'll see if it. I have a path. So I don't know if it'll be true that we may have reached not, I mean, over time, design jobs will continue to increase, but we may have reached a kind of peak design job era, meaning the hyper growth of design over the last 10 or 15 years, depending where you want to kind of market from. We've probably capped out at that and we're going to see a decline in that. And one of the reasons for that is the hyperscaling era is at an end, at least for now, in technology. Another reason for it is that the tooling is getting better, meaning we're getting more efficient. And also engineers are seeing this as well, where tools allow a designer to be more efficient, right? And do their job. So let's just imagine for a second the Figma AI or what, photoshops or whatever makes a designer 20% more efficient, right? There is an argument that, okay, well, you just need 20% fewer designers. I'm being overly simplistic, but like, efficiency gains in any industry eventually mean that you need fewer people to do the same job to do it. I also think to some extent there's a bunch of work that will be able to be done by other people aided by technology. And so. But that's not new, right? If you think about making websites, right? It used to be if you wanted to make a website, you had to have someone who knew how to design, how to code, you know, how to like put together a server, FTP, whatever, and that's still true today. But we also have things like wix and Squarespace that can make a pretty damn good website with like a person with or Canva or you know, whatever. Like the tools have gotten pretty good that like a bunch of people can just do it themselves. A store owner with a, you know, enough motivation can build a pretty good looking site without requiring all that. And so arguably there's a bunch of design jobs that don't exist today that maybe, you know, due to technology with AI. I think what's going to happen is I think that there's going to be a bunch of work that designers do today that's going to go away. And I just think it's going to go away. I think there'll be other work that will emerge that will be necessary and needed. So. But I think that ultimately we're probably going to go through a phase of contraction around design jobs. I see people, I hear from people it's harder to find work now than it was two or three years ago. I see teams figuring out how to operate much leaner. And a lot of that is due to tooling. Not all of it, but a lot of it is due to tooling. And it's just going to make things a bit faster and easier.

And I think, I mean, I think in some ways that kind of sucks, but in some ways it's also good like, like, you know, like enough of the, like, you know, doubling headcount, tripling headcount and then have to lay everyone off like a year after. It's like very bad for people's careers.

Yeah. And I think that it's very like, if you look back through the history of technological progress and cycles in all sorts of industries, this is actually a very natural kind of part of the evolution. That doesn't mean that it's not painful, it doesn't mean that people's lives aren't impacted and that I don't have sympathy for that. But I also think that it's a natural part of the maturation of industries as new tools come in. And like you can go through every industry and find examples of moments of like, like this. But typically if you also look over time, for the most part everything grew. Right. Like, you know, we don't make there. There's many things that employ Linotype. If you know about how newspapers were typeset, you know, for decades just through these Linotype machines and there's these Linotype operators, la type operators don't op. That job doesn't exist anymore. Right. But did exist for a long time. And that's a. And that's just an example of, like, how industry kind of evolves and moves through. So for the designers, I think you're right. Design teams kind of got a little crazy because we were doubling and tripling to keep up with the scale of everything. We don't have time to talk about this, but there's a whole other thing about how teams scale. And I think we made a mistake because engineering was scaling in this very linear way. We would scale design similarly and linearly, and I think that was maybe a miss. And so now things are shrinking and we're sort of recalibrating it. But AI, I think, is just a tool in the same way Photoshop is a tool or was a tool. Like, I'm now old enough to have seen a few cycles of this, and while it sucks for in the short term, I think in the long term it'll be fine, but it'll take some time to play out.

Got it. So it's probably just like the most actionable thing just to use these tools and, like, learn how to be more.

Effective with, oh, I would not fight these tools. That's insanity. I think, though, that also you have to remember that these tools, we're going through a bunch of hype cycles around this. And so I think that, like, how often are you using AI to actually design things?

Right now I only use, like, one or two AI tools, mostly to write stuff, not to design stuff.

I don't really, you know, they got a ways to go. They do definitely help and they're getting better and they're progressing really quickly. But, yeah, like, you should use them. And I don't think fighting them makes any sense. I do think there are some interesting questions about how they're trained and, you know, what that all looks like. But, you know, I think that we'll work through those. I think those are good debates to have and good discussions to have, but it doesn't mean you either, like, fully dismiss it, nor do you, like, fully embrace it. Like, oh, yeah, no, it's totally cool that it's doing all these not great things and you have to find something in the middle to work our way through.

This makes sense. So, John, I'm not, you know, where can people find you? Where can people find your writing? Online.

So online, if you want to. A lot of things we talked about are in written form at John Lax Jon L A X Framer AI and that's just where I just sort of pushed out a bunch of my writing. You can also find me predominantly nowadays on threads. Also. J O N Lax is my username. I don't I'm not so much on Twitter or X as much as I used to be but I do occasionally pop up there and that's jlax J L A X and so those are all good ways to find me.

Awesome John well thanks so much for your time. I love how you know with so many decades of experience you cut through a lot of bullshit and say it like it is. So so yeah. So I really appreciate that and thank you so much.

Thanks Peter. This has been fun. A L A X and so those are all good ways to find me.

Awesome John well thanks so much for your time. I love how you know with so many decades of experience you cut through a lot of the and say it like it is. So yeah. So I really appreciate that and thank you so much.

Thanks Peter. This has been fun.