Team Structures

As a software engineer you often don’t have much impact on the team structure and you just have to deal with what management decides is best. Management however often does not know the impact of team structures on the produced software. Splitting up people in teams will make this separation clear in the code as well simply due to the extra barrier communicating with other teams and code being developed in parallel without much knowledge of each other.

A number of factors that in my opinion affects productivity, quality and performance of your team are:

* Amount of teams
* Number of people in a team
* Skills of the people in the team
* Structure of a team

In this blog I will go over each of these topics and discuss them shortly.

The amount of teams, as mentioned in the introduction determines the layout and structure of the code. It can however also affect code duplication and communication overhead in case the responsibilities of each team are not clearly separated. Having multiple teams working on code that is highly coupled is a bad idea because they will constantly have to check with each other and discuss different things, doing this kind of work with multiple people is already hard enough but putting these people in different teams and thus more separated only makes it worse.

An easy solution may be to have just a bigger team instead of multiple small ones. But this doesn’t solve the problem either, and it usually even makes it worse. Because all people in the team will have to be kept up-to-date there is a huge overhead. Either you have formal code reviews by every person or something much lighter but people will have a much harder time to start working on code that hey haven’t touched for a couple of weeks or even months but has changed drastically. Their idea of how the code works is outdated and they need to familiarize themselves with the code each time they want to work on it.

The only solution is to have separate small teams with a clear separate responsibility such that a team does not need to know the details another team is doing. The same abstraction that you would have in your code should be applicable to your team organization as well.

Another deciding factor is the skills of the people in your team. Either you have a team with all people having the same skills, which works well as long as the only responsibility of the team is to do things related to those skills. A different approach is to have a team with complementary skills, which encourages people to take responsibility of a certain part of the work but will deteriorate the team communication because people don’t fully understand the work of another. Having such a team allows your team to be more agile, such that it can easily be changed from project to project as itself contains all the skills it needs. It is however critical that in such a team there should be no skill only one person possess, if this is the case catastrophe will strike sooner or later.

The structure of a team should be up to the team to decide, but again you often see management decided there must be a team lead that manages the team. This is an old concept and follows the strict hierarchical company design that has lived for many years now. The agile movement tries to break this concept and creates a team that can make its decisions instead of having a team lead to decide everything. I’m a big fan of such a structure as I often have ideas and want to share and discuss them with the rest of the team. Just like many other software engineers I’m quite intelligent and thus don’t just take orders to execute them without decent reason.

It is however required to have someone that will communicate with the rest of the company and management, whether this person should be a software engineer himself will depend on how much communication needs to be done. If meetings, presentation and other required work takes too much time it is best that the person only acts as a communication channel instead of doing software development himself as well. Forcing people in a structure where they can not express themselves leads to dissatisfied and frustrated people who either leave the company or don’t care about their work anymore. This of course must be avoided at all costs as it will deal a lot of damage to the company.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.