Stopping the Enterprise Death Spiral with Mob Programming

Stopping the Enterprise Death Spiral with Mob Programming

In 1963 Dr. De Solla Price developed “Price’s Law.” Price’s law describes unequal distribution of productivity in most domains of creativity. The original target of this study was the scientific community and the contributors to it’s advancement.  Dr. Price discovered that half of all scientific contributions were made by the square root of the total number of scientific contributors: so if there are 100 scientists within a given discipline, just 10 of them will account for 50 percent of all publications.

What’s fascinating about this law is that it also applies to human productivity of value in any domain. Let’s look at an example:

Out of all the classical composers who existed only 5% make about 50% of the classical repertoire. Now take that 5% and realize that only 5% of the music they wrote makes up about 50% of all their music played.  

NOTE : This finding goes hand-in-hand with the many examples of Pareto Distribution (

Another example:

Let’s say you are at a company with 10 people; the law states that approximately 3 people will be responsible for half of the productivity of value. Scale that out to 100 and now it’s 10 people who are responsible for half the productivity of value. Now scale that to 10,000 and you have 100 people responsible for half the productivity of value.

Took a look at what happens at scale…


What happens when a large company has a couple of rough quarters? Sometimes they will begin layoffs.  Those 100 people who are highly productive and create a lot of the value?… some of them may be the first ones to leave. The attrition could be for many reasons, but it’s a reality and it can start a death spiral as people who are the most creative and produce the most value walk out the door. Then, as things get worse, more of people leave and the spiral continues and increases rapidly.

In the last 40 years only 12% of the Fortune 500 remain. We need highly skilled and creative people in our companies not only doing the work themselves but actively helping to bring others up to “their level.” And treating these people like “resources” from a top down management approach is the opposite approach we should take if we want to accomplish this. They are a major key to the company’s success!

So, what is one way we can take on Price’s Law and scale creativity, productivity, and quality?


Mob programming!

From a software development team perspective, mob programming is the practice I recommend based on past experience to develop cross functionality, build in quality from the beginning, and increase competency and team performance.

Mob programming is an agile practice created by Woody Zuill (@woodyzuill) which is the successor to pair programming. I’ve seen it change team dynamics drastically and not only grow skillsets but increase competency as well.

A “mob” is made up of 3 or more people and is based on something called “strong-style” pairing; this is a pairing technique where the person with the idea does not do the programming. In other words, in order for something to get from your head into the computer, it cannot go through your hands.

To quote Woody Zuill: “All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer.”

Here are the rules:


  1. Provide an environment of safety
  2. Use a strong-style approach
  3. Rotate frequently (3,5,7, or 10) min intervals.
  4. Everyone drives
  5. Everyone navigates


The Driver is the person actually typing at the keyboard. This person is not doing much thinking but taking instruction from the Navigator . The Navigator is the person who is responsible for what is being typed (along with the rest of the “mob”) but for this interval they are leading the conversation.

One great thing about a mob approach is it doesn’t matter what your skill level is, you can participate. I once facilitated a 30-person mob session with only 3 developers in it! I don’t recommend that in practice as it’s too many people, but I wanted to show how it worked to a large number of people in 90 minutes. In my experience the ideal size for a mobile is about 3-7 people. You don’t need to be a developer to participate…in fact it can be awesome to have some non developers in the mob, like people with a QA background, BA background, Product owners, etc.

For people who have a lot of experience, the Navigator just has to provide high level of instruction. For people who have some knowledge the Navigator can be more detailed and for people who have no idea how to do it, the navigator can tell them exactly what to type. The point is everyone gets to drive and experience doing the task in real time with others. Usually when you are done driving, it’s your turn to navigate. Remember… everyone navigates! If the Navigator doesn’t know what to do they can lean on the rest of the group to help them problem solve collectively. If they are highly skilled in that area than the rest of the group can observe, offer input, or ask questions.

Mob programming can help break down siloed skill sets, foster team collaboration, engagement, ownership, and grow competency among not only the team but the organization as a whole. As more people grow the relevant communities of practice become stronger. Once a team becomes high performing, said team member can volunteer to move to another team and mob with them to help accomplish the same goals….Making the company stronger, increasing throughput through the system, and increase productivity across the company!

Of course, I’m not suggesting mob programming is the only thing you should do to prevent a death spiral, but I believe it is a great place to start.

For more info on mob programming check out Woody Zuill’s talk here:

I have a video on YouTube called TDD and Mob programming for non-programmers which was done via skype with people who never programmed before. You can see that here:


Stopping the Enterprise Death Spiral with Mob Programming

By Troy Lightfoot

Twitter: @g4stroy