Will Larson: belief

Transcript context

…This is a question that's coming up even more in a moment when we're reducing a lot of the size of teams from the industry when the venture capitalists that are on the board for these venture-backed companies are pushing on the efficiency of engineering. Engineers are trying to figure out how do we represent this? How do we prove that we're appropriately productive for the amount of headcount and funding that we have as an organization? And man, that's hard. So the first way that people focus on trying to answer these questions is just benchmarking by the amount of funding that you have. And that's pretty straightforward to do is a mechanical exercise. You get a data set from your venture capital funds or whatnot, and you figure out, "Okay. How much should we be spending in R&D? How much should we be spending in engineering? How much should we be sending on infrastructure engineering in R&D?" And you can benchmark this all out and figure out what the correct numbers are there. The problem is this is a very mechanical and not very insightful, driven way. It'll get you a defensible answer. It's like the old, no one gets fired for buying IBM, which definitely hasn't been true in my career ever. But this idea that if you just have the right benchmarks, DCs won't judge you for spending too much in engineering, but this doesn't actually help you get to the right place. It just helps you get your board to be less angry at you, which is useful because it's hard to do good work when your board is angry at you. But it's not useful in the sense that it doesn't actually help you run your organization effectively. So then there's the much harder mediator problem of how do you actually know if your R&D team or engineering team is effective? What I find is a couple of things. First, if you're a good leader and you talk to engineers, they will tell you... The engineers know if their teams are effective or not. And if they're not, they'll also tell you why not. And their diagnosis can be wrong, but there's a crumb you can start picking up and you can trace the crumbs to figure out what's wrong. Often you'll have more experience to analyze the complaints to figure out what kind of the contributing causes are to them. But yeah, if you just go talk to the team on an ongoing basis, you'll know if they're effective or not and you can go work to solve those specific problems. But again, you can't tell your board, "Oh, it's fine. I talked to the teams that they're good." My intuition's spot on because how do they know if your intuition is good or not? They're dealing with a huge portfolio and some of their leaders are talking to are good, and some of them have terrible intuition. How do they actually assess? I think it's tricky. What I've tried to do is basically two things. One, aligning engineering evaluation to the business and product goals. So I want us to be wholly accountable with the product goals. Well, we did a good job products like screwing up over there. ngs. One, aligning engineering evaluation to the business and product goals. So I want us to be wholly accountable with the product goals. Well, we did a good job products like screwing up over there. Obviously, a lot of companies find comfort in doing that, but really we're here to support the product, to support our customers in doing something interesting. We're not here to build novel systems unless it supports the customer and the product. So first try to align heavily there. Second, I think just showing the roadmap of the valuable things we've done in the last six months is really powerful. I think sometimes people are like, "I don't have anything to put there." And you're like, "Yeah, that's a real issue." Or if you have the ton of stuff to put there, that's great. I really find that if you just commit, show the number of meaningful, meaty things that have impact that you're doing and you can explain the impact, people will step back and give you space. If you can't populate that list, people will have concerns and rightly so, they should be concerned about that. Is there any metrics or tools or anything like that that you find useful too? Because these are all awesome piece of advice, but I imagine everyone is always just like, "Give us this number we're tracking, give us this dashboard, see what engineers doing."…

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