The Team Prima Donna

with 6 comments

This post is part of my series on Managing Developers – How not to suck

We’ve all worked with them at one time or another – the loud, opinioned, argumentative, authoritative, hardworking, smart capable, type A developer. The guy that always seems to have an opinion… on everything. The guy who’s code review feedback is usually something like ‘that code doesn’t look like my code’. They dude who wrote the super-complex-only-he-can-understand-it code your entire product depends on. You know, the code everyone else is forbidden to touch. The code that has no comments because it is all ‘self documenting’. He tells you he doesn’t have time to write comments anyway(1). The guy that must use every esoteric odd language feature he can find because coding it simply is too ‘verbose’. This is the guy that gets loud and upset at the drop of a hat. The guy that has to use the most complex (beautiful he says) algorithm for even the most mundane tasks. They guy that writes his own debugger because existing one just isn’t good enough. The guy that wrote his own domain specific language (using complex regular expressions) because “there was no other way to solve the problem”. They guy that uses LINQ expressions for everything because they are ‘fluent’. They guy that gets impatient when other people can’t instantly understand his code. This is the guy that to fix a bug, works straight through a weekend and completely re-writes a big chunk of code because ‘the code needed to be re-written anyway.’ This is the guy that always expects an ‘A+’ performance review – every single time.

You know – the team prima donna: a vain, undisciplined, egotistical, obnoxious or temperamental person who finds it difficult to work under direction or as part of a team, and although irritating, cannot be done without.

The Big Problem™ you likely face with your prima donna is that he is probably is also a genius or a 10X developer. The team depends on him. You depend on him. He gets a lot of work done, and he works a lot of hours. He is also very likely visible to your management chain, CEO or other Important People™.

Let me ask you three questions about your team prima donna.

  1. How much time do you and the rest of your team spend dealing with the prima donna?
  2. Is his code really that good?
  3. What would your team look like if he quit tomorrow?

In my experience the team prima donna soaks up an awful lot of other people’s time. I’ve spent way too much time cajoling, soothing, arguing with, and otherwise dealing with the team prima donna. Think about it this way – compared to other people on your team how much time do you spend dealing with the prima donna compared to others on your team? How much time do other team members spend dealing with the prima donna? If your experience is anything like mine, it is disproportionally much higher.

How much does the genius annoy, frustrate or simply piss off others on your team or people on other teams? How often have you had to sooth another team member and make excuses for the genius? Do others on your team avoid working with him? Do they walk on egg shells around him? Are they careful what they say to him in meetings? How about yourself? Are you happy to see the genius in your doorway? Or do you cringe when he walks in your door? Can you trust the prima donna talk to customers? Does the prima donna get his way because it is simply too costly and disruptive to argue with him?

Think about his code, is it really genius code? Or is it merely over designed and over implemented? Did that problem really require the use of C# expression trees? Or a hand rolled recursive decent parser? Did he really have to write his own debugger? Did he really have to write his own custom template based XML de-serializer? Really? I’ll bet if you went back and looked at his work you will find it to be over designed, difficult to debug, difficult to understand, fragile, and challenging to maintain for anyone but him. Very likely the problem could have been solved in a more simple manner.   Does he get his work done on time?  Or is everything always done right at the last second?

Think about the third question – what would your team look like if the prima donna quit tomorrow? Your first reaction is probably ‘Oh crap! We’re screwed!’. But think about it some more… would the quiet guy who is often overshadowed by the genius be able to shine? Would the frustration and friction levels on your team go down dramatically? Could that smart kid form the test team who really wants to be a developer now step up? Would you have more time to coach and mentor your other team members with him gone?

If your experience is like mine, then the prima donna is likely not as nearly as beneficial as you or others may think. Its likely that he is really quite disruptive and the technical value he brings to the team not really that super-awesome.

As manager, your job is to help the prima donna maximize his benefit to the team while minimizing or eliminating his disruptive behavior. You must help him understand that the high costs of having him on the team are only a little lower than the benefit he brings to the team. Help him see how much time he costs everyone else. For example, help him see that he cost the test team two weeks of regression testing by re-writing that big pile of code over the weekend and he forgot to re-write all the unit tests. In short, your job is to help him mature.

This isn’t easy. The team prima donna doesn’t take constructive criticism well. He is volatile, stubborn and will almost never agree with you. But you must try anyway because there is a chance you can help the team prima donna become a solid team member. That’s a great outcome.

Even if this doesn’t work, your efforts will benefit the rest of your team. They will see you as helping them by minimizing the prima donna’s disruptiveness. This can do wonders for team moral and the team’s trust in you.

The really hard part comes if the prima donna simply doesn’t come around. If this happens, you need to get the prima donna off the team – they are just not worth it. Disruptive people are death to an otherwise good team, even if they are a genius. While painful in the short run, both you and your team will really be much better off without the prima donna.



(1) I actually had a developer tell me this many years ago. It just took too much time to write comments.


Written by foredecker

June 12, 2011 at 8:55 am

6 Responses

Subscribe to comments with RSS.

  1. Obviously need to post anonymously here. In my interview I met one of the devs that seemed to suit these characteristics. I was worried about how I’d manage them, it turns out he’s my boss!


    July 29, 2011 at 2:30 pm

  2. I’d like to repost this Article on my website, and I would give you full credit and a link back to your blog. Would you be okay with that?


    March 24, 2012 at 5:01 am

  3. geniuses work better by thierselves!!, all by theirselves, that’s real genius. they are super gifted people you do not want to piss off!!!!;-).


    September 3, 2012 at 7:11 pm

  4. Not convinced about the “self-documenting” no-comments stab. My team rarely write comments (except for the really important “hey this is weird!” parts), and I don’t have a difficult time reading their code.

    Tim Harper

    May 17, 2014 at 4:12 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: