Organizational Unit Model¶
Organizational model — instantiates Scale-Appropriate Modeling
Represents an organization at the team-or-unit scale so coordination behavior that individual logs and company averages both hide becomes visible.
An organizational unit model represents a company at the scale of teams or units rather than individuals or the whole organization, chosen because the coordination behavior that matters — handoffs, cross-team dependencies, queueing between groups — lives at that scale and is invisible both in individual task logs and in company-wide KPIs. Its defining move is selecting the unit (team, squad, department) as the modeling primitive and retaining the between-unit relationships as the variables that carry the behavior, with a trigger to drop into an individual unit's internals when that unit becomes the bottleneck. It models the graph of groups and their handoffs, not the people inside them and not the aggregate above them.
Example¶
A product organization keeps missing release dates and no one can see why. Individual engineers are all busy — their task logs look full — and the company dashboard shows healthy overall throughput. The delay lives between teams. An organizational unit model represents the org as roughly a dozen teams and the handoffs between them: who waits on whom for design sign-off, API contracts, and QA. The team is chosen as the unit (scale selection); the cross-team handoffs and their wait times are retained as the behavior-bearing variables, while individual task detail is elided; and a trigger is armed — if one handoff's wait comes to dominate the schedule, drop into that team's internal workflow to find out why (detail reintroduction). Run this way, the model reveals a single QA team that every stream funnels through — a bottleneck that neither the individual logs nor the company KPI could ever surface.
How it works¶
- Select the unit. Choose the team, squad, or department as the modeling primitive.
- Map between-unit relationships. Lay out handoffs, dependencies, and queues among units.
- Retain the behavior-bearing variables. Keep wait times and handoff volume as the variables the model reasons on.
- Arm the drop-to-individual trigger. When one unit's internals become the binding constraint, zoom into that unit's workflow.
Tuning parameters¶
- Unit granularity — squads versus departments. Finer units expose more coupling but leave more model to maintain.
- Relationship set retained — which between-unit links count: formal handoffs only, or also informal dependencies and shared services.
- Reintroduction trigger sensitivity — how dominant a bottleneck must become before you zoom into a unit's internals.
- Boundary definition — where one unit ends and another begins, which matters most when teams overlap or share people.
When it helps, and when it misleads¶
Its strength is making coordination cost visible exactly where the individual and the aggregate views both hide it; it resonates with Conway's law, the observation that a system's structure tends to mirror the communication structure of the org that builds it[1], so the unit graph often predicts the software's own seams. Its failure mode is that team boundaries are fuzzy and shifting, so the model can quietly encode an org chart that no longer matches how work actually flows — and it can smooth away a single overloaded individual whose load the unit average hides. The classic misuse is taking the formal org chart as the unit model without checking the real handoffs. The guarding discipline is to derive units from observed work flow rather than the chart, and to keep the drop-to-individual trigger armed.
How it implements the components¶
An organizational unit model realizes the select-retain-and-escalate side of the archetype in the org domain:
scale_selection— choosing the team or unit as the primitive is the scale selection.retained_variable— the between-unit handoffs and their wait times are the retained variables.detail_reintroduction_trigger— the rule to zoom into a unit once it becomes the bottleneck is the reintroduction trigger.
It does not test its own fidelity or prove the unit scale is not an artifact: behavior_preservation_test is Mesoscale Simulation's and scale_validation belongs to Policy-Scale Analysis — the unit model selects, retains, and escalates, but leans on those siblings to show the unit scale holds up.
Related¶
- Instantiates: Scale-Appropriate Modeling — it applies scale selection to an organization, choosing the unit band over individuals and aggregates.
- Sibling mechanisms: Coarse-Grained Model · Executive-Level Summary · Mesoscale Simulation · Level-of-Detail Model · Policy-Scale Analysis · Ecological Scale Selection · Architecture-Level Model
Editorial Notes¶
Form Classification¶
Form family: Analysis, Modeling & Optimization
Rationale: Organizational Unit Model operates as an analytical, modeling, inference, comparison, or optimization procedure that derives insight or a solution because it represents an organization at the team-or-unit scale so coordination behavior that individual logs and company averages both hide becomes visible.
Independent corroboration: The frozen evidence defines Organizational Unit Model as 'Represents an organization at the team-or-unit scale so coordination behavior that individual logs and company averages both hide becomes visible', so its operative form is Analysis, Modeling & Optimization.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Organizational Unit Model is most directly rooted in organizational and management science's practice of coordinating people, authority, strategy, knowledge, and work. The lineage fits its defining practice: Represents an organization at the team-or-unit scale so coordination behavior that individual logs and company averages both hide becomes visible.
Related originating lineages:
- Sociology & Anthropology — Mesolevel analysis of groups and institutions materially supplies the bridge between individual and aggregate behavior.
- Systems Thinking & Cybernetics — Organizational Unit Model also draws materially on systems thinking and cybernetics' treatment of feedback, control, emergence, and multilevel system behavior, which shaped this mechanism rather than merely adopting it as an application.
Review resolution: Both independent reviews agree on primary origin organizational_management; reconciliation resolves alternate_origin_disagreement, domain_reach_disagreement. Formative alternate lineages retained: systems_cybernetics, sociology_anthropology. The broader reach of later applications is kept separate as domain_reach=multi_domain; origin_mode=cross_disciplinary_synthesis records how the formative lineages relate. Confidence is conservatively reconciled to medium, and encyclopedia_synthesis=true preserves the reviewers' boundary judgment.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
References¶
[1] Conway, M. E. "How Do Committees Invent?". Datamation 14(4), 28–31 (1968). Argues that a designed system’s structure reflects the communication structure of the organization that produced it. registry ↩