Most software development teams are actually software development groups. Don't be part of a group, be part of a team.
What does this mean? What's the difference?
A software development group is a group of people who happen to share the same general environment, but which act independently for their own concerns with their own motivations. For example, a group of people at the airport all want to get onto the same plane, and they each worry about their tickets and belongings. They help the plane leave on time because each of them wants to reach their destination. However, if one person's luggage can't fit, nobody else is concerned. If another person forgot important travel documents, the group will leave them and not be concerned.
This is contrast to a team, which all have the same goal and all need to accomplish that goal together. Each member of the team might have a role to play, but if a person is missing, others will step up to make sure the team accomplishes the goal. When a team member is missing, the team is sad but still goes on. When a team goes on a plane, they make sure all the equipment gets on the plane, because if any equipment is missing, the whole team suffers. If any team member misses their documents, another team member will step up and try to help find a solution. And most importantly, the team is ok if other members of the team are “sitting on the bench” or experiencing slack time, while others are actively engaged in a task.
How does this apply to me as a developer?
- Be a team member. Help the team focus on one goal at a time. Help limit the work in progress, so the goal of the team is accomplished and the team can be proud of their efforts.
- Encourage each member of the team to do their best and create safety for them to fail. Let them fail quickly so feedback is quick and progress can be made.
- Don't think of yourself as a person who is in a group which has a specific skill in a specific language or technology. Instead think of yourself as a member of a team trying to accomplish a specific task, and use your talents, both technical and general, to accomplish that task. Your specific technical skills will help you contribute to the task, but it should not limit the ways you assist the team. Maybe you'll sit this one out and help optimize the code for better readability or testability and performance. Maybe you'll find ways to automate some tedious process the team complains about. What is more important is that you solve team problems as a team member with unique abilities, and not as an individual who just happens to be co-located with another group of people who want to get to the same destination.