The people are the system!

A couple of years ago I ranted about the way that people have created a religion around Deming and take his statements as absolute facts. In particular the statement Deming made about the importance of the system versus the people irked me. Recent work has made me revisit this topic and I now realize that Deming’s statement is more or less irrelevant in the domain of software development.

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

Posted on 2013.04.17 at 12:59

Comments are off for this post.

8 Responses to The people are the system!

  1. I don’t know if you noticed it yourself, but I think this is the most important thing I’ve read all this month:

    “If you follow a number of features from idea to deployment you will find that the “production line” is unique to each feature.”

    If true, this, as they say, changes everything.

  2. smalltalk80 says:

    Hi Johannes,
    Yes, this is something I believe a lot of people get wrong. They implicitly assume that software development can be described with the same models as manufacturing or even service delivery. A good software team is a network of individuals that dynamically decides how to solve a problem.

  3. Joakim Holm says:

    Hi!

    I agree with most of what you say in your post. It’s very much along the same lines as my own thinking. On a micro level, people are much more important in software dev than in, for example, a factory setting. But something still bothers me about “The people are the system”.

    Do you agree that “the system” is the context, the environment in which people are trying their best to achieve some results? If you do, that is a very big context. It would include things like office furnishing, management culture, customer agreements, outsourcing strategies etc etc, as well as obvious things like the micro process the team employs for each feature. Most of these things are beyond the power of the individuals or the teams to change, but have a serious effect on the effectiveness of their work. Only management, and sometimes not even them, can change them. This is also “the system” and it can have a very real detrimental effect on the outcome of the work even in software.

    I think the statement is simplistic. I suggest this wording: “The system consist more of people than in many other areas”. Not as catchy, I’ll admit.

  4. smalltalk80 says:

    When I say that the system and the people cannot be separated it does not mean that all actions have an equal effect on both. There are things that have more to do with the system and other things that primarily affect the people. But then again there are things that have a profound effect on both. The danger with using a system/people dichotomy is that many statements become tautological. If you think something is bad you describe it as a people thing and if you like it you do the opposite. I think it is better to review possible actions and decide whether they are good or bad based on the effects they will have. Pair programming is often a good thing since it has positive effects on both the people and the system. Performance reviews are mostly bad.
    I also agree that my description of the system was too narrow. There are many aspects of the system that do not have to do with the “production line”. But these aspects are also embodied in the people. A typical company has loads of written procedures of which only a fraction is actually followed. The way the system works is usually decided by the interactions between the people.

  5. Joakim Holm says:

    Yes, one danger with using the people/system dichotomy is that there is something fatalistic about it. “F*ck, it’s the system, man. Can’t do nothing about it.” But it’s like management. We created the system. Hence, we can change it.

    But I feel it _is_ useful to be able to talk about how forces outside of teams and development organisations affect them. These forces are often seriously underestimated (or even unknown). There, I think, the system metaphor of an organisation is nice and easy to grasp. Or do you have another suggestion?

    I’ll finish off with a “poem”:

    Some Things
    ———–
    Some things… are in our minds
    Some things… are external
    Affect our minds more than we think

    Some things… we can change
    Some things… other’s can change
    We can change more than we think

    Some things… are unchangeable, decided
    Buried in the walls
    To change those
    We must cease and be born again

    :)

  6. smalltalk80 says:

    I am not against using the term system to describe things that are out of control of the individual. What I do not like is the dogmatic faith in a statement Deming made in another age and in a different context. In my experience, many command and control software houses focus too little on increasing the capability of the individuals while building workflow systems that try to treat software development as if it were a production line. Telling managers in these companies that they should focus more on the system will get you nowhere.

  7. allan kelly says:

    Try this thought experiment:
    - if we can perfect the system they we have a repeatable process
    - if we have a perfect system we can write it down
    - if we can write it down we can automate it

    We like automating things, we do software. Remove the people from the loop.

    What next?

    Automation is good in itself (more efficient) but the next step is to build on it. We can reach for more difficult problems, we can introduce innovation.

    The thing is, when we do this we can’t automate it because we can’t understand it (yet) so we need people.

    Thus we are back where we started only at a higher level.

    I would argue this has happened several times already. e.g.
    - Building software was hard
    - So we invented make
    - We started building more complex software
    - So we invented more sophisticated tools
    - Continuous delivery became possible

About Niklas

Born in Sweden, grew up in New York, lives in Norway. Yes, I have problems with identity, but I do think that my background helps me see things from a different perspective.

Read more