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 team is nearly so fortunate: Some are trapped 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.
