In my career, I’ve seen many “teams” that mainly collaborate only when the work gets tough or if someone has been stuck for days. In these cases, teamwork is more of an exception than a regular practice. This approach is backward. Collaboration should be the standard way of working, and we should only choose to work independently for good reasons.
In the last article, I wrote about how outstanding software teams form without team-building through collaboration.
One significant advantage of collaboration is team building on the job, but that’s just the tip of the iceberg. Groups often make better decisions than individuals. They learn from each other, improve their communication skills, and are typically more effective at solving complex problems. Plus, working together allows for the sharing of knowledge.
When a team writes code together, they review it as they go, fixing any issues immediately. While writing the code, they discuss software design, acceptance criteria, testing, and formatting. This process isn’t just about creating code; it’s about building a common understanding of the code base, setting shared standards, agreeing on what ‘done’ means, and getting to know each other better.
A team that is collaborating needs the following much less:
- Asynchronous code reviews
- Definitions of Done
- Discussions on coding standards
- Daylies (see “Ways to Decrease Performance: Daily Standups”)
- Handovers when somebody leaves
- Extensive onboarding documentation for new joiners
- Lengthy planning and refinement sessions
- … I could continue.
The number of meetings some teams need to discuss their work so they can work asynchronously makes my head spin. We can avoid almost all of them just by working together more. More importantly, those meetings often assume that we can predict the future and answer all questions upfront. This, of course, is an illusion.
And here is another (maybe) surprising benefit of plenty of collaboration:
Asynchronous work and communication improve through synchronous collaboration.
Synchronous collaboration is tremendously helpful to get to know each other. This has the side-effect that asynchronous communication also improves.
When we understand someone well, we’re better at figuring out what they mean, even if their message isn’t clear. This understanding helps us feel more empathy, making us more likely to think they mean well. This makes our back-and-forth messages, even when not in real-time, smoother and more positive.
Synchronous collaboration, where we work together simultaneously on the same thing, is an excellent way to kick off work that will later be continued asynchronously. It’s important to realize that always working together simultaneously isn’t realistic. It can be tiring and doesn’t consider team members’ diverse needs and backgrounds. We might be spread across various time zones or have different personal schedules because of family commitments, appointments, or other reasons. And that’s perfectly fine!
How to collaborate in a team?
Starting to work collaboratively means a behavior shift for many people who used to work in isolation. Setting a WIP limit below the team size and the simple rule to ask first if one could join a collaboration before starting something new alone can help teams form a new habit.
Forming a strong team bond won’t be easy if people prefer working in isolation. Of course, they can find other ways to work around those limitations, but in my experience, they miss many opportunities and achieve less than their collaborating peers.
Talking about why someone doesn’t want to work closely with others can be helpful. Many times, the team can fix these issues. For instance, a colleague didn’t like pair programming because my IDE’s color scheme was difficult for them to see. We could solve this by changing the color scheme or using a tool like CodeWithMe (JetBrains), where everyone can choose their own colors, font type, and size. Also, some people might find working together easier if there’s someone to take notes and a system to make sure everyone gets a turn to speak without being interrupted.
Collaboration often requires a team to really concentrate as they think, talk, and solve problems together. This can be tiring. So, taking breaks is essential to keep it an enjoyable experience.
Mixing collaboration periods with quiet time for solo work can effectively get the best of both approaches. Collaborative efforts can initially feel overwhelming and draining, particularly for those new to teamwork. It’s usually better to start with a smaller amount of collaborative work and gradually increase it while enhancing the collaboration quality. Jumping straight into doing 80 or 90% collaborative work is less likely to be successful.
The team must reflect together on their collaboration: why it can be tiring and in what situations. By doing this, you’ll soon discover how to make working together more enjoyable, productive, and less draining.
Do we always need to work together?
As you can probably tell, I generally favor more collaboration. However, that doesn’t mean I believe in collaborating 100% of the time. I also need moments to think quietly, without sharing my thoughts, for someone else to understand constantly. Sometimes, I appreciate just being in silence or listening to ambient music while working on something alone.
It can be code, it can be documentation, it can be reading something, or it can be some exploration and mapping of the code base. Sometimes, I need time alone; sometimes, others do not have time to collaborate. And this is true for most people I know.
What I found very helpful are the following guiding principles:
- Before starting something new, collaborate on something still in progress.
- When starting something new, invite others to join.
- When someone is joining late, give them a brief introduction.
- When you work alone, share the context when you stop working so that others can continue.
- Set a WIP lower than the team size as a forcing function for collaboration.
All of the above does not mean you will collaborate 100% of the time, but you will collaborate unless you have a strong reason not to. Default-to-collaboration!
- Collaboration should be a team default, not just a response to tough situations.
- Benefits include improved decision-making, learning, communication, problem-solving, and knowledge sharing.
- Collaborative coding leads to immediate review and shared understanding.
- Mix collaboration with individual work for balance; not everyone needs to collaborate 100% of the time.
- To foster collaboration:
- Start with ongoing collaborative tasks before beginning new ones alone.
- Invite others to join new work.
- Provide brief introductions to late joiners.
- Share context when switching from solo to collaborative work.
- Set WIP limits to encourage teamwork.
- Embrace collaboration as the norm, but allow space for individual work when necessary.
What are your thoughts and experiences? I am looking forward to your comments!
Is collaboration one of your challenges?
Try my Engineering Excellence && Happiness Partnership; I am helping teams like yours become high-performing. Let’s work together and accelerate your journey.
Find out more about the partnership and schedule a call with me here.