Retiring the "Rock Star" Stereotype
A case for reforming or eliminating the idea of a "rock star" from your team/company
Recently, I was in an interview that asked me what I would do as a manager if I had a “rock star” employee that was an asshole to everyone on the team.
FIRST - I’d dispute the fact that anyone treating their team like toilet paper is actually a rock star employee.
SECOND - as a manager, you have a responsibility to protect your whole team, not just the one person that “seems productive” whether they are assholes or not.
Let’s break down why “rock stars” are generally not good for teams.
While this person may be “producing” a lot of work, are they actually being productive or just making more work for everyone else?
Having standout developers are great when they are leveraged to help the rest of the team as a lead or mentor. It quickly turns into a problem if management or the team in general is afraid to touch anything because it won’t be as good as the rock star can do. Even worse, the team is assigned work (or not assigned work) by the rock star based on whatever they don’t want to do because they are “in charge.”
If your team dynamics are like this, well then, “team” is really a misnomer here. If all the decisions are being made by one “important person” it can really derail a lot of things later, like maintenance, quality, scalability, performance, and usability.
I’ve seen examples where a rock star was asked to build something for a team, and he wrote it in a language that no one knew but him, and used a database system that wasn’t common for a backend data source. When he tried to hand off the tool, the team was really reluctant to use it because they didn’t understand how the data was aggregated nor how to maintain or update any of it.
The months of work that “rock star” put into the tool was wasted because the team couldn’t use it. They had to return to a manual process, creating more work, and now the very unique and interesting to code tool becomes abandoned software. And your company just paid someone for two months of work that isn’t useable at all.Who knows how long it might hang out in the codebase?
He’s an asshole, but he’s the “best” we have.
Why are we putting up with behavior that is clearly against company harassment policies? This has happened at several places I’ve worked, and I’m still baffled by why managers, and the company in general, puts up with it. Every time I’ve had to deal with a so called “rock star” they were doing some really crappy things that I knew was going to impact product quality at minimum or the team down the road when something wasn’t fully worked out but used quickly to fix a problem.
As for harassment, I’ve seen teams yelled at, people backed physically into corners, whole management teams avoiding dealing with the rock star developer because of seniority and “they know the system so well.”
AND not once in all my years has anyone called a woman a “rock star” at any company I’ve ever worked for. So that should tell you something about that moniker. Red Flag Anyone?
The rock star is also the best “fire fighter” we have.
I’m all for folks that come up with solutions on the fly, but how many times have those solutions stuck around because teams are either scared to touch it because that “rock star” bypassed all the normal checks and practices making the code flaky therefore untestable. Or the team doesn’t take ownership of it (rightly so) because they didn’t have a hand in building the solution.
If we are looking for teams to work together and develop into mature development teams, our senior team members need to match that energy. If senior members are actively undermining other team members because they don’t agree with their opinions or approaches, that’s foul. Management knowing about it and letting it happen is even worse.
Granted team members can have a different approach to problem spaces, HOWEVER, agreeing on an approach and then undermining that approach with external teams is just WOW. I’ve seen this happen across disciplines - program, project, quality, development, management - it’s not pretty when it happens and it unnerves everyone because there isn’t an agreed upon decision or direction.
This is different from critically talking about a problem as a team. Like I said before, team members can disagree on the approach and talk out what approaches might work best. At the end of the day, disagree and commit is a good thing.
Sometimes having multiple options is also good, because if the first one doesn’t work, you can circle back to another option. Yet if teams have a broken collaboration process or one person is clearly doing command and control or command and deliver, then when that fails, it’s going to fail in a big way.
This is when management needs to look out for the “senior vs the team” scenario.
Going back to the interview I mentioned earlier. I was told that my approach to minimizing the rock star was wrong, that I should have suggested firing the team.
- FIRING THE TEAM - over a person that is apparently doing all the work and seems to be a one-person development team. That’s just, wow. So, yeah, that interview didn’t go much further than that. If you have that opinion as a manager, you’ve failed to manage people, in my opinion. If your company has this opinion and there are major organizational problems, well, you’re probably hiring “rock stars.”