Leadership Insights From Growing 2X in 8 Months

A lot of people ask me, how do you know you have product-market fit? Well, if you have to ask, you don't. Product-market fit feels like you're being dragged, kicking and screaming by the market as users ask for more and more stuff. I joined a company with PMF last year and at one point an interviewee asked me how does it feel to work here. Honestly, it feels like I stepped into a blender and someone just keeps pressing the blend button. We've grown engineering by 3x, the company by 2x, and we're running out of office space and we still can't keep up. The market just wants more.

So this talk is my attempt to step back and write down some of the things I've learned. I hope you find something useful to apply in your team. So there's this game, keep talking and nobody explodes. Two players diffuse a bomb. One has the instructions, one has the bomb. Your goal is to work together. When I played this game with my partner, we tried both roles.

When she had the bomb and I had the instructions, the game sucked. We kept bickering and fighting and we lost the game. Both of us felt panicked and out of control. But when I had the bomb and she had the instructions, we won. Both of us felt in control, calm and the words were flying. The more you talk, the easier it is to diffuse the bomb. So I feel in control when I do the work, my partner feels in control when she understands the instructions.

Growing the team is a lot like that game. The more you talk, the more you win. Because you can't do everything. You have to let others do the work or you'll be the one who explodes. And the worst part of this is that you go from holding the bomb to holding the instructions, which for me is hard. As others do more of the work, they need someone to be the glue and keep everyone pulling in the same direction. And that's kind of scary. It's disorienting. Half the time you feel like you have half an idea of what's going on. The other half, you have all these ideas and no time to make them happen.

So as the most experienced member on the team, you go to areas with least certainty. You surf out front and create clarity for others, figure out what needs to get done, what technologies you want to use, who do you need to talk to, you find all the fires and you try to go where there's uncertainty. That's why it feels like a blender. You're constantly confused, jumping between levels of abstraction. One minute you're in the weeds, helping to debug a database issue. The next minute you're answering, Hey, how's that initiative for the quarter going? Like, I don't know, man. Software flies like a squiggle, but you're accountable. You've got to know. And if you try to jump, and if you try to time-bounce all of this jumping around, you'll just create piles of unfinished work waiting for you.

So the simple fact is you cannot do everything and you cannot be everywhere. The list of priorities and good ideas never ends. The more you create, the more users ask for, and the more ideas you have. The solution I found is to stop thinking about how to do the work and focus on who is doing the work. You've got an idea? Awesome. That's for Jane. Got a feature request? Great. That one's for Joe. Bug? Alice knows all of the code. Every piece of work goes to somebody else. You can hold the instructions, but you can't hold the bomb anymore. There's too many bombs.

So you become the side quest specialist. Since you can't work on critical things anymore, you become the side quest specialist. That's still safe for you to do. The sort of projects where it doesn't matter if you have to put it down for a few days or weeks, sometimes months. For example, I just implemented an idea that I started working on back in February. It's pretty cool, but it was a little bleeding edge and the tech wasn't ready yet. I had to let it cook for a few months, but I'm really happy now. So that's the sort of thing you can do as the side quest specialist. Long term ideas with dubious feasibility or super short projects that unblock a thing for tomorrow so that your team doesn't get distracted.

