Four ways to improve collaboration in your team

Most of us developers, despite being more or less aware of the benefits of doing more work together, work on our own most of the time. Why? What can we do about it? Let's dive into it!

Short answer: no, it’s not. As software developers we don’t just write code, we also play a crucial role in actively shaping, challenging and clarifying requirements. And this happens in many different flavours: emails, issue tracking systems, chat tools, team meetings, inter-team meetings... Every area of our work can benefit if we approach it in a more collaborative way.

What is the greatest hesitance when thinking about working more with other colleagues? Well, for some folks it may feel cumbersome in terms of time consumption and efficiency. But if we dig deeper, we will probably find out that this hesitance has a lot to do with the well-known impostor syndrome. Often times we might feel like we are not good enough. The need to ask for help, the idea of someone watching you work and seeing the uncertainty with which you approach problems, the risk of revealing your lack of knowledge in some areas... This is frightening for most of us. Literally “stage fright”.

These fears are common in developers regardless of their degree of expertise. But they shouldn't stop us from learning from each other. In fact, we are learning all the time, and the more we interact with others, the more we learn. I have the same fears, but I decided to open myself more to collaborative work for three main reasons:

• I was not happy with the amount and quality of collaborative work in my teams

• I realized that these fears are mostly based on prejudices

• Every time I was approaching work in a more collaborative way, even though it felt unnatural, it showed to be quite powerful

Don't get me wrong, I am not talking about overdoing it, but about finding the balance, the sweet spot where collaborative work produces a positive impact in our working life. In order for that to happen, it is crucial to accumulate experiences and get a feeling of which collaboration paradigm is better to apply for each use case. Daily meeting? Knowledge sharing session? Second opinion? Think of a toolbox for team collaboration, this is exactly what is offered to you. Every person, every situation, every topic is different. That's what makes this journey exciting and why you want to have a variety of options and adapt each time.

In this section, I will present you four fantastic, experience-proved ways to foster collaboration in your team. As you will realize, the common factors of any kind of collaborative work are: clear goals, preparation, focus, continuous challenge of yourself and each other’s thoughts, and a constructive attitude.

Don't limit yourself to this list, but use it also as inspiration to find your own ways!

When you start working on a task, sometimes it feels intimidating. If you are lacking knowledge and you can find resources on the Internet, that’s the way to go. But if the overwhelming complexity lies in project specifics, or you just have a colleague who is really proficient in that area, the best you can do is to ask for a short meeting. 15 to 30 minutes should suffice, keep it short and don’t enter into too many details. Depending on the situation, this session is either about your colleague sharing their knowledge with you or you both trying to figure out how to tackle the task. In addition, if you both agree and the schedule allows it, you might decide to have an ad-hoc session of pair programming.

I have to admit, most of the time I am shy to ask for these sessions. But after having one of them I always feel amazed about how helpful it was and how much progress we did, and I always regret not doing it more often. Do not hesitate, ask for those sessions.

Another very handy chance is to ask for a second opinion about the piece of work you have done on your own. Essentially the same as the previous one, it just happens when there has already been progress in the task, and therefore the discussion revolves around the solution. Imagine you have implemented the code of a new feature, but you are not happy with the solution you are providing so far and don't know how you could do it differently. Or you have done it in a certain way but the rework you have in mind involves a lot of changes. You might end up doing all that rework, creating a Pull Request and eventually deciding with the team that the initial solution was actually a better option, which is a very unproductive approach. We all have done that. How can we do better?

Kindly ask one of your team colleagues to have a session on that. Here you can discuss with your colleague the solution you have provided and the challenges you are facing, or you can even go a step further and do a pair programming session. Almost every time I do this, I end up asking myself why I spent X hours on my own, when talking 15-30 minutes with a colleague made the landscape so much clearer.

This was already mentioned as a great way to start working on a task. But knowledge sharing is much broader than just that.

Many times we are lacking knowledge in some project areas. This happens often and for various reasons like an extensive codebase, vacations, a high project throughput delivered by a (probably) too large team, which doesn’t allow to keep up with all the changes, etc. Of course you can figure things out out by yourself, this is hands down the best solution for small or simple parts. But in many cases, asking a colleague with knowledge on that is a great idea. You will understand everything much better, you will need less time, and will greatly contribute to a much better solution. The following are some examples of excellent opportunities to play the knowledge sharing card:

• There are many parts involved and you are struggling to figure out how everything works together

• The quality of the code makes it really difficult to understand it (try to avoid having bad quality code in your project at all costs)

• A concrete part of the codebase (a library, a big feature, etc.) is just new to you and you simply don't know what is going on

• You are about to review a Pull Request and you are not familiar with that part of the code

Keep in mind to open those sessions to other colleagues who might be interested in grabbing the same knowledge. Your team will get even more out of the session in that way, since the knowledge will spread to a longer audience. But don't overdo it.

How does this additionally improve the team's strength and flexibility? A lot. Imagine a team fellow who has acquired a much higher amount of knowledge in one area and is the only go-to person when a meeting with stakeholders is needed, or when someone needs to take care of a related issue or bug. That does not help your team. This person will eventually be absent for any reason, like being on vacation or leaving the company. He might someday be overloaded with too much work, or working too long on the same area and silently hating that no one is also taking ownership on that part. Knowledge sharing sessions are the cure for unhealthy team dependency.

You are working in a team which is part of a bigger ecosystem. From time to time, there are meetings to discuss and clarify important topics, and it is really difficult to get a second chance for follow-up meetings in the near future. So you want to make sure that you and your team are fully prepared for that meeting, and get the most out of it. After all, probably you have been trying to clarify the issues via written communication for weeks or months, and the call for this meeting is probably the result of piled frustration. Many times, we don’t realise how relevant such meetings are. We just don’t prepare, or do not coordinate preparation efforts with other team members. There is no proper agenda here, there is no structured sequence to present the issues in the meeting. This significantly lowers the chances to have a productive meeting, leading to wasting the time of everyone attending, to not reaching any meaningful improvement and to more frustration and a feeling of powerlessness.

Phew, that’s really bad. What can we do? Nominate 2 (max. 3) team members to attend the meeting and have a preparation meeting to prioritise the topics that need to be discussed, to define what is the right information to provide and the right questions to ask for each of the topics, and to update the meeting agenda if necessary. Consider always the time available for the actual meeting while preparing, since this influences the amount of items you can clarify and how deep you can discuss them.

I hope after reading this article you feel inspired and empowered to improve some work practices that are not working quite well in your team at this time.

Your initial reaction to working in a more collaborative way might be rejection, since it can be unpleasant to do something that exposes yourself to others, mostly if you are not used to doing so in a working environment. But there are so many positive consequences, that I firmly believe we should conquer those hesitances. You will be working as part of a team that communicates well, a team that is flexible and strong to overcome any challenge it will face, a team where every one grows and takes ownership, and definitely a team where everyone is engaged and happy. And the cherry on the cake is that you will deliver a much better product. Isn't that fantastic? 🎉

It is in your hands, start doing more collaborative work today, get out of your silo, you will be amazed.