> We don’t ever, ever want B players on an A team. Define B players. I've hired engineers not because they are the most amazing coders, but because they are a

> We don’t ever, ever want B players on an A team. Define B players. I've hired engineers not because they are the most amazing coders, but because they are amazing at finding out what is wrong organizationally and then making the needed friends to help move things along. I've hired engineers who are catalysts for making other engineers perform better. I've hired engineers who wrote solid code, at a reliable speed, but whom I wouldn't describe as "brilliant". I could assign them a feature and know they'd hit the deliverable date +/- a day, every single time. Sure I had rockstar 10x engineers, but it takes all types, and focusing on "amount of quality code churned out per hour" is only going to work in certain organizations at certain times in a company's life.