Junior, Middle and Senior: How to Effectively Build a Team of Different Level Specialists

The success of any project in many ways depends on the team. Even a small product is mostly designed by a team, even if that team consists of just two people. Building an effective team is very important and, at first glance, this looks like a much simpler task than it really is.

Each member of the team has his own opinion and vision about the project, its development, evolution and other processes. It is necessary to organize everything in such a way that all these factors will be in harmony with each other, and specialists’ joint efforts will be focused on achieving the customer’s specific business objectives. Therefore, this must be taken into account when starting a project.

Why is the right team configuration important?

The importance of the structuring the team correctly is obvious. First of all, it affects the final budget. The cost of each developer depends on his level of knowledge and experience.

It is important to save the optimal cost of the project, so you have to build the team and recruit people for different levels of tasks on the project taking, into account their duration and workload.

It is important to note that there is such a thing as a human factor. If a ten-person project will have ten architects or senior-level developers, the probability of conflict occurring increases because the developers will probably all want to express their own vision, which cannot always be called constructive.

The work effectiveness is one of the key priorities in software development; thus, in order to solve each type of task you need to pick the right person. Someone can handle routine tasks perfectly well and spend hours dealing with the algorithm, and someone else likes to do everything dynamically and see progress right away.

Understanding and considering these things, you will be able to recruit the right people to the right place. As a result, efficiency will be at the maximum level.

It is important to consider that not every developer is a good team player, so there should be a person who manages the team — a team lead. He not only has to control the project’s development and team’s progress, but also smooth out conflicts, raise the motivation of the developers, and take on the pressure from the customer.

Actually, the control of the project should be the responsibility of the team lead, the project manager and tech lead. These are the key people who should be at the heart of building the team. In fact, they are the skeleton staff who manage the project from start to finish.

As for juniors, although they often lack experience, these developers sometimes play an important role in projects with a large number of routine and simple tasks. Junior developers spend about the same amount of time solving issues as middle or senior ones. This raises the question: “Why does the customer have to pay more?”

Team formats: recommendations, tested in practice

Single developer. Let’s start with the smallest. In fact, the team is not only developers, but everyone involved in the project. This can include the customer, product owner, tester, intermediary and so on. This type of team is typical for small projects or MVP development for the startup.

2–10 people. This is the most common team configuration for small and medium-sized projects. To build such a team is relatively easy, since you can recruit the right developers who can work productively together, are close in mentality, mood, style of work and communication.

These teams are easy to manage, show high performance and have minimum conflicts. You can clearly see all the risks and disadvantages. Commonly, these teams include the team lead, tech lead, project manager, and some developers.

The best way to build a team is to start with the skeleton staff and then proceed depending on the tasks of the project. It makes no sense delegating simple tasks to the senior developer, so it is advisable to hire a middle developer, which will make it possible to save on the budget without losing quality.

It is important for the team lead and tech lead to get on with the developers and have a shared vision of the processes. Sometimes it’s worth recruiting a junior developer to do the routine work, such as duplicating functionality, working on templates, and helping senior developers.

The number of testers depends on the size of the project and the volume of progress that must be tested, so there is no universal formula here.

10–50 people. In such teams there should be well established processes, since managing a large number of people is quite difficult. For that, you need to have an experienced project manager and team lead, as well as senior developers with good technical backgrounds.

From my experience, when managing a team of 30+ people it’s best to break it into junior, middle and senior clusters, for example: 4 juniors, 5 middles, 7 seniors, project manager, team lead, tech lead and testers. These proportions are the most effective for most projects.

There is another possible type of team configuration: freelancers and random developers. This can cause the most problems in projects, since the people have never worked together and each have their own style of work, different working hours, etc. And they are often not eager to compromise.

As a result, all the listed factors create a direct risk to the project, despite the high level of developers.

Resume

From my own experience working on various projects, I can say that the best choice is a team that has worked together for a while and works from one office. This is a guarantee of success and stability on a project.

Team formation is an important and difficult task. If you trust this to the professionals, the risks for the project will be minimal, and the probability of its successful completion becomes almost 100%.

Originally published at lvivity.com