Software Development team: Structure

When discussing application shortcomings, users often say that the developers were too lazy to do a good job. But what is software development? First, let’s figure out what roles there are in the development team.

Are there all of them?

In principle, one programmer is enough to provide full-fledged software development. But as the complexity and time of the product grow, someone will have to do some roles, even if they are not assigned (in the form of positions).


An essential aspect of software development is that this very development is carried out within the framework of the projects. Timelines desired results, and project budgets are outlined. This also usually includes human resources. People are hired for money. The amount of money determines how many developers and what qualifications can be employed. Now let’s try to understand what the software development team structure is.

The programming team

Those people who come up with the project and do software development. They:

  • come up with the architecture of the application;
  • write the code;
  • advise others on how to write the code;
  • review the code after others;
  • write automated tests (at least part of them are unit tests).

Without written and compiled code, software development is impossible. That is why it is impossible to exclude programmers altogether. Even if some applications are created in a simple visual constructor, it is also a kind of development.

It is programmers who often decide how exactly this or that functionality will be implemented in the application. And if the functionality is poorly executed, then a significant portion of the blame can lie with the programmers. But maybe not because it is not they who have the final say in decision-making.


These are the people who check if the software development is going correctly. And correct doesn’t mean convenience for the user. A tester can write usability objections, but their main task is to ensure that the application works according to requirements and specifications.

You can test applications manually or with autotests (e.g., programmatically pressing buttons and checking which screens open).

If there are no dedicated testers in the development team, their functions are usually delegated to programmers. In this case, it is assumed that a programmer cannot correctly test what they developed, so cross-testing is performed. 

Another way to save on testers may be that an experienced person is brought in only to write a testing plan while novice testers perform actual testing.

If the software development team has made a noticeable and uncomplicated error (the buttons in the calculator sometimes do not get pressed), then part of the blame lies with the testers (they did not check something).


This is the person who determines how the application will look and behave. The mutual arrangement of elements, the scheme of moving around the screens, the animations – all this has to be thought out by the designer. If the application is large and complex, more than one designer may be there. Or, for example, one of the designers can draw the interface, while another thinks globally about the whole concept of interaction with the user.

Not all the companies engaged in software development have a designer, so if an application doesn’t promise commercial success, there is a temptation to save money on hiring a professional designer (and a whole team even more so), transferring his duties to programmers. And it may turn out to be not so bad if the programmers are experienced enough, and the concepts of “usability” and “user experience” are not empty words for them.

Sometimes the designer and the programmers are jointly responsible for some of the errors in the application: it happens that it is pretty challenging to implement the design you came up with, and as the complexity increases, so does the probability of errors. And, of course, all the comments “uncomfortable interface” are stones to the designer.

The customer or owner of the product

This is the person who determines the entire course of the creation and development of the product. He decides what should be done and assesses whether the implementation of the product concept or not. For example, the programmers tell him, “It will take us two months to implement this. We can use third-party libraries and do it all in a week, but then the application will increase by 54 MB”. 

The product owner may say, “Another 54 MB? That’s unacceptable,” or “We have a release in a month. Make it as fast as possible and go live”. And he is also responsible for the direction of product development. So if you read the feedback, “Why did they ruin such a good application? Now it’s gone bad at all”, know that it was the product owner who determined the project’s fate.

The difference in role titles stems from the type of company. For example, the product owner is designated in a product company (which develops its internal product). On the other hand, a customer representative is singled out to interact with the developers in custom development.

Can a development project do without this person? Of course, the project can, but the product (application) cannot. Someone still needs to understand what the application is being developed for and how it should exist and develop in the future.

Project Manager

The person who manages the whole mess of this entire team. Keeps track of deadlines for tasks. Responds quickly if quality problems arise. Motivates the team to work more efficiently (“knocking out” bonuses, ordering pizza, etc.). 

Together with the product owner, it makes decisions when alternatives are possible when choosing the development of the product during development. If the project is extensive and complex (still rare for mobile applications), it can be broken into several subprojects. 

They may have their managers, and the project manager is assisted by a project administrator, who deals with most of the work: keeping minutes of meetings (recording the decisions made), drawing a graph of the project progress (e.g., “task burnout”).

According to statistics, only a small part of software development projects is completed on time with the set level of quality and within the initial budget. If something goes wrong, the project manager is ultimately responsible for what will have to be sacrificed: to release the product later, fix bugs with updates, or get more money (for example, to give part of the development to another team for some money).

In small projects with an experienced team of programmers and testers. Then his role is usually performed by a leading programmer – team lead.

Leave a Comment