Can you analyse the natural bricolage process of engineers compared with the procedural discipline of methodologists and categorisers such as Snowden and Hoverstadt

The tension between the natural bricolage of engineers and the procedural discipline of methodologists like Dave Snowden and Patrick Hoverstadt represents the clash between “unselfconscious” adaptation to a messy reality and the “self-conscious” attempt to manage it through formal models[1].

Based on the sources, here is an analysis of these two competing modes of engaging with complexity:

1. Natural Bricolage: The Engineer’s “Deep Smarts”

Engineers and practitioners often rely on experiential know-how—what Nassim Taleb calls “practical knowledge” (the green lumber fallacy)—rather than textbook theory[4][5].

Stochastic Tinkering: Following Taleb, this process involves making small, “safe-to-fail” mistakes to gather information from the environment[6][7]. This is “bricolage”: using whatever is at hand to “nudge” the system into a more desirable state[6].

Muddling Through: John Flach advocates for incrementalism. In “wicked” systems, the most rational path is not perfect foresight, but making small, reversible moves and correcting course based on feedback[10].

Recognition-Primed Action: Herbert Simon demystifies “innate ability” as recognition[13]. Experienced engineers recognize familiar patterns (“chunks”) stored in memory, allowing them to access solutions unselfconsciously without an exhaustive analytical search[14].

Work-as-Done: This approach prioritizes how tasks are actually achieved on the “sharp end,” often through intelligent workarounds that circumvent rigid, ineffective procedures (Work-as-Imagined)[17].

2. Procedural Discipline: The Methodologist’s Map

Methodologists and categorisers attempt to provide cognitive infrastructure to prevent groups from falling into behavioral pathologies like “Spreadthink”[20][21].

Dave Snowden (Cynefin): Snowden emphasizes multi-ontology sense-making[22]. While he supports “safe-to-fail probes,” his discipline requires first categorizing the environment (Simple, Complicated, Complex, Chaotic) to determine the appropriate response[23].

Patrick Hoverstadt (VSM & Grammar): Hoverstadt utilizes “Variety Engineering” to design for organizational autonomy[26][27]. His “Grammar of Systems” posits that there are universal cybernetic laws (like feedback loops and recursion) that must be strictly followed to ensure a system remains viable[28].

Codification and Abstraction: Max Boisot defines this discipline as the effort to compress fuzzy data into stable codes and generalized categories that can be easily shared and scaled[31][32].

3. The Core Conflict: “Handle-Turning” vs. “Dancing”

The sources, particularly from “The Other Group” (TOG) and “Meeting of Minds” (MoM), provide a sharp critique of the divide between these two stances:

The Trap of Functionalism: Critics argue that methodologists often engage in “handle-turning”—applying a framework (like VSM or Cynefin) mechanically without understanding the unique physical constraints or value of the outcome[9].

The Museum Fallacy: James Wilk warns against the belief that reality comes pre-labeled in fixed categories[35][36]. Methodologists risk “mutilating” the problem to fit their preferred tool[37].

Instruction vs. Perturbation: Humberto Maturana points out that a system is structure-determined; you cannot “instruct” it to change[38][39]. The methodologist’s plan is merely an irritation; the system’s internal logic determines how it will react[40][41].

The Net and the Catch: As noted in our previous discussion regarding Dennis Noble, the methodologist’s choice of “net” (the framework) determines what they “catch” (the data) [user-provided context, 1521].

Summary of Stances

FeatureNatural Bricolage (Engineers)Procedural Discipline (Methodologists)
Logic ModeAbduction (Best guess/Hunch)[10][42]Deduction/Induction (Linear steps)[43][44]
GoalViability and Resilience[45][46]Optimization and Control[47]
View of FutureIndeterminate/Unknowable[50][51]Predictable via Modeling[52]
Source of OrderEmergence (Bottom-Up)[55][56]Frameworks (Top-Down)[57][58]

--------------------------------------------------------------------------------

Do your current projects rely more on the “Deep Smarts” of veterans who know which variables to ignore[8], or are you currently trying to “turn the handle” on a formal methodology to find an answer?