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
1













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?










share|improve this question









New contributor




user5514633 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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

















up vote
-1
down vote

favorite
1













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?










share|improve this question









New contributor




user5514633 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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













up vote
-1
down vote

favorite
1









up vote
-1
down vote

favorite
1






1






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?










share|improve this question









New contributor




user5514633 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












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






share|improve this question









New contributor




user5514633 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




user5514633 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited Nov 26 at 23:06









jcmack

6,55411036




6,55411036






New contributor




user5514633 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Nov 26 at 22:42









user5514633

11




11




New contributor




user5514633 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





user5514633 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






user5514633 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




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


















  • 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










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.






share|improve this answer




























    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.







    share|improve this answer








    New contributor




    ShinEmperor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.

























      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.






      share|improve this answer

























        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.






        share|improve this answer























          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.






          share|improve this answer












          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 26 at 23:23









          Simon B

          2,8412816




          2,8412816
























              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.







              share|improve this answer








              New contributor




              ShinEmperor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
              Check out our Code of Conduct.






















                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.







                share|improve this answer








                New contributor




                ShinEmperor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.




















                  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.







                  share|improve this answer








                  New contributor




                  ShinEmperor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  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.








                  share|improve this answer








                  New contributor




                  ShinEmperor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  share|improve this answer



                  share|improve this answer






                  New contributor




                  ShinEmperor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  answered Nov 27 at 15:27









                  ShinEmperor

                  64115




                  64115




                  New contributor




                  ShinEmperor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.





                  New contributor





                  ShinEmperor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.






                  ShinEmperor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.















                      Popular posts from this blog

                      QoS: MAC-Priority for clients behind a repeater

                      Ивакино (Тотемский район)

                      Can't locate Autom4te/ChannelDefs.pm in @INC (when it definitely is there)