Identify and deal with problematic teammates

Posted: June 15, 2013 in Seeds

Being part of a team could be cool and istructive, and I’m not referring only to software development. For example, I’ve played volleyball for 13 years, in 6 different teams and I’ve enjoyed a lot at playing with different people with different styles. Sometimes people forget that you can learn not only from the best players, but also from the worst ones.

From the best you can acquire tips and tricks, pills of experience, you can refine your technique, you can just mimic him (or at least try!). From the worst player you may understand how to deal with failures and recurrent errors. The worst player should be (I repeat, should be) the athlete who gives her best to improve herself. This desire to get better is instructive and, often, is not very apparent in high level players. Anyhow, each member of a team can learn and teach at the same time. I consider this thing very valuable.

Same concepts apply to work, for example in a team of software developers. Team is first about people and only after about software, volleyball or whatever you want. So a team of developers can be messed up by the same problems of a team of footballers. Generally these problems are some difficult people and situation. Here I’m trying to describe four types of problematic teammates, basing this classification on my experience and lots of discussions with other software developers.

These guys are initially welcomed into the team, but are capable of causing troubles when their shortcomings become apparent. And I’m not talking of technical skills, because those with insufficient technical skills are usually not hired (usually…). I’m talking about attitude, that is more difficult to treat.

Let’s start.

Rambo is the first type of problematic programmer. He is talented and everybody trusts and depends on him. If you can’t solve a problem Rambo is your guy. Rambo knows he is the best, he enjoys his position and sometimes (if the management is too weak) he also keeps the top-level manager in check. In fact, the top-level manager invested him of a special power. In the worst case, Rambo takes complete ownership of his code and tries not to let anyone else near it. He doesn’t trust anyone, so no one can touch his code. And often it happens that Rambo voluntarily write difficult code, so no one can (easily) understand it.

Another bad thing that can happen is when your team builds and evolves a product. Rambo can be assigned to make the new stuff, because he is the best and he knows how to do them fastly. Also clients trust him. This can lead also to jealousy inside the team.

Rambo has a high contractual power specially if the top-level manager relies heavily on him. It is useless to say which troubles the whole team may experience if Rambo quits, leaving a vast quantity of source code that is difficult to deal with. And what if he fails or he is sick? He is a bottleneck. The bad news is that Rambo is mostly a tricky management problem. Why tricky? Because it can happen that the team-leader cannot really “order” anything to Rambo, in fact he responds only to the top-manager.

The Prima Donna is another plague. He is the best and he knows it. If you criticize him, you’ll suffer his wrath! His idea is the best, he’s been a programmer since he was a child, his ideas are always excellent and his code is perfect ever. He’s not capable to take criticism. But unlike Rambo, he was not invested of a special power by the top-level manager so – from a management standpoint – the prima donna is a team-leader problem. The prima donna lacks interpersonal skills and he divides other teammates in two classes: those who are less skilled than he and threats. He generally criticizes who he perceives as a threat by insulting their intelligence and their skills.

Very likely, the prima donna is the biggest pain for a team. He can cause other skilled – but less arrogant – people to quit. Sometimes the prima donna forms an alliance with Rambo (or at least he tries). And if he succeds the things will become even worse.

The parasite is the factotum but the master of none. He knows all about the system (the product), so he is one of the most important “historical mind” of the team. Database, GUI, core, … he has worked on every aspect of the system so when you have problems on old (and very used) features then he is your man. Sometimes he just wants to preserve his job so he is not interested to innovate the system with new technologies, that – from his point of view – are something new to learn or, even worse, something that new programmers can learn easily.

The parasite is the most useful of the negative developer types and, sometimes, can be viewed as positive. He is not a menace for the team, indeed, in some cases he is the developer that is worth preserving. The good news is that the team-leader can easily make people working with him so his know-how flows in the team.

The coward programmer is the typical computer geek. He is personality-deficient even if he is very capable. He tends to be very withdrawn and taking criticism is also difficult for him. In fact, he considers a critics like a reproach because his communication model is freezed at the age of 12. Due to his awe and introversion, it’s not unusual that he considers sending emails the best way of communicating.

