Why Hiring Rockstars Is Harmful to Your Organization
I’m writing this in August of 2017, which means it’ll probably get published around September or October — over a decade since I’ve graduated from school. Every other semester during my time at the University of Waterloo, I would look at job postings and prepare to apply for my co-op term.
At the time, job descriptions were typically very plain. The more clever companies would use their allotted writing to grab the reader’s attention and make a strong impression amidst all the other boring job postings. For example, I still remember a company in Quebec using the job title “Human Cannonball” to describe the role of a tester. They also used “Death Ray,” I can’t recall for what role though. (You, dear reader, may be able to figure it out.)
Clearly, they were effective to a certain degree. Over ten years later I still remember them fondly.
Then, shortly after I graduated, I started seeing the second iteration of this technique. I started seeing companies look for a “Rock Star Developer” or “Code Ninja” to join their team in the Web 2.0 era. It was probably very effective the first couple of times, but then everybody did it and it became very played out. It made the opposite impression of the more novel first wave — I want to roll my eyes every time I see this. This stream of thought still perpetuates, as we see articles now building on that analogy.
I’m uncertain if companies are necessarily looking for “rock stars,” but I do understand they want to project that candidates they’re hiring are awesome. We all want to express that. But if you’re hiring a rockstar, what does that make the rest of the team?
And even if you do succeed, and have now hired a bunch of “rock stars,” you don’t have a team. You have a bunch of “rock stars.” In reality, rock stars typically don’t play well with others (consider these examples), and each member is typically just in it for themselves.
We all know the power of hiring an “A player,” but a “rock star” is absolutely the most backward way of thinking about this when it comes to building a great team. More bothersome is the careless use of this term. I believe some companies confuse the difference between an “A player” and a “rock star.” They don’t do the hard work of defining what an “A player” means to their team, so they just go with the flow and look for a “rock star.”
We define an “A player” according to our culture and what outcomes we expect from them. I’ve already written a bit about Flipp’s culture and company values, but I want to contrast an “A player” with a “rock star.”
An A Player is Team First, a Rock Star is in it for Themselves
Having co-founded and actively led Flipp’s engineering team for a decade, I’ve had a fair amount of influence on who we hire. Although I can’t say I have a lot of firsthand knowledge about working with a “rock star,” since we’ve never wanted to hire one, I have had a ton of conversations and interviews with people who have.
As a purely hypothetical example, let’s say I’m interviewing someone who is a full stack developer at her current company. She’s looking for the new opportunity and has been interviewing at a ton of other technology companies we respect.
When I ask her about her biggest accomplishment, she talks about this extremely robust platform she built and maintains herself. She sighs about how she’s frustrated being stuck with her teammates, these B-players, and how nobody could understand the code she put together even when she tried training each of them.
This coder’s prior company might consider her a “rock star” since she was an ace full stack developer and clearly the only person smart enough to understand the platform’s code. Let’s say the code was beautiful, and the platform was amazing, but her dozen other teammates couldn’t understand it. A couple of red flags go up in my mind.
What Are the Red Flags?
First of all, when she leaves, nobody on that team will be able to take over the platform because nobody can understand it. Uh-oh. This single point of failure is not good for a business, and I certainly wouldn’t want that to happen to my team (see the “bus count” concept).
Secondly, that code doesn’t sound that great. Great code is simple to understand and maintain, and rarely are a dozen people wrong and a single person is right. So, this “rock star” is overconfident (classic rock star mentality). She probably also isn’t the greatest coach or mentor, which is important to my team. We strive to build a great learning organization, one in which people are generous with knowledge and communication.
Also, the coder never doubted her own code. In fact, she disparaged her teammates for being “B players” and not understanding her code. She might not have fathomed that the fault was with her.
The coder may have the idea that putting others down makes her look better, but for us, her behavior and comments have the opposite effect. She shows a lack of leadership and communication qualities.
These “rock stars” try to project confidence, but it comes across as arrogance. In contrast, Flipp values humility and being team first. It’s not about people claiming ideas or promoting their own ideas, but refining ideas by combining them together or working them against each other.
In our interviews, we try to learn about our candidates’ processes and mistakes, lessons they’ve learned along the way, and their ability to share their mistakes with others so everyone can learn from them.
An “A Player” can Delegate, a Rock Star Will Not
Sometimes, people don’t realize — or want to admit — they’re in a situation where they need to delegate. But as a manager and leader, you must identify this issue and be radically candid about it. It’s never a good situation to have just one person who knows the whole system. That one person’s main job must shift to disseminate that skill, knowledge, and information throughout the rest of the organization.
This works out for the company because now, even if it takes up precious human resource hours, more people can understand, maintain, and develop the code. More importantly, it’s also good for the one person because they’re free of routine maintenance and problem-solving tasks. That one person is no longer the only one others can turn to for support. Now, that person can focus on creating new projects and innovating — tasks that engineers have always wanted to do.
Instead of having everybody turn to that one person in times of trouble as first-level support, she might now be second or third-level support.
Easier said than done, though.
If you have one of these rare, gifted, individuals on your team, you need to get her to delegate. Delegation is a very tough thing to embrace and execute on. In order to do it well, she needs to understand whom it is she’s delegating to.
She also needs to appreciate that while it may take her five minutes to do something, it might take someone else a couple of hours. She must make the time, the couple of hours, to teach someone to solve something. It doesn’t “just take her five minutes,” it will take an infinite number of five-minute segments to solve the organization’s problems.
The opportunity cost is the stuff only she can do, which is more valuable to the company than the extra one hour and 55 minutes. Trust me.
An “A Player” is Humble and Shares Mistakes, a Rock Star Doesn’t Bother
It’s human nature to preserve the self. To protect one’s own job. Sometimes, that’s at the cost of the rest of the tribe or organization. It’s very scary to put yourself out there and look like a failure, to admit that you made a mistake. But we’re all human, and we all make mistakes.
It’s also important to avoid repeating each other’s mistakes, in order for us to execute faster and in a more excellent way. So we want to encourage this unnatural behavior to spill out failures very candidly, otherwise, we’ll run into the same problem as all the other companies…
And really, to me, the only way around self-preservation or holding back mistakes is to dive headfirst into sharing mistakes. Reinforce that type of behavior, and make it like a muscle that you exercise. If you don’t, then you’re just like everyone else paying lip service to innovation and knowledge transfer.
We didn’t formally instate postmortems, but we started doing them three years ago with our engineering team after we fixed an error. Really, the intent of these meetings is to document and publish notes and mistakes so others can learn. It is just knowing that unplanned and unanticipated things are going to happen that might catch us off guard, and wanting a way to improve moving forward.
Everybody involved should be present at a postmortem. That way, someone absent from the meeting can’t be faulted, and we can’t avoid talking about what actually happened. These meetings should be facilitated by a team lead or director, who has experience running them.
When our team was 30 people, we knew everybody at the company relatively well. We have deep relationships and we understand how to react. But as we’ve grown to more than 400, our process has grown a bit more formal. Some people share it themselves. Other times, learnings are shared organization-wide.
Our method of sharing mistakes is straightforward. Someone says, “Hey, we made a mistake and this is what we learned.”
When we’re running a postmortem, we make sure to find a root cause. This is not finding someone to blame, but understanding how this happened and how we can prevent it from happening next time.
For example, someone might say, “I mistyped a command and I deleted the database.” One lesson is to “Be more careful next time whenever you’re typing a command.” That’s an okay lesson because people should already know to be careful. The stakes are high. But a better question is, “Why were you even able to delete the database in the first place?”
This is known as the second story, which David D. Woods defines in “Behind Human Error” as “Human error is seen as the effect of systemic vulnerabilities deeper inside the organization.” I read this from Etsy’s former CTO John Allspaw blog post on blameless postmortems.
Final Thoughts
The worst part about hiring a “rock star” is that they value individual success over the success of the team and company. They don’t contribute to the learning culture and actually take away from it by setting a poor example. Humility is the key ingredient to spreading lessons across the team.
Ultimately, hiring a “rock star” may seem like a win in the short term, but they will be a detriment to your company in the long run. They may be able to accomplish more than the next candidate, but you can only achieve so much as an individual. Strong teams learn from each other, feed off of each other, and the sum of their efforts is what ends up moving mountains.
David Meyers is the Managing Director of Technology and a co-founder at Flipp, a leading consumer marketplace reinventing weekly shopping. He leads the engineering team that builds data systems and infrastructure to power the shopping experience of the future.
