The Rockstar

A Developer so talented, so productive, so essential that if they were to leave, the entire project would collapse.

  • Can mutate into: “The Hostage Taker” or “The Diva” Developer
  • Dangerous when coupled with: “The Optimist” Project Manager
  • Likelihood of fixing: None
  • Danger to project: Extremely High


In the software development industry, the term “Rockstar Developer” is often bandied about by recruiters attempting to attract developers by inflating their egos, i.e. “We are looking for a few Rockstar Developers.” True “Rockstar” developers are hard to find, as they are the perfect developer:

  • There is no problem they cannot solve (and quickly).
  • They work all hours of the night to make their deadlines.
  • They have virtually no bugs, or any bugs are quickly resolved.
  • They take on the most difficult parts of the project.
  • They are generally well liked by the peers.

Unfortunately, once hired, they become indispensable to the project.

The Rockstar Developer is like a black hole of work: work spirals around them, and is eventually and inevitably sucked into them to be done. This can be as extreme as them taking work away from slower developers in order to meet a deadline – much to everyone’s relief. If the project is in a bind, they will bail it out. If something dramatic and unexpected happens, they will know what to do. They are truly remarkable – and every recruiter knows it.

The Rockstar Developer will receive several recruiter calls a day, every day. This is because their reputation precedes them. Companies are always looking to poach “Rockstars” because they know how valuable they are, and in many cases will do almost anything to get them.  The situation, therefore, is someone indispensable to your project having just about every other company wanting to poach them from you. If they do, the project fails in a classic case of putting too many eggs in one basket.


There is no “solution” to The Rockstar Developer – indeed; you would be foolish to “fix” them as they are your most productive developer by far. All you can do is mitigate the damage from them by building a team around them that can continue to be effective if The Rockstar were to leave. This will most likely mean that you will need several developers to replace the productivity of a single “Rockstar”, but at least you will be able to survive their departure.

To test how bad your situation is, pay close attention to developer productivity when they go on vacation. If, when The Rockstar goes away for a week, all development halts, then you need to redouble your efforts in getting other developers to a level whereby they can keep the project moving when The Rockstar is not in the office.

This can be challenging if the developers have become so accustomed to The Rockstar handling difficult problems that they have become lazy and complacent. There is a chance that with the sudden departure of The Rockstar, the other developers will spring into action, but more likely they are so fond of The Rockstar that they follow them out the door to work with them again at their new company.

Fan Art

Dave Kopet created fan art for “The Rockstar” that is available as a T-Shirt from his Etsy store. Thank you Dave – it’s pretty awesome.


16 thoughts on “The Rockstar

  1. Possible solution: turning them into ‘teachers’ via peer-programming. Not always feasible, depends a lot on the environment and needs a strong cohesion between product and team/technical leadership to create the space for this.

    • I have seen this model work extremely well, but as you say it requires a leadership team with enough wisdom to say, “While I know in the short term we won’t get this person’s horsepower, in the future will end up with a stronger team overall.” Unfortunately, I’ve also seen this model fall on it’s face, as coaching and mentorship is a very different skill set than being an excellent developer. Having said all that, with a leadership team and developer with the right disposition, it can work given time.

      • If Rockstars are smart and love what hey do they will teach other team members as they know that team will be much more productive and deliver more. Rockstars are not afraid to loose the work as they know that they will find work they like very fast so in average they will be more willing to share gathered knowledge to less experienced developers.
        The only issue I see (based on my own experience) that some Rockstars become bored with the same project after some time and they start looking for new projects or move to other companies if they cannot find new technical challenges in the current company.

  2. Since you need multiple developers to replace the Rockstar, make sure you pay them well. It’s unfair to the Rockstar for getting slightly higher pay but solving most of the complex problem in the team.

    • How is that beneficial for the team? I can’t see it being beneficial in neither the long or the short term. The Rockstar adds a lot of value as long as they stay and you will have the same problem(productivity drop) when they leave. Therefore it’s no reason to fire them.

    • You could suggest that same solution for all of the Problem Personalities that Neil has outlined. In my opinion, his suggested solutions are more thoughtful, constructive, and practical than firing everyone.

    • Wow, that’s 100% counterproductive. As opposed to actually getting the productivity out of the individual and actually planning for their departure, you’d rather remove them up front (for being the best producer you have) and trigger an exodus of people thinking they’re next.

  3. The solution is to fire everyone else, increase his salary and hire more rockstars. If the other stars recognize he was a fake, you’re in trouble.

    • Exactly! Cut the dead wood from the team and build the team up from nothing BUT rockstars. That’s the fix. The problem isn’t that you’ve got one developer who’s really good, it’s that you have other developers who aren’t.

Leave a Reply