DEV Community

loading...
Cover image for Why we work in teams

Why we work in teams

aismagulov profile image Arsen ・3 min read

Throughout my career, I worked in different team and environments; some were better; others were worse. Some teams were supportive, collaborating and productive; others felt alienated, too competitive and too slow at the same time.

In the last few years, I got interested in the topic of teamwork and collaboration. What makes the team a good team? How can we affect it? Every team and every person are individual, but are there founding principles of effective collaboration? These are questions I am researching.

But first, why do we even work in teams? Everyone is so used to work in teams that it feels like something by default. But to optimize, we need to formulate first why working in teams is preferable. Here are my observations:

Parallelization

A group of developers delivers a task faster than a single developer. Of course, there are many "ifs", there are limits to the size of the group, but there is a truth to it in general. There is a certain gain with growing the number of people - not linear, but at least logarithmic.

Cross-functionality

A group of people with varied skills can deliver a more complex product. There is a lot to know in software development, and it is impossible to know everything. So we choose specializations - servers, clients, databases, machine learning. Four people with deep knowledge in different areas can do more than one person who knows a little bit of everything.

Two heads are better than one

We all have our career paths; we go through unique experiences that make us better developers over time. We learn practices and techniques from colleagues and books, and then we meet in one team. The team's combined experience is more extensive than each personal view. Discussing the ideas, approaches, and practices allows us to choose the best way for a particular case.

Bus factor, sharing tacit knowledge

Developers come and go. Every developer who is leaving a company takes away her share of knowledge. There is a lot of tacit knowledge in software development - tricks, hacks, weird use cases, that appear here and there in the codebase. Tacit knowledge is something you forgot that you know. It is hard to share such things when you work alone. But when you work together every day, there is a much larger chance that tacit knowledge gets distributed. A team forms a shared "knowledge cloud" that exists in everyone's head. When one person leaves, the knowledge is mainly preserved.

"Management"

Ten to fifteen years ago, companies were obsessed with "individual performance", "lazy employees", "motivation", carrots and sticks. Since one person cannot hand out carrots and sticks to fifty people, five managers would be in charge of ten people each. These groups would be called "teams". Luckily, these times are going away. Nowadays, management work is shifting towards personal development and goal-setting.

So, these are the reasons that I keep in mind when thinking of team efficiency. We have a good team if we:

  • have the necessary knowledge and skills;
  • deliver what we are tasked to do;
  • do it in the best possible way.

But how to make it a great team? I will keep writing about my discoveries, but I invite you to share your thoughts.

Alt Text

"Bodie, Doyle, Tiger, the Jewelry Man!" (from "IT Crowd" TV show)

Cover photo by Richard Lee on Unsplash

Discussion (0)

Forem Open with the Forem app