Pareto Principle

Many, if not all, software developers who ever worked in a medium- to large sized team know that feeling when your development process feels “unbalanced”. Your backlog is full of tedious and/or boring tasks, you feel like no one except you is actually doing something to advance your project or the opposite of it: you feel like all you do is meaningless for your team/product.

Luckily, we have a rich history of scientific research, psychological laws (like Parkinson’s Law), principles and rules which can be useful to figure it all out. Among those principles is one which offers an explanation to the above phenomenon.

The Pareto Principle

In 1896 Vilfredo Pareto published a book showing that about 80% of the land in Italy was owned by 20% of the population. It was not until the management consultant Dr. Joseph Juran mentioned in the early 1950’s that the Pareto Principle was indeed meaningful - not only for economics. He even noted it a “universal principle”.

The Pareto Principle, oftentimes called law of the vital few, goes like this:

Roughly 80% of the consequences come from 20% of the causes.

Such a simple fact sounds ridiculous. But cognitive bias aside, it’s actually true in many cases. It sometimes even surpasses the moderate 80-20 and sometimes hits the ballpark of 90-10 or 99-1. For simplicity, I’ll always use a 80-20 distribution in this article. Also, I’ll refer to the causes which are not causing the 80% of the consequences the “non-vital lot”.

Just for fun, here are some Pareto’d statistics:

• in 1989, the richest 20% of the population accounted for about 80% of the world’s income
• about 4% of the languages worldwide are spoken by 96% of the population
• for most retailers, 10-20% of their products generate 90% of their revenue

Also, be cautious: the numbers don’t always add up. It’s merely coincidental that 80+20=100. If you think about it, “10% of your customers generate 99% of your revenue” is very possible.

Pareto in action

There are quite a few applications found mainly in books about management and/or marketing where the Pareto Principle is fundamental. Commonly, these strategies imply that the vital few are indeed among a group of individuals. Finding the vital few is generally the first step, followed by focussing your resources on them. I did find a very good example of the Pareto Principle in my daily life as a software engineer working in a medium-sized team.

Given we have a team of 10 engineers (product owner, scrum master, etc. aside) working on a single product. As the Pareto Principle is supposedly universal, you end up having two really good engineers (20%) who’s efforts attribute to 80% of the finished product. The other eight engineers (80%) were able to contribute only 20% to the finished product.

Superficially, this seems like a case where dropping the non-vital engineers from the team to free resources is a good idea. But think about this: the eight engineers are most likely covering a lot of the tedious stuff. Updating dependencies, supporting customers, fixing minor problems in your infrastructure, the list of tedious (yet important!) tasks in software development is very long.

In other words: Only a fraction of the team’s development time spent (maybe ~20%?) is actually responsible for most of the value your product is delivering (perhaps ~80%?).

If we were removing the non-vital engineers, a vacuum would be created. The tedious stuff above still needs to be done, no matter how many people are on your team. If your vital few engineers are busy supporting your users all day, they won’t advance your product, either.

Such a scenario is very, very, very common in larger tech-driven organization. The reason is mostly that teams are ideally staffed with 1 or 2 Senior-level engineers and a bunch of Professional- or even Junior-levels. That’s so common because it is a sustainable way to keep your talents in your organization without hiring fresh blood to fill the ranks. Additionally, finding good engineers is super hard (last time I checked there were 70.000 open positions in Germany alone). The Senior engineers are not the ones solely responsible for the bigger chunk of your product’s value, it’s a teamwork feat.

But is it always a good idea to maintain the non-vital lot just to keep my vital few?

I guess the real answer is: it depends. Given you have resources to spare and no other use for them, being able to shift resources without sacrificing much (the aforementioned 20%) sounds like a great idea. Just think about a supplier/customer who troubles you a lot without generating a lot of revenue for you.

The Pareto Principle is great overall and due to it’s (supposedly) universal nature it’s easy to spot such distributions. It is very useful to find your focus when there are lots of options and also very useful to decide what to get rid of when you run out of options. I find it difficult to rely on it as a predictive tool and it’s use in small sample sizes is debatable.