Introduction
One of the questions prospective clients ask us frequently is what the typical software development team looks like. The truth is, the “typical” team is hard to define. The “proper” structure and composition has been the subject of many debates, and there are so many configuration options that it is unreasonable to expect a “one-size-fits-all” approach.
As with any area of software engineering at Syberry, we always explore our options to find the optimal team composition based on each client's specific needs, rather than simply recycling identical team compositions over and over. In this article we will outline the key decisions we make to compile the best team to build a software product.
People First
While discussing technical parameters of a software team, like the right roles or the optimal size, it is easy to get lost in the “mechanical” thinking and forget about what is most important for the best team: the right people.
The underlying basis for hiring the right people in any company is an organizational culture that serves as the filter to define whether any individual will be “the right fit” or a successful contributor. But even with the filter of company culture, every prospective employee has a unique personality, and it's management's job to combine those personalities into one, cohesive group. The same is true when building a software development team for a particular project.
You want your team to be motivated to work on the new product, so take some time to match their expectations and development opportunities with the specific project at hand, be it a new technology an engineer wants to try out or the first team management experience for a new lead engineer.
Team Size
As long as there are enough people to get the job done effectively and efficiently, there is no true minimum number of team members to aim for. However, it is possible to have too many people on a team. Ever heard the phrase, “too many cooks in the kitchen”?
General wisdom says the maximum team size should be about seven or eight people. This number pops up in the context of SCRUM teams, and our experience supports the guideline for other process models as well.
That said, sometimes a large project requires us to scale the production process further, using more than seven or eight people to make up a team. In this case, we have to think about the specific process models much more and start looking into a more formalized processes by which we can create and combine multiple, smaller teams to ensure alignment in both goals and tactics.
Specialization
The next thing to consider in structuring your team is the assignment of roles and specializations. While there is a popular industry opinion that an agile team should not include specialized roles, in our experience this approach works well only in a very small team of highly qualified people.
To understand the question of specialization, consider the team-building approach within your own organization. Have you created a cohesive, product-oriented team or have you divided specialized functions (like DevOps or Project Management) into centralized services and departments? The answer of course depends on what you are trying to optimize. Specialized teams are good for achieving specific goals, while centralized, nonspecialized teams are ideal for knowledge sharing and process control. Each approach has its pros and cons, and that's why we use both at Syberry. We know that some functions, like engineering, project management or requirements, are better kept inside of the team since they are highly customized for the specific products and projects. But other functions, like DevOps or QA, are better kept in specialized teams that work separately from the rest of the group.
The key here is to find the right balance between specialization and customization by choosing which components of the engineering process to isolate and which to keep in the core team.
Qualifications
When you're building a small team, it is easy enough to compose it with a top-tier specialists from every field of engineering. But as your team grows, it will inevitably become optimal to hire bright but less experienced people and train them to do the necessary jobs. In some sense, this is a social responsibility of the company, because if no one is willing to train less experienced engineers, they'll never grow into senior specialists.
One drawback of an all-senior team is the high risk of analysis paralysis in the decision-making process. How often have you seen the engineers in the process of indefinite holy war on the selection of the framework or the architectural approach for the new system? Each senior team member will have a preferred way of doing things, and while healthy conflict is the source of quality improvements, when it's taken too far, it may stall the team productivity. Often, it's more efficient to have one or two senior leaders who can be trusted to make effective strategic decisions and then guide the less experienced team members through proper implementation.
We believe that the optimal team structure is pyramid-like, with a very few specialists on the top and greener talent on the bottom. This creates a balance between strategic decision making and forward motion, maintaining room for healthy argument while giving new people an opportunity to learn and improve — all while keeping the project moving forward in the right direction.
The management role here is to ensure that the structure of the team reflects the members' competence and nothing else, and that the team culture is one in which everyone feels secure in sharing opinions and that ideas are judged on their merits not their presentors' authority.
Conclusion
These are some of the most important factors in team composition, but they're just a few of the many aspects that should be taken into account. At Syberry, we undergo a rigorous process to create the ideal team to develop every client's unique product or system. But the most important thing to remember is that people are central to this process. Start with identifying the right people, and then work backward to design the team — starting with the goals you would like to achieve and the parameters you would like to optimize, then devising the team that works best for each particular context.
