According to Deming 95% of variation in the performance of a system (organization) is caused by the system itself and only 5% is caused by the people. This also known as Deming’s 95/5 rule. This sounds counter-intuitive and people often argue that having great people would solve the problems. There’s also a firm belief among startups that great team can make shitty product a good one and bad team can fuck up a great product. They believe that people have greater impact than mere 5%. Many also argue that we should invest in people, coach them, motivate team members and do other “people stuff” to get better.

Denim explained the theory in Youtube video:

Deming’s point was that in most processes any effect that the individual may have is swamped by the system their are part of, in fact the variability they cause is just part of that system overall. So if measurements are falling within the confidence limits you can’t point to one person over another and say they’re better or worse.

Focus on the customer

Dispite the Deming’s focus on system he still thinks that “The consumer is the most important point on the production-line.” (source)

This leads us the APIs and primary customer which is a developer solving problems with your API. I hate processes, but systems are build on top of processes. I would love to work with others in the company without processes, but that just does not work. Consider the API development. You have multiple people involved in the process; they are acting in a system. I agree that Deming’s view points looks a lot Tayloristic and resembles idea of “T-ford factories filled with people doing one specific task again and again”. We do live in specialised world. API development and productisement requires multiple disciplines and specialised talented people. Generalists do not flourish in the workflow.

Automation

When Deming was writing his theory automation was still taking baby steps. It was applied mostly in factories with physical objects. Now the business has more turned into service driven business. We buy services, not goods. People don’t want to own, but get access to. In IT the automation really kicked in when DevOps started to spread. Then everyone started to automate IT development tasks. Of course people (developers) had been writing scripts and application to automate even before that, but DevOps as a phenomenon took automation to the next level.

Now agile organisation developing APIs automate all they can. Aim is to reduce the amount of people in the process; at least in managing the boring repetitive and non-creative tasks. Still human designs the API based on the human given feedback. Humans implement the logic in the API (although it can be automated partially). We humans still review results such as documentation, guides and examples. Human is where the machine driven solution is still too cumbersome to handle or takes too much effort to build (low ROI).

Despite the fact that humans are still needed in validating logically the results in API development, machine driven processes are taking over more and more.

When to automate?

I recommend against upfront automation – always do something manually a couple of times, so you understand the failure points and consequences. Attempts at upfront automation seem always to lead to frustration. Upfront automation also lead to over-engineering, or perhaps it would be more accurate to say that you end up solving the wrong problems.

A sequence of actions performed manually multiple times is a surefire recipe for disaster. Instead, try this:

As you are performing ruthless automation, you should be also doing ruthless simplification. Now if in 1980s claim was that 95% of variation in the performance of a system is caused by the system itself, what is the number now in IT? We have devops; all developers build automation solutions even for small tasks.

If you believe in the Deming’s theory, you should be focusing on the processes in system to increase the performance more easily than educating your staff.

Some more to read from 100 Days DX