How to Structure a Development Team

A development team’s structure plays a significant role in a project’s success. Surely, other factors like developers’ expertise, experience, and talent are extremely important. Yet, proper management and teams’ structure allow profiting from these factors as well as making the whole development process easier and faster.

The generalist approach has the following pros and cons:

Taking that into account, the “one team for all” approach might be more suitable for you if you might feel like it’ll be easier to supervise the team when they’ll all be working together, etc. Plus, it’s more common for companies with up to 10-15 employees to use such an approach.

We at Stormotion use this approach in 80% of cases since our goal is to help our talents become true professionals in as many fields as possible so they can use this extensive knowledge to build even more complex projects every single time. Yet, when there are more than 15 people working on the same project, it might not be convenient.

Specialist Structure

This arrangement approach means that each team member is an expert in a certain programming language, framework, or technology, and thus, fully responsible for their part of development. You can create teams with their own hierarchy and structure to complete one part of the project. It all depends on the scope of work.

As for the advantages and disadvantages of the specialist approach, here they are:

Such an approach is normally used by companies with over 15-20 employees for projects with rather big scopes of work. Additionally, if you’re working on several projects simultaneously, the specialist approach might be more suitable. It’s also reasonable to use it when your schedule is tight.

To minimize the downsides of this structure, there’s an alternative — assigning tasks via tickets. Each part of the code is connected to a digital ticket that gets distributed between developers randomly. This way, developers get to work with previously unknown parts of the product, which also makes the code itself a better quality since there are multiple points of view. Plus, it contributes to making team members less dependent on each other and them being interchangeable.

Our Expertise: Specialists Approach

The key point in team structuring is finding the perfect approach to each case separately. To provide you with hands-on experience, we’ve decided to share some insights from Stormotion’s workflow with you.

Once we started working on Yangol, a project of Stormotion’s co-Founders that helps companies structure and manage talent onboarding, we were using the specialist approach. We had 3 developers from our team assigned to 3 separate tasks — backend, mobile, and web app development.

Later on, our developer who was responsible for the web app part needed to work on a mobile preview feature for it. Thus, it required him to get to know the mobile codebase. Eventually, he took over all 3 codebases once they were fundamentally written and worked on their improvements. Since then, we switched to the generalist approach on this project.

It’s important to keep in mind that such switches require a lot of energy and time, yet, they’re not always avoidable.

Hybrid

Hybrid project teams imply exactly what the name says. They have both people who focus on a product as a whole and can narrow their focus down when needed.

Let’s take a look at the strong and weak sides of this approach:

As for two team types differences, we’ve gathered the main aspects in the following table:

Yet, it’s really important to understand what a small team is. Firstly, it highly depends on your use case. For example, Jeff Bezos, the CEO of Amazon, said that he likes to follow this concept: if you can’t feed a group of people with 2 pizzas, it’s too big.

Surely, this concept is really situational, but the idea is clear. You might consider limiting your team size to 5-7 members for maximum productivity. In the next subsection, let’s talk about how to divide your team into small groups if you have more employees.

# 2: Split Big Teams Into Smaller Ones ✂️

There are multiple cases when products were developed by huge teams. There are software or game development teams with over 1000 employees and it’s still manageable with the right approach — you can divide big teams into small ones and work from there.

You can divide developers into small teams in several ways:

• By specialization. Like teams of designers, front-end developers, back-end developers, etc.
• By roles. For example, a PM, a designer, and software developers within one team to cover the full cycle.
• By development stages. Let’s say you know exactly what will be needed at each stage of the development and build teams according to the requirements.

Yet, more teams will require more coordination and supervision, which you definitely should take into account when taking care of this matter.

# 3: Decide Who You Need for the Project 👨‍💻

First of all, try to keep your teams balanced. A so-called full-cycle software development team (meaning it has enough specialists to perform end-to-end development) usually includes:

• 1 UI/UX Designer (UI and UX can be handled by different specialists if necessary).
• 1-2 Front-End (or Mobile if you craft an App) Developers.
• 1-2 Back-End Developers (if needed).
• 1 QA Expert.
• 1 Project Manager.

Surely, team structure can vary depending on your specific use case.

Secondly, pay attention to roles within the team. They aren’t the same as positions and sometimes have nothing to do with it at all.

For example, you might need someone to be a team lead. This role isn’t only for a project or senior manager. The team lead is responsible for a team’s success in a certain software development aspect — be it front-end development or design. They often act as coaches for the team and can work in any position at the company (developers, designers, etc.).

It’s better to assign the team lead in each subteam. Yet, if your application development team structure isn’t too branched, it’s ok to have only one person in this position.

Once you have several development teams formed, you might also need a chief architect. This is the person who coordinates all your teams, builds consensus around a product’s architecture and design, and oversees the general development process from a technical point.

# 4: Feel Free To Change Up The Teams 🔀

Another important thing to understand is that you can freely restructure your software teams when you need to. It can either happen occasionally (for example, if you need to review the code in another sub-team) or you can change them permanently. Some even say that it’s better to move people between teams regularly.

Here are some typical situations when it can be useful to shuffle developers and change your software development team structure:

1. Before starting a new project.
2. Because of a reduction or an increase of the number of employees.
3. When a sub-team faces a task they can’t solve. Yet, this situation can be avoided by assigning tasks to competent teams in advance.
4. When the team shows low performance.
5. According to the needs of the particular project.

Also, try to assign people to the projects that match their interests. Strong initiative sometimes is as important as experience.

# 5: Make the Workspace Friendly 😄

Last but not least, make sure to keep the atmosphere friendly and relaxed so everybody would feel included and welcome.