The Silicon Valley mythology is built on the back of the "Rockstar." We are told to hunt for the elusive 10x engineer—the individual contributor who can do the work of ten ordinary developers. We are told that one brilliant mind is worth more than a dozen competent ones. We believed the hype. We recruited aggressively from FAANG, offering astronomical salaries and special perks to attract the "best of the best."
And for eighteen months, our culture became a toxic waste dump. The rockstars were indeed brilliant. They could refactor a core service in a weekend. They could optimize a database query to save milliseconds that nobody noticed. But they also brought with them a level of arrogance and interpersonal friction that ground our actual progress to a halt.
We fired the rockstars. We started hiring what the industry dismissively calls "B-Players." These are the engineers who have families, who have hobbies, who don't spend their weekends rewriting the compiler, and who—most importantly—understand that software is a team sport. Here is why the Rockstar is a liability and the B-Player is your greatest asset.
The Cost of 'Brilliant Jerks'
Reed Hastings of Netflix famously popularized the term "Brilliant Jerk." The idea was that you should tolerate the jerk if they are sufficiently brilliant. We found that the "brilliance" of these individuals was consistently offset by the "tax" they levied on the rest of the team.
Our rockstars wouldn't participate in code reviews because they felt they had nothing to learn from "lesser" engineers. When they did review code, their comments were condescending and demoralizing. They would unilaterally rewrite entire modules without consulting the team, invalidating weeks of other people's work because they thought their approach was "cleaner."
The result? Our average engineers stopped speaking up. They stopped proposing architectural changes because they knew they would be mocked or ignored. The "brilliance" of one person silenced the collective intelligence of the team. We were paying for one 10x engineer and getting 0.1x from everyone else.
The 'Bus Factor' Nightmare
Rockstars thrive on complexity. They love building systems that only they can understand. It's a form of job security disguised as technical excellence. One of our lead "rockstars" built an entire event-driven orchestration layer in a custom DSL (Domain Specific Language) that he invented. It was undeniably clever. It was also completely unmaintainable by anyone else.
When he left for a higher-paying role at a crypto startup, the "bus factor" of that entire subsystem was exactly one. We had to spend four months and three engineers' full-time effort just to reverse-engineer his "brilliance" so we could fix a basic production bug. The supposed 10x output of his first six months was entirely negated by the 100x maintenance cost he left behind.
The Virtue of the 'Reliable B-Player'
When we shifted our hiring strategy, we stopped looking for "raw intellect" and started looking for "reliability and collaboration." We looked for people who could explain complex concepts simply. We looked for people who admitted when they didn't know something. We looked for people who actually enjoyed mentoring juniors.
The "B-Player" is the engineer who:
- Follows Standards: They don't try to reinvent the wheel for every ticket. They use the existing patterns, making the codebase predictable.
- Writes Documentation: They know they might not be there forever, so they ensure the next person can understand their work.
- Communicates Pre-emptively: They tell you when they are stuck. They don't disappear for three days to "solve it themselves" through sheer willpower.
- Collaborates by Default: They understand that getting a feature shipped is more important than being the one who wrote the "best" code for it.
The Productivity Paradox
Our overall productivity increased after we fired the rockstars and hired the B-players. This sounds counter-intuitive. How can "average" engineers outperform "brilliant" ones?
The answer is Parallelism. A team of five collaborative, predictable engineers can work in parallel on five different features. A team with one rockstar and four silenced observers is essentially a serial processor. The rockstar becomes the bottleneck for every architectural decision, every code review, and every deployment.
Furthermore, our attrition rate dropped to zero. The "B-players" were happy. They felt valued. They felt that the company respected their work-life balance. They didn't leave every time a recruiter offered them an extra $20k. They stayed, they learned the domain deeply, and that institutional knowledge became our most valuable competitive advantage.
Conclusion
The tech industry's obsession with genius is a major management failure. Software development is not a solo performance; it is a relay race. You don't need the fastest runner in the world; you need a team that can pass the baton without dropping it.
Stop hunting for unicorns and rockstars. Start looking for the people who are reliable, humble, and competent. These are the people who actually build companies. The rockstar will give you a great weekend; the B-player will give you a great decade.
Written by XQA Team
Our team of experts delivers insights on technology, business, and design. We are dedicated to helping you build better products and scale your business.