What happens in organizations. And what to do about it.
What this is about
There is a class of difficulties that shows up in almost any organization doing intellectually-intensive work. On paper everything is in place — roles, processes, meetings, reports. In practice, in varying proportions, the same things appear: decisions get made several times over, each time from scratch; critical information lives in the heads of a few people, and when they are busy, work stops; pushing harder produces fatigue without motion, while easing off produces drift; teams burn out against production numbers that look nominally fine.
This is not a managerial mistake, and not a hiring problem. It is what structurally happens to organizations doing intellectually-intensive work — when the shape of the activity itself has not been made visible.
What follows names what typically remains invisible, explains why it hollows the organization out from the inside, and describes the instrument I am proposing.
First thing usually invisible: work runs in three layers at once
In any intellectually-intensive activity, three distinct layers run simultaneously. They are irreducible to one another. Almost every organization notices one and ignores two.
Activity. The concrete work unfolding in a concrete situation: a person writes code, a team ships a release, an analyst produces a report. This is where value is produced. Knowledge enters here from outside — through communication.
Communication. The transfer of descriptions, tasks, and requirements between situations. A sender in one situation encodes a message; a receiver in another situation decodes it. The situations are always different. Meaning does not sit in the text — it arises at decoding, and brings with it more than the sender enclosed. Most of what we call "silent divergence" in an organization lives here. Communication is the axis between the other two layers: without it, thinking does not reach activity, and activity does not return to thinking as material for revision. Most organizational failures are failures of communication dressed up as failures of execution or performance.
Thinking. Work on schemas fixed to a shared surface: diagrams, tables, structured documents. Thinking in this sense happens with and through the surface. Without a surface there is activity and talk, but no shared object to think about. This is where schemas are constructed and revised; where one can stand above the cooperation and see it as a whole.
The three layers do not reduce to one another. If communication is collapsed into activity ("why write it down, we'll just talk it through") — the function of carrying across situations is lost, and knowledge stays in heads. If thinking is collapsed into communication ("we discussed it in the meeting") — the place where a schema becomes visible is lost, and decisions drift. If thinking is collapsed into activity ("no time to think, just ship it") — the organization ossifies: it becomes structurally incapable of revising its own schemas.
Hence the effect often described as "people don't understand what they're told." This is not about people. It is about the third layer not being set up: there are no places where thinking is materialized as objects that everyone sees the same way.
Hence also the first constructive move of the proposed approach: communication is not left to the discretion of speakers but structured through canonical document forms. Each act of the cycle produces a document of a defined form — a disposition, a program, a plan, a report — and each such form is itself a methodological contract. The form specifies what information must reach a given position for that position to do its work, and in what structure. A document is not merely a record of an outcome; it is a channel of communication with fixed norms on content and ordering. The invisible layer becomes a visible artifact.
Second thing usually invisible: "management" is not one function but three
The word "management" in most organizations fuses three entirely different functions. They have different objects, different actions, different conditions of completion. Fused, they do not work.
Organizing. Constitutes the structure of places (positions with functions) and their contracts. Assembles people or operators into the places; establishes who owes what to whom. Organizing has an end: once the places are filled and the contracts set, organizing stops. It is resumed only for a deliberate structural revision.
Leading. Sets and changes goals, knowledge, and means for positions within the structure. It works only if the occupant of a position has explicitly accepted that within the position its goals override their own. Without that acceptance, leading binds nothing. Leading operates through the structure; outside the structure it produces compliance-theater without commitment.
Managing. Steers the trajectory of a self-moving object toward the target state set by the manager. It presupposes self-movement: an object without self-movement cannot be managed — it can only be transformed. It is possible only through knowledge: knowledge of the natural trajectory (what happens without intervention), knowledge of the project of the desired state (where the manager intends to take it), knowledge of the resources and means available (what the manager can actually do). Managing compensates continuously; it does not return anything to a norm, because a norm cannot be maintained on a self-moving object.
All three are activity over activity: the material is always the actions of other people or operators. The manager's schemas operate on actions, not on material. The moment a manager begins dispatching material, the over-activity character is lost, and the manager is reduced to a ticket-mover.
Most of what is casually called "management" is an attempt to manage where leading is required, or to lead where organizing is required. Hence the familiar sense of "pushing and pushing, and nothing moves." Pressure is not the tool; the object requires a different kind of action.
Third thing usually invisible: the polysystem
An organization is not one system. On the same material — the same people, the same time, the same artifacts — three distinct monostreams run, each with its own success condition.
The principle — that several systems, in contradiction, always run simultaneously on a common material — is structural and has long been described in the systems-methodological tradition. The specific triad proposed here (production / collective / knowledge) is an operational decomposition chosen for modern intellectually-intensive organizations; in other contexts the triad may be refined or extended, but the polysystem principle stands.
The production monostream. Converts signals into delivered work. Success condition: the cycle closes with a bounded delta between what was programmed and what was produced.
The collective monostream. The standing group of position-occupants, its history, its mutual obligations. Success condition: positions remain filled across cycles; the organization retains the capacity to reproduce itself.
The knowledge monostream. The living body of grounded artifacts — norms, principles, schemas, cases — and the activity of capturing, indexing, and retrieving them. Success condition: decisions in the other two monostreams are traceable to grounded ground.
The three share a single material and pull in different directions. The contradictions between them are structural — they are not deviations from a norm. Management compensates between them; it does not dissolve the contradictions or reduce them to one.
Attention in practice typically settles on the production monostream — it is easier to measure. The collective monostream erodes quietly. The knowledge monostream decays quietly. When they give way, production numbers drop suddenly, and from those numbers it is impossible to see why. A cycle that tries to reduce the polysystem to a single monostream loses what the others carry.
The proposed approach
The proposed approach takes the form of a methodologically rigorous framework that automates the orchestration of organizational management. The framework renders the shape of activity as executable and verifiable artifacts, and carries the work through a cycle in which every act has a known product, a known producing position, and a known method of verification.
What the framework constitutes
Functional positions. The structure of the organization is given as a set of positions. Each position is a node that consumes an incoming material and produces an outgoing one. A position can be thought of as a pure function. Positions are defined separately, not as pairs — this is fundamental, and it determines everything else.
Contracts. A contract is a triple: incoming material, position, outgoing material. It is the unit through which a position participates in the organization's activity. The incoming material may be a single document or a bundle — that does not matter; what matters is that it is one incoming material of this contract. Same for the outgoing. A position may have several contracts when it works with several distinct input/output pairs — each pair with its own incoming and its own outgoing material.
A contract fixes: what incoming material the position accepts (with requirements on it), what outgoing material it produces (with guarantees on it), and the norms of the work itself: shape, invariants, validity conditions.
Composition. Positions compose through shared material: the outgoing material of one contract becomes the incoming material of another. A composition of several positions is itself a position — with its own contracts: the composition's external input is the input of the first position in the chain, its external output the output of the last; the internal orchestration is hidden behind the interface. This yields an important architectural property: a one-dimensional flat list of positions with their contracts expresses any hierarchy the organization may take on. The hierarchy is not set separately — it is reconstructed from the nodes through the materials of their contracts.
Filling of positions. For each position, the framework defines which fillings are admissible — people with particular skills, or agents of a particular type. There is no restriction on the nature of the filling: the same functional slot may be occupied by a human or an agent in different contexts, depending on skills and task.
Boundaries of positions. For each position, what it does not cover is explicitly fixed. This is not a formality: without explicit boundaries, functional obligations leak into neighboring positions, and the structure loses its governability.
Three forms of the contract
A contract can exist in three forms simultaneously. The forms do not replace one another — they work for different purposes.
Form 1. Markdown document. The contract as text, consumable by a human. Used where the work of the position is executed or moderated by a human, and wherever a language for discussing change is needed.
Form 2. Executable skill. The contract is automatically translated into code — a skill that executes the work of the position. Where the work is algorithmizable and repeatable, the skill replaces manual execution.
Form 3. Formal model with verification. The contract is translated into a formal model suitable for mathematical checking. This yields three successive possibilities: — checking the contract itself for consistency and completeness before any execution; — translating the formal model into programmatically executable code; — reverse-engineering the running code back into a formal model and comparing it with the original model of the contract.
A divergence between the two models means the implementation has drifted from the specification — and the divergence is localized provably, not by expert judgment. The reverse-engineered model can additionally be checked mathematically on its own, so execution defects are found demonstrably.
The substantive shift: the integrity of a contract stops being a matter of trust and becomes a matter of verification.
The operational cycle
On this infrastructure, a management cycle unfolds. It proceeds through the following phases.
1. Accumulation of signals. Events in the organization's activity produce signals. A signal is a recorded rupture in current activity. Signals accumulate until a session is opened.
2. Session — batch processing. The session is the batch processing of signals. A working set of signals is selected: all accumulated, some, or specifically introduced — depending on the framing of the session. The selected set is the batch.
3. Thematization. From the signals in the batch, themes are extracted — configurations the work will address. A single signal may belong to several themes; a single theme may gather several signals.
4. Problematization. Each theme is classified into one of three cases: — Problematic. A rupture in the activity due to a missing material: a contract that no longer meets requirements, or a positional structure that does not meet current challenges (for instance, a required skill is absent at the position). This calls for changes to the shape of the organization. — Working. Everything needed for the work is in place; a defect occurred at execution. Nothing in the shape of the activity needs to change — the error needs to be corrected. — Noise. The signal is not related to the organization's activity, or has no bearing on anything.
Problematization answers the central question: is the situation a cause for changing the shape of activity, a cause for correcting execution, or neither. This step cuts off the main source of false activity — work on things that do not require work.
5. Situational analysis. The situation is reconstructed in the working context of each functional position touched by the theme. From within that context, each position performs a reflective reading of the problem. These readings collide — this is the polyphonic collision test: where and at which position the situation looks different. Collisions are not smoothed over; they are recorded as working material.
6. Disposition. The result of situational analysis is formalized in a single document — the disposition. The disposition describes the macro-situation: who collides with whom, what material has been objectified, which contradictions are active. It is the starting working document of the cycle.
7. Program. Problems are converted into assignments. The work of the program is to establish what exactly must be done so that the current problem becomes a working procedure and is henceforth resolved automatically. This is also where it is decided which changes go into the structure of the organization and into position contracts, and which matters remain ordinary tasks within existing processes.
8. Plan. Assignments are unfolded onto the organization's real working material: who, with what means, in what sequence, within what deadlines. The plan is a formal document that goes into execution.
9. Execution and report. The framework executes the work packages. On completion, a report is produced: how well the work was done, whether there are drifts from what was planned, how accurately the contracts were realized against how they were designed. From the report, new signals for the next cycle arise where needed. In parallel, signals accumulate from the day-to-day activity of participants — every rupture in the activity becomes a signal.
The cycle closes: the output of one cycle is the input of the next.
Cross-cutting rules
Design from the whole. Process before functional structure; functional structure before morphology; morphology before material.
Knowledge precedes action. No act of the cycle from situational analysis onward is initiated until three items have been written into the working directory: a forecast of what happens without intervention, a project of the desired state, an honest assessment of available resources. Without them, the cycle does not start. This removes the firefighting mode at the level of mechanics, not at the level of good intentions.
What this eliminates in practice
Drift. Each cycle opens with signals read against the program; drift surfaces at delivery as a registered delta, and as material for the next cycle. The delta is recorded, not assumed.
Absence of self-development. Every cycle produces at least one knowledge artifact. The knowledge base is an explicit substrate, not a substance scattered across heads. Someone joining a month later can find how a decision was made, by whom, from what.
Authority without control. No act from the disposition onward proceeds without the three knowledge items. Decisions lacking them are rejected by the mechanics of the cycle before execution, not lamented after.
Fragmentation. Positions with their contracts, boundaries, material — in a single registry; grounded artifacts — in a single knowledge base. The Guru is the single point of inquiry. A question that used to require five people in one room is resolved through a single consultation against the base.
Firefighting mode. Work proceeds through a fixed cycle of named acts. Reaction-to-whatever is not a first-class act. A cycle that skipped program or plan cannot produce a legitimate delivery.
Late feedback. Every cycle produces a delivery record and an execution report with the delta between what was planned and what was produced. The Founder reads them at cycle close, not from third parties a quarter later.
Polysystemic blindness. The three monostreams, with their distinct success conditions, are named separately. The Founder's review looks at all three. Erosion of the collective and decay of knowledge become visible before they bring down the production number.
Complexity mismatch. When work exceeds the reach of a position, the registry constitutes new positions, contracts, or materials — with dated changes. New positions with their contracts open new possible compositions without separately hardcoding the hierarchy. Rising complexity is met by structural growth, not by burning out a single filling.
Tool proliferation. New tools enter the framework only through the material plane — as skills, services, or files bound to the registry and the contracts. Tools that do not bind are external and are not the framework's concern. The count of systems of record stays at one.
Alienation of the management function. The framework is installed on the practitioner's own machine; the registry is in the practitioner's own files; the knowledge base holds the practitioner's own material. The team operates the framework without the continued involvement of a vendor. The practice of management returns to the local manager.
What this does not eliminate
The framework names its limits honestly — this is not a marketing document.
Self-movement is not eliminated. The framework continuously compensates for drift; it does not remove the underlying self-movement, which is built into the fact of being an organization.
Polysystemic blindness is not closed — it is narrowed. Within the team that uses the framework. Beyond that, the blindness continues.
Global fragmentation grows with technology. The framework provides a coherent substrate inside one team's activity; it does not integrate what lives outside that team.
Self-sustainment in the methodology's own terms is unfinished. The vocabulary around revenue, cost, customer, and viability is currently imported from market-economic frames. The methodological transformation of concepts for self-sustainment has not yet been carried out from within the approach.
Capability verification at dispatch is partial. Dispatching work to a position presupposes that the filling is capable of realizing the work with the means assigned. The check that confirms this before dispatch is not complete — a cycle in which a position has been assigned structurally unrealizable work may proceed to delivery undetected.
These are working material. They are named so that the next cycle begins with them in view.
What this changes
This kind of work — the shape of management over intellectually-intensive activity — is currently transmitted from person to person. It lives in the heads of a few experienced practitioners and dies with them. It cannot be bought. It cannot be installed. Either you have someone to work with, or you do not.
I claim that it can be installed. The procedures can be written down, executed, and checked. A practitioner seeing the framework for the first time can complete a first full cycle in a week, not a decade.
If the claim holds, what is now a craft becomes a practice.