How do you learn to work in team?

Question

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?

Answer 1

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.

Answer 2

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.