The authors reference a Will Felps experiment[1] that showed that introducing just one pessimistic, lazy, or mean actor into a group of professionals cut the entire group's productivity by 30-40%.
As a result of this lesson, Netflix now only hires "A-players" and is pretty aggressive about letting go of "B-players" and "C-Players."
[1] https://www.thisamericanlife.org/370/transcript
This has been borne out in real-world observational studies, too: https://www.washington.edu/news/2007/02/12/rotten-to-the-cor...
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.
* - and the focus/determination/consistency with which you part ways with the D and F players.
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 heroes are able to conquer insurmountable Cthulu-grade existential threats. But that often involves doing things you wouldn't normally do and can cause collateral damage. Fortunately, such threats are fairly rare. Of course, many people who use the term "A players" are really just referring to "good people" not true super stars.
A wise F500 CEO once told me there were only about 20 such super stars in his >10,000 person organization but he shared it more with a tone of "thank goodness there's only about 20 of them" because identifying them and getting them onto the right problems was a constant challenge. He didn't think the organization needed more of them, it just needed to better manage and direct the energies of ones it had - and by direct, he meant "direct it outward" on a massive, high-value problem - not inward laying waste to the day-to-day structures that keep the org running.
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.
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.
I had an initial screening where I had to write some code, write a test case, run it, then discuss how i'd parallelize the algorithm (didn't have to write this part). The code wasn't tricky, but I was glad I had practiced writing code quickly as general interview prep.
After the screen was an algorithmic coding round, but it was enjoyable and nothing that couldn't have been solved with some basic data structures and recursion. The interviewer was talkative and was happy to brainstorm as I talked through my solution, it felt like pair programming where I was driving, not just me being watched while I coded.
Then I did two system design interviews and an "HR" type interview/culture fit one.
I also had a 'practical' coding interview that again was challenging but really just some basic data munging. They gave me some (simplified) data structures and a simple version of a problem Netflix has to deal with, then I had to rearrange the data to the right format.
Again, not tricky, but needed lots of thought, they made me run code, and I was glad I had done practice interviews.
Finally, I was scheduled to the final round of the senior manager team interview, but by then I had accepted an offer for a team I liked at Google.
Google also had a really nice interview process except it took 4x as long.
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.
The same corporate strategy and culture that hired "A-player" engineers for streaming is hiring "A-player" studios for content.
Defining A-players as such means you've set the rules of the game instead of building a culture of adaptive success criteria to meet customer opportunities. The label itself is a function of organizational ossification. This is the likely legacy of our tech giants; innovative in only one direction and not able to change fast enough to avoid becoming a brittle, mediocre institution over time.
As consumers, we can all feel this ossified mediocrity every day.
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.
No job description can realistically capture every responsibility; this language helps prevent bad-faith disputes when new tasks or responsibilities arise that aren’t explicitly mentioned but are 5 millimeters away from those mentioned and entirely reasonable to be considered as in-scope for an existing employee.
Clear communication and transparent accountability are the way.
I am personally guilty of being far too lenient and tolerant in overlooking "hard to work with". Bluntly, as an engineer, I enjoyed working with a few particular "brilliant assholes" (as their brilliance was often but their AH nature rarely directed at me) and so I tended to tolerate them too much when I transitioned into leadership roles. I don't know if that was biggest mistake as a leader, but it was for sure in the top five.