Collaboration and Cooperation on Software Teams
November 19, 2023
Software teams need to work together to be successful. A team with no shared goals, bickering teammates, and no desire to build something together will fall apart quickly. No surprise there.
What might be a surprise is that teams can work together successfully in various ways. Some teams want to swarm and work together on every problem the team has, while other teams might tend to work alone and seek help from each other when it’s only deemed necessary. Other factors contribute, too, such as the team’s perspectives on communication styles or even the team’s domain itself.
But at the end of the day, a team can succeed in working together across most of these factors. Some styles might be better than others, but the real failure of a team is when they stop working together entirely.
Two big buckets to describe different types of effective teamwork are collaborative teamwork and cooperative teamwork. Many people consider these terms to mean the same thing. I, however, think they are different; pretty divergent, in fact.
In this post, I want to describe these ways of working on a team. I’ll touch on the pros and cons of each model and some of the reasons a team might select one over the other. Last, I’ll describe some ways to effectively work in each model to help you be a better teammate and boost your career.
Collaboration: Working Together to Reach a Common Goal
Collaboration is likely the first term you think of when it comes to teamwork. And rightfully so. Collaboration is often thought of as individuals working together towards the same goal.
In a collaborative team, members often work on the same problems and only work independently once an agreed-upon solution is identified. Collaborative teams often “gather, scatter, and repeat.” They gather together to work on the problem and then scatter to independently implement specific pieces of work toward that solution. They repeat this over and over as new issues emerge. In a collaborative and agile team, this process happens almost daily.
One pro of a collaborative team is the opportunity for knowledge sharing and often a better final solution. A well-oiled collaborative team will share insights as they work on a problem. They will be unafraid of respectful disagreement that pushes them towards deeper thinking and problem-solving. They will often work hard to identify who will work on what to achieve the shared common goal but also be willing to help each other with complex or challenging tasks.
Another advantage of collaborative teams is that they can often move quickly. Even when accounting for the cost of coordination (a disadvantage discussed below), a highly collaborative team can often swarm on a problem or project and deliver a solution. However, moving quickly requires the team to have enough slack to prioritize only one or two projects at a time.
Ironically, it is hard to truly be a collaborative team with more than a few priorities at once anyway. Too many items in progress will lead to more communication overhead, quickly removing slack for the team to execute the planned work. Instead, they will be in meetings talking about what to do more often than doing it. When this happens, team members will naturally begin working more independently and move towards a cooperation model.
The cons of a collaborative team are what we just mentioned: there is often overhead in the form of coordination and constant communication. The ideal solution needs to be defined, work tasks need to be written, etc. Even for teams that prefer mob programming or pair programming sessions, the team still needs to keep each other in the loop about what each team member is working on. In my experience, this overhead usually becomes negligible as the team moves toward the performing stage of the Tuckman model. On the best teams, this coordination and communication hardly becomes a concern as it fades into just “the way we work.”
Cooperation: Working Together to Help Each Other Reach Their Goals
Another way for teams to work together is via cooperation. While seemingly the same idea as collaboration, cooperation focuses on teams working together to accomplish individual goals rather than a shared goal.
An excellent example of the difference between these two ideas comes from the show Suits. In the show, we see how the individual goals of different lawyers push them to work together by helping each other when needed. But this help often comes with strings attached. Sometimes help looks more like trading favors or “I owe you”s.
While this might sound completely selfish (and there is some selfishness in the show!), there is an underlying belief: if we help each other accomplish our personal goals, the firm’s success (a mostly shared common goal) will follow suit.
Software teams can sometimes be organized similarly. The team might divide responsibility or projects among members. Each member is then responsible for completing and delivering their project. By and large, most of the work is done by that one team member with little interaction with the rest of the team.
But there are still moments when team members will need help. They might be stumped on a particularly tricky problem and need help. They might need to learn a lot of context from a teammate before beginning their work. Or perhaps they need a code review. Even when working toward individual goals, the success of those goals will require the cooperation of others.
Many developers might immediately read this idea and scoff. “How could that ever work?” One advantage of this model is that it allows for much more deep work than in a collaborative environment. When done correctly, coordination should be relatively small, meetings scarce, and freedom to focus is abundant. Sounds a lot like asynchronous remote work, doesn’t it?
Another potential pro of this strategy is that depending on the project and the individual assigned, some projects will be completed much faster than others. Short, isolated projects are especially likely to move faster in this model because the responsible team member can code, test, deploy, and deliver their work as quickly as they can type.
However, the cons of this model are that complex work can take longer. It is easier to effectively solve complex problems with practice in collaborating and communicating about them ahead of time. Weightlifters don’t start their career by bench pressing 700 lbs. They start with something much smaller and build up to higher weights. A team that has yet to practice collaborating on even simple issues will require more time to effectively collaborate and solve complex problems when required.
The other con of this model is the lack of shared knowledge. At first, this disadvantage might not seem that big of a deal. But consider things like on-call rotations, outages, or when someone leaves the team. If large projects are done in isolation with minimal sharing, how can a team properly support the resulting systems without the owner of the project present? In short, it’s a large risk to maintainability.
Operating in Each
Knowing the pros and cons of each approach is helpful, but the real value comes in learning how to operate within these approaches. Once you know how to do this, you can excel and quickly become a more valuable team member.
Now, I can’t go through an exhaustive list of every behavior you should aim to have for each approach. That would take too much writing, and I’d still likely miss a few. Instead, I’ll touch on some of the top ones for this discussion.
Collaboration
When you work within a highly collaborative team, one of the best things you can do is contribute. How can you contribute a new idea or an alternative solution? Can you provide a prototype of something you think would help your codebase? Can you provide evidence to back up (or refute) a leading idea for a solution?
Focusing on contributing within a collaborative team is more important than, say, writing extremely incredible code or producing extensive technical design documentation. Are those things important? Absolutely.
But for a highly collaborative team, you want to be seen as being involved and pushing the entire team along toward common goals. If you can help navigate your team through a complicated architecture problem or help your team finish the last bit of work to complete a project (no matter how small or tedious), you’ll be seen as part of the team.
Another critical strategy for a collaborative team is to make sure to invite feedback from your team. From code to docs to process, asking your team for feedback on your work items is an excellent way to learn and share knowledge within your team.
Cooperation
A cooperation-focused team will require a few different tactics toward teamwork than a collaborative one. Being effective on such a team focuses on two components of communication: being clear and being succinct.
This focus is essential because the communication between a cooperative team is going to have a few interesting properties. First, the communication is likely going to be infrequent (or at least less frequent than a collaborative one). You won’t get multiple opportunities to reclarify points or tease out a nuanced idea. You need to be really clear and really succulent to get your point across quickly and effectively.
Secondly, it is likely that when a request for help or feedback is sent, it is urgent and important. Not only will you need to be available to help, but you will need to be clear about how you can help and be brief in articulating your perspectives and what you can do. It won’t help your team members if you spend a whole day reviewing their pull request if the author is looking for a quick gut check on their strategy. I’m not saying to shy away from offering critiques, but be aware of the context.
The flip side of this is also true: when you ask for help on a cooperative team, be sure to be clear and brief about what you need and why. If you are asking the team to review a doc, highlight the most important sections and give your team a date by which you would like reviews to be done. It might sound like you are asking a lot, but it helps set the stage with clear expectations about what you are asking of them.
If you’ve read my blog before, I’m a fan of the more collaborative style of working.
And yet, as I grow in my career, I see more and more the merits of different ways of working. I’m learning that a cooperative team can also be a great software team too. You might need to adjust how you work in such a time if you do, however.
But at the end of the day, the core takeaway is that working together on a team is (IMO) still a better way of working than working alone. Be willing to ask for help and help each other. Offer ideas and consider the ideas of others, even ideas around working style.
It’s hard to beat a team that does those things consistently.
Happy coding!
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.