Mycelium Organizations: Phenotypic Plasticity for Continuity via Unity in Diversity

Introduction: The Challenge of Dual Business Modes

Equipment enterprises that sell standard products and handle custom projects often struggle to run both in one organization. Standard orders follow stable processes; custom projects require cross-functional judgment. Forcing all projects through the same flow creates bottlenecks; creating separate teams duplicates resources and prevents knowledge sharing. The problem goes beyond centralization vs. decentralization: the organization must accommodate different work styles while remaining a single, cumulative entity.

Biological Metaphor: Phenotypic Plasticity

In biology, phenotypic plasticity describes how a single genotype expresses different traits under different environmental conditions. Fungal mycelium exemplifies this: a shared underground network (the core) supports diverse above-ground fruiting bodies (the frontline) that adapt to local conditions. The article adopts this metaphor — "strong core, live frontline" — to explain how an organization can maintain a common foundation while forming task-appropriate structures that change with circumstances.

Unity in Diversity (一体多态)

Shared Foundation Connects Diverse Forms

"Unity in diversity" means the common foundation and the varied forms support each other. The "unity" gives teams shared direction, rules, and capabilities; the "diversity" lets them organize work differently per task. Only when linked does local flexibility enhance overall organizational capability.

Organizational Forms as Work Modes

Organizational form is reflected in how people combine, collaborate, who decides what, and how resources reach tasks. Department names on a chart may stay the same while daily work adopts different modes: a mature order runs through a stable process, a complex project uses a cross-functional team, an uncertain opportunity is explored by a small experiment. These modes can coexist and transform as tasks evolve.

Strong Core, Live Frontline

The mycelium model connects foundation and form through "strong core, live frontline." The core guards shared purpose, basic rules, public capabilities, and risk boundaries. The frontline organizes action based on customer and site conditions. The core provides reliable support; the frontline brings back new problems and experiences. This round trip lets flexible collaboration rest on a stable base and lets the common foundation update.

Shared Direction: Consistent Commitment Understanding

For the equipment enterprise, shared direction first appears as a common understanding of customer value. Both standard and custom teams must honor the company's quality and service promises — not push unconfirmed technical conditions or delivery dates to clients for their own performance. Teams may work differently, but their understanding of commitments must align.

Shared Capabilities: Reusing Accumulated Assets

Shared capabilities let different teams leverage existing assets: technical documentation, validated design methods, supplier capabilities, quality requirements, and past anomaly records. When a team reassembles for a new task, it doesn't start from scratch; the organization's previously built capabilities keep pace with today's work.

Shared Rules: Connecting Responsibility Across Changes

Shared rules ensure responsibility connects. A customer's purchase promise doesn't vanish because internal staff reshuffle. The project owner coordinates delivery, engineers guard technical judgments, quality staff perform inspections. When phases shift or people leave, unfinished commitments must be explicitly handed over — not end just because the original team disbanded.

Updating the Foundation

The common foundation needs entry points for updates. When custom projects encounter conditions that existing methods can't explain, they should surface facts and improvement proposals so the owners of relevant standards re-examine current arrangements. This preserves organizational wholeness while allowing local exploration to influence shared methods.

Different Collaboration Modes for Different Tasks

Standard orders have clear specs and handling rules; stable division of labor reduces re-confirmation. Custom projects have interdependent requirements, technical solutions, and delivery conditions; separating judgments and stitching them later may miss cross-issue links. In custom projects, having sales, engineering, and delivery people work jointly on the same customer problem ensures necessary judgments meet in time. Sales knows usage needs, engineering explains technical constraints, delivery confirms site conditions, and the project owner structures the solution and fulfillment. The customer still talks to a clear company contact; internal cross-functional collaboration is organized by the enterprise.

Role Fluidity Based on Capability

Roles shift with tasks. An engineer who understands field-use problems can take key judgments in a custom project, then return to the professional team to build technical depth, mentor juniors, and maintain methods. "Capability is identity" means task assignment depends on what problems a person can solve, not just their title. This opens contribution space beyond positions, but new roles still require professional qualifications, explicit authorization, and matching resources — not just a verbal endorsement.

Employee Experience and Sustainability

Employees need clarity on what flexibility means for them: time allocation, original duty adjustments, contribution recognition, post-task growth. If every ad-hoc team relies on a few key people working overtime, the enterprise gains only temporary speed while burning future capacity.

Extending to Partners

When external expertise is needed, partners can join specific tasks. Internal standards, interfaces, and responsibility structures help integration, but partner investment, returns, information use, and post-exit responsibilities must be explicit. Diversity expands collaboration space, letting both sides create value together; sustainability depends on fair exchange and reliable fulfillment.

Dynamic Adaptation (动态适配)

Continuous Re-assessment and Adjustment

"Dynamic adaptation" describes how an enterprise re-judges existing arrangements as environment and tasks change, adjusts people, resources, and collaboration modes, and corrects based on results. It includes change, retention of still-effective practices, and termination of arrangements that have lost value.

Situational Awareness as Basis

Facing shifting customer needs, sales, engineering, and delivery staff must connect customer requirements, technical conditions, delivery pressure, and available resources to understand the current business situation and its possible evolution. They then judge whether existing processes suffice or collaboration arrangements need adjustment. This situational awareness underpins dynamic adaptation.

Authority Matched to Capability and Consequence

Sales can respond within existing commitments; new technical risks go to qualified and authorized technical leads; cross-business resource conflicts are decided by the business owner; other matters beyond authority go to the relevant responsible person. Proximity to the frontline brings information advantage, but decision rights must align with capability and accountability.

Real Resource Trade-offs

