14

I have worked in environments where I was either an individual contributor or a lone techie without much need for team effort.

As I go further in my career, I find it necessary to branch out to positions which have more structured teams and need a significant amount of team effort. I also believe that this is a vital career development effort a person can put forth to happen upon better opportunities.

Neither is this a question about how to become a team-lead nor am I looking to find out how to acquire leadership skills. I am interested in learning how to become a team contributor, what ways one can become more involved, and how to become an effective participant in team efforts.

11

Lots of things to say here. First and probably the most important if you have been working on your own, your ideas are not the only good ones.

Further, rarely in a career do you join a team that is starting to build something new from scatch with no decisions made prior to your arrival. Expect that there will be decisons made about tools, architecture, techniques, standards that you don't agree with. Sometimes these descisions were made years earlier and are not subject to change as too much code would have to change to do so.

The person new to the team must first establish a reputation as someone who can accomplish things before trying to change the team or the way they do business. Until you have the respect of your peers and supervisors, you cannot effectively manage change. So when you first join a team, learn what they do and how they do it and establish yourself as a team player and valuable employee before trying to make people do things the way you want to.

I bring this up because usually this is the first issue people face when starting to work as a team, the loss of total control over what tools they use, how the software is architected and how to write code.

For instance if the team has a coding standard (which may or may not be formally written (but is generally apparent from the existing code when it is is informal), then follow it even if you don't like it. These standards make it easier for people to understand code they didn't write, so follow them. Insisting on doing this sort of stuff your way is the fast track to people not wanting to work with you.

Be aware that the time to argue for a change or a diffeernt way of doing things is before the decision has been made. You will get your chance later, have some patience at first.

Now how to get that respect and become a team player. First, do the tasks you are assigned to do and do them on time as much as possible and as well as the enviroment will allow you to. If you have meetings where software decisions are discussed (A planning meeting for a new project for instance), speak up with your ideas, but also listen respectfully to the ideas of others.

Talk to your team mates. Remeber that they may not have seen your resume and thus don't know what experience you have that might be valuable to them, so if you have expertise in something that is clearly on the horizon and someone else is stumped, offer some advice. But do it carefully, don't come off as a know-it-all.

Compliments to others can go a long way towards them accepting you as a part of the team. But make them genuine, people can spot a phony compliment a mile away.

Offer to do some of the tasks that are unpopular.

Learn where everything is and how to do most common tasks. Become the go-to person for domain knowledge or even how to submit a help desk request.

Take on the hard tasks if you feel you have the programming chops to do them, but don't be surprised if you have to prove yourself on easier things first before being allowed to do the harder more interesting things.

Be aware that you are now responsible for more than yourself. If you are having a problem and need help, ask for it. Don't let the team down by hiding problems or by pretending you are going to meet a deadline that you have no chance of making. If your delay will cause a delay for someone else, make sure they know well in advance. I can remember a project where we were all supposed to use something that one person was going to develop. He didn't ask questions of anyone else, he didn't let us know how he was getting along in the task and he didn't get it done which affected about 20 other things and made a lot of people certain to never recommend him or want towork with him in the future.

Treat people with respect, even those you personally do not like. To get respect, you have to give respect.

Learn the fine art of compromise. You can only get some of what you want by giving others some of what they want.

Have a positive, can-do attitude. And then translate that can-do into did-do. Nothing makes you a more valuable team memeber than the rest of the team knowing you will deliver.

Don't be defensive in code reviews (if other people will have to maintain your code and they will in a team, then they have a right to ask questions and try to make your code something they can understand) and don't be personally attacking when you do them for other people. Keep things professional.

4

From my experience:

  • Feedback is alaways good. Ask other members of your team how can you help, request opinions and criticism etc... Be prepared for harsh comments that might happen; eventually you will learn to ignore or to make something positive out of them.

  • The reverse is also true: give feedback. Encourage people to come to you and talk about their issues. Get everybody to be a voice and participate in decisions. Always try and find something positive about someone's work, then use this as an starting point on how his/her work can be improved.

  • Always be honest and open with issues, but without pointing fingers or being condescending. Also, do not argue for the sake of it.

  • Do not be afraid to speak up if someone is doing something wrong, time-wasting, hurtful (i.e. off-color humour, misbehaviour towards other people etc..) or harmful.

  • Be patient, understanding and tolerant - develop those skills, not only for team work, they're useful for pretty much everywhere.

2

From, "The Fast Forward MBA in Project Management," it provides a great list of essential qualities of being a team player:

  • Listen actively.
  • Ask questions.
  • Give constructive feedback. Don't express an opinion as a fact explain your reasons.
    • Awareness of body language and tone.
    • Appropriate humor.
    • Develop rapport with your team members.
    • Patience.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.