Home > Opinion > People You Don’t Want On Your Team

People You Don’t Want On Your Team

Study after study has shown that the biggest causes of software project failure are over-optimistic scheduling and unstable requirements.  I think the only reason team dynamics isn’t in the #1 spot is that it’s hard for an outsider to judge after the fact. In my experience, though, how well people work together is a lot more important than how smart they are individually: everyone in the engineering group of the first start-up I joined was very good at their job, but when you put us together, our IQs somehow canceled out.

I put together the profiles below to jump-start discussion in undergraduate project teams about the many ways in which someone can not contribute. If you have more to add, feel free to use the comment box :-)

Anna knows more about every subject than everyone else on the team put together—at least, she thinks she does. No matter what you say, she’ll correct you; no matter what you know, she knows better. Annas are pretty easy to spot: if you keep track in team meetings of how often people interrupt one another, her score is usually higher than everyone else’s put together.

Bao is a contrarian: no matter what anyone says, he’ll take the opposite side. This is healthy in small doses, but when Bao does it, there’s always another objection lurking behind the first half dozen.

Caitlin has so little confidence in her own ability (despite her good grades) that she won’t make any decision, no matter how small, until she has checked with someone else. Everything has to be spelled out in detail for her so that there’s no possibility of her getting anything wrong.

Frank believes that knowledge is power. He enjoys knowing things that other people don’t—or to be more accurate, he enjoys it when people know he knows things they don’t. Frank can actually make things work, but when asked how he did it, he’ll grin and say, “Oh, I’m sure you can figure it out.”

Hediyeh is quiet. Very quiet. She never speaks up in meetings, even when she knows that what other people are saying is wrong. She might contribute to the mailing list, but she’s very sensitive to criticism, and will always back down rather than defending her point of view. Hediyeh isn’t a troublemaker, but rather a lost opportunity.

Kenny is a hitchhiker. He has discovered that most people would rather shoulder some extra work than snitch, and he takes advantage of it at every turn. The frustrating thing is that he’s so damn plausible when someone finally does confront him. “There have been mistakes on all sides,” he says, or, “Well, I think you’re nit-picking.” The only way to deal with Kenny is to stand up to him: remember, if he’s not doing his share, he’s the bad guy, not you.

Melissa would easily have made the varsity procrastination team if she’d bothered to show up to tryouts. She means well—she really does feel bad about letting people down—but somehow something always comes up, and her tasks are never finished until the last possible moment. Of course, that means that everyone who is depending on her can’t do their work until after the last possible moment…

Petra’s favorite phrase is “why don’t we”. Why don’t we write a GUI to help people edit the program’s configuration files? Hey, why don’t we invent our own little language for designing GUIs? Her energy and enthusiasm are hard to argue with, but argue you must. Otherwise, for every step you move forward, the project’s goalposts will recede by two. This is called feature creep, and has ruined many projects that might otherwise have delivered something small, but useful.

Raj is rude. “It’s just the way I talk,” he says, “If you can’t hack it, maybe you should find another team.” His favorite phrase is, “That’s stupid,” and he uses obscenity as casually as minor characters in Tarantino films. His only redeeming grace is that he can’t dissemble in front of the instructor as well as Kenny, so he’s easier to get rid of.

Sergei is simply incompetent. He doesn’t understand the problem, he hasn’t bothered to master the tools and libraries he’s supposed to be using, the code he checks in doesn’t compile, and his thirty-second bug fixes introduce more problems than they solve. If he means well, try to re-partition the work so that he’ll do less damage. If he doesn’t, he should be treated like any other hitchhiker.

Categories: Opinion Tags:
  1. June 18th, 2010 at 17:45 | #1

    This article gave me a real chuckle, but is actually fairly comprehensive in coverage of what my “not on my team” list would look like. I’d add Adrian, who isn’t accountable. Emails, voicemails, and all other forms of communication to him fall into a black hole – they never get answered, or even acknwoledged, frustrating the entire team because they can’t move their own work forward without his input, and they don’t even quite know why until weeks later when the trail is picked up again. When you manage to get Adrian face-to-face, he says things like “I’ll get on that right away.” Two weeks more pass before you realize that nothing has occurred.

  2. Terry Adams
    November 8th, 2010 at 02:38 | #2

    Greg,

    This is a big topic in Agile development and folks like Johanna Rothman and Ester Derby talk about this often in their talks and writings. Often managers think that everyone under them can be plugged and played on any team which is faulty thinking especially on development teams that are trying to build a team and not a working group.

    Recently, our little team started thinking about what build and holds a team together. Shared Values. Here is the start of our shared values:

    —————————————————————————————————–
    14 May 2010

    * Team Objectives Take Precedence Over Individual Objectives.
    * Team Members Who Are Aware Of Themselves, Who Listen And Learn, Who Value The Cohesiveness Of The Team.
    * Relationships Are Important. (It is not sufficient to develop technical competence or recruit star performers.)
    * Just As Eager To Learn As To Teach.
    * Open To New Ideas.
    * Good Communication.
    o Teams Talk. They Communicate. Everyone Has The Right And The Responsibility to Question and Encourage The Other Members.
    o Create A Safe Environment For Exploring Ideas and Sharpening Relationships.
    o Create Space To Hear Everybody.
    o Be More Eager To Listen Than To Speak.
    o Open Communication (though the Good and Hard Times) So We Can Move Forward …. Together.
    * No Five Stones[1].
    * Willingness To Improve On The Preceding Values.

    Shared Values also mean that we confront one another when we deviate from these values.

    Note: What is our Rope? What is the common thing that ties us together.

    [1] “When a team decision needs to be made the options are clarified and each team member has five votes – five rocks to vote toward the options. Normally when two options are on the table team members will vote their rocks 3-2 in favor of one option. If a person feels strongly about an option they may vote 4-1. It is rare that a person votes his rocks 5-0 since that implies no worth at all in the alternative. A 5-0 vote in our mind does not give the team credit. A 5-0 vote can skew the outcome. It gives too much weight to the individual. Team voting acknowledges that every option was proposed because it has value in someone’s mind.” – From Walter Wright.

    ——————————————————————————————————

  3. GregL
    March 11th, 2011 at 16:19 | #3

    Unfortunately more than one of those reminded me of people on my current team and past teams that I have worked on :(

  4. krosenvold
    March 11th, 2011 at 19:52 | #4

    Tarik – Amazingly smart guy who has more brains than the rest combined. Just out of school and talks about metaprogramming and creating new languages within. Creates classes named “And” and “Or”, and is totally lost in abstraction. Must always use big abstract ideas to solve even the most trivial of problems.

  5. Greg Wilson
    March 11th, 2011 at 20:27 | #5

    @Terry Adams Most people would agree with most of these; it’s how they actually act that I’m describing :-)

  1. June 19th, 2010 at 18:16 | #1
  2. June 20th, 2010 at 02:33 | #2