Three Phrases Every Consultant Hears
"I can't see how the crisis is affecting the company"
"I can't see how the company behaves in a crisis"
"I can't see how we can change during a crisis"
The key word here is can't see. Not "don't know," not "don't understand." Specifically — can't see. The problem isn't a lack of data. The problem is the absence of a language capable of describing and showing what happens to a company's structure under pressure.
The Problem: Company Structure Is Described as a Photograph
Classical tools — org charts, UML diagrams, process descriptions — capture a single state. A snapshot. Here are the departments, here are the connections, here are the functions.
But in a crisis, the structure moves. People become overloaded, roles blur, departments contract, business directions die off. A static diagram won't show any of this. It becomes outdated the moment it's created.
What's needed is not a snapshot, but rules for how the snapshot changes. Not a description of the structure, but a description of how the structure transforms under pressure.
Theoretical Framework: Taleb and Three Types of Systems
Nassim Taleb identifies three levels of system response to stress:
• Fragile — breaks under pressure
• Robust — withstands pressure, maintaining functionality
• Antifragile — grows stronger from pressure
What is described in this article is not antifragility. A company doesn't become stronger from a crisis on its own. This is about robustness through managed structural reorganization: the ability to maintain functionality by reorganizing from within.
An Analogy from Frontend: Adaptive Layout, Not Fluid
In web development, there are two approaches to how a website responds to screen size changes:
Fluid layout — everything changes smoothly, continuously, totally. Blocks stretch, compress, overflow. There are no fixed modes. If the rules are poorly defined — elements break out of bounds, the interface falls apart.
Adaptive layout — the system operates in clearly defined modes with specific boundaries. When a threshold is reached — the layout restructures: the composition changes, blocks appear or disappear, the placement logic becomes different.
A company that responds to crisis in a "fluid" manner — without clearly defined modes — becomes unreadable to external players. Clients, partners, suppliers, regulators don't understand: who is responsible for what right now? What commitments are in effect? Where are the boundaries?
A company built on the principle of adaptive layout presents clear states to the outside world. Flexibility lives inside. A readable operating mode is what's shown outside.
Two Levels of Change
A company's structure in crisis doesn't change in just one way. There are two fundamentally different mechanisms:
Continuous Level (Within the Structure)
Roles, functions, employee workload, task distribution — all of this changes smoothly, within ranges. As long as the structure holds — the system compensates for pressure by redistributing the load.
Example: a department of 10 people, each with one professional profile. The crisis reduces headcount — the number of profiles per person grows. People take on more.
Discrete Level (The Structure Itself)
Departments, business directions, organizational units, connections between them — these change abruptly. This is reassembly: merging departments, removing management layers, shutting down business directions.
Example: employee profiles are a reflection of business directions. When a department shrinks below a critical threshold — it's no longer about overloading people. The budget can't sustain it, adjacent departments can't cope. This means the business directions themselves must be cut.
The key point: first, the system compensates internally. When the internal resource is exhausted — structural reassembly occurs.
Crisis Is Not a Single Parameter
A single cause of crisis generates multiple parallel consequences for a company:
• Financial pressure (cash flow, budgets)
• Staffing shortages (layoffs, overload)
• Operational overload (processes can't keep up)
• External environment pressure (regulators, market, clients)
A crisis doesn't strike along a single axis. It hits the entire system simultaneously.
Cascading Threats: Not a Gradation, but a Screen Rotation
When multiple threats coincide — the company's response is not sequential, not "step by step." It's not a gradual deterioration with a transition to the next level.
It's an instant mode switch. An analogy from the same frontend world: not a window resize, but a screen orientation change — portrait → landscape. Everything restructures at once and entirely.
A company that lacks pre-defined rules for such a switch loses controllability at that very moment.
Language Architecture: Two Layers
Layer A — Structure (UML Level)
The base description: departments, people, roles, functions, connections, business directions. This is the company's "skeleton" at a given moment. Classical UML handles this well.
Layer B — Deformation Rules (CSS Level)
A description of how the structure changes as pressure shifts:
• At certain environmental parameters → headcount changes
• At certain parameters → departments are reorganized
• At certain parameters → new functions and responsibilities are introduced
• At certain parameters → business directions are cut
This is not a static description, but a set of cascading transformation rules — analogous to how CSS defines rules for changing the display when conditions change.
Why the Visual Layer Matters
An important note: the company's business model doesn't change through this process. What changes is the internal organization. But to manage these changes, they need to be visible.
When the structure and its dynamics are visualized:
• Assessment criteria can be assigned to every element's state
• UI dashboards can be built for monitoring and analysis
• It becomes possible to see in real time: where the overload is, where the gaps are, where the structure is at its limit, where reassembly is already needed
Visualization is not decoration. It is a management instrument. Without it, the executive returns to those same three phrases: "I can't see."
Conclusion
A company is a system with two layers of dynamics:
• Internal → continuous redistribution of roles, functions, workload
• Structural → discrete reassembly of departments, connections, business directions
What's needed is a language that describes not a single state of the company, but the rules of transition between modes. A language in which:
• The UML level defines the structure
• The CSS level defines the rules of its transformation
• The visual layer turns this into a manageable, observable system
Then the executive stops "not seeing" — and begins to manage not by intuition, but by architecture.
Top comments (0)