5 Reasons to Avoid Hiring Rockstar Developers

Software development can be a complicated process. Never mind the complexities of the technology itself; people on the team need to work together well, and that’s not always easy.

Fortunately, hiring managers know that “good fit” is a crucial factor, and ask interview questions designed to evaluate candidates’ teamwork and “soft skills.” Personally, I’ve been lucky: my current team works together well, despite ages that range from 29 to 59 years old. We’ve managed to work smoothly together, even with the stressors that come with a release only three months away.

But not every tech pro is nearly so fortunate: Some are trapped on teams with a “rockstar” developer.

On paper, a “rockstar developer” sounds really good. Conventional wisdom holds that they can develop software ten times faster than other tech pros (a synonym for this kind of employee is the “10x developer” or “10x programmer”). HR managers salivate to hire them. CEOs complain about the lack of them.

Who wouldn’t want to hire someone that capable? It seems almost a no-brainer. But there are reasons you should be wary of hiring someone like that, including a major one: It can upset team dynamics, whether the team in question is composed of 100 people or three.

Weakening Teamwork

Teamwork is about playing to each other’s strengths. Not everyone on a team can do everything with consummate skill; you need someone who knows a particular programming language, or even how to effectively deal with a company’s overarching bureaucracy.

In my career, I’ve learnt about programming games, aeronautical software engineering, accounting systems, oil trading, derivative trades and real estate accounting. I’ve picked up enough knowledge to get by in each area, but if you really want to become a subject-matter expert, you probably need to dedicate ten years or so to the effort.

A rockstar developer is certainly a master in one area, but they’re almost certainly not a high performer in every area, despite their claims to the contrary. If they try to do too much, it can create friction with other team members who are actually experts in certain project aspects. And when that happens, overall team morale (and productivity) can quickly degrade.

Alternatively, a rockstar developer may try to focus only on what they’re really good at, despite their job responsibilities encompassing other areas. If they don’t have time to spare for those other functions, other team members will need to put their own responsibilities aside in order to cover for the rockstar. That’s also bad for the team.

Demoralization

Having a rockstar on a team can be demoralizing; you feel that your performance will compare poorly, especially if your managers spend all their time talking up the rockstar’s skills. If the team fails in its strategic objective, there’s also the possibility that everyone except the rockstar will end up taking the blame.

Draining Credibility

Everyone makes mistakes (and by ‘everyone,’ we mean everyone—including you). But when you believe you have found a problem with a rockstar’s code, it’s a tougher battle to be believed.

This actually happened to me in my software engineering days. I had difficulty getting some code to work, and I blamed it on a piece of software written by the department’s rockstar. Nothing happened. Two years later (and a year after I’d changed jobs), a former colleague confirmed that I’d been right about the bug all along.

Impeding Team Development

Having a rockstar on the team means that managers will favor them to take on the tougher problems. Managers usually want the software written by yesterday, so having your best programmer do the hardest problems will save time. At least, that’s the thinking. The reality is that the other team members won’t have the opportunity to develop their skills and work on the project to the fullest of their abilities, while the rockstar is (usually) overloaded from the first day.

And it’s also a bit of a vicious circle. The more development is put on the rockstar, then the less cohesive the team overall.

Lengthening Recovery Time

Inevitably, there will come a time when the rockstar leaves. Whatever the reason behind their departure, the rest of the team will need to pick up the pieces. If the rockstar was managing the bulk of the coding, however, that recovery will take even more time, as the rest of the team won’t have the necessary institutional knowledge to seamlessly reconstitute the key parts of the project.

Is There Anything You Can Do?

What you want to build is a rockstar team: Not a team of rockstars, but a team that works well, supports individuals, and gets problems solved without relying too much on a single worker.

A lot of this is ultimately up to whomever is managing the team. But even if you’re not team leader, you can facilitate things for your team and the “rockstar” by emphasizing the need for communication and clear goals. It’s often miscommunication and goal misalignment that leads to insurmountable friction; honesty and transparency are cultural values that will allow a team to transcend its members and accomplish something great.

If you’re in a management position, emphasize to the rockstar that they need to help their colleagues; let them know that team-oriented results are the ultimate goal. By aligning their individual goals with that of the team, they’ll hopefully help you drive every project forward.

Related

6 Responses to “5 Reasons to Avoid Hiring Rockstar Developers”

  1. Nonsense. Utterly wrong. Point by point. Hogwash.

    Do NOT hire the mediocre, always hire the rockstars, and make sure that those who are not in that class get an opportunity to learn and grow.

    As the manager, it is your responsibility to ensure that the team atmosphere remains positive in the presence of the rockstars, so don’t shirk your responsibility by hiring lesser capable individuals.

    Bah humbug.

  2. I’d say the biggest risk with rockstars is potentially ditching the job for greener pastures when a project under development is at its critical point. Have seen this in multiple places I’ve worked and in my opinion they whine the most when being overworked or have to put in extra hours and doesnt want to, knowing that they can just jump ship for even more money and restart the cycle.

  3. Andreas Falkenberg

    There are true Rockstars and perceived Rockstars. Unfortunately often we perceive a person as a Rockstar, which might not be one and vice versa. I had an engineer in my group who never would have himself considered a Rockstar, but I think he was at least close to a 10x developer if I look backwards, but he would not ever have stated that about himself. Also he was super shy and therefore not the person who stood in the front. On the other hand I know a guy who pretty much thought of himself as being a Rockstar and again in the long run he was a great talker and presenter (I truly give that to him) and could explain things well. This also led to others (Management) thinking about him as a Rockstar, yet when it came to actually doing things he was not as capable and lots of things did not work or in the end someone else had to finish it up. So if someone comes in and he thinks of himself as a Rockstar then most often he might not be. And vice versa there may be hidden gems completely unnoticed by management.
    Another problem is that if management does not know what it usually takes to finish a particular task. Say you have task A and task B of similar complexity. Task A is given to developer Jim and B is assigned to John. Now Jim is ready after 1 week and John is ready after 10 weeks. Then management concludes that task B was 10 times harder to do than task A. Further it gets worse John comes in early and stays late and comes in on the weekend because he needs much more time, then he gets promoted an praised because he works so much harder. Further for the next task of category A management in general thinks it is much easier to do than tasks similar to B therefore they think that Jim’s job is easier than John’s job. Especially if these are longer term projects being really a good developer may never be appreciated.

  4. This is wrongly titled (I agree with the other comments on managements inability to lead the team with rockstars). It should be “rockstar leads” who dominate a team because the manager wants to remain uninvolved.