You Don't Want to Hire "the Best Engineers"

No matter what you do, you will make wrong decisions and need to fix things once you need to scale. That's the way of startups. However, you also need to prevent the high level footguns such as OWASP top 10 and exponential algorithms with minimal supervision.

And you haven't had a single candidate that could possibly pick up the missing skills[1]?

==================================================

[1] I don't know what those are. There are two extremes here:

1. PhD level Maths is involved.

2. You require them to have experience in a specific product (anything from a Python library to a framework like HF)

If your requirements are closer to the first extreme, well sure, you're gonna have to wait for someone that has that.

If your requirements are closer to the second extreme, why not just take a candidate? If it takes 2 months to skill up on whatever product you need them to skill up on, right now you would have had that position filled for the last 4 months with your ideal candidate.

startups are generally moreso a business endeavor than an engineering one, although the engineering must correctly support the business

the engineering begins to take the driver’s seat as the tech debt and cost of scaling catch up to successful companies and begin to create excess drag

but for many years, such companies can typically still afford to throw away money to solve business problems, including these problems of scale

If you find product/market fit before you run out of money... that's when you need to hire engineers who are in it for the long hall. People who focus on reliability and scaling. People who might stick around for 5 years to see if your startup becomes a unicorn.

The best engineer I've ever known spent most of his career doing drivers at Qualcomm. When he left his job they offered him significant raises to stay, offered months of paid leave, and then said he could always come back. Later, an OSS project he worked with heard he was free, and they changed their remote work policies to hire him. He's under 30, and despite working remotely at an OSS project makes significantly more than me.

I like to think I'm a good engineer, but when I work with customers they aren't setting linkedin alerts on my name for if I leave my job. To qualify for what this article is getting at, you really need to be the best engineer out of 100's, not the best engineer in your team of 5.

Frankly, being a consistent super-star engineer on a team of good engineers, is more important than actively maintaining a network. Experienced founders ask everyone in their small circle of long-time, highly credible, proven associates "who's the best engineer you've ever worked with?" If the answer is interesting, they follow up with "Where are they now?

In my startups, I recruited nearly all of the star engineers this way. In most cases, getting them on board required significant sustained effort. Sometimes just finding them wasn't easy. So - if you're really the engineer on your team who most everyone else would identify as "the best", please don't waste any time maintaining a network. Just keep doing truly great work that others will still be telling stories about over drinks years from now.

If you're not that engineer... then by all means be a reliable, likable, good communicator and maintain your network! Because as a founder, I never had enough high-credibility sightings of "great engineers" in the wild, so I had to mostly build teams out of credible referrals of best "good engineers" and even best "intern or new grad engineers with potential" you've worked with.

* Aside from a random, serendipitous surprise (which you shouldn't count on), early on the only proven "A players" you're going to have are your co-founders - which is why you chose them and gave them a huge chunk of equity. So you're going to have to get good at the art of hand-crafting a team that can win out of B and C level players. Doing this is hard but it's a tangible skill you can develop if you consciously work at it. They key is developing the knack for spotting raw, undeveloped and emerging talent. Of course, experience over time is the best way to get the knack but there are shortcuts. Always ask your circle of experienced advisors to tell you about times when they've seen someone emerge as a star despite starting from average (or below) expectations. Ask what that future star was like before and probe deeply on this. Ultimately, just being aware this is something you need to do and focusing on it can go a long way.

* Since you can't recruit enough star talent to win playing the game you wanted to play or using the strategy you'd planned, you have to adapt. Be willing to change your game, strategy or approach based on the unique talents and abilities the team you can recruit has. This is how great coaches can still win even with 'B-level' random talent.

* Be willing to accept unconventional, incomplete or flawed candidates if they have above average talent in one or more domains that matter to your unique value prop. Maybe you've figured out there's a backdoor way to win by making a product which doesn't have all the checkbox features but is fr faster than any other alternative at a couple critical things - and your hypothesis is that for some set of customers that will be enough to overlook your lack of features. Then you hear about a dev who's "the best goddamn high-perf optimizer I've ever seen" but after finding and talking to him, you learn he's got an uneven, checkered resume, has a felony record and can't work or live within 500 feet of a school - which is probably why he's available to start immediately if you're willing to have a chat with his parole officer.

Okay, maybe it's not that bad but the point is, you don't have the luxury of being inflexible. Back in the 80s I hired a talented engineer who was openly trans - and this was in a fairly small mid-western city. Times were very different then and it caused significant problems with other employees and even our landlord but I managed the downsides and this person delivered some incredible code that helped our launch product shine. Since times are (fortunately) different today, let's update the example. Maybe today's deeply flawed but weirdly-gifted-in-one-useful-way candidate comes to the interview wearing a MAGA hat and inquires if their licensed hidden carry firearm is going to be an issue in the office. Are you a good enough coach to extract winning results from a random team of flawed players with some unique gifts which are only partial, potential or still emerging? Can you craft a winning team by thinking different and digging deeper than anyone else through the bottomless pool of candidates who couldn't pass the first screen at Google or that hyper-funded AngelList-darling startup everyone's buzzing about? Because there are gems buried in that mountain of mediocrity if you can find and polish them.

See this other post from us: https://www.otherbranch.com/shared/blog/would-you-still-hire...

I think after the dot-com run-up, "startup" often implied "unprofitable idiot idea that looks plausible long enough to convince VCs to use your company as a demonstration of the greater fool theory." But I said "often," not "always." The critical and vexxing part of this is it's so hard to figure out which idiot ideas are profitable before the VCs shower a small cadre of Stanford GSB grads with cash.

I didn't get "I'm retiring now" money, not even close. But consider I expected nothing, was only a senior-level IC there for a year, and remained an IC after, it made appreciable change in my life and got me a good paying job at Google after.

But I think in that case it had more to do with the parties involved (our management were great people, and Google was motivated to treat us well).

I'd love to replicate this experience, but it ain't gonna happen.

So far I've mostly found different (often worse) kinds of dysfunction and not really much better velocity.

There are broader dysfunctions in our industry.

In the immortal words of Jobs, "real artists ship". Those names are well known precisely because they have a proven track record of shipping products - very few of those would let a challenging environment get in the way of shipping.

That said, as their employer, you may well not like the way they go about it. Name-brand engineers don't take shit from management, and if you get in their way, they won't be shy about airing that publicly.

Still, when we're staffing, there's a world of difference between the great engineer who is happy being mostly left alone and writing complex but well-specced SQL queries for 12 weeks and the great engineer who can balance software architecture, customer meetings, and programming for the same project.

Senior Software Engineers should not promote bad habits to juniors.

The people in power circle the wagons around their preferred cliques, because they don't care about the business succeeding nearly as much as their buddies (because there's always the next job.)

Then often the folks are left to do more work with the same pay and the impression that a random draw occurred and they lucked out, nothing more. It really can sour previously hard working folks and have them become that employee that you then think you need to get rid of.

The truth is that most companies are not made of "only A-Players" and that its basically impossible to staff such a company, so you need to limit the damage anyone can do, create systems of checks and balances, reward brilliance and have clear objective levels of work people need to meet to keep their jobs.

Very challenging, but no tricky questions, it felt collaborative and low pressure (comparatively at least) and everyone seemed like someone I would enjoy as a coworker.

That's what makes an A player. I manage a bunch of programmers and I'll always hire and keep those who want to be there and want to learn over those with "skill." In fact, I find many junior engineers who outperform senior engineers. All the time. Because they're present. They're there. They care. They're careful. They learn. They're dependable and accountable.

I know it may sound silly, but it's really true and I think a lot of people are surprised.