Tell me who is on your team, and I’ll tell you how far you will go. It’s no secret that to a large extent, the wellbeing of your business depends on the people you work with… and how you work with them.
When hiring a software development team for a new project, you may have thousands of questions. How many people do I need? How should I assign roles? And how do I manage my team so it will perform like a perpetual mobile of ultimate coding? We are here to answer them all!
How big should your team be?
According to an old saying, “two heads are better than one”. It’s simple math that two developers will deliver a result faster than one. Plus, the more people working on a project, the greater the chance that one of them will come up with a good idea or an important update.
True, but only to a certain extent.
When a team grows bigger, the good old Ringelmann effect comes into full force. It is also called social loafing, and it illustrates how the individual productivity of team members decreases as group size increases.
But why?
First of all, the bigger group means less personal responsibility, simply because it is harder to evaluate the individual contribution of each member. So, people start thinking things like: “Hmm... someone will have to do this job anyway. Why should it be me?”
Another reason is communication. J. Richard Hackman, Professor of Social and Organizational Psychology at Harvard University, states in his study that basically the problem lies in the number of connections people need to maintain to keep the process up and running, rather than in the number of people itself.
For example: a startup of 7 people must maintain 21 connection, while 12 people cope with 66 connections.
With the growing number of connections, there is an increasing risk that one of them will fail. Such failures lead to communication issues, holdbacks, and the increased impact of human error on operations.
On top of this, people start feeling stressed, isolated, and, as a result, less engaged.
So, what is the optimal team size?
As a baseline, you can use Jeff Bezos “two-pizza rule”: If you can't feed a team with two pizzas, it's too large. In such groups, creative ideas will prevail over mediocre shared vision, and productivity will remain high.
Since we all know at least one person who can eat two pizzas single-handedly, it’s best to clarify that a typical “two pizza team” consists of 5-7 people.
If your team is larger than that, you may want to consider splitting it into several. However, having too many teams may cause the same issues as managing one overpopulated one. You’ll need a person to coordinate the cooperation between these groups. Otherwise, you may face the situation that some of your teams are working on the same task without knowing it or, which is much worse, on tasks that conflict with each other.
Sum up
Depending on the size of the company and the complexity of the project, we can distinguish the two most common types of team structure: let’s call them “One for All” and “All for One”. Here is the comparison:
|
One for All One team for a project |
All for One Splitting your team into separate goal-focused groups |
|
| Company | Startups and small businesses with up to 10 employees | Mid-sized and large companies |
| Project | Small or relatively simple projects | Complex or divided projects |
| Pros | Easy to manage. The communication between teammates takes less time. | An opportunity to work on various domains of the project at the same time. |
| Cons | The larger the team grows, the harder it becomes to manage it. | Higher probability of communication issues. You’ll have to manage not only the workflow in the separate groups but also the cooperation between them. |
| Approach | Agile and Waterfall are both suitable | Best suited for Agile |
Assigning roles and responsibilities
Now, once we’ve decided about quantity, let’s proceed to quality. To build a fully functional team, it’s not enough to divide people randomly into small groups – your team should be well-balanced. In other words, your crew should be able to handle every stage of the project development on its own.
Classically, a software development team consists of:
- UI/UX Designer.
- 1-2 Frontend Engineers
- 1-2 Backend Engineers
- 1 QA Manager.
- 1 Project Manager.
This is not set in stone. There may be some variations depending on the type of your project. For example, you may consider adding iOS/Android specialists if you’re developing a mobile app.
Putting together a group doesn’t mean it becomes a monolith. Feel free to shuffle your teams when necessary. For instance, you can do it prior to beginning a new project, when there are changes in the number of employees or their or productivity, or simply when you want one team to review the code of another.
And last but not least: be sure to assign people to projects that match their personal interests.
Roles, roles!
The second step of turning your team into “the Mighty Coding Group” is to assign the roles. Here are a few you may want to pay attention to in the first place.
Team Lead
Don’t confuse this with PM – they are completely different things. The responsibilities of the Team Lead include retaining the team cohesion and ensuring availability of all the resources needed for a project. The Team Lead is not always the best engineer - the ability to take care of the team's needs is more crucial for this role. Some prefer to use the term coach for this position, which is also very suitable. If you have a few teams, it’s a good idea to assign a Team Lead for each of them.
Chief Architect
If your company’s structure is branched and unites many development squads, you may need a person who can coordinate the workflow between these squads. The Chief Architect is also responsible for building common understanding of product architecture, design, and concept.
Product Owner
The main function of the Product Owner is to make sure that the team builds the right product. This person is responsible for prioritizing the tasks in the backlog and for planning the scope of work for the next few months. In other words, the Product Owner is the connection point between the team, stakeholders, and users.
There are a lot of other specific development roles that can upgrade your team. And that topic is definitely worth a separate article.
Paying attention to the inner climate
The psychological compatibility of your team members can affect performance even more so than their qualifications. So, be aware of the way your teammates treat each other. Do your best to resolve arising conflicts and encourage partnership and team spirit.
Create an environment where people feel free to discuss and suggest ideas – this creates fertile soil for growing a successful project.
In our blog, we have already discussed how to boost morale in newly emerged teams. To learn more, read ‘3 Golden Rules of Building Corporate Culture at Early Stages’.
***
I hope this article will help you build a super team for your next project. Alternatively, you can always contact us to hire a software development team that is already highly qualified, well structured, and friendly. Feel free to use our calculator tool to estimate the potential cost of your perfect crew.
Leave a Comment