Hacker Newsnew | past | comments | ask | show | jobs | submit | rachofsunshine's commentslogin

Rationality on an individual level is not the same thing as what produces the best long-term outcomes for both parties. On an individual level, bringing up comp immediately significantly reduces your chances of being moved forward. It shouldn't, but it does.

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


You have no leverage "immediately". You bring up compensation at the last minute, when the company extends its offer.


This is a specific application of a good general principle. Big companies need to watch for failure modes. Small ones need to watch for success modes, because the default is always failing.


We can. That's kind of the entire point of our business. Check back in a week or two - we've got another blog post on some of our interviewing data in the pipeline.


Those things are fakeable, but there are plenty of people who will aggressively signal a LACK of hunger. It's more of a negative predictor than a positive one.


Yeah, to some extent you have to be willing to deal with this stuff in recruiting, which is why I've taken on the clients under discussion at all.

In my Triplebyte postmortem (also on the blog), one of the mistakes I talked about was that Triplebyte was aggressive about trying to dictate terms. We told people how they had to hire.

Otherbranch takes a softer approach: if you ask for my opinion, I'll tell you what I think. Otherwise, I'll do my best to find you what you asked us for, with the understanding that some sets of constraints reduce the probability of success to ~zero.

That goes on the candidate side, too. I get a fair number of people who will come in and tell me "I only want a remote job where I can take a day off whenever I want and only want to work on a super clean codebase and also get paid 250k a year" - and those people are almost never going to end up with jobs. But the tradeoffs they want to make are their business, not mine, until they ask me to do otherwise.


It doesn't even need to be "good enough". People SHOULD be picky about founding engineers. But they should be picky about HIRES, not about top-of-funnel proxies for skill.


This is a good addendum. Do you mind if I add it to the post (credited, of course)?


You can use it, and you don't need to credit me, I don't think it's that unique.


It isn't, but neither is the original post! It's an important addition.


I'm not the poster you replied to, but as a recently retired multi-decade serial tech startup founder of the old-school bootstrap type - the addendum I'd add is what I now teach to young entrepreneurs: Assuming you're a first-time founder whose not playing the high-profile "raise more/spend more drag race" then accept you cannot hire "the best" engineers. You simply don't have the capital or reputation to recruit proven, top-notch talent. So, the only way to win is to play the game differently.

* 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.


Depends on the business.

Some startups (like mine) are delivering a service, and the technology used to deliver that service is instrumental. Our back-end is an Airtable I configured myself, and it's been sufficient so far; better tech is not make or break for what we do. Other startups, like Flexport some years ago, fundamentally depend on technical function because that's the core of what they do.

One of the common mistakes founders make, in my expetience, is not asking which camp they're in. It's not a hard question to answer (usually), but it's an easy one not to ask.


There is some truth to this, but I would argue (with a considerable amount of data on both assessments and hiring behaviors) that it is less true than people might like to hope it is.

I very intentionally did not write anything about finding engineers who are just good at the things you care about and not at other stuff, because every bit of data I have says there is a considerable component of general engineering skill underlying most eng roles. No, it isn't totally one dimensional, but (in a principal-component-analysis sense) it is fairly low-dimensional.

There really are just better and worse engineers in the sense that eng A is better than eng B for virtually every job. But that's precisely why recognizing the competitiveness of hiring is important - the more you insist on narrowing your pool, especially in ways others also narrow theirs, the less likely you are to find the rare unknown great engineer.


Totally agree with this. I'm in consulting, where there's a significant client communication component to most of our eng roles, so it's a slightly higher-dimensional space than engineering for product orgs. Still, there is a pretty powerful "g factor," where someone who excels in one dimension will probably be pretty good at all the other dimensions.

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.


There's a bit of doublethink involved.

On the one hand (and as I mentioned in the post), yes, most employers are not as dumb as I'm making them sound. In principle they know they need to comprpmise - but in practice, they often balk at doing so because they haven't clearly articulated what they will compromise on.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: