I have been managing 10-30 member teams for a good three years now and here are somethings that have worked for me in building a team I can't wait to get back to work with. Much of this will have an engineering team flavour, largely because ours is an engineering heavy team. But I think the anecdotes scale well.
A++ engineers are whom 100% of their friends would call the best engineer they know. Applies to marketers, designers and any role, really.
I am extremely slow at hiring. I never hire because we have an immediate need. I take Mark Zuckerberg's advice pretty seriously - "Hire people you'd be comfortable reporting to". It's a great filter.
Finding an A++ player is obviously very hard. Not only are they scarce to begin with, but if they are really that good - they'd be either already hired or would be doing something of their own. So, it is impossible to find these hires when we need them. Instead, I'm always in hiring mode. If I like an engineer at a party, I will engage. I will take interest in what they are working on, mostly with a barage of questions - coming from a place of genuine curiousity. I expect nothing in the short term - other than learning something from a great artist. I am an introvert. I find small talk exhausting. I just can't do it. But when I meet someone who is operating at peak performance, I want to learn from them. I don't want to hire them immediately.
When a conversation is interesting enough, we tend to keep in touch. This keeping of touch usually doesn't mean messaging to and fro. It doesn't mean a call once in a while. But rather, when there's an interesting conversation, one remembers. My hack to interesting conversations is to ask interesting questions. I am bad at giving answers, but good at asking and listening. So, if we remember an interesting conversation - we're kind of in touch for a long time without needing to work on it any more.
Over time, if and when there is a match between our future roadmap and the people I'm in touch with, I reach out. Most times they're not hireable. But if there is interest, I find a way to work with them, albeit a small project. Afterall, I need this hire several weeks or months from today for our future roadmap. Not today.
When there is something urgent and we don't have bandwidth, I contract. I don't hire.
To give a concrete example, I hired an engineer almost 7 months after first contact. We first came in touch when I had tweeted out an engineering challenge. It was a silly challenge, just for fun. I probably had a couple thousand followers back then. This engineer completed the challenge. We exchanged a few messages, had a good laugh and moved on. A couple months later, we were doing a small hackathon. I asked them if they were interested and booked tickets and stay. We had a dinner together at the hackathon. We could have talked about anything, but we ended up talking about all the cool hacks we did at college. In the week that followed, everyone who was there at the hackathon described this person as probably the best engineer they now know. And I offered this person to join us. He said he was already doing two full time jobs, but had a couple of hours available a day. So we started working together. I'd only give them small tasks. But very soon, it was evident that those two hours a day already had huge impact. Over the next couple months, I would keep asking what would get them to join us. And eventually they bit the bullet and joined us citing "the work here is way more interesting than the other jobs I do". That brought a 6-7 month hiring process to fruition.
I am willing to go over and beyond to make a hire when I feel confident.
Almost everyone on the company right now has a special clause in their hiring agreement.
The following are some examples of things that would have traditionally been a no-go.
... and so on.
I'm always try to increase talent density by firing. There are many good engineers I've let go. It's a shame. But that's the cost of doing business.
I have let go of the best engineer I've ever worked with. But i had to let them go, because our work styles didn't match. We prioritized different things. I prioritized shipping fast. They optimized for robustness. Just being a great engineer is not enough. One has to be a great engineer in the context of the ambitions of the company.
In one situation, I've let go of another great engineer - only because their next career goal was to become an engineering manager. Nothing wrong with it. But, not at this company. We don't have any managers. We'll see why, in just a bit.
In another situation, we had to let go because of mismatch in compensation expectation. The engineer wanted a certain compensation. We weren't able to match. We devised a super convoluted arrangement for them to make the equivalent amount via a combination of bonuses and equity. But that didn't cut it. We had to part ways. This was an educative experience. It helped me figure out that "Over and Beyond" does have practical limits. It's best to part ways than to drag our feet when there's an expectation mismatch.
Firing fast is super important. We regularly fire. I'm not proud of it, but see it as one of my primary job. That's the only way to make sure we ensure everyone at the company is indeed an A++ player.
Great team players extract the best out of the others. They raise the bar by sheer inspiration. It's incredible what a great engineer for example is capable of pulling off. And even more incredible what they can get done when the aspire to be better. They aspire to be better only if people around them are aspiring and being better each day.
You can say that about 100% of our team. They are improving truckloads every week, just because every week someone new gets a surprising amount of work done. Someone new solves a problem in an unexpected way. Every week the answer to who was the best engineer this week changes. Everyone is one-uping each other. Not as a competition, but because they keep pushing their own boundaries.
A++ players probably have tons of opportunities. Everyone wants them on their team. And most opportunities pay well. But the parity in how much they pay is not really much. They're all in teh same ballpark. Put differently, no matter how much you offer, there are always other companies that are willing to pay the same or more.
So, the question becomes - why should a great talent join you? It's because there is interesting work. For the best talent their work is their artform. Does your team give them a great place to weild their brush?
No great engineer wants to build the settings page of a SaaS product. We need to give them problems worth their time and talent. I feel many companies are dishonest about this. Many companies' answer to why their engineering team is interesting is "Hey, we have millions of users and we have to scale our systems". That's a lazy answer. Great engineers won't bite. Scalability is not trivial, but it surely is commoditized. For most apps, just slapping a bunch of VMs behind Elastic Beanstalk is probably enough.
The answer has to be much more nuanced. What is it that, that has never been built before? Great engineers want to be pioneers. Pioneering work keeps great engineers excited and committed. Afterall, if they're not enjoying their time here - why are we here in the first place?
Reclaim protocol is incredibly lucky that we have dozens of hard engineering problems to solve. Hard as in no one has ever solved them before. Finding the solution and bringing it to fruition is satisfying.
If there is great work being done day in day out, if there's a mundane task to be done once in a while it sounds like a fair trade.
All our teams are one member teams. Each product has exactly one owner. If the said owner leaves, we're fucked. But I'm willing to pay that risk-cost in the interest of moving super fast on the days they're with us.
We're 25 people at this point. This is definitely not the time for a product or project manager. I wonder if there is ever a time for one. We have hired product managers in the past. However 100% of them have been let go, or have picked up some other important IC role at the company. Everyone reports directly to a founder. We're lucky we have 4 strong founders. But, I can totally imagine the same being true even if there were only 2 founders.
The number one source of feet-dragging and thereby slowdown, that i've seen in companies large and small, is the ICs not trusting the manager. If the Engineer doesn't trust the product manager for the work they're putting in, they will drag their feet when implementing. The worst kind of product managers are ones that don't talk to hundreds of customers and just try to use their intuition to make decisions. Engineers and designers see right through that bullshit. If one was using intuition, an engineer may use their intuition instead. In my experience an engineer's intuition is only slightly worse than a product manager's intuition if they've not spoken to hundreds of customers. Speaking to five customers doesn't cut it. An engineer will respect someone who has put in the hours to speak with 100 customers. Something the engineer doesn't have the time, motivation or the skills to do. Product managers rarely earn the trust and respect by doing the work.
So, at the cost of missing great product managers joining us - who I know exists, and even know a few personally - it's almost a policy to not hire managers. If you're not an IC, you're not welcome. I don't know at what company size this stops being true. But that number is surely not 25.
I think another mistake that many companies make is to design everything before implementation. I think that's a waste of everybody's time. It probably was a good idea 10 years back. Or, it probably is a good idea for products with completely new user interfaces like say AR headsets. But for most part, designing before engineering is out-dated.
All engineers have used enough great products in their life - on mobile phones and on websites. If it's a mobile app or website, all they have to do is just make it look like one of the apps they use. It's a pretty low bar. And these days, there are enough UI frameworks for engineers that it's pretty hard to fuck up.
A designer often comes of value in the second iteration. The first iteration is usually good enough for testing out the product. A designer can pick up from the feedback received and make a good product, great. It's the best use of everyone's time. A designer needn't waste time building screens for basic iterations. Why waste creativity on mundane stuff? Use creativity where we need creativity. Use creativity where the status quo design doesn't cut it. Let framweworks do the boring work.
The only way to get a team to do great work is to know what great work looks like. "Delegate not your weaknesses, but rather your strengths". Delegate what you are good at, not what you are bad at. To be good at something, you need to put in the hours. Founders usually have some strengths that they come in with. Those are the teams that are easier to build. At our company, none of the founders had done sales before. We've built sales orgs again and again, and failed. The time it started working was when the founders rolled up their sleeves and became ICs. Now we have a small sales team. But one of the founders needs to put in the work, if that skill isn't already part of the company's skillset.
The number one reason for failure at building a sales org is because it's hard to catch bullshit if you don't know it is bullshit. Colleagues aren't trying to bullshit. But they're often blurred by the context they're operating in. My cofounders' and my job is to help them zoom out and unblur. To call out bullshit. If we don't know it is bullshit, we can't nip it in the butt. Then that bullshit baloons in to a mega bullshit and at some point implodes.
It is hard to bullshit with me on engineering. I am now plugged out of a lot of engineering. I write almost no production code anymore. But I do look at code every day. If someone tells me a bullshit excuse, I can call out that bullshit. But until recently, none of the founders were able to call bullshit on sales. We struggled. Thankfully that is fixed because founders did it themselves first.
The second reason is if you're not able to help debug, your peers lose respect for you. If something is not working, you need to spot it early. You need to offer fixes. You need to offer alternatives. If you aren't consistently right, people stop trusting you and your judgement. If people lose trust on your judgement, you can't put your foot down in times of crisis. When it's a time of crisis, you just need people to trust you and execute. For that to happen, you need incredible trust. That trust comes from being right over and over again.
If you're offering ideas and solutions that don't work iteration after iteration, people will lose respect. They'll either not follow what you say or drag their feet about it. Ofcourse you can be wrong. But you have a hard limit on the numer of times you can be wrong per unit time.
You need to have answers. If you've not done it yourself, you won't know how to debug the edgecases.
A++ players are scarce and distributed. It'd be stupid to believe every smart person is in San Francisco. I lived in India for 30 years of my life before spending a year in SF. I was forced to build a team remotely, because obviously I didn't have the resources or the connections to hire from SF. But then now that I've seen SF, I would say there's absolutely nothing special about the top talent here. We have exactly zero engineers from SF on the team. Not every great engineer has the motivation or resources to move to SF. I'm not against hiring from SF. I continue to search for great talent here. But there is absolutely no reason for me to setup an IRL office in SF. And if not SF, probably nowhere else.
Even if multiple people live in the same city, they don't meet very often. No city has more than 3 people anyway. We try to do offsites/onsites semi-regularly to build bonding.
Almost fully async. All the work happens on Slack and Notion. Mostly Slack. We have slack bots for a lot of management. Across timezones. So, the SLA on anything is usually 12 hours. You need to trust your team that they're working on the important things and working hard at it, even when you're not looking. If I hadn't hired A++ players, it would have been really hard to enforce this.
If something requires short TATs, it usually needs to be planned before hand. But there are very few situations and very few periods of time where this is needed. So, when called upon to be available at off hours, it sounds like a reasonable ask.
We almost have no meetings. Except in crisis situations. At the time of this writing, we're nearing a launch. So, we do a daily standup. For probably all of 2023 we had no standups. Other than the one standup, there is no scheduled meetings.
For any meaningful work to be done, one needs un-interupted blocks of time. In my experience that's an 8 hour block of time. That's typically how much time it takes to get something meaningul from ideation to execution. Steps usually include : understanding the problem, intuiting a few solutions, reading up a few resources, writing code or a one pager, debugging it, and getting some feedback. This is a 8 hour task. Each time there is a meeting you lose 1.5 hours. Any subtask usually takes an hour at the least. If there's a meeting upcoming, you won't start something one hour before the meeting. It takes 30 min to get out of a meeting and get back into the focus mode. So 1 meeting slows you down by about 20%.
Things that work for me
Again, no particular advice on team building really worked for me. But a concoction did. Hope you find some ingredients for your concoction here.