#1
❓ I can’t get enough output. I keep adding teams, but the results do not grow as much! Why?
Companies usually react to not getting enough output by adding more typing hands, i.e., resorting to scaling.
Scaling typically means “we need to add more teams” or “we need to add more people to the teams.” That is the common reaction, but also a common mistake.
❗️ Scaling scales everything!
Low output is often a consequence of dysfunctional teams or processes. Scaling those also scales dysfunctions.
Put simply – small problems become big. And output does not increase proportionally, since soaring dysfunctions prevent it.
💡 To scale successfully, descale first!
💡 Resolve issues and dysfunctions, and if you still want to increase output, you’d be in a better place to scale!
#2
❓ It seems as though adding more people slows down my teams! What is happening?
💡 One of the most overlooked effects occurring within teams is that productivity or participation in the output and outcomes of a team is not equally distributed among team members.
One of the possible explanations comes in the form of Price’s law. The law was formulated by Derek J. de Solla Price in the early 60s while studying scientific productivity.
📚 The law states that the SQUARE ROOT OF THE NUMBER OF PEOPLE in a productive domain produces HALF THE OUTPUT!
🔎 Put plainly, a handful of people are the main contributors to the results of a group, while the others have significantly less contribution.
In a group of 4, chances are that the contribution would be balanced. However, the effects of a growing number of group members come as a surprise to many.
For example, in a team of 10, just three individuals (i.e., square root of 10) are responsible for 50% of the team’s creative output. The remaining seven are responsible for another 50%!
That hits even harder as the number grows, so for those bragging that they either have or manage teams of dozens of people, here is what the law says:
➡️ a team of 20 has only 4 individuals responsible for 50% of all creative results!
➡️ theoretically, a team of 100 developers has merely 10 individuals responsible for 50% of all creative results!
Now, who has a team of 100 devs, one might ask?
Depending on how independent teams are, in a scaled environment this is not hard to imagine.
On the other hand, even if we independently consider 10 teams of 10 developers and add up the effects, we still have only 30 developers contributing 50% of all creative results! The remaining 70 developers are responsible for only as much!
Anyhow, according to Price’s law, the progression of competence is linear, while the progression of incompetence is exponential.
Bear that in mind while you make scaling decisions!
#3
❓ I want to prepare my SW dev team for scaling. What should I do?
There are loads of aspects to take care of, but the most overlooked one is technical excellence.
❗️ Rest assured that whatever is missing in that area will surge at scale!
The usual villains of teams looking to scale are the usual bottleneck generators:
➡️ missing test automation (or automation of any kind),
➡️ code reviews obstructing pipelines,
➡️ poor design choices and other consequences of “heroism” or “soloism” within the team.
Take missing automation as an example. If the team relies on manual testing effort as a verification and validation mechanism, with time the output inevitably suffers. The quality suffers as well, and costs soar.
So, the temptation is to increase declining output by scaling.
💡 Scaling such a team scales all those dysfunctions as well. So, for a minuscule chance of increasing the output, we get the certainty of even greater quality deterioration and exploding costs.
Address those BEFORE you decide to scale.
#4
❓ I am managing a competent SW dev team and want to increase output by adding more teams. Are there any pitfalls in doing so?
💡 Even though your team is competent and performant, be very cautious about attempting scaling.
Team self-management occurs as the competence of a team reaches a certain level. The group bonds and makes decisions together in the best interest of the group. They also tend to resist imposed changes to the team and insist on being essentially included in expanding or modifying the team in any way. They also take great care to constantly improve the team’s performance and quality of results.
In contrast, there are two more possibilities:
➡️ the team is externally managed, i.e., it has a manager
➡️ the team is told to self-organize, but they lack the skill or knowledge to do so
Either way, those are dysfunctions and will become prominent with scaling.
Scaling externally managed teams require scaling of management structure as well, which further leads to externalizing of communication and decision making. It is just the tip of the iceberg of dysfunctions to follow, including (but not limited to) disengagement, frustration, inattention to results, loss of quality, siloing, individualism, “not my work” syndrome, etc.
Dysfunctions soar in the second case as well – scaling teams instructed to self-organize, but lacking the skill or knowledge to do so. The organization and performance of the group hang by a thread in this case and becomes much harder and even impossible if such environments scale.
💡 Either way, look for dysfunctions before you decide to scale. They might be obfuscated by habits or traditions you might have.