The idea that one can work on the system or the people is an example of a dichotomy. Splitting something into a dichotomy is often a bad idea since reality tends to be more gradual. In all fairness though, Deming worked in manufacturing and it is reasonably straightforward to separate the system from the people here. You have the machines, trucks, robots and all sorts of physical things that make up the production line. This is not the case in software. People have their workstations but you can not see a production line. Some would argue that there is a virtual production line that can be described even though it is not visible. I think this is bollocks. If you follow a number of features from idea to deployment you will find that the “production line” is unique to each feature. The people are the system in software. Individuals will dynamically decide to send a problem to a colleague if they believe that this will help in getting it solved.
If people are the system in software development the whole idea of separating the system from the people becomes mute. As an example, if you introduce pair programming are you changing the system or the people? The answer is of course both. There are in fact many things that you can do to enhance the capability of the people in order to improve the system. The fact that there are many stupid things that you can do to the people in a software company is not proof of the system/people dichotomy. Yes, performance reviews are mostly evil but that does not prove that you should work on the system. Most software companies should work more on helping their employees increase their capabilities, not less.
There is a second reason that statements about system versus people are pointless. The message is sender oriented. If you want to influence someone you need to figure out how they think and tailor your message so that it makes sense to them, not you. I have met quite a few managers of software developers over the years and most of them do not think that their primary problem is the people. What they do tend to think is that they have a system that is not working well and they are trying to figure out how to make it work better. The problem is that the changes they introduce very often make the system even worse. Telling these managers that “you should not work on the people, you should work on the system” is absolutely pointless.
Software development is a network of people solving a problem. If we want these “systems” to improve we have to demonstrate changes that work. Some of these focus on how the network works as a whole while others focus on increasing the capabilities of the individuals.
Note
Some of the people that have responded to this post seem to have gotten the impression that I am arguing against systems thinking in software development. That is not my intention. For me systems thinking is the study of a system as a whole. In this perspective people are part of what you study. Only after deep study do you start drawing conclusions as to what should be modified. In many cases the causes of problems can be found in the way the system is set up. It is also true that managers efforts to make things better can often lead to the opposite. The only cure for this is to help managers better understand how the system works. Once they understand the system better they will realize that some of the things they were doing were misguided. The problem is in other words managers lack of understanding of the system, not that they are evil or only focus on the people.
Niklas Björnerstedt
Comments are off for this post.
8 Responses to The people are the system!