Who can be called a good team player?

Question

Many times you encounter something like "team-worker" or "enthusiast to work in a team" or stuff like that in employment ads which state that they want you to be or become a good member of a development team.

Who can be regarded as a good team member? Which qualities of a developer can be regarded as good points regarding to work in a team? Also how can a developer improve his/her teamwork skills (or attributes, if you will)?

Answer 1

IMHO:

1. Good team member is a person who is goal-oriented instead of self-oriented.
2. Qualities: thinking more about big picture rather than self-satisfaction. This is key point. All other qualities (like reliability, constructive communication,) inherits from this one
3. How to improve:

Try to qualify how have you interact with your team during the day, define good and bad points, pay attention to them during next meetings.

Place yourself on the other's roles, think how you can affect others work.

Try to use different techniques ( like Six Thinking Hats ) during "hard" conversations

Answer 2

Communication is key. A mindset that you're working on "our code" and not just "my modules" would be the second.
A breadth of experience that allows you to pull from someone else's work queue if your own is depleted. And vice versa, knowing when to ask for help from the team if you've hit a snag that might delay your own work queue. Adhering to local standards for coding and module design styles. Maintain a sense of the team's progress overall.

So as a general definition for all aspects of a work environment I propose: A good team member is someone who can think and react one layer above his own responsibilities.

Answer 3

In a recent job description, I said that I was looking for something similar. Here's what I mean:

1. You like working with others. This doesn't mean you have to be particularly extroverted. But if you don't like collaboration, we'll just make you crazy.
2. You have some social skills. As a fellow programmer, my standards aren't super high here; I'm pretty dorky myself. But you have to know something about how to play well with others.
3. You care about other people. Knowing how to get along with other people isn't enough. You have to care about how other people are doing, and what effect you have on them.
4. You're more interested in team achievement than personal achievement. Glory hounds, heroes, and cowboys can wreck a team. As in sports, good development teams win or lose together.
5. You can think independently. The best teams have people with varied backgrounds and the strength of character to maintain their own viewpoints and opinions.
6. You can compromise. Even though you think independently, you don't have to win every argument. If the rest of the team prefers a difference code indentation style and you can't persuade them otherwise, you can let it go.
7. You're generally happy. Eeyores, whiners, and mopers can suck the energy out of a team. You don't have to be a ray of sunshine every second, but you should be able to stay positive and enthusiastic most of the time.

That seems like the basics to me.

I should note that when some people say "teamwork" they mean people who will put up with unending bullshit because that's what someone in power finds convenient. Those people will say that somebody standing up for themselves (or for the customers) "isn't a team player". But when support goes just one way, that's not a team. Beware of that!

Answer 4

Who can be regarded as a good team member?

It's incredibly hard to determine exactly what a single individual needs to do in order to be a team player. There are some characteristics, but a person can be a total flop on one team, and a valuable asset to another. The study of topics such as social psychology, organizational behavior, management, and leadership all lead to an understanding of team dynamics. There's a huge wealth of knowledge in various research as to how to build and maintain teams.

I think that the team is the best judge of who would be best for that team. Every place I've ever interviewed, I've always interviewed with a number of members of the team. Perhaps not the entire team, but usually the team leader/manager, the team's technical lead, and at least one engineer, in addition to HR and the hiring manager.

The short answer would be that a good team member is someone who can fill the current needs of the team, technically and personally.

Which qualities of a developer can be regarded as good points regarding to work in a team?

It depends on the team and what the team needs. Different teams have different needs, so there's no singular answer here. Generally, a developer (or anyone on a team) should probably be high in the Big Five's agreeableness, conscientiousness, and extraversion traits. Flexibility, adaptability, and openness to new ideas and concepts would also help, regardless of your job and role on the team.

The specific knowledge and experience of the individual would probably be more useful in determining what capacity they can serve on the team.

Also how can a developer improve his/her team-working skills (or attributes, if you will)?

First, understanding your personal attributes would be a good start. I've seen the Big Five Personality Traits as well as Myers-Briggs Type Indicators used. Neither is that great - your current temporary state can have a drastic impact on the results. But taking various surveys over a period of time would probably help understand where you are now on a personal level, and then identifying traits that might be undesirable on a team and working toward correcting those traits. However, it's a long-term process that might not even be possible for everyone.

Second, it's also important to understand your technical knowledge. You need to know what you can bring in terms of functional roles to the team. This could be ability to work with requirements, system design and architecture, implementation using a specific language and/or framework, debugging and testing, and so on. Knowing what you like to do and what you are good at can help you advertise yourself to teams more effectively and know what roles you would be most suited for.

