Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You don't want to hire "the best engineers"

otherbranch.com

Post reply on HN
Print view View original

291–300 of 326 posts

Re: You don't want to hire "the best engineers"

#291

Post by questionableans »

mrandish wrote: post #276
sokoloff wrote: post #238

Earlier quoted context omitted.

I think most significant sized operations are built and succeed or fail based on the quality and leadership of the B players. You just can't find enough A players to build an entire [large] company of them and hopefully the C players contribute in a steady, no-drama fashion, leaving the B players* as the differentiating aspect of your particular company. * - and the focus/determination/consistency with which you part…

> You just can't find enough A players to build an entire [large] company of them The corollary to this is that too many real super star players can hurt a large company, especially if they're too close to each other. They need to be spaced out and inserted into the right places at the key moments when there are critical challenges they are uniquely suited to solve. Super heroes generally make lousy mayors. Super her…

That’s an unusual definition of superstars. It sounds like you’re talking about very lopsided people who are experts at one thing?

Re: You don't want to hire "the best engineers"

#292

Post by monkeyelite »

Apocryphon wrote: post #199
monkeyelite wrote: post #9

Earlier quoted context omitted.

This is just true on its face. Imagine you were building a new CPU architecture and the head engineer was just not at the office. Maybe people would agree if we change the word “best” to “most responsible” or “most accountable”.

Mac OS X was largely ported to Intel by John Kullmann working remotely, close enough. (Several more engineers were added to the project but not until a year and a half after he started.) https://www.quora.com/Apple-company/How-does-Apple-keep-secr...

A solo tech explore is not leading a project.

Re: You don't want to hire "the best engineers"

#293

Post by Apocryphon »

monkeyelite wrote: post #292
Apocryphon wrote: post #199

Earlier quoted context omitted.

Mac OS X was largely ported to Intel by John Kullmann working remotely, close enough. (Several more engineers were added to the project but not until a year and a half after he started.) https://www.quora.com/Apple-company/How-does-Apple-keep-secr...

A solo tech explore is not leading a project.

Forget leading a project, he completed most of it.

Re: You don't want to hire "the best engineers"

#294

Post by Gud »

Centigonal wrote: post #182
glimshe wrote: post #116

Earlier quoted context omitted.

Sometimes I'm just happy to avoid the worst engineers. They do exist. Bad work ethic, poor foundational skills, hard to work with. I feel that if I can weed them out, I've done 75% of my job as a hiring manager.

Reed Hastings and Erin Meyer talk about this right at the start of No Rules Rules . Netflix had to lay off a big chunk of of their staff because of a funding crunch early in their history. Despite the negative emotional toll that took on everyone, productivity actually improved. The authors reference a Will Felps experiment[1] that showed that introducing just one pessimistic, lazy, or mean actor into a group of prof…

Ironic considering Netflix content is mostly F-level junk these days.

Re: You don't want to hire "the best engineers"

#295

Post by AllenM999 »

I think this framing is exactly right: once you cross the threshold of intelligence and work ethic, “best” stops being a single axis and starts becoming contextual.

In practice, the engineers who end up being game-changers aren’t necessarily the ones with the cleanest codebases or the fastest prototype cycles — they’re the ones whose strengths match the moment.

A few real-world examples come to mind:

Linus Torvalds didn’t just write code; he created a system of distributed collaboration (Git) because the scale of Linux demanded it. His engineering contribution was partly social architecture.

Margaret Hamilton at NASA defined entire disciplines of software reliability and safety at a time when “software engineering” wasn’t even a recognized field. Her context required meticulousness and systems thinking over speed.

James Gosling’s creation of Java wasn’t just about syntax, but about building a portable runtime when fragmentation was the biggest pain point in the industry. He solved the problem the world cared about most at that time.

Guido van Rossum intentionally designed Python to be simple and approachable, betting on readability over performance. That “engineer as teacher” quality ended up seeding one of the most important ecosystems today.

The “best” engineer isn’t universal; it’s the one whose particular strengths — whether speed, rigor, clarity, or community-building — align with the bottleneck you’re facing.

So maybe the hiring question isn’t “Who’s the best engineer we can find?” but rather: “What kind of engineering excellence will unblock us right now?”

Re: You don't want to hire "the best engineers"

#296

Post by pydry »

Gud wrote: post #294
Centigonal wrote: post #182

Earlier quoted context omitted.

Reed Hastings and Erin Meyer talk about this right at the start of No Rules Rules . Netflix had to lay off a big chunk of of their staff because of a funding crunch early in their history. Despite the negative emotional toll that took on everyone, productivity actually improved. The authors reference a Will Felps experiment[1] that showed that introducing just one pessimistic, lazy, or mean actor into a group of prof…