The real problem is that he never really participates the team. He doesn’t propose his – often excellent – ideas. This lack of communication is painful and the company doesn’t get all the real value of this kind of programmer. A coward programmer is hard to deal with for the team-leader as well as for the top-level manager, because in the coward’s mind they are too high level to communicate peacefully with him. So, each teammate (seen like a “peer”) should help the coward to improve his communication skills, for example by integrating him a bit more in the job. Also pair-programming may help.

So I presented four kind of painful teammates. A thing that sometimes I stressed was about top-level management and team-leader. They are responsible to identify and deal with these people from a management standpoint. Obviously, if you are a teammate of Rambo or Prima Donna, you have to deal with them from a technical and often interpersonal point of view. Suggestions are hard to make. People are different and each character has subjective reaction.

If you have to work with a prima donna, the tip I’d give you is to never react to his critiques with another critique. Be professional, the battlefield of a prima donna is about provocations and technical religion. If you like Java and he hates Java, don’t try to convince him that Java can be used for a project. Rather, say “ok, you’re right, let’s talk about our job now”. And if it is impossible for you to work with him, talk to your team-leader.

As I wrote, sometimes Rambo leads to jealousy inside the team because he is assigned to new and cool stuff. If your company organizes meeting with the top-level manager (individual or group), tell you want to join new projects. Try to be pragmatic, convince him you have the required skills. This can be useless, but trying is better than nothing.

Parassites and coward programmers are generally harmless from an interpersonal standpoint. You could be in contrast with an “old” parassite who does not like innovation. Here, again, be pragmatic, make clear the benefits of the new stuff. But don’t claim to win every single battle!

And what if you identify yourself in one of this category?! Fuck you. No, I’m just joking 🙂 Well! Consider you could be a sort of problem for your teammates and for your company. And if you don’t care maybe other people do!

  1. Dan says:

    Really good post, only seeing it now. I’ve observed (and worked with) all of these types.

    There are others, such as:

    The Bully – kind of a mixture of Rambo & the Prima Donna – the guy who knows a lot and shouts a lot, and convinces not through technical excellence, but by sheer force. Actually as I write this, I realize it’s very similar to Rambo.

    The Negative Producer – the person who literally isn’t cut out for development. No sense of abstraction, no design sense, no programming books on the bookshelf, breaks the build once a month, ventures into undefined behavior in C or C++, etc. Really unqualified to write code, unwilling (and unable to learn), in the wrong profession. The group’s productivity would go up if this person would just stay home everyday and collect his salary.

    The OOPer – “everything is an object” kind of guy. Even algorithms are objects. Why are you using function pointers? Wrap it in an object! “If I can’t model it, I can’t implement it!” Frequently creates byzantine inheritance hierarchies, worships at the altar of UML.

    The Toolbox – sometimes accidentally writes some software for the product. Spends most of his time writing Perl & Python scripts to re-invent the wheel, or do some one-time task. Prefers to write tools and play with scripting languages than get his job done.

    The Excuser – never seems to make progress on his assignments, is always “hunting down issues” that he’s just discovered as part of his assignment. “Bill, how are you doing on adding network connectivity to that widget? Almost done?” “Didn’t make any progress this week on that, boss… but I’m really troubled by something I saw in the network stack that we’re planning on using, so right now I’m hunting down issues in the stack!!!” “You mean, the stack we’ve been using on 6 other products for years without problems? So you ‘re spending all your time noodling around in 3rd party code that we believe is solid, instead of getting your work done?” “Exactly.”

    There are many, many more…

    • Marco Arena says:

      Hi there! Thanks a lot for sharing! Have you a blog where I can read more?

      • Dan says:

        Hi Marco, unfortunately I don’t have a blog, just a lot of experience developing firmware for embedded systems (consultant). Mostly C and C++, close to the hardware.

        As a consultant, I have to deal with all of these strange personality types. The good news is that I always get to meet and work with smart people, so I am always learning.

        I just found your blog (either through Reddit or Hacker News I think?), looking forward to future posts!! Happy holidays.

        P.S. I bought Davide di Genarro’s book probably one year ago, I am still working through it, some of it isn’t easy for me!

  2. Marco Arena says:

    Consider opening one! The previous comment was spectacular! Imagine what you can do in an article 🙂

    I think someone shared my blog post on reddit (thanks for that whoever you are!)!

    Davide’s book is not easy but it’s very inspiring and instructive! I spent some months at reading it but it was worth! Definitely!

    I wish you a merry Christmas and a nice time! Thanks for reading.

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