How to Structure a Development Team
Published: May 2, 2022
10 min read
In this article, you'll learn:
1
📐 Software Development Team Structure Approaches
2
🌊 Agile Software Development vs Traditional Development Teams
3
📚 Tips on Structuring a Development Team
4
💡 Takeaways
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.
Software development team structure impacts project management practices, development team roles, etc. (image by Paul Hatch)
In this article, we’ll cover such issues as approaches to organizing a development team’s workflow, agile and traditional teams differences, and give you some tips on organizing. Additionally, we’ll go over Stormotion’s approach to managing our development workflow.
So, if you’d like to build an in-house team of developers or you’re an IT firm yourself and need some insights from an experienced software development company — welcome. We hope our expertise would be helpful to you!
📐 Software Development Team Structure Approaches
In fact, there are 3 main approaches to arrange a development team. Let’s call them generalist, specialist, and hybrid. So, in this section, we’ll take a look at their strong and weak sides, and give you some examples of when one of them might be more suitable for you.
Generalist Structure
This approach implies building a development team of people with a highly diverse set of skills. Great results are reached thanks to the face-to-face communication and the cooperative effort of all members.
For instance, a front-end developer can also have some knowledge of back-end Java. Or a Project Manager can be familiar with UI design and help with this development part.
A software development team within the framework of generalist approach has variable team roles
The generalist approach has the following pros and cons:
Pros
- All team members implement features as a whole, with no need to communicate that often to cover different aspects of the same task. Thus, they have less blockers and can proceed faster
- You can have different points of view on the problem which contributes to a more efficient solution
- You contribute to a long-term skills improvement, which will make projects’ development much faster in the future
Cons
- Development can take more time as your team members will work on some tasks that may be absolutely new to them
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.
A specialist software development team normally limits members’ responsibilities to their team roles, and they do one task throughout the whole cycle
As for the advantages and disadvantages of the specialist approach, here they are:
Pros
- Deep understanding of each part of a project separately, which allows perfecting them
- Faster development since most of the elements get completed simultaneously
- Clearly distributed responsibilities
- With a well-structured reporting flow, less supervision is required since everybody’s highly competent in what they’re doing
Cons
- More coordination of the workflow is required since there’s a higher risk of miscommunications due to a possible lack of general understanding of the project
- Developers aren’t interchangeable, meaning that for team members to work on other tasks, they’ll have to get to know a certain part of the code anew
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.
Specialist approach is quite hard to connect with agile software development since they nurture different values (image by Stormotion)
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.
With the hybrid structure, you can build agile software development teams even with parts of specialist approach since it’s easier to combine values (image by Alex Krugli)
Let’s take a look at the strong and weak sides of this approach:
Pros
- The efficiency is maximized thanks to the higher flexibility of approaches
- Brings the best of two worlds and minimizes those drawbacks of the 2 previous approaches
Cons
- Coordination is quite challenging since variable approaches require variable supervision techniques
- Such teams are normally more expensive and time-consuming to build
Basically, any company with enough time and budget can build such a team since it’s multi-purpose. Yet, making such an effort is more reasonable when it comes to complex and challenging projects. So, if you work on a simple product or small adjustments to it, we’d recommend considering something less resource-consuming.
🌊 Agile Software Development vs Traditional Development Teams
Nowadays, when companies create teams for projects, they can be either agile or follow traditional corporate values. Even though agile is considered modern and more efficient, traditional team structures still exist and some cases actually benefit from them a lot.
Both agile and traditional aren’t methodologies — they’re sets of principles and values that help to determine how to manage teams properly depending on what results one aims for.
Before we talk about the differences, we’d like to mention that there’s a term called Agile Manifesto, which is a summary of agile principles:
Agile project management is considered more innovative and productive, yet, some cases still require traditional development team roles and hierarchy (image by Hygger)
As for two team types differences, we’ve gathered the main aspects in the following table:
Agile | Traditional |
|---|---|
Team management and organization is almost free of supervision; the Project Manager (PM) guides and coordinates the team as well as makes the workflow as smooth as possible | Strong hierarchical structure and responsibilities distribution; PM is responsible for the result |
Team performance over individual metrics | Individual metrics over team performance |
Multi-purpose teams and specialists, skills are valued in the first place | Clear roles and duties distribution |
Up to 10 people in one team | Teams aren’t limited in sizes |
Traditional teams might be more suitable if you know you need developers to “blindly” perform requests so as not to create chaos or hold back the development. Yet, most modern IT companies and departments prefer agile team structure since it allows workers to bring the value of their best personal traits while still cooperating and being team members.
You surely don’t have to follow all the principles from one of the team types, it’s a great idea to take the best from each one of them.
📚 Tips on Structuring a Development Team
In this section, we’ll give you a couple of tips on how you can arrange and structure your software development teams.
# 1: Decide On The Size Of The Team 👥
The size of your software development team plays a significant role since it actually impacts most aspects of the process: development time, costs (on salaries/hiring), amount of resources (finance, time, and energy) needed for management, etc.
Normally, development teams aren’t that big. Even if they are, C-level then divides them into smaller ones. In fact, having small teams can give you a lot of benefits. According to QSM’s research, small teams:
- Don’t face (or face noticeably less) organizational and workflow issues.
- Are quite dynamic: they are easily structured and restructured.
- Are able to work more independently.
- Allow setting communication and coordinating the efforts of team members easier.
Apart from product development itself, software engineering can include building traditional or agile teams, applying agile methodology, etc. (image by Carolina Contreras)
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.
Agile methodology in software development includes structuring a team in way that it’s not too big (an agile team normally includes up to 10 members) (image by Kasia Bojanowska)
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.
You should decide who you’ll need for the software development process in your traditional or agile team (image by Anton Fritsler (kit8))
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.
Building an agile team can sometimes mean shuffling team members (image by Coach Risk)
Here are some typical situations when it can be useful to shuffle developers and change your software development team structure:
- Before starting a new project.
- Because of a reduction or an increase of the number of employees.
- 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.
- When the team shows low performance.
- 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.
For the productive software development process, it’s essential to create a friendly atmosphere (image by Patswerk)
You should make sure that:
- Everybody has a voice.
- Team members respect each other.
- All issues are addressed.
- Even if you have a hierarchy, it shouldn't be oppressive but more of a coach-student relationship.
💡 Takeaways
To sum up, let’s recall what we’ve talked about in this article. First of all, there are 3 main approaches to structuring development teams: generalist, specialist, and hybrid. When it comes to defining principles and values of the workflow, it can be agile or traditional.
As for tips on structuring the development team, let’s briefly summarize them as well:
- Decide on the size of your team and don’t be afraid to split it into a few smaller ones.
- Wisely choose specialists that you’ll need for the project.
- Properly assign roles according to the software development team hierarchy.
- Feel free to move developers between teams.
- Take care of your teams’ microclimate.
If you have any questions left or maybe you’d like to know our opinion on your specific use case, we would be happy to help you!
Was it helpful?
Read also
Our clients say
![Stormotion client David Lesser, CEO from [object Object]](/static/93e047dadd367691c604d8ffd1f54b58/1b3aa/david.webp)
They were a delight to work with. And they delivered the product we wanted. Stormotion fostered an enjoyable work atmosphere and focused on delivering a bug-free solution.
David Lesser, CEO
Numina