When founders become bottlenecks, it's time to hire leadership. The speakers argue that engineering managers should only exist if your culture demands it, and that DORA metrics and Git analytics can track team productivity without punishing individuals.
Chapters
Part of the reason that we want to get both of you here is that I think there's very few companies in crypto that have gone through kind of a major scale-up, and OpenSea is one of them. And then OpenSea also is in a market that, like crypto itself, has had a lot of ups and downs. And so with the benefit of hindsight, I think there's probably a lot of lessons learned that you can kind of pass on to the next generation. Having gone through that experience. So that's why we're here today.
Speaking generally, not just for engineering management hires, there comes a point where you feel this pain of being the bottleneck, where someone, whoever is the de facto manager, which starts as the CEO, realizes that they are bottlenecking the whole organization. And having that self-awareness of when you've become the bottleneck is really important. And it starts at the CEO. It starts at really all the co-founders. So identifying that, I think for me, is the clearest sign that it's—
that you should hire.
It might, it might be like too, you know, it can even a following lead, like not a leading indicator, but the opposite, a trailing indicator of when you need to hire. And I think for an early startup, it's a really good indicator. It's not, if you wanna hire slowly and keep your team high talent density, which I believe most of the time you should do, then the moment you feel like you're at the bottleneck, the next question is, who's it gonna be?
First of all, first principles question, do you need to hire an engineering manager? That's the very first question you should ask yourself is, do you actually need to do this? I think a great heuristic is what Alex brought up, is this question of, are you becoming the bottleneck as CEO, as the technical co-founder? It's a great signal to start to think about that. I suspect that a lot of people start to hire engineering managers more so because they have money or because they feel like I've reached a series whatever and now I should be able to, I gotta go hire the VP of Engineering, I gotta go hire an engineering manager so I can focus on the strategy and all this sort of stuff. You should ask yourself if you really actually need to do that because as technical companies, incompetence and talent density and culture of your engineering team is probably one of the top 2 things that's most important. And so you should really ask yourself as a founder whether or not that's something you wanna start delegating away until it's like, expect until you have a culture and set of norms that are extremely congealed and stable to actually build on top. There's no such thing as like one size fits all culture. You kind of got to decide what matters to you. Like, are you guys gonna be like, we like grind, like we are just output, like we, we hack, we ship, we like, we're just like move fast and break things? Or are you like an Amazon-style culture, like, you know, you You write everything in a doc, everybody reads it synchronously, you're super hyper-rigorous, like, but you make sure to like, you know, be very metered and like sort of like long-term sustainable in terms of your work. That's all just so contextual in the company itself and sort of company you want to build. And there are successful models in all of those. What I would say is that I wish that I had had— I'd been more deliberate about that and I'd said to myself like, this is what I want. And then A, codified that. B, communicated that to people. C, made sure to regularly check in with myself, like, is everybody actually behaving this way? And if so, yes, great. If not, why not? I have a very specific tactical answer because we just went through a cycle trying to figure out the best way to do this. If you want to be actually very quantitative about it, there's a variety of different frameworks that exist. There's what's called DORA metrics. If any of you ever worked in traditional engineering organizations, that would track— essentially, it's like this composite metric that tracks your engineering team's productivity. That's more like an advanced, like, evil thing, so it might not be right for your organization. What I've found to be really, really helpful is, like, There are tools out there that are what are called GitOps tools essentially, or Git analytics tools, where you just, it basically just gives you a better version of the GitHub heatmap for your engineers. Now you should never measure people's performance or turn that into a performance review type of thing on the basis of what the heatmap looks like, 'cause contribution velocity, commit velocity is not necessarily like the best measure of productivity, but it's really good at identifying outliers. And that's like, that's really, really helpful. It's like you look at this thing and you're like, oh, very clearly I can see that this person is like, is not contributing as much, right? Or I can see very clearly like we, you know, we checked in like 400 PRs last week and we've only checked in 100 this week. What's going on, right? And And what's really helpful, I think, is like, if you make it like a— it's— you don't make this thing where it's like, oh, the CEO or the CTO is like, you know, looking at all my commits like secretly in the background and like judging me on the basis of that. Like, no, actually just make it like a team-wide thing where you're like, hey, like, let's all like look at this together. How are we doing right now? Like, oh look, it looks like we, we've been checking in more code than ever before, how awesome. It's like, oh, we're slowing down, why are we slowing down? Make it like a like a shared goal, essentially. Something that everybody owns together as opposed to a tool of accountability.
Sometimes managers don't give them feedback. It's just kind of like a basic thing. The feedback feels like, "Oh, I'll just save that for when things get bad." and it's not like delivered quickly and in real time to the person. Delivering your feedback quickly and in real time, setting up a one-on-one if it's needed, is just super, super, super critical. And just make it like a really key tenet for your company if you can. And having like feedback roll up into documents that are delivered 2 weeks later and just not think of it. And I think you just lose a lot and it just forgets. It also adds all this management work and it makes you a better manager.
