Dogmatic and prejudiced.
Preface
When you increase the number of developers to grow a software product more, at some point you will need to reorganize the team structure. This is because as the complexity of the breadth and depth of what we are doing increases, the amount of noise and catch-up we have to do in meetings and reviews decreases productivity.
What kind of structure is best for development with maximum velocity?
Dunbar Count: The Big Picture
The Dunbar number is often used as an indicator for organizational management, not only in software development. Anthropologist and evolutionary biologist Robin Dunbar proposed the concept of 150 people (100-200) as the upper limit of the number of people with whom a stable relationship can be established.
It is based on an analysis of group formation in hunter-gatherer societies, assuming that the cognitive capacity of the human brain is limited. I have heard that it is also used as a reference in determining the composition of armies.
Various people have added their own interpretations to what Dunbar proposed, but if you want to get a rough idea, here is what I think it looks like.
- 5: Family
- 15: best friends
- 35 (30-50) people: a band. Friends
- 150 (100-200) people: a village. Special acquaintances
- 500: tribe. Acquaintances
- 1500: the limit of the number of people you can recognize.
The number of people in an organization should be based on certain guidelines, such as 35 for a department, 150 for a division, 500 for a company, and 1500 for a holding company, for example.
Dunbar's study suggests that a hunter-gatherer society is modern enough, but there may need some adjustments to the number of people in a society with information technology.
Aim for 5-10 people per team
With that general framework in the back of your mind, let's assume that the group of people you are considering teaming up is less than 150 people. How many people should be on each team?
Amazon uses the two pizza rule, 5-10 people per team based on the number of people around two pizzas. The Scrum Guide also has a maximum of 10 people.
Span of Control, the number of people that one manager can see, is said to be 5 to 9, although there are various theories. If you include the manager, a team consists of 6 to 10 people. This is consistent to some extent.
In a traditional Japanese company, there may be a section manager without subordinates, but the context sharing cost is high and productivity is low. Conversely, I feel that if a fast-growing team is stretched to one team of 30 people by postponing the team split, the noise level will increase and productivity will suffer.
I think 5-10 people per team is the sweet spot and right on target. On the other hand, it is also important to consider the origin of this range, since the ability to increase the number of people on a team depends largely on the self-driven nature of the team members.
A team with only new members is a team with low self-drivability. Perhaps five members is the limit for a team to work. On the other hand, if all the members are top-notch, the manager will have less work to do, and even 10 members will work.
If a team has only inexperienced members, more than 10 members is more likely to fall apart. The manager has too less tasks if the team is full of veterans. Only imitating the top of the two pizza rule will not increase productivity.
Organize your code as you organize your team
As you organize your team, organize your code. This is because Conway's Law is well known in software development that the boundaries of infrastructure and code are the boundaries of communication.
If you divide the team without organizing the code, you will end up in a halfway state because you will need to communicate with other teams to change the shared parts.
Conway's rule can be said to be a warning that if you let things flow without a will, the boundaries of the code will become the boundaries of the team. You will end up deviating from the optimal point of the two-pizza rule.
I believe that what is generally referred to as the reverse Conway strategy is that by organizing the code and infrastructure with a will, you can increase the number of developers with high productivity without deviating from the two-pizza rule.
What roles should team members play?
What roles a team should consist of depends largely on the type of business, but one thing that can be said is that the closer the team as a whole is to an independent startup, the more flexible it will be.
There are several common patterns of failure for startups and internal new businesses in the early stages of establishment, and it is said that starting a business alone or with too many co-founders is more likely to result in failure. If the founder is a one-man operation and does too much of everything, it is easy to go under, and if there are too many co-CXOs, it is easy to go under.
Although three founding members (Hacker, Hustler, and Hipster) are sometimes required, the most common pattern for an IT company is to have a CXO and CTO as two founders. The CTO does both technology and engineering, so let's call him a CTEO.
If you use this as a base, I think it is essentially perfect to have a mini CEO (PM) and a mini CTEO (Tech Manager (Technology & Engineering Manager)) on every team.
On the other hand, mini CTOs are rare. I hear that only 10% of engineers want to be in a managerial position. If anything, it seems to me that there are more organizations that separate Engineering Managers and Tech Leads. If you divide the duties of the Tech Manager, each team has a Tech Lead, and if there is one EM in two teams, it will work.
There are companies that break down the work of PMs into PdMs and PMMs.
My idea of the most powerful Spotify modification model
The Spotify model is often cited when considering patterns of team structure. The team structure is organized in terms of Tribe, Squad, Chapter, and Guild.
However, Spotify does not seem to be using this model currently and is sometimes said to be a failed approach. My understanding is that the base part is good, but probably what went wrong was the EM ratio and Chapter constraints.
If the company has a CTO and VPoE structure, the VPoE is often in the hiring interview, so it depends on how hard they are trying to hire, but as mentioned, if the CTEO is divided into Tech Lead and EM, I think 1 EM for every 2 teams is a limit. There is some talk about the need for Manager in Google's paper, and the Spotify model seems to have too few EM.
The other thing is the Chapter constraint. In the Spotify model, for example, it seems to imply that Chapter and Guild can scale infinitely, but I don't think that's true. Span of Control's 5 to 9 people also works laterally. Although it depends on how it is done, it needs to be divided once a certain number of people have been reached.
Is a Tech Manager (Playing Manager) Really Unnecessary?
Generally speaking, in modern career paths, engineers are forced to choose between being a player or a manager at a certain rank. The larger the company, the more the career path is often irreversible, as it is evaluated based on the ability of the chosen one.
On the other hand, there are an increasing number of companies that have reached the end of their single business and are working on new businesses. When I talk to companies in their second start-up phase, they all say that there is no one they can entrust the job to.
As startups gradually move up through the phases, they undervalue the full-stack engineers who have been with them since the startup period and recommend converting them to a single specialty, while at the same time lamenting the lack of full-stack engineers when they try to start new businesses in a roundabout way. I have also seen such incidents. Perhaps the span of time in which new business must be refined is shorter than it was a decade ago.
It is indeed stifling that the only career path for engineers in traditional Japanese companies to get promoted is management, but I also hear that the EM role differs from company to company. If it works out well to have three choices, including the role of Tech Manager, which is more like mini CTO, instead of two choices of Engineering Manager and Tech Lead, then I think that is one way to go about it.
