How to structure software development team organization that will kickstart your business

Define the size of the team

It is easy to assume that the larger a team, the more productive it is, the better the software development team structure is, and the better results it is able to drive. However, large teams are often much less efficient than smaller ones. Larger teams often require additional communication channels, which in turn, can lead to increased communication and management overhead.

Create a perfect team-size-formula for different kinds of businesses, in our experience 4-7 members is as close to perfect as it gets.

Large businesses require larger teams. In this case, it is highly advisable to hire the needed number of developers and then divide them into two or more small cross-functional independent teams each led by a team lead. It is better to have two relatively independent teams of 5 developers rather than one large team of 10 team members.

Conclusion: In order to keep your team on the same page, make its size about 4-7 members. Remember, the more people that are on a team, the more communication channels you will have.

Choose the team type

While building your own software development team, one of the challenges that appears is whether to build a team of generalists, specialists or a hybrid team.

Generalists

A generalist is someone who possesses a wide range of knowledge and skills and is able to apply their competence across a vast range of areas within their expertise. Generalists can utilize a variety of different resources, perform different tasks, and often have stronger communication skills and the ability to quickly acquire new knowledge.ʼ

Hire a team of generalists (the term "generalist" usually refers to "full-stack developers" in the IT industry) if the product you are developing requires a variety of different skills to be completed successfully.

Specialists

In comparison, a specialist has a specific set of skills and techniques or a preferred single methodology. A specialist possesses a high level of expertise and the ability to use this methodology while solving complicated business problems in areas where greater attention is demanded.

While working with software development teams, it is better to assemble a team of specialists, who are focused on a particular part of development, namely database specialists - for a database, Automation QA Engineer - for the automation test suite, Manual QA - for manual testing, etc.

Hybrid

In a nutshell, it is a mix of both. This kind of team will focus specifically on areas where your project needs the most work and will handle additional tasks if the need arises.

So, what kind of team to choose? The answer depends on your business specialization and the project you’re working on. For software development teams, create a blend of specialists and generalists with a 3 to 1 or 75% to 25% ratio.

Takeaway: Hiring T-shaped employees is the best option. The long vertical line of the “T” indicates the general knowledge of the developers, while the horizontal line - the depth of their additional skills. For example, back-end developers, who write code on PHP (main expertise) can have a general understanding of JavaScript, databases (additional expertise). Such employees aren’t considered to be complete generalists who can do everything, but rather team members that are able to work with other specializations if necessary.

Document responsibilities

Define and document the roles of your software development team (developers are not the only role we are talking about) before you start recruiting. For example, if you work with Scrum, three roles exist: Development Team, Product Owner, and Scrum Master. It is reasonable to define specific roles inside of Development Teams: Architect, DevOps Engineer, Tech Lead, Tech Community Leader, whatever is most applicable to the engineering culture of your company. Additionally, here is a good interaction game to try with your software development team.

The aim of this game is to define the roles and responsibilities by answering the following questions:

• What are the roles of your software developers?
• What are 2-3 important goals they work on, or ways they help the team?
• What resources and/or support do they need that they aren't receiving?
• What's getting in their way?
• What are the roles of your software developers?
• What are 2-3 important goals they work on, or ways they help the team?
• What resources and/or support do they need that they aren't receiving?
• What's getting in their way?

By doing this exercise you will be able to define the contribution of each team member and learn what missing aspect hinders your success.

Choose your management style: Strict management vs. self-organization

Sure, you are not planning to provide your software development team with the full freedom of self-management immediately after meeting them, this option requires time and trust to be implemented. Apply strict management during the initial stage of team development, and self-organization—when the team has had experience working together. To make the best use of self-organization on your team, try to distribute control, and delegate the responsibilities among your team members.

As soon as your remote developers understand what it is like to work as a united team, the idea of self-organization management can be considered.

Be a good team lead

A product development leader should be a good communicator, able to set clear goals and requirements, and resolve conflicts. It’s also the responsibility of a project leader to make every developer understand what their role is and what is expected from them.

The stages of a software development team structure

Each software development team typically undergoes 5 stages of development:

Forming. This initial stage takes place when the team first meets. The team members are usually polite and friendly, there are no foreseeable conflicts. A team lead plays a crucial role at this stage since responsibilities are loosely defined and people barely know each other.

Storming, or a conflict period. This is when the excitement from the first meeting has evaporated. People start working together, reveal their weaknesses, the way they work, and different opinions about how things should be done. All these things can potentially cause conflicts within a team, and you, as a team lead, have to do something to rectify the situation and make the sky blue again. Try not to simply avoid conflicts, but recognize and resolve them, otherwise, the situation within a team gets worse and in the end you spend twice as much time trying to repair it.

Norming. During this stage, the team starts working as a single unit. The interaction between team members gets better, and fewer conflicts arise. Annoyance gives way to appreciation and mutual respect for knowledge and skills.

Performing. This is when your team becomes confident, motivated, and, attention please, self-organized! As a team lead, you can delegate a large amount of the work and spend more time focusing on how to make your team even better.

Adjourning, or the final stage is applicable to those teams that are not supposed to stay together further. All goals are accomplished, the project is completed and the team - disbanded. At this point, a good team lead must personally express gratitude and acknowledgments to each team member.

Starting is the hardest part. However, knowing what challenges you can expect during each stage and how to overcome them puts you one step closer to creating your self-organized dream team.

How to resolve conflicts when structuring your software development team organization?

A well-tried technique to help you resolve any conflict is to let each side communicate their point of view while you facilitate a compromise. However, even a compromise is not always the best solution, since both sides have to give up their point of view for a consensus to be reached. In order to achieve win-win results, follow the ‘5 WHYs” method. It is an interactive technique used to define the source of a problem by asking questions starting with "Why?".

How to use the “5 WHYs” method? Start with a problem and ask your team members why it happened. Ensure your answer is substantiated, then ask "why" again. Continue asking until you find the real root of the problem and the appropriate solution.

For example:

• Why did the customer complain he couldn’t use the particular feature of our application? - Because there was a bug in the latest release.
• Why there was a bug in a test release? - Because we didn’t test an application.
• Why didn’t we test an application?
• Why did the customer complain he couldn’t use the particular feature of our application? - Because there was a bug in the latest release.
• Why there was a bug in a test release? - Because we didn’t test an application.
• Why didn’t we test an application?

Use this technique every time team members have an issue or a disagreement about whose solution is best.