Taking a break out of my realtime quest for Enterprise 2.0 to share something that is hampering my (our) progress right now: broken methods and denial. One of the fundamental principles of complexity is that living entities (humans, organizations) have to reconcile all new thought to existing thought (aspects of self-reference). Any attempts to compromise that process leads to psychological incongruities that manifest themselves in other ways. Or, you can’t just change an organization overnight. Imposing deep changes in principles (how people think about things, their beliefs) requires them to apply ‘adaptive’ layers to their thinking (modulators). When the gap to be modulated is really large, you’re dancing with the fundamentals of schizophrenia. There are many companies that culturally operate in this mode.

One of the nontechnical aspects of Enterprise 2.0, more relevant than for Web 2.0, is this dimension of human change (on the Web, people show up and leave at will — in organizations, they’re captive audiences and have created entire mechanisms to survive the captivity). This dimension has been there all along, but the principles of Systems Engineering never addressed it. Let me state this clearly: solutions can only be technically engineered, the rest is architecture. You cannot engineer complexity (although the concepts of Enterprise Systems Engineering introduces many of the missing principles) — you can only architect infrastructures to facilitate it. The human mind still lacks the divine insight to see, let alone understand, the dimensions of influence that comingle to create each moment in time and space.

The moment we engineer something, we’ve excluded a myriad of possibilities (indeed that’s the intent of engineering in the first place — controlling for risk). The ‘practice’ of systems engineering shapes how problems are defined and solved. The fundamentals of this thinking (or perhaps, the way in which it is typically practiced) is contrary to 2.0 thinking. The shift moves from the solution to the design (pull out your gantt charts — if the build cycle is longer than design, you’re a candidate for re-thinking). It is necessary to get exercised in the principles of design thinking.

To begin this transitional shift in thinking, embrace this possibility — there are no requirements. In reality there are requirements and indeed they’re engineering requirements. But true engineering requirements are facts. The practice of requirements solicitation, and the influence of the individuals typically gathering requirements, results in a collection of opinions. We’re not building products influenced by the laws of the materials we engage (e.g the tensile strength of steel, or the flex properties of concrete), we’re building products that should be influenced by the laws of human nature (so how many psychologists do you have on your team?). Practices need to transition from opinion-based design to evidence-based design. The goal is not to create solutions free of flaws (the greatest denial of all) but to facilitate continuous change (adaptive systems, ala. complexity).

The good news is, design thinking is actually quite natural for us. We’ve simply allowed ourselves to be overshaped by a reference model that has its place and is really good for what it can accomplish in the right situation. Enterprise 2.0 is not that situation. We’re not looking to save lives, we’re looking to free minds.