Abstract

I decided that I needed to do something mindless yesterday, so I spent the whole of Saturday playing Pax Imperia. On Sunday morning, I awoke with the idea that perhaps the ratio of senior to junior and intermediate developers is determined by Price's Law.

After some pondering, I have the beginnings of a model where the number of senior developers determines the number of other staff - devops, testers, DBAs, junior developers - needed to augment the development of the software, could be determined by the converse of Price's Law.

This emerges from the productivity indicators that favour specialisation.

Parallel ideas involve team size, clustering of teams, and the retention and optimal allocation of the more competent and productive staff.

Context

Price's law states that the square root of the number of employees (root staff) are responsible for half the productivity of all the staff.

The way that this is usually interpreted is that staff size grows, competency increases linearly and incompetency increases exponentially. That is to say that value creation is asymmetrical.

I am also considering that an individual's productivity cannot be split into units of time as different staff will have different skill levels in different expertise.

I am commentating in the field(s) of software development here and it is assumed that the reader is familiar with some of its jargon.

Introduction

The graphs above are the normalised ratio of the average productivity of a root staff member to an other staff member. Let's expand on that by example:

Let's say that one has 100 staff, and we produce $180 of productivity:

root_staff: nᵣ = √n = √100 = 10
other_staff: nₒ = n - √n = 100 - 10 = 90
product_of_each_staff_group, r and o: Pᵣ = Pₒ = ½P = ½ x $180 = $90
product_of_each_root_staff: pᵣ = Pᵣ/nᵣ = $90 / 10 = $9
product_of_each_other_staff: pₒ = Pₒ/nₒ = $90 / 90 = $1
normalisation: pᵣ : pₒ :: $9 : $1 :: 90% : 10% (where 0.9 + 0.1 = 1)

Let's take a look at (the initial) data series.

n (total staff)	nᵣ ~ pᵣ (root staff)	nₒ ~ pₒ (other staff)
4	2 ~ 50%	2 ~ 50%
9	3 ~ 67%	6 ~ 33%
16	4 ~ 75%	12 ~ 25%
25	5 ~ 80 %	20 ~ 20%
36	6 ~ 83%	30 ~ 17%
49	7 ~ 85%	42 ~ 15%
64	8 ~ 87%	56 ~ 13%
81	9 ~ 89%	72 ~ 11%
100	10 ~ 90%	90 ~ 10%

Observations

I'm going to focus on three observations here:

(team) size;
(staff and team) specialisation; and
staff skill levels.

Team Size

The point that I'm driving at with the above table is that as the number of staff increases, the ratio of root staff product to other staff product also increases (logarithmically, as one would expect): n ∝ pᵣ:pₒ.

Here incompetence is increasing exponentially which implies that having smaller teams is to have less incompetency and thus better efficacy.

Specialisation

It is of consequence here that the all staff in the team are considered to be performing almost homogeneous, indistinguishable tasks, to produce an undivided output. (Notice the effective use of the passive voice here too!)

If people are not playing to their strengths - which, as they gain experience, will also tend to be their preferred specialisation fields - they will tend to move from the root to the other category in terms of productivity; for example:

A senior Python developer who prefers back-end (model layer) programming and using an ORM (like Django's) and an API (like DRF) is going to be neither happy nor productive if you have him maintaining databases, writing in Go and doing the devops for an API router (like Kong).

He'll probably feel frustrated and unproductive and sooner or later (depending on the labour market for software developers) leave in favour of implementing his stronger expertise and being more productive.

This implies that one should hire, develop and deploy staff according to their stronger skills and interests.

Skill Levels

Based on the productivity ratio, n ∝ pᵣ:pₒ, it would seem that the root staff, r, are relatively more skilled than the other staff, o. It could even suggest that Price's law can be used to determine the number and skill level of new hires, for example:

Start with two senior developers. Productivity distribution is fairly even as nᵣ > 1 & nₒ < 1.

Hire two intermediate developers. In this fairly small team of four, the intermediate developers will be as productive as the senior developers, pᵣ = pₒ = 50%, and visa versa.

Next, hire five juniors. We now have pᵣ = 67% & pₒ = 33% with one of the intermediates as productive as a senior and the other as productive as a junior.

With hiring less skilled people as the team size increases there is a reduction in the average wage as incompetency increases exponentially whilst competence increases linearly.

Conclusions

The proposal here is a combination of the observations above:

Deploy staff according to their skill sets;
Keep teams to a maximum of about 10;
After establishing a core competency of senior staff, hire mostly juniors; and
As staff become more experienced, skilled, and specialised, break them out into new teams.

Another idea is to create clusters of teams with the cluster sizes following these recommendations.

The evidence here is none that I've formally analysed, besides lived experience; this is an hypothesis as to why productivity contribution does not increase linearly as one adds developers of similar ability to a software project.

References and Further Inquiry

Price’s Law: What It Is And Why You Should Care - Darius Foroux.
Another Reason Companies Fail: Price’s Law - Barry Dunaway (America First Investment Advisors).
"These horrible people do everything" - Dr Jordan B Peterson.

Price's Law and Software Development

Team Size, Specialisation, Skill Levels.