Solving Complex Problems
Next: Fractal Architectures
Complex problems
If decentralised communities ever are going to matter in any meaningful way, they need to address complex problems
Complex problems are ones where the underlying factors are interconnected in multiple ways, forming one or multiple loops. Changing one thing leads to a cascade of secondary, tertiary and so on changes that in turn affect back the source.
Different stakeholders tend to promote quite different approaches, and do not often even share the definition of the problem. There is also disagreement on who has authority to address the issues.
Urban planning is a typical domain, where people often share common desire to live in a prosperous and safe city with lots of activities to choose from but widely disagree on ways to achieve this.
The root cause for this often is that decision making becomes a status game where its more important who gets to decide rather than what the decision is. Some model is needed to overcome this.
How to Solve Complex Problems
There are specific frameworks for solving such issues. See for example Alexander de Haan’s Solving Complex Problems: Professional Group Decision-Making Support in Highly Complex Situations
They are based on a notion that there are quite a lot of cases where people coming from different directions and having different world views can still find solutions that they agree on. They do not agree necessarily on the ideological background, but can still find things that for different reasons are the same. I.e. finding common ground while maintaining uncommon desires
The model in the above-mentioned book is (as far as I understand) as follows.
First thing to do, is to understand the environment (context). This means mapping what things in the environment affect each other.
If we make this change, what parts are directly affected, what are in turn impacted by the first line of changes and so on (secondary effects). Complex systems form closed loops where one change affects many other parts of the system that in turn change the area that was originally changed. There are many examples of today’s policies where a good sounding policy backfires badly. This type of modelling creates a system where one can think of a multitude of ideas in different parts of the system (we can change this thing or that thing or that third thing). There is no need to get fixed into a single idea.
Next is to understand different stakeholders’ primary goals, not just what they now propose. As example assume people propose building an extension to an airport but part of the population opposes due to increase in noise and pollution. Both groups (or majority of these groups) might agree that getting more visitors to the city increases economic activity, brings jobs and prosperity which are positive things. They may not share what exactly are the positive effects (more business activity to private companies vs. more tax income to city to build better services) and share some of the views (more jobs). Still from different starting points share the same ultimate goal. Now airport extension is just one of the many options that are possible to increase economic activity and vibrancy in the city.
This opens up the mind to think of a multitude of ways to reach the goal, think about more than one action. The dependency graph is a good source for ideas and shows when several actions work together and strengthen the outcome. It’s a tool for different groups with different motives to find common ground at least on part of the topics.
The core idea thus is not for some team of leaders or experts analyse, generate possible solutions, evaluate and prioritise, develop action plans and implement but to create a tool that acts as a discussion table for stakeholders and once something emerges, this can be planned, implemented and then monitored how it worked (or not as even the best laid out plans of mice and men often go awry).
The voting models in previous posts are more to ensure that the decision making processes are somewhat in order so firstly sensible candidates can be generated and that things do not immediately go kaboom after implementation.