Getting engineers involved early in custom requirement assessment requires managers to make real resource trade-offs. When standard and custom work need the same engineer, the business owner can protect existing delivery commitments while carving out limited time for custom assessment, postponing a non-critical improvement. The engineer focuses on assessment early, then supports key milestones during manufacturing. The custom project gets timely expert judgment; the standard team bears the cost of delayed improvement.

This decision must verify that current delivery is truly protected and explain reasons to affected people. If nothing can be postponed, the owner must renegotiate the custom project's timeline or scope, or add resources. Simply adding the engineer to a new chat group without adjusting original tasks only forces one person to juggle two incompatible commitments.

Experimentation for Exploratory Tasks

For exploratory tasks where it's unclear if a new customer need warrants a product, the enterprise can assign a few people for a limited time and budget to compare options and validate demand. As the need clarifies and business repeats, the organization should establish more stable division of labor and delivery arrangements to reduce the cost of continuous experimentation.

Review and Institutionalize Learning

After engineers join requirement assessment, managers check: did it reduce rework from missed requirements? Were existing deliveries kept on schedule? Did postponed improvements increase later costs? If the arrangement only fits a few special projects, keep its scope limited. When similar needs appear repeatedly, consider dedicated support time or training more assessors. Expand, correct, or stop — all based on actual results.

From One-off Fix to Organizational Capability

A single adjustment solves the immediate problem, but the further question is: when similar tasks recur, can the enterprise reuse this experience? If every project depends on the owner temporarily finding people, re-explaining, and re-negotiating, the organization is merely firefighting, not building sustained adaptation capability.

Codifying and Validating Experience

Sales and engineers can turn easily overlooked customer usage conditions from assessments into requirement clarification checklists: which issues sales can confirm first, which need engineering judgment, which situations still require separate evaluation. This helps later teams prepare necessary information earlier. Customer-specific designs retain their applicable scope and are not blindly generalized.

To avoid treating one project's effective practice as a universal method, these experiences must be independently used by other qualified people in new tasks, verified by those not involved in the original trial, and formally adopted and maintained by the owners of relevant standards or methods before entering public capabilities. Saving documents only leaves materials; whether later actors can act on them still needs practical validation. The organization must also recognize the contributor's value, giving them opportunities to own method maintenance, complex judgments, or talent development.

Closing the Loop: Frontline Changes Update the Core

Thus frontline changes and core updates form a cycle: shared capabilities support new tasks; new tasks test existing capabilities; validated findings improve shared capabilities. "Unity in diversity" and "dynamic adaptation" connect here. Teams may dissolve, people may switch roles, but the formed knowledge, standards, and professional links remain as conditions for the next action — the enterprise doesn't restart from zero with every change.

Maintaining Continuity in Change

Continuity means that when the organization changes team compositions, collaboration rhythms, and resource allocations, shared direction, customer commitments, professional capabilities, and accumulated experience still connect seamlessly. It requires managers to discern which foundations are worth keeping, which arrangements should change, and to bear the cost of those choices.

Question Uniform Requirements

Managers can first examine the rationale for uniform mandates. Quality inspection, critical commitments, and common data standards need reliable consistency. But must different businesses also use the same reporting cadence, identical team compositions, and identical execution steps? That should be answered by task conditions. A requirement effective in standard business doesn't automatically suit an exploration project.

Weigh Opportunity and Cost Together

When deciding whether to continue supporting a custom project, the owner must judge opportunity and cost together. Custom demand may open new business space or merely consume scarce engineering time. Establishing a collaboration mode for it must explain what the customer gains, what the enterprise invests, and whether that investment is worth continuing. The project owner owns the task; the business owner owns the trade-off between businesses.

Watch Coordination Overhead

Using multiple organizational forms can increase coordination costs. Constantly rotating teams, people receiving multiple conflicting directives, and repeated coordination for the same work may push diversity beyond the enterprise's management capacity. If tasks are highly repetitive and current processes deliver reliably, stability has good reason. If the bottleneck is talent shortage, structural tweaks alone won't solve it.

Resilience Requires Maintained Capabilities

Organizational resilience must be understood in this process. When a key engineer is absent, if knowledge is retained, others are trained, and collaboration links can reconnect, the enterprise has more ways to recover work. If knowledge stays only in individuals, even the most flexible team can be blocked by one person's absence. Resilience needs maintenance and investment; phenotypic plasticity provides adjustment possibilities but cannot automatically fill missing capabilities.

Judge Change by Real Outcomes

Whether a change is worthwhile ultimately returns to the actual situation of customers and the organization. Are customer problems solved faster and more reliably? Do commitments still have owners? Do participants get needed support? Do other businesses bear excessive cost? Can new experience help later comers? Has the enterprise reduced permanent dependence on specific individuals? These results — not how many new teams were formed or how many org charts were redrawn — indicate the value of change.

For such equipment enterprises, what's worth keeping may be the mature processes of standard business, early joint assessment for complex projects, and validated requirement clarification methods. What should end may be the habit of pulling the same engineer into every phase every time. The same business judgment can simultaneously drive retention, change, and exit, focusing limited energy on arrangements that still create value.

Conclusion

In equipment enterprises running standard and custom businesses in parallel, leaders can let standard business keep its mature processes, arrange necessary joint judgment for custom projects, and feed verified assessment methods back to future teams. Team compositions change, but customer commitments hold, original professional capabilities keep working, and new experience gets a chance to stay inside the enterprise.

Such continuity requires managers to identify the shared foundations worth preserving and to accept the cost of allowing diversity. Only when one enterprise can contain multiple work modes, and each mode can withstand reality's test, can the organization accumulate capability through continuous adjustment.

The inspiration of phenotypic plasticity for management is to let form follow task, and let existing accumulation enter new action. Every valuable adaptation leaves better conditions for the next action and preserves the possibility of continued growth.