Dealing With Complexity
A constant struggle in current life is “dealing with complexity and uncertainty”. At least this is what I hear a lot. Some years ago, I read the following sentence in the presentation by a consulting company: “You need to improve your management of complexity!”
In a second it struck me that there is something dreadfully wrong in this statement. I just could not nail it down.
Some years ago around the same time. Enter podium discussion at a tiny conference close to Detroit. Some agile “what-ever”. I was on stage with two big names. No idea why I was asked to participate on stage. The topic was agile scaling or rather how to run big projects in agile. At the time, I was very much into micro services and reversing Conway’s law and architecture centricity and topics around it. We were discussing the standards like big room planning, program boards, minimum viable products, walking skeletons, whatever… At one point I had an idea. “We need to manage the work such that there are as few as possible dependencies on the board. Best case scenario is NO dependencies.” That one touched a nerve and I was disqualified as not understanding systems at all. Easy bait. Lesson learned: Do not be creative on stage. Does not work. 
But: Still, the idea was attractive to me. It leads to simple solutions with very little dependencies and dependencies is where I get a headache.
Fast forward to some project management conference. Quite a few system engineers were presenting. I have seen a few people proudly showing off their skills in management of complex dependencies.
My mantra became a lot clearer: “Keep it simple, stupid.” There are many variants to the idea and it dates back a couple of hundred years. Just search the web for some trivia. Anyhow, the recommendation to the executives by the consulting company should have been:
“You need to reduce complexity.”
How to reduce complexity? Make it complicated for few and simple for many. This involves
- Unterstanding that architects are in a leadership role. They shape business and products. Cannot be separated. Both go hand in hand.
- Understanding that organizations that develop systems are systems themselves and that these are social systems of people, developing for people. (In the end there most of the time there is still a human interacting with your product. The product should be there to serve a purpose.)
- Understanding that the world is changing at a certain pace. To manage solutions, you need to be faster than the changing environment. Elements of self-management might be a good idea to maintain speed.
- Understanding that “divide and conquer” does not necessarily mean micro-management.
Why should we reduce complexity at all?
- Simple solutions are easy to build.
- Simple solutions are easy to adapt and to modify.
- Simple solutions are cheap.
- Simple solution can be delivered very fast.
Complexity kills speed. I want to move