Or you can do the uncertain groundwork, get things halfway done, then let others take over and finish the feature. This is fun but super unrewarding. You never get to a point at something and say, I did that. That was me. That feature, I did that, because you didn't. The team did it, you were just talking about it. But what you can do that's super rewarding is you get to mentor lots, whatever that means. Honestly, I still don't know how to point my finger at mentorship. It's not like you have a meeting on your calendar that says mentoring or an item on your daily to-do list. Mentoring is this thing that happens in between the work. Some days you spend three hours working with someone and it changes how they approach the work. Other days, you make a throwaway comment and people keep quoting you forever and it becomes part of your culture. If you get this right, people will keep coming back to you for years, even after you both work at different companies. At least that's what I do. I just talked to my mentor last week and I'm not even sure he realized that he's my mentor. So make sure you keep in touch with all of your mentors. It really does mean a lot to them. So I can't point at mentoring for you, but here's a few things that I think I do that count as mentoring. The first is that you should always explain your reasoning on PR comments, on design documents, on just making quick decisions in Slack. Spend the extra 30 seconds to explain your thinking. This helps you check your work. It gives others the opportunity to say, hey Suez, that assumption is wrong. You're full of shit. And it helps them make good decisions later. You need to trust your team to run things without you. Otherwise, the who not how approach won't work. If you don't explain your reasoning, you'll just become the bottleneck that has to make all the decisions forever. And the next thing is to always mentor one thing at a time. If you're teaching someone how to design a robust distributed system, you can't also teach them how to break down a large user story in the same conversation. Yes, they'll need to do both.

But if you keep your feedback focused, they can actually implement it. You'll help them lather up on everything over time. But if you make it all sound important today, they're just going to get lost and they won't be able to implement any of what you're telling them.

The other thing is that newbies need encouragement while experts want feedback. There's actual research on this. Forget the shit sandwich. The shit sandwich is for losers. You need to evaluate where people are in their newbie to expert cycle and adjust your approach. One person can be in different stages for different skills. This part is important.

So when someone's a newbie, you need to encourage them. Don't talk about the missteps. Focus on the good stuff and encourage them to do more of that. Newbies can improve their average performance just by getting better at the stuff they're already good at. But when someone's an expert, you have to focus on their weak points. They can't get better at the stuff they're already crushing. The way to raise average performance is to bring up the rear and get better at the stuff they can't do.

So if you're reviewing a PR for someone who's a beginner, pinpoint the stuff they're doing really well. Say, oh yes, this is great variable naming. It's great how you broke down this feature into different functions. All of that is awesome. They're going to do more of that, get better, and everything they do will become better. But if you have an expert, someone who's already really good at the code, you want to focus on, hey, this code is in the wrong place. You should move it somewhere else. Or hey, that comment you made yesterday during a meeting, that was bad. Don't say stuff like that because it discourages others. So yeah, keep feedback timely and focus on talking about bringing up the rear and improving the worst parts of expert's performance while focusing on the good parts of the newbie performance so that they can do more of that and they will just automatically get better.

Remember, the same is true for you. You need encouragement on the stuff that's new for you, and you need feedback on the stuff that you're already good at. Your other role as the team lead or whatever is to keep everyone focused on the outcomes. You're the bad cop who says, yes, that's cool, but what does it help us do? This is the part that really sucks. You want to play with all the new tech and fun toys, but you've got to be the adult who says no. Everything you do needs to lead to an outcome. You don't have time for navel gazing, for debates about the right code structure, or any of that. You need to get results.

You need new superpowers, new features, new abilities for the stakeholders. There should always be an outcome for everything that you do. Obviously, let people engage their curiosity, but keep them focused. When they find work that needs doing, say, great, what does that give us? When they find code they want to refactor, say, awesome, how exactly is it blocking you? Because if it's not actually blocking them, they don't need to fix it right now. And always try to find ways to make their work useful sooner. There's more people waiting than you realize. For example, we just had a feature where one of my engineers was working on building new announcements for our product. Always find ways to make their work useful sooner. There's more people waiting than you realize. For example, we just had a feature where one of my engineers was building announcements where one of those little pop-up bubbles, you click on it and you see, wow, you guys have a new feature. This is so cool. Nobody really cares, but you need to tell people about new features.

