How do you learn to work in team? [duplicate]
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty{ margin-bottom:0;
}
up vote
-1
down vote
favorite
This question already has an answer here:
How can I deal with being told I ask too many questions?
17 answers
I often think that I should know something already. Sometimes I catch myself thinking that if somebody knows how to do something then he/she could do this by himself and when I ask for everything then it takes much more time.
I have also second voice in my mind which tells me that it is not waste of time, because the more people know something important for the company the better it is (because if somebody who has all the knowledge left the company then it would be disaster).
I am interested if that is the case of most of you have similar thoughts or I haven't learned how to work in teams yet. How work in teams should look like and what is your experience from working with younger co-workers? What you expect from them and what their role in team should be. Is there a good way to learn how to work in teams or I just have to be patient?
team teamwork team-role junior
New contributor
marked as duplicate by Dukeling, Jim G., gnat, IDrinkandIKnowThings, ChrisF 2 days ago
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
up vote
-1
down vote
favorite
This question already has an answer here:
How can I deal with being told I ask too many questions?
17 answers
I often think that I should know something already. Sometimes I catch myself thinking that if somebody knows how to do something then he/she could do this by himself and when I ask for everything then it takes much more time.
I have also second voice in my mind which tells me that it is not waste of time, because the more people know something important for the company the better it is (because if somebody who has all the knowledge left the company then it would be disaster).
I am interested if that is the case of most of you have similar thoughts or I haven't learned how to work in teams yet. How work in teams should look like and what is your experience from working with younger co-workers? What you expect from them and what their role in team should be. Is there a good way to learn how to work in teams or I just have to be patient?
team teamwork team-role junior
New contributor
marked as duplicate by Dukeling, Jim G., gnat, IDrinkandIKnowThings, ChrisF 2 days ago
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
Related: How to politely ask a coworker to “Google it”
– Dukeling
Nov 26 at 23:57
There's a lot more to working in a team than just knowing when and how to ask questions, but explaining all of that would probably unfortunately be too broad for this site.
– Dukeling
Nov 26 at 23:59
add a comment |
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
This question already has an answer here:
How can I deal with being told I ask too many questions?
17 answers
I often think that I should know something already. Sometimes I catch myself thinking that if somebody knows how to do something then he/she could do this by himself and when I ask for everything then it takes much more time.
I have also second voice in my mind which tells me that it is not waste of time, because the more people know something important for the company the better it is (because if somebody who has all the knowledge left the company then it would be disaster).
I am interested if that is the case of most of you have similar thoughts or I haven't learned how to work in teams yet. How work in teams should look like and what is your experience from working with younger co-workers? What you expect from them and what their role in team should be. Is there a good way to learn how to work in teams or I just have to be patient?
team teamwork team-role junior
New contributor
This question already has an answer here:
How can I deal with being told I ask too many questions?
17 answers
I often think that I should know something already. Sometimes I catch myself thinking that if somebody knows how to do something then he/she could do this by himself and when I ask for everything then it takes much more time.
I have also second voice in my mind which tells me that it is not waste of time, because the more people know something important for the company the better it is (because if somebody who has all the knowledge left the company then it would be disaster).
I am interested if that is the case of most of you have similar thoughts or I haven't learned how to work in teams yet. How work in teams should look like and what is your experience from working with younger co-workers? What you expect from them and what their role in team should be. Is there a good way to learn how to work in teams or I just have to be patient?
This question already has an answer here:
How can I deal with being told I ask too many questions?
17 answers
team teamwork team-role junior
team teamwork team-role junior
New contributor
New contributor
edited Nov 26 at 23:06
jcmack
6,55411036
6,55411036
New contributor
asked Nov 26 at 22:42
user5514633
11
11
New contributor
New contributor
marked as duplicate by Dukeling, Jim G., gnat, IDrinkandIKnowThings, ChrisF 2 days ago
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by Dukeling, Jim G., gnat, IDrinkandIKnowThings, ChrisF 2 days ago
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
Related: How to politely ask a coworker to “Google it”
– Dukeling
Nov 26 at 23:57
There's a lot more to working in a team than just knowing when and how to ask questions, but explaining all of that would probably unfortunately be too broad for this site.
– Dukeling
Nov 26 at 23:59
add a comment |
Related: How to politely ask a coworker to “Google it”
– Dukeling
Nov 26 at 23:57
There's a lot more to working in a team than just knowing when and how to ask questions, but explaining all of that would probably unfortunately be too broad for this site.
– Dukeling
Nov 26 at 23:59
Related: How to politely ask a coworker to “Google it”
– Dukeling
Nov 26 at 23:57
Related: How to politely ask a coworker to “Google it”
– Dukeling
Nov 26 at 23:57
There's a lot more to working in a team than just knowing when and how to ask questions, but explaining all of that would probably unfortunately be too broad for this site.
– Dukeling
Nov 26 at 23:59
There's a lot more to working in a team than just knowing when and how to ask questions, but explaining all of that would probably unfortunately be too broad for this site.
– Dukeling
Nov 26 at 23:59
add a comment |
2 Answers
2
active
oldest
votes
up vote
6
down vote
You learn just by doing it. There is no training manual.
As for asking questions - if you are a new starter, then you will have to ask questions. It will distract the person you are asking, but that is expected. It's a part of hiring new people.
Before you ask a question, try to work out the answer yourself. But don't waste time spending hours on it. Try to get the question into some meaningful form that the other person can actually help you with.
But beware of asking "X-Y problems". These come up occasionally on Stack Exchange. See XYProblem web site for an explanation.
add a comment |
up vote
1
down vote
I'm a technical lead for a small firm (10-12) employees. We often wear multiple "hats". One week I'm leading a small team (2-3 devs) on building some new module. The next, I'll be working on another platform supporting another lead. In our company, each leads manages a platform but often leads develop cross platform.
So, here's my basic "how to work in a group".
Respect the disciplines of a multi-disciplined team. Often different people are strong at different things, acknowledge and respect that.
Listen, understand, and repeat in your own understanding. When tasked with something, repeat what you've been told for clarification.
Work as hard as your team. Don't rely on other people to solve all your problems or accommodate your weaknesses. Always put your best foot forward.
Patience is a virtue and sometimes a time saver. Contrary to popular belief, expecting everyone to google everything is not always the ideal approach. Sometimes we have interns who are learning and while I appreciate they google things, if a task is tight on time and they have no clue, I expect them to ask me. This is about time and efficiency and applying my experience to their problem. Most juniors are very good and coding and sometimes not so good at understanding the problem. If time is tight, and I understand the problem, then I psuedocode the solution and send them on their way. It's the best way to stay on top of a deadline.
Respect other leaders. As a lead I end up working under other leads. I respect their decisions and I will follow the tasks that have been given me. Whether I know better is irrelevant, that lead is responsible for the platform, they are accountable to the platform. That's not to say to not bring up a better solution if you have one. But if the lead decides to stick with their implementation, trust that judgement and do your job.
Order is more important to the success of a project than perfection. In short, the code is not perfect, and never will be. But, if we stick together, work on it together and focus on completing the task, then we can release a solid product, nit picking about edge case inefficiencies or styling nitpicks isn't going to help us long term.
Communication is important. Talk to peers, talks to managers, tell people what your doing and how you intend to do it. Sometimes requirements change, sometimes scope changes and those things can get lost in the mix. Leaders are busy people, so taking the initiative to let them know what you're doing and giving them a sense of how it's going to get done, is important.
New contributor
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
You learn just by doing it. There is no training manual.
As for asking questions - if you are a new starter, then you will have to ask questions. It will distract the person you are asking, but that is expected. It's a part of hiring new people.
Before you ask a question, try to work out the answer yourself. But don't waste time spending hours on it. Try to get the question into some meaningful form that the other person can actually help you with.
But beware of asking "X-Y problems". These come up occasionally on Stack Exchange. See XYProblem web site for an explanation.
add a comment |
up vote
6
down vote
You learn just by doing it. There is no training manual.
As for asking questions - if you are a new starter, then you will have to ask questions. It will distract the person you are asking, but that is expected. It's a part of hiring new people.
Before you ask a question, try to work out the answer yourself. But don't waste time spending hours on it. Try to get the question into some meaningful form that the other person can actually help you with.
But beware of asking "X-Y problems". These come up occasionally on Stack Exchange. See XYProblem web site for an explanation.
add a comment |
up vote
6
down vote
up vote
6
down vote
You learn just by doing it. There is no training manual.
As for asking questions - if you are a new starter, then you will have to ask questions. It will distract the person you are asking, but that is expected. It's a part of hiring new people.
Before you ask a question, try to work out the answer yourself. But don't waste time spending hours on it. Try to get the question into some meaningful form that the other person can actually help you with.
But beware of asking "X-Y problems". These come up occasionally on Stack Exchange. See XYProblem web site for an explanation.
You learn just by doing it. There is no training manual.
As for asking questions - if you are a new starter, then you will have to ask questions. It will distract the person you are asking, but that is expected. It's a part of hiring new people.
Before you ask a question, try to work out the answer yourself. But don't waste time spending hours on it. Try to get the question into some meaningful form that the other person can actually help you with.
But beware of asking "X-Y problems". These come up occasionally on Stack Exchange. See XYProblem web site for an explanation.
answered Nov 26 at 23:23
Simon B
2,8412816
2,8412816
add a comment |
add a comment |
up vote
1
down vote
I'm a technical lead for a small firm (10-12) employees. We often wear multiple "hats". One week I'm leading a small team (2-3 devs) on building some new module. The next, I'll be working on another platform supporting another lead. In our company, each leads manages a platform but often leads develop cross platform.
So, here's my basic "how to work in a group".
Respect the disciplines of a multi-disciplined team. Often different people are strong at different things, acknowledge and respect that.
Listen, understand, and repeat in your own understanding. When tasked with something, repeat what you've been told for clarification.
Work as hard as your team. Don't rely on other people to solve all your problems or accommodate your weaknesses. Always put your best foot forward.
Patience is a virtue and sometimes a time saver. Contrary to popular belief, expecting everyone to google everything is not always the ideal approach. Sometimes we have interns who are learning and while I appreciate they google things, if a task is tight on time and they have no clue, I expect them to ask me. This is about time and efficiency and applying my experience to their problem. Most juniors are very good and coding and sometimes not so good at understanding the problem. If time is tight, and I understand the problem, then I psuedocode the solution and send them on their way. It's the best way to stay on top of a deadline.
Respect other leaders. As a lead I end up working under other leads. I respect their decisions and I will follow the tasks that have been given me. Whether I know better is irrelevant, that lead is responsible for the platform, they are accountable to the platform. That's not to say to not bring up a better solution if you have one. But if the lead decides to stick with their implementation, trust that judgement and do your job.
Order is more important to the success of a project than perfection. In short, the code is not perfect, and never will be. But, if we stick together, work on it together and focus on completing the task, then we can release a solid product, nit picking about edge case inefficiencies or styling nitpicks isn't going to help us long term.
Communication is important. Talk to peers, talks to managers, tell people what your doing and how you intend to do it. Sometimes requirements change, sometimes scope changes and those things can get lost in the mix. Leaders are busy people, so taking the initiative to let them know what you're doing and giving them a sense of how it's going to get done, is important.
New contributor
add a comment |
up vote
1
down vote
I'm a technical lead for a small firm (10-12) employees. We often wear multiple "hats". One week I'm leading a small team (2-3 devs) on building some new module. The next, I'll be working on another platform supporting another lead. In our company, each leads manages a platform but often leads develop cross platform.
So, here's my basic "how to work in a group".
Respect the disciplines of a multi-disciplined team. Often different people are strong at different things, acknowledge and respect that.
Listen, understand, and repeat in your own understanding. When tasked with something, repeat what you've been told for clarification.
Work as hard as your team. Don't rely on other people to solve all your problems or accommodate your weaknesses. Always put your best foot forward.
Patience is a virtue and sometimes a time saver. Contrary to popular belief, expecting everyone to google everything is not always the ideal approach. Sometimes we have interns who are learning and while I appreciate they google things, if a task is tight on time and they have no clue, I expect them to ask me. This is about time and efficiency and applying my experience to their problem. Most juniors are very good and coding and sometimes not so good at understanding the problem. If time is tight, and I understand the problem, then I psuedocode the solution and send them on their way. It's the best way to stay on top of a deadline.
Respect other leaders. As a lead I end up working under other leads. I respect their decisions and I will follow the tasks that have been given me. Whether I know better is irrelevant, that lead is responsible for the platform, they are accountable to the platform. That's not to say to not bring up a better solution if you have one. But if the lead decides to stick with their implementation, trust that judgement and do your job.
Order is more important to the success of a project than perfection. In short, the code is not perfect, and never will be. But, if we stick together, work on it together and focus on completing the task, then we can release a solid product, nit picking about edge case inefficiencies or styling nitpicks isn't going to help us long term.
Communication is important. Talk to peers, talks to managers, tell people what your doing and how you intend to do it. Sometimes requirements change, sometimes scope changes and those things can get lost in the mix. Leaders are busy people, so taking the initiative to let them know what you're doing and giving them a sense of how it's going to get done, is important.
New contributor
add a comment |
up vote
1
down vote
up vote
1
down vote
I'm a technical lead for a small firm (10-12) employees. We often wear multiple "hats". One week I'm leading a small team (2-3 devs) on building some new module. The next, I'll be working on another platform supporting another lead. In our company, each leads manages a platform but often leads develop cross platform.
So, here's my basic "how to work in a group".
Respect the disciplines of a multi-disciplined team. Often different people are strong at different things, acknowledge and respect that.
Listen, understand, and repeat in your own understanding. When tasked with something, repeat what you've been told for clarification.
Work as hard as your team. Don't rely on other people to solve all your problems or accommodate your weaknesses. Always put your best foot forward.
Patience is a virtue and sometimes a time saver. Contrary to popular belief, expecting everyone to google everything is not always the ideal approach. Sometimes we have interns who are learning and while I appreciate they google things, if a task is tight on time and they have no clue, I expect them to ask me. This is about time and efficiency and applying my experience to their problem. Most juniors are very good and coding and sometimes not so good at understanding the problem. If time is tight, and I understand the problem, then I psuedocode the solution and send them on their way. It's the best way to stay on top of a deadline.
Respect other leaders. As a lead I end up working under other leads. I respect their decisions and I will follow the tasks that have been given me. Whether I know better is irrelevant, that lead is responsible for the platform, they are accountable to the platform. That's not to say to not bring up a better solution if you have one. But if the lead decides to stick with their implementation, trust that judgement and do your job.
Order is more important to the success of a project than perfection. In short, the code is not perfect, and never will be. But, if we stick together, work on it together and focus on completing the task, then we can release a solid product, nit picking about edge case inefficiencies or styling nitpicks isn't going to help us long term.
Communication is important. Talk to peers, talks to managers, tell people what your doing and how you intend to do it. Sometimes requirements change, sometimes scope changes and those things can get lost in the mix. Leaders are busy people, so taking the initiative to let them know what you're doing and giving them a sense of how it's going to get done, is important.
New contributor
I'm a technical lead for a small firm (10-12) employees. We often wear multiple "hats". One week I'm leading a small team (2-3 devs) on building some new module. The next, I'll be working on another platform supporting another lead. In our company, each leads manages a platform but often leads develop cross platform.
So, here's my basic "how to work in a group".
Respect the disciplines of a multi-disciplined team. Often different people are strong at different things, acknowledge and respect that.
Listen, understand, and repeat in your own understanding. When tasked with something, repeat what you've been told for clarification.
Work as hard as your team. Don't rely on other people to solve all your problems or accommodate your weaknesses. Always put your best foot forward.
Patience is a virtue and sometimes a time saver. Contrary to popular belief, expecting everyone to google everything is not always the ideal approach. Sometimes we have interns who are learning and while I appreciate they google things, if a task is tight on time and they have no clue, I expect them to ask me. This is about time and efficiency and applying my experience to their problem. Most juniors are very good and coding and sometimes not so good at understanding the problem. If time is tight, and I understand the problem, then I psuedocode the solution and send them on their way. It's the best way to stay on top of a deadline.
Respect other leaders. As a lead I end up working under other leads. I respect their decisions and I will follow the tasks that have been given me. Whether I know better is irrelevant, that lead is responsible for the platform, they are accountable to the platform. That's not to say to not bring up a better solution if you have one. But if the lead decides to stick with their implementation, trust that judgement and do your job.
Order is more important to the success of a project than perfection. In short, the code is not perfect, and never will be. But, if we stick together, work on it together and focus on completing the task, then we can release a solid product, nit picking about edge case inefficiencies or styling nitpicks isn't going to help us long term.
Communication is important. Talk to peers, talks to managers, tell people what your doing and how you intend to do it. Sometimes requirements change, sometimes scope changes and those things can get lost in the mix. Leaders are busy people, so taking the initiative to let them know what you're doing and giving them a sense of how it's going to get done, is important.
New contributor
New contributor
answered Nov 27 at 15:27
ShinEmperor
64115
64115
New contributor
New contributor
add a comment |
add a comment |
Related: How to politely ask a coworker to “Google it”
– Dukeling
Nov 26 at 23:57
There's a lot more to working in a team than just knowing when and how to ask questions, but explaining all of that would probably unfortunately be too broad for this site.
– Dukeling
Nov 26 at 23:59