Posts tagged ‘Requisite Variety’

Goodbye Planning, Welcome Real Time Decision Making – You Can Make It Possible!

Figure source. Just some crazy thought, but suppose organizations could make all of their decisions in realtime, just like a flock of birds does? What kind of information would we need to make realtime decisions? Well, if the goal is just to “survive” (“keep flying”) it would probably be sufficient to have  information of the innovation speed and direction of direct “neighbors”. Suppose we could facilitate (supported with modern ICT) a distributed network of decision making information. And each node (decision making “entity”) in the network would get the decision making information relevant for making the most important (“survival”) decisions. So what are then the most important decisions? If we compare to the flock of birds, it’s making sure you’re “local” innovation speed and direction matches that of your direct environment. It’s allmost as if we would apply Ashby’s Law of Requisite Variety here. The law states that  “variety absorbs variety, defines the minimum number of states necessary for a controller to control a system of a given number of states.” So here you have it: you need to match your own variety with that of your direct environment. Don’t make it more complex or less complex but make sure the complexity matches. And to reduce the decision making complexity you could try to limit the number of decision making connections because that would make the distributed decision making process more complex. That is because the complexity of the network increases quadratically with the number of connected nodes. But also the value of a network increases proportional to the number of connected nodes (Metcalfe’s Law). So we need large networks to create more value. The large networks could consist of interconnected small “local” networks to reduce the total decision making complexity. So here’s a wrap up: use the distributed topology Paul Baran† designed for the Internet as a reference model for distributed decision making and as a reference model for distributed value creation, combine that with Ashby’s Law of Requisite Variety to reduce the “local” decision making complexity and combine that with Metcalfe’s Law to increase the total value of our network. If we would really do that, I wonder how our would world look like?

Culture eats Strategy for Breakfast (and how to eat breakfast)

Ofcourse you know everything about deliberate strategies or architectures (the ones you designed yourself).  And ofcourse you know everything about emergent strategy or architecture, the one that your organization realizes in reality. It’s all hidden in the golden word “real”.  So the real difference is that reality realizes real strategies, and that’s just exactly why culture eats strategy for breakfast. So next time you design a strategy (or architecture for that fact), first check with the realists in your company if it is realizable. This approach is also very good in line with Asby’s Law that states that the controlling system (“the strategy” in this example) must be equally complex or complexer than the controlled system (“the organization” in this example). So if you really want to eat breakfast next time, first ask the cooks how it should be prepared (they might give you some clues…).  Final quote: if your realists say it’s realizable then reality realizes real strategies.

Making Complex Things Simple by Making Simple Things Complex

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“.

Tag Cloud

%d bloggers like this: