Systems archetype: Success to the Successful


The Success to the Successful systems archetype explains how very small differences, and random factors, can lead to one actor in a system to be hugely more successful than other actors:

  • how monopolies are created
  • why income is so unevenly distributed in many countries
  • why success in the school system leads to success later in life
  • how Microsoft became dominant in the software market

...and many other phenomena. Success to the Successful provides an explanation model for the Pareto Principle, the observation that in many systems, roughly 80% of the effects come from 20% of the causes.

To understand the causal loop diagram above: Assume that you have two actors A and B. A and B compete for resources. A and B may start out being equal. That is, there may be no observable difference that would give either a competitive advantage.

As long as the system is perfectly balanced, nothing interesting happens, but, if there is a random event that either favors A, or hampers B, then A will gain an advantage over B. A can use that advantage to gain more resources. Because resources are limited, B will be starved for resources. This will mean a greater advantage for A. When the cycle repeats, A will be able to gain even more resources, and B will have less.

If the cycle is not checked, it will continue until A kills off B. In cases where A and B are interdependent for survival, A will then die too.

Examples

Two recent Youtube videos provide excellent examples of the effects of the Success to the Successful systems archetype.

The first video describes how income distribution in the United States have changed in the past few decades:

The second video shows the same income distribution phenomenon occurring in Sweden. The video is in Swedish, and I have included it mainly for my Swedish readers.

Remedies


The video above shows Warren Buffet and Bill Gates discussing a remedy to the problem of uneven income distribution. It is well worth watching.

There are two tactics that can be used to restore balance in a Success to the Successful situation:

  • Identify the resource being unequally distributed, and redistribute it more equally. For example, this is why tax scales in many countries are progressive. It has nothing to do with justice. It is a way to prevent distribution imbalances that would eventually lead to economic collapse.
  • Separate the reinforcing structures, so that they no longer are allocated resources based on their relative results. For example, when Apple was being outcompeted by Microsoft and the PC manufacturers, Apple broke into the music market with the iPod. This reduced Apple's dependency on the computer market, a system dominated by Microsoft and the PC, and allowed it to build strength in an area where there was less competition.

Review

I have asked the very nice people in the Systems Thinking in Action group at Linkedin to review this post. The comment thread is here (for group members only). I will update this article whenever someone catches me making a mistake.

References

Higher Learning Research Communications, March 2013, Volume 3, No. 1
Systemic Perspective, Vol. 4, Gene Bellinger (Out of print. Visit the Systemswiki instead.)
Business Dynamics, John Sterman

Comments

Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che...
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so...
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta...
Read more