Ironic considering Netflix content is mostly F-level junk these days.

Not really. The quality of engineering has little to do with the quality of content.

Their problem is that the quality of engineering started off being critical (who cares how good the content is if you get endless streaming failures?) and is now not so important.

Re: You don't want to hire "the best engineers"

#297

Post by Jensson »

questionableans wrote: post #291
mrandish wrote: post #276

Earlier quoted context omitted.

> You just can't find enough A players to build an entire [large] company of them The corollary to this is that too many real super star players can hurt a large company, especially if they're too close to each other. They need to be spaced out and inserted into the right places at the key moments when there are critical challenges they are uniquely suited to solve. Super heroes generally make lousy mayors. Super her…

That’s an unusual definition of superstars. It sounds like you’re talking about very lopsided people who are experts at one thing?

That is what people typically mean with superstar, a person exceptionally good at a thing. A superstar basketball player doesn't necessarily come with a good attitude, same with movie stars, they don't always deliver great results if they are unhappy with their role.

What do you think superstar means? That they are good at everything? Nobody is good at everything. A superstar programmer is probably not a superstar manager etc, not is he a superstar football player.

Also the more sought after you are the harder it is to stand bullshit, so generally superstars are more fickle than average workers. They don't get more irritated, they just don't hide it as much because they have less reasons to.

This means if your job involves a lot of bullshit then a superstar will likely perform worse than an average worker and will quit soon, since superstars tolerate less bullshit. That doesn't mean they are not a superstar, tolerating bullshit is generally not a part of being a superstar in most peoples definitions.

Re: You don't want to hire "the best engineers"

#298

Post by jama211 »

010101010101 wrote: post #289
jama211 wrote: post #270

Earlier quoted context omitted.

The worst managers I’ve ever had didn’t use Jira, because they didn’t use much of anything at all, and everyone was confused about when and where their next task would come from. The answer was usually “they’ll message you at any time with a random request and demand a deadline at the same time”. Jira helps turn terrible managers into mediocre ones, it at least forces them to write down what needs to be done and let’…

The best managers I’ve ever had didn’t use Jira, because they didn’t use much of anything at all, and more senior engineers were trusted to manage work streams and run projects without needing to conform to a process demanded by someone not directly committing code. Jira might turn terrible managers into mediocre ones, but it also turns good managers into mediocre ones too.

How did those senior engineers assign and track work to less senior devs in the team in your case out of curiosity?

Re: You don't want to hire "the best engineers"

#299

Post by 010101010101 »

jama211 wrote: post #298
010101010101 wrote: post #289

Earlier quoted context omitted.

The best managers I’ve ever had didn’t use Jira, because they didn’t use much of anything at all, and more senior engineers were trusted to manage work streams and run projects without needing to conform to a process demanded by someone not directly committing code. Jira might turn terrible managers into mediocre ones, but it also turns good managers into mediocre ones too.

How did those senior engineers assign and track work to less senior devs in the team in your case out of curiosity?

Depends - sometimes with simple Jira boards, sometimes with other tools like Smartsheets or Air Table or a simple spreadsheet, sometimes with post-its and a white board, sometimes with no system formal or otherwise. My point is less about Jira specifically and more about tool/process dogma (although I do think Jira is the tool of choice for most “we must used the Agile Toolkit Scaled Enterprise Framework Productivity System MegaProcess for all things!” types than others, mostly because of having been around forever and because of Atlassian pitching organizations to use Jira workflows for compliance as if it were uniquely capable of tracking when someone clicked a button in a UI).

Re: You don't want to hire "the best engineers"

#300

Post by tikhonj »

jama211 wrote: post #298
010101010101 wrote: post #289

Earlier quoted context omitted.

The best managers I’ve ever had didn’t use Jira, because they didn’t use much of anything at all, and more senior engineers were trusted to manage work streams and run projects without needing to conform to a process demanded by someone not directly committing code. Jira might turn terrible managers into mediocre ones, but it also turns good managers into mediocre ones too.

How did those senior engineers assign and track work to less senior devs in the team in your case out of curiosity?

One way is for senior engineers to give junior folks well-defined areas of responsibility, and then not worry about assigning and tracking small tasks within that. The more senior folks explain and motivate what we need and talk through what the interfaces around the area are and how it fits into the broader work of the team, then help as-needed.

Instead of trying to "track" work in terms of tasks, you keep up with the state of the system by understanding the state of each area. Which is pretty natural to do since you'd be helping with design discussions, code review and some pair programming and debugging.

You can get a lot done by talking and by looking.

Post reply on HN