During a meeting I did a couple of years back, I was in sitting with an executive and a consulting party to assess the organization’s operating model, and more specifically, the organization hierarchy, job descriptions, and architecture. Anyhow, the executive was presenting a previous strategy consulting work that included a high-level operating model that included an unrefined n-1 organizational structure. The current organization hierarchy had little resemblance to what was in the paper, and to which the consulting party asked about the reason for such apparent deviations. The executive responded with a sentence that I don’t still ring in my ear. He said, “We haven’t deviated at all, but this always happens when you try to implement a design you have at hand.”

The thing about that response was that everyone in that room seems to agree about the existence of an unseen disjoint that we tend to design and the reality of the actual project of the design in the real world. It never matters of how compelling and useful the PowerPoint presentations, convincing word documents, how it is elegantly presented to top management. The reality that taking those artifacts and mobilizing teams and budgets to implement and deliver them will tend to fail to reach all objectives to some extent or another. And when things fail, then it is back to the drawing board while picking a scapegoat to take the hit.

I had seen this happening to me when I was a mere developer who is tasked with modeling UMLs for projects and then using tools and IDEs to generate well-structured code files and interfaces to be populated by business logic and processes. And do you know what? I, as well as my peers, modified much of the code structure to a level that resulted in mess-ups that didn’t have any resemblance to those UML diagrams. And I ended up with such an inconsistency between the architecture and the actual implementation that forced me to lie to my management and to say everything is a-okay. Because hey, it is all about what works and functions and not we keep in files and documents.

The design and delivery paradox is real, and there is no way running from it. Yes, everyone is moving to an agile model at an organization-level (it worked for those geeks and the software they develop, so why not implement it at the business operating level). But it is still finding hard spots to land in. And even with permitting an organizational growth with an agile and product-focused mentality, it always doesn’t resolve the paradox of taking the business aspirations and objectives and translating them into an adjusted operating model that doesn’t deal with producing code every time a scrum team plan for a sprint.

The complexity of systems, whether they are as complected as running a country or simple as managing a household, implies dealing with an unlimited number of knowns and unknowns. This makes it impossible to ensure an accurate representation of a system from the idea of its inception to the level where it runs within the world. Thus, any design should include many characteristics ensuring its flexibility toward dealing with a world that is chaotic by nature.