So we were working on this. We were not really sure how it's going to go. And then we realized, you know what, we don't need to build the, has somebody already seen their announcements feature just yet? Let's just put the announcements up. And then when people complain, we can make the little red bubble go away. And guess what? As soon as we shipped that, the very next day somebody was like, hey guys, do you have a good way for us to put some announcements up? We just launched a new feature that we want to tell people about. And it was great. So we just shipped this. We weren't sure where it was going to go. As soon as we shipped it, somebody had a use case. And as soon as we started using that use case, somebody came and was like, hey, can we make that red bubble go away? It's really annoying. So now we're working on that part. So make things useful sooner than you want. There's more people waiting than you realize.

And when it comes to that, it turns out user stories are good, actually. They're surprisingly helpful to help. They're surprisingly helpful in focusing you on the outcome. Yes, they sound dumb, but they really do work. As a type of user, I want to achieve an outcome. This structure is important. You have to know who benefits from everything that you do. That way, you can ask them if it worked, and you have to know the outcome that they want to achieve, otherwise you won't know if it did work. So you want to know what will they be able to do when they weren't able to do before. Avoid just doing work and delivering code. Focus on the outcome.

Sometimes code might not even be the best way to make the outcome happen. You might want to swipe a credit card instead. Most importantly, when you're talking user stories, every engineer can think critically and decide if they're falling down a rabbit hole or working towards a crisp result. This is super useful for me. I'm the rabbit hole guy. I like to go and start refactoring a bunch of code and fixing things and then realizing, wait a minute, I haven't worked towards an actual result in two hours.

Maybe I don't need to do this right now. So having a user story is super helpful here because you can focus on who you're helping and what you're giving them that they weren't able to do before. And that reminds me, you should write down everything. Feeling like you're in a blender comes from holding too much stuff in your brain at the same time. Some of this is inevitable. You can do the job if you don't think about it in the shower. But when it comes to tactical stuff, write it down. Keep notes on decisions made and the inputs that went in.

Write down your system designs. Put more context in your stories. Keep subtests for all in-progress work. Have documents for mid-term roadmaps. You have to be able to put things down and pick them back up three months later because priorities change, roadmaps diverge, things go wrong, and you might need to stop what you're doing and go do something completely different for a month or two, and then go back and pick up where you left off. You can do that if you don't write it down. I think of it as stateless decision making. You want to read one or two documents and make a decision without having to remember everything that happened in the last six months.

Because I don't know about you, but I can barely remember what happened last week. So this also lets you delegate or get help because you're sharing the context. It's easier for others to jump in and lend a helping hand, and it's easier to tell others what you would like them to do so that they can help you out. So part of this is that you need to set the vision and take small steps. I just mentioned roadmaps. You want to keep roadmaps flexible. Your task manager, like Asana or Jira, is way too rigid for long-term planning. Anything that's more than a few months out, you should keep as an idea in your head, a target that you're aiming for.

It's going to keep changing, and that's okay. Talk to people, get more input, keep making changes of the vague idea that you have in your head. The next month or two, you should keep those in a doc. Those docs are easy to change, but they're more crisp than vague ideas. They force you to write it down, make it something you can hold on to, and it clarifies your thinking if you write it down. So you can make it more actionable that way.

The next few weeks, two or three weeks, those should be user stories in your task manager. Focus those on achieving outcomes. As a type of user, I want to achieve this sort of outcome. Make them small and make them valuable. Also aim towards the ultimate vision in your mind. It's okay to twist and turn around the ideal path, and always remember that shipping will also change your mind. Write user stories so they ladder up towards the ultimate vision that you're thinking about, and that usually works pretty well.

But also don't be afraid to throw things that you're never going to do on the backlog. Putting stuff on the backlog gets them out of your mind and onto paper where they're safe to forget about. That's right. The backlog is where you put shit that you're never going to do, and don't worry. The good shit will come back. If it's important, you're going to think of it again. A stakeholder is going to say it, it's going to keep coming back, and then you're going to be like, oh, wait, hey, we already thought about this three months ago, and now we have a user story that's already mostly flashed out. We threw it on the backlog because it wasn't important enough, but now it is. And remember, you're basically a new company every 12 to 18 months.