We tend to make complex things simple by astracting (hiding!) the complexity into an area where we can easily “forget” about it so we can concentrate on the things we call our core competences. This however can often lead to popping up new or unforeseen complexity in other areas. So when you start abstracting a certain complexity never forget to investigate where the new complexity will pop up and how you’re going to handle that new redistribution of complexity. A typical example is outsourcing: by abstracting the complexity of let’s say commodity ICT technologies, you are distributing that complexity to other parties. But inevitably you will have to compensate for that “simplification” strategy by organizing something new, in this case: managing the party that you have given part of your controller functionality. It’s all in Ashby’s Law of Requisite Variety: your own “complexity” as a “controller” must match the complexity of the system you want to control. Take the simple example of a traffic light: it has 3 states (Red, Orange, Green). You as a car driver heading towards the traffic light system are in this example the “controller”. As a controller you must understand the complexity of the system you want to “control”, which is the traffic light system. So your control complexity must be at least that of the controlled system: you have to understand the complexity of the 3 states Red, Orange, Green. If you “outsource” your controlling function to another party, you have to trust that they know the complexity of that system, so far nothing wrong with that if you can make clear to the outsourcer what the complexity of the system is that you’ve given control trust to. If you start moving complexity around just because you want to avoid it a any cost, you should start asking yourselve questions if this is still the right approach. Ulbo De Sitter (founder of the sociotechnique in the Netherlands) has a vision on this that I really like: “complex tasks in a simple organization instead of simple tasks in a complex organization”. I wonder what kind of working environment we would achieve if we combined this sociotechnique vision with the following statement from the Diversity Demotivator®: “every person deserves an equal chance to prove their incompetence” and combine that also with avoiding organizing your company around the Peter Principle: “in a hierarchy every employee tends to rise to his level of incompetence“.
Posts tagged ‘Task complexity’