---

Team dynamics, like I mentioned above, is a huge area for research in a number of fields. Below is just a brief summary of what I can dig up quickly.

According to my organizational behavior textbook, team effectiveness can be determined based on four factors. These factors are context, composition, work design, and process. Your question seems to focus on the composition of the team, which is how the team should be staffed. The four components of team composition are abilities of team members, personalities, role allocation, diversity, team size, member flexibility, and member preferences.

A team needs a balance of three different skill types - technical, problem-solving/decision-making, and interpersonal. You want to make sure that your team has the appropriate balance of all of these. A team, on day one, doesn't need all of these. For example, you might not need technical skills until it's time to implement a solution. Depending on the type of problem(s) that the team is trying to solve or goals that the team is trying to reach, you'll need a different mix of these skill types.

In terms of individual personality traits, the Big Five Personality Traits are frequently used to identify people who have the greatest potential to be team players. Teams that are, across all of the members, high in extraversion, agreeableness, conscientiousness, openness to experience, and emotional stability tend to perform better. It's also been found that mixing a wide variance (for example, having some members who are extremely introverted and some who are extremely extraverted) across any of the traits tends to decrease performance. Some key traits that can affect the whole team are agreeableness, conscientiousness, and extraversion - a person who is extremely low on agreeableness, low on conscientiousness, or introverted can easily bring a team down.

Nine key roles in a team have been identified - linker (coordination, integration), creator (initiates ideas), promoter (champions ideas), assessor (analysis of options), organizer (creates structure), producer (direction and follow-through), controller (details, rules), maintainer (external battles), and adviser (information search). Some people fill multiple roles, and some people might fall into a single role. However, on a team, each of these roles is probably going to be filled by someone. It's a good idea when building or maintaining a team to make sure that there's someone who can step into each of these roles.

Enhancing diversity among members (in terms of personality, gender, age, educational, specializations, experience) leads to increasing the chances of providing the team with the skills and personalities that are needed to complete the job in an effective manner. This increase in diversity also increases the possibilities for conflict within the team as the members begin to go through the stages of group development. A group with less diversity will probably go through the stages quicker and with less conflict, but will also be less likely to have the needed team composition to do as good of a job.

The ideal team size has been identified to be between 7 and 9 people. This size range allows for the necessary diversity in personality and skills, but is a number small enough to enable communication and management. Effective coordination is important to get the job done, and 10 people is about the limit for effective coordination and communication between management and the group and within the group itself.

A team that is flexible, such that members can complete each others tasks, perform well. This reduced reliability on individuals. The members, at the start of the project, might not be cross-trained, but including people who are adaptable and open to training to develop new skills makes building a team easier. Flexibility allows a team to maintain performance over time.

Not everyone wants to work in a team. Some people prefer working individually, and forcing those people onto a team isn't the best option for the team. Having dissatisfied people on the team will hurt team morale and performance.

Answer 5

See if these things are TRUE in your case -- if yes, you're G.o.o.d

• I am friendly with my teammates and they are friendly with me
• I am friendly and generous with everybody, no matter how egoist, pompous, high maintenance one or more of my teammates are
• whenever I differ in opinion with my teammates, I successfully put my differences across so that no one is offended
• my boss is happy with me
• I always help my colleagues save face in front of my boss if they've done something wrong
• I help my teammates with their code related problems, and also successfully say NO when I am busy -- without disheartening them
• I don't get argumentative on petty issues with my colleagues or BOSS, and NEVER make it an issue of self-esteem or supremacy
• my teammates like my sense of humor

Answer 6

A good team worker is someone who is prepared to work on the project for the project. They are happy to not take the limelight and help others achieve they targets and objectives (as required) as they know that that in the long term will help benefit the company and team as a whole.

They don't go looking for praise, and they don't try and take credit for features that they weren't responsible for. They provide constructive criticism at all times.

Although they might not be the first person in mind when a manager is thinking of building the team, this is only because in the managers sub-concious mind they are already an integral part of the team.

They are honest and hardworking and are recognised not through the things they say or who they know, but through the things they do. A good team worker may often be overlooked by managers but with their peers they are held in the highest esteem.

Answer 7

Does the team get more done as a result of having you as a member?

1. Doing your part of the work.
2. Avoiding practices that hinder others from doing their work.
3. Don't say yes to everything. Voice your opinion if you disagree, but don't take up a disproportionate amount of time relative to your potential contribution.
4. Make sharing information with you and from you convenient and complete.
5. Give up on having everything your way. It's not going to happen.
6. Attract other developers to the team.

Good programmers always over-come constraints. Being on a team is no different.