Yuhki Yamashita: evaluation

Transcript context

…the PM for the rider experience at Uber, I'd be like, you know what? We're going to contribute incremental trips because the experience is going to be so good that we can get more people to come back. And I think the reality for a lot of that is, it's a metric that you don't have full control over or there are many hops until it can affect it, and okay, well maybe we can make the experience better and maybe that improves your attention and maybe this. And by the time you get there, you actually can't even prove that you moved the top level metrics. So either you anchor something that matters, but you can't move, or you anchor something that you can't move but doesn't actually matter. So that's the relationship I've had with [inaudible 00:42:45], so even it's really frustrating. So when I write that thinking about, one of the things I realized is that we had OKRs, but people were treating it almost as a to-do list or a task list of, okay, here's how, by the end of quarter, I need to complete these tasks and then I'll feel like I did my job, kind of thing. And we would have these dreadful meetings where we go through these spreadsheets and have people stand up in front of everyone and talk about those commitments, or those key results, rather. But they were dreadful for a reason, which is that you just couldn't really understand what the team actually really cared about. And it got to this point where we had all these, and this is similar to the secondary metric problem, but either you couldn't approve that you actually moved it, or you're trying to work on something that I don't actually understand why it's useful. And so that was when I deprecated it and said, "I just want to understand your headline. What are you trying to do, philosophically?" And just don't stress about whether you can measure it or not. I just don't understand what you're optimizing for, and let's first have that to date. And then once we get there, then let's talk about, okay, well what are some ways that you can measure it? And some of it's qualitative, so it's quantitative, and that's fine. And I almost feel like sometimes, it's better to take the report card approach of saying, Hey, just give yourself a score, tell me how you derive that score, let's all understand that the metrics and those inputs that go into it can change over time, and we're going to get more sophisticated about how we measure it. But at least everyone understands what on earth you're trying to go for. So that's where I moved in my first year, I would say, and then we hired a Head of Data who is a friend of mine from Uber, too. And one of the things she felt was, okay, but it's still very loosey goosey, and super subjective, so let's just try to bring OKRs back and see if we can just do them better next time. And so we've done that, and they were definitely better than when I first arrived just because we had a data science team and we had more rigor around metrics and things like that. But again, this time it was less about not understanding what people were doing, but more not understanding if teams are actually committed to moving those OKRs. r around metrics and things like that. But again, this time it was less about not understanding what people were doing, but more not understanding if teams are actually committed to moving those OKRs. And one of the problems that you find is we have these OKRs, but they feel like these post-rationalizations of the projects that you're working on, anyway. And at the end the quarter, you come back and see if those OKRs move, fingers crossed. But if you stop an engineer in the middle of the hallway or the virtual hallway, so to speak, and ask them, okay, what are your team's biggest goals or OKRs? [inaudible 00:45:31], they wouldn't be able to say it. They're just like, well, I'm working on this project that's really important. And so it's, well, what's the point of publishing this OKR if you're actually not thinking about moving it on a daily basis almost, right? And so that's when we've tried to experiment with this terminology, well, maybe if we should call it commitments instead, people would take it a little bit more seriously. And it's my belief that oftentimes, commitments are this care between the why and the what, and sometimes the face of the commitment is the what. It's a project and there are many why's behind it, or it's the why and there are many projects behind it. So that what's trying to formalize that idea, but it definitely felt a little bit complicated, a little bit. Sometimes people are like, well, OKRs exist for a reason and this is, basically, an OKR with just a different name. So my honest sense is we still haven't figured it out and we're still iterating on a bunch of different things, but I think I've developed some philosophies around it, which is, no matter what you call it, because it doesn't matter as much. I think that, for me, there are three things that really matter about the good OKR, and one is legibility. People look at it and understand what it is, and it's not some weird obfuscated metric that doesn't mean anything to anyone. I think actionability, I want OKR to inspire action. You look at that and you're like, it's stirs action, makes me want to do something differently. And the third one is authenticity, which is, does this actually, honestly depict what you're doing, what you're trying to do on a day-to-day basis? Because if it doesn't, then it's hard for me to trust that, that it matters. Or if that's something that just happens to describe what you're doing but isn't really connected in a meaningful way, then I question the value of it all. So that's why I am in the process. But I definitely am all ears to advice around this kind of stuff, because I feel like we haven't quite cracked the code. I love hearing that. That ,hole journey. I feel like you always hear from product teams, here's what we do now. You never hear, here's the experiments we've been through, here's what we've tried, here's what worked for a while, here's what doesn't work now, and here's what we're doing now. So it's really cool just to hear all the experimentation you've done. Clearly, Figma is a company where you encourage experimentation and trying new things that aren't working, and it's cool they have the flexibility to just like, let's just do headlines for now, and no more specific goal metrics. We're just going to build things that we think are important. And in the newsletter post, for folks that are listening, you actually show the templates that you're using these days for planning your projects and laying out your OKRs, so folks can check those out if they're interested in seeing how you're doing that, now. You also mentioned you've hired this awesome data scientist, and maybe just expanding that further, I imagine a lot of the success of Figma and the product that you built is the people that you hire. At Figma, I believe you have 22 product managers, which sounds very small for a company like Figma, and I imagine they're all amazing. I'm curious what you look for in product leaders and product managers that you hire that, maybe, other folks aren't as focused on, and just what does the interview process look like at Figma?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.