Mixing
How can I become a team person?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
14
down vote
favorite
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.
career-development team
edited Aug 2 '12 at 19:03
yoozer8
4,10442955
asked Apr 11 '12 at 16:44
Animesh
335816
add a comment |Â
up vote
14
down vote
favorite
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.
career-development team
edited Aug 2 '12 at 19:03
yoozer8
4,10442955
asked Apr 11 '12 at 16:44
Animesh
335816
add a comment |Â
up vote
14
down vote
favorite
up vote
14
down vote
favorite
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.
career-development team
edited Aug 2 '12 at 19:03
yoozer8
4,10442955
asked Apr 11 '12 at 16:44
Animesh
335816
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.
career-development team
edited Aug 2 '12 at 19:03
yoozer8
4,10442955
asked Apr 11 '12 at 16:44
Animesh
335816
edited Aug 2 '12 at 19:03
yoozer8
4,10442955
edited Aug 2 '12 at 19:03
yoozer8
4,10442955
edited Aug 2 '12 at 19:03
yoozer8
4,10442955
4,10442955
asked Apr 11 '12 at 16:44
Animesh
335816
asked Apr 11 '12 at 16:44
Animesh
335816
asked Apr 11 '12 at 16:44
Animesh
335816
335816
add a comment |Â
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
11
down vote
accepted
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.
answered Apr 11 '12 at 17:26
HLGEM
133k25227489
add a comment |Â
up vote
4
down vote
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.
answered Apr 11 '12 at 16:59
Renan
22125
add a comment |Â
up vote
2
down vote
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.
answered Apr 11 '12 at 17:06
chrisjlee
85211324
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
11
down vote
accepted
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.
answered Apr 11 '12 at 17:26
HLGEM
133k25227489
add a comment |Â
up vote
11
down vote
accepted
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.
answered Apr 11 '12 at 17:26
HLGEM
133k25227489
add a comment |Â
up vote
11
down vote
accepted
up vote
11
down vote
accepted
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.
answered Apr 11 '12 at 17:26
HLGEM
133k25227489
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.
answered Apr 11 '12 at 17:26
HLGEM
133k25227489
answered Apr 11 '12 at 17:26
HLGEM
133k25227489
answered Apr 11 '12 at 17:26
HLGEM
133k25227489
answered Apr 11 '12 at 17:26
HLGEM
133k25227489
133k25227489
add a comment |Â
add a comment |Â
up vote
4
down vote
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.
answered Apr 11 '12 at 16:59
Renan
22125
add a comment |Â
up vote
4
down vote
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.
answered Apr 11 '12 at 16:59
Renan
22125
add a comment |Â
up vote
4
down vote
up vote
4
down vote
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.
answered Apr 11 '12 at 16:59
Renan
22125
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.
answered Apr 11 '12 at 16:59
Renan
22125
edited Apr 11 '12 at 17:08
answered Apr 11 '12 at 16:59
Renan
22125
answered Apr 11 '12 at 16:59
Renan
22125
answered Apr 11 '12 at 16:59
Renan
22125
22125
add a comment |Â
add a comment |Â
up vote
2
down vote
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.
answered Apr 11 '12 at 17:06
chrisjlee
85211324
add a comment |Â
up vote
2
down vote
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.
answered Apr 11 '12 at 17:06
chrisjlee
85211324
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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.
answered Apr 11 '12 at 17:06
chrisjlee
85211324
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.
answered Apr 11 '12 at 17:06
chrisjlee
85211324
answered Apr 11 '12 at 17:06
chrisjlee
85211324
answered Apr 11 '12 at 17:06
chrisjlee
85211324
answered Apr 11 '12 at 17:06
chrisjlee
85211324
85211324
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f391%2fhow-can-i-become-a-team-person%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
