#1
❗️ Scaling a software development setup is not a trivial task. Depending on the SW dev setup’s condition, it might be wiser not to scale at all, or at least to postpone the scaling until the setup itself is ready.
In addition to Price’s law’s effects on scaling teams, other commonly-known laws and principles manifest while scaling.
For example, take a look at Conway’s law:
📗 “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” (Melvin E. Conway)
Speaking practically, inefficient communication or collaboration between groups within a team decreases the chances of closer collaboration between parts of a system being developed by those groups.
Scaling the team by introducing more team members increases the chance of further communication and collaboration issues, emphasizing the effect further.
The similar is true for parts of the system, services, or components developed by different teams within the organization.
Scaling the software development environment by introducing more teams also emphasizes the effect.
Of course, loose coupling is a desirable feature of a system. However, Conway’s law indicates that such decouplings might happen at undesirable points, violating good design decisions and architectural choices.
💡 This effect might not be self-evident from the start, but it is crucial to have it in mind when making scaling decisions.
#2
❗️Brooks’s law is often brought up when talking about the negative effects of adding people to SW development environments.
📗 The law itself says: “Adding manpower to a late software project makes it later” (Fred Brooks, Mythical Man-Month)
Although it might be the famous one, the law often manifests through other laws and principles, such as Price’s and Conway’s laws.
Software development teams are not mechanisms with interchangeable parts. They are not easily expandable mechanisms either, expandable by plugging in new parts.
Every new team member is a complex biological system that is intended to interact with the other similar, but quite different complex biological systems (i.e., other team members) – each with its deficiencies and strengths. Establishing and maintaining effective and productive relationships between them is a gargantuan effort in its own right.
💡 Putting those aside (as if that is not enough to raise an alert), we need to take into account the effects described by the aforementioned laws to even have a chance of attempting to scale any SW development team effectively.
All this is all too commonly ignored, and culprits are looked for elsewhere when things go awry.
#3
❗️ Scaling the teams is affected by organisationally related laws (e.g., Price’s law, Pareto principle, Conway’s law, Brooks’s law)
💡 However, it is also important to consider the effects of seemingly unrelated laws and principles.
Take Gall’s law for example. It is usually quoted in the context of computer or software systems.
📗 “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” (John Gall, Systemantics: How Systems Really Work and How They Fail)
If we consider an organization to be a system (which it is in fact,) or we do the same for a team, the dangers of scaling become obvious.
Let’s rephrase the law to make it more obvious:
💡 An organization that works is invariably found to have evolved from a simple organization, or a single team that worked. An organization designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple organization, or an effective working team.
❗️ Descale first! Start with making a team, or a small and highly effective organization. If you still need to scale after doing that, evolve an effective organization on a healthy basis.
#4
❗️ Deciding to scale a software development environment, organizations often neglect the effects of transformations within teams the process itself brings.
Let’s consider the Peter Principle:
📗 “In a hierarchy, every employee tends to rise to his level of incompetence.” (Laurence J. Peter)
It is a concept in management theory that says that employees tend to rise to their highest level of competence and then get promoted to a role beyond their abilities.
Thus, employees are promoted until they reach a level at which they are no longer competent, and unfortunately, they remain in that position.
That usually means that the most incompetent person is in charge, so the entire organization suffers as a result!
❗️ Since the Peter Principle applies to any organization where employees are promoted based on their performance in their current roles, it is relevant for software development teams as well.
In a software development team, this often means that excellent engineers are promoted to management positions, even if they have little experience or skill in managing people.
Of course, that leads to problems since they might not be able to effectively manage teams and make good decisions, which can negatively impact the teams’ ability to deliver high-quality software.
💡 Scaling the software development environment, either by introducing more developers to a team or introducing more teams usually results in making such organizational changes.
That’s a form of “catch-22” situation, where organizations either introduce new managers (or “leaders” who are strangers to the team) or incapacitate good engineers by promoting them to management positions.
💡 Scaling the software development environment should not be taken lightly and should be considered a last resort.