Building a software development team is no mean feat. When it comes to skilled developers, demand exceeds supply. But even if you do get hold of the best people, you as a team leader probably know that your work has just started. There are still things to consider, such as knowledge sharing within the team. Especially if there, for example, is active development in complex parts of the code. What happens if you then become (too) dependent on specific individuals? What are the risks?
The key is, of course, to be prepared. To identify your key personnel, and analyze what happens if one of them leaves. You need a team structure where knowledge isn’t isolated, but shared and distributed. Structure and processes are parts of the puzzle, but it is also about emotional aspects such as team spirit and atmosphere.
Know your team
New to the job, and just starting to get to know the people in your team? Social aspects aside (although they are very important too!), you probably feel the need to understand who does what. And as anywhere else in society, it is not always the person with the loudest voice that gets the most work done. Therefore, in addition to all the face-to-face interactions you have with your team, it may be a good idea to use a code health analysis tool. It makes even more sense if parts of your team is outsourced and you don’t meet and/or talk to them on a daily basis. As well as showing you where in the code base your team spends their time, the tool should give you information on who does what.
The tools derive that info from the version history system (e.g., GIT). For example, if one of your developers is responsible for over 90% of the work in a critical part of the code, the obvious conclusion is that this is a key person. And you can create a plan to ensure that your key developer’s knowledge is shared, thereby minimizing the damage if he/she leaves the team. Maybe you can even make simulations on what happens if that certain person no longer is part of the team?
The challenges of team size
Team size is another dimension to consider. So-called ‘knowledge islands’, where certain knowledge is isolated to individuals, may be present regardless. But in really small teams consisting of, say, three or four people they are hard to avoid. It may be impossible to both maintain delivery speed and prioritize knowledge distribution. Larger teams, on the other hand, may struggle with coordination issues. Let’s say multiple developers are working on code simultaneously. The code is unbranched separately. But what happens when everything is going back to the main branch? If the code is complex, the risk of things going wrong naturally increases.
Analyzing your team’s work can be challenging on several levels. So don’t forget the psychological aspects. People may act defensively if they feel monitored or questioned. That is only human and worth having in mind when presenting the results of an analysis - feedback can be tricky to both give and receive; especially if it is perceived as criticism. Again, getting ‘hard facts’ from a tool and an external party is a good way to secure that there are no doubts that the analysis is unbiased.
It is important to make sure everyone in the team is onboard and have understood that this is not about pointing fingers at anyone. Quite the opposite, it is about optimizing their daily work.
Want to learn more about how to create a sustainable process for software projects?
