A Difficult Software 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” Difficult Developer
- Dangerous when coupled with: “The Optimist” Difficult Project Manager
- Often confused with “The Assassin” Underappreciated Developer
- Likelihood of fixing: None
- Danger to project: Extremely High
Relevant Podcasts
Problem
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.
Solution
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 leaving 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.
Unfortunately, once hired, they become are indispensable to the project.
Slight typo here
Good catch – fixed!
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.
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.
The solution is probably to rip off the bandaid, fire them, and build a stable reliable team without them.
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.
Agreed, the presence of “Rockstar” developers should be considered as turbo mode, implying that without them there exists a normal baseline level of productivity.
Remember, if everyone is a “Rockstar”, more thank likely the honest truth is you have zero Rockstars on your team, as Rockstar implies deviation from an average.
To be fair, replace plebs with Rockstars and move up Rockstar to Hall of Famer.
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.
Really?
That’s a great way to demotivate the entire team and leave them wondering who will be next on the chopping block.
So your solution is to fire the most productive developer for the “greater good”?
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.
Found the Non-Technical manager.
Neil, you need another mgr type – The Create-New-Problems-Only-To-Then-Solve-It-er manager.
the Rockstar pattern is a problem with the team, not the individual. It’s on the team to improve their competencies, and to be able to function in the absence of the rockstar.
Where it becomes a problem is if the rockstar holds the project hostage, or if people start to demand too much from other developers (not holding sustainable boundaries), but those are issues that are separate from the core pattern named here.
This is how Rockstars become Soldiers. They learn that no good deed goes unpunished and that the best way to keep a job is to keep their heads down and be a 1.1x developer instead of a 10x.
Depressing because of how absolutely true it is.
That’s when you get into the, ‘Im just going to take the easy money and pour my passion into something outside of work’ work mode… as I am.
Probably should fire the “incompetent manager” as well
I agree with Jonathan. A stable, reliable, bonded team of developers is a way more efficient way to build a solid business foundation. “Rockstar” consultant could be the way to go as the temporary nature of the engagement is in the contract from the start.
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.
Fire everyone, keep rockstar developers.
What you say is fine in theory but in practice it’s entirely unrealistic, considering it’s pretty fortunate to have even one developer who fits all of the “rockstar” criteria outlined above. Accepting only rockstar performance will likely lead to unrealistic expectations and unhappy developers, who will seek greener pastures.
Meant for that to be a reply to somebody else, ended up at the bottom of the comments instead. Oh well
This blog (wordpress, I didn’t write it) is set to stop at 3 levels of depth in reply, but you may be able to put it where you want if you reply a level above.
Rockstar developers are great to have but when they become Diva’s you have a problem in your hands. They tent to rip apart other peoples code and nit pick every line of code others write to prove that they are better. Their code executes 20 ns faster so therefore its better. Ripping other developer code apart during peer reviews is so frequent it turns other developers away from the team. If the manager does not keep them in their place they become tyrants..
I consider myself is a Rockstar developer, whenever I was on vacation, the sprint failed because others have no one to ask when they stuck. But I work somewhat differently. I work 1 to 2 hours per day, that’s enough productivity to keep me at the top of the company. The rest of the time I read books, learn something new, programming or not.
I care about writing clean code that others can understand. When I review code, I ignore minor flaws, I only comment about the code design when I believe it’s bad and cannot easily to change when we need to add a new feature or modify the existing feature. Everything is a trade-off, spending too much time fixing minor flaws not worth it.
I help people when they are asking me to help them. But I never jump in without permission.
My problem is I get bored quite fast and jumping job is easy so I change job every year or 2.
A Rockstar costs 1.5x or double compared to a normal developer, but his productivity is 5 or maybe 10 times better. Actually, it’s cheaper when you count the price/performance.
I heard recently that said success isn’t only i.q… it’s also e.q.
I fully agree with your approach to looking at the greater good, and not just feeding your ego.
p.s. also moved around a lot.. but found myself now in a support role where the solutions are not just code solutions but business solutions overall, and a flexible dev schedule that doesn’t follow p.m. timelines, and there’s always some new challenge or system or team that needs tweaking or support. best career move I’ve made in my own instance
The problem with training others in “your spare time” is that you often end up with people who are ill suited for the task. Now you’re siphoning off time from the productive and made an easy out for the non-productive.
Management often takes the position that anyone can be plugged in. So then the failure is on the “trainer” who gets decreasing amounts of time to get their own actual work done and spends increasing time fixing everyone else’s work.
I’ve been there and it’s often used by management to shift their responsibilities off to others who now are seeing diminishing returns but are held accountable without being given the power to change the equation.
How I’ve gotten around this is the “train the trainer” approach. It also makes them responsible for the documentation and material they pass on to others. After all, the best person to judge the training material is the newly trained, right?
The problem isn’t the rockstar, but rather, the team’s dependence on them. This framing helps avoid situations like another comment above, where the recommendation is to fire the rockstar.
(though, of course, the possibility of them changing into a diva or hostage-taker is certainly an actual risk)
What’s wrong with giving the rock star extra high salary and really cool benefits to keep them from defecting?
When a rockstar recognizes that they are one, they should be working on enabling the other members of the team.
I fully believe that being a good programmer means that you should be a good teacher as well. The existence of the Rockstar is the existence of knowledge gaps.