Task Interdependence¶
Core Idea¶
Task Interdependence is the workflow-coupling principle that the completion, quality, or timing of one task depends on inputs, outputs, resources, information, or decisions from other tasks, such that system performance depends not only on individual task performance but on the couplings between them[1]. The essential commitment is that in any work system with multiple tasks or actors, dependencies create coordination requirements; that James D. Thompson's (1967) three-level typology—pooled (units contribute to a common pool but do not directly exchange work), sequential (A's output is B's input in fixed order), and reciprocal (A and B iteratively exchange inputs and outputs)—with each level requiring progressively more intensive coordination; that the visible, formal interdependence (documented in workflow specifications) often diverges from actual dependencies emerging through practice, creating coordination failures when unnoticed; and that matching coordination mode (standardization, planning, mutual adjustment, integrating roles) to interdependence level is critical for system performance[1].
How would you explain it like I'm…
When Jobs Need Each Other
Linked Jobs
Workflow Coupling
Structural Signature¶
- The interdependence typology level (pooled, sequential, reciprocal, or team) characterizing the coordination intensity and required coordination mode [1]
- The directional structure of dependencies (unidirectional flow as in sequential versus bidirectional iterative exchange as in reciprocal) [1]
- The resource basis for dependencies (information dependency, physical artifact dependency, approval/decision dependency, shared-resource dependency, skill-complementarity dependency) [2]
- The tightness of coupling (tight coupling where delays propagate immediately versus loose coupling where buffers absorb variation) [3]
- The density of interdependence (how many other tasks each task connects to; sparse versus dense networks) [4]
- The visibility gap between formal interdependence (documented in specifications) and actual interdependence (as revealed through practice and coordination) [5]
What It Is Not¶
-
Not just coordination. Coordination is the management response to interdependence; interdependence is the underlying structural property. A task-interdependence problem cannot be solved by "better coordination" alone if the fundamental coupling is not understood or aligned.
-
Not the same as task complexity. A complex task done in isolation is not interdependent. A simple task requiring inputs from three other departments is highly interdependent. Interdependence is relational, not intrinsic.
-
Not equivalent to communication needs. Communication supports coordination but does not eliminate interdependence. Two tasks might communicate frequently yet remain loosely coupled; two others might communicate rarely yet be tightly coupled at critical points.
-
Not identical to schedule dependencies. Scheduling (Gantt charts, PERT/CPM) models some temporal dependencies, but interdependence includes quality coupling (one task's output quality affects another's success), resource coupling, and information coupling that scheduling alone does not capture.
-
Not a consequence of poor design alone. Some interdependence is inherent to the work (a surgeon depends on radiology scans before operating). Other interdependence emerges from how organizations structure tasks. Recognizing which is which is critical for intervention.
-
Common misclassification: Treating all high-communication work as "properly coordinated," when the underlying interdependence structure may require different coordination mechanisms than are in place.
Broad Use¶
Task Interdependence appears in organizational workflow design (assembly lines exhibiting tight sequential interdependence; multiservice organizations with dense cross-departmental interdependence), in software engineering (code-level coupling; API dependencies; build-system DAGs; microservice synchronization; team-topologies informed by interdependence patterns), in project management (PERT/CPM networks modeling task dependencies; critical-path analysis; risk analysis of delay propagation), in healthcare operations (operating-room teams coordinating in real time; clinic workflows with patient-flow interdependence; cross-department patient progression), in supply-chain management (sequential supplier dependencies; inventory-buffered versus just-in-time coupling), in government and public administration (interagency coordination requirements; multi-jurisdictional operations), in scientific collaboration (multi-lab research dependencies; instrumentation-sharing interdependence), and in emergency response (incident management with dynamic task-interdependence patterns changing as incident evolves).
Clarity¶
Task-interdependence framing clarifies why "siloed" task management fails: it reveals the coupling structure that makes tasks interdependent. Without the frame, managers blame poor communication or uncooperative behavior when the underlying issue is that the interdependence structure is not explicitly recognized or that coordination mechanisms are mismatched to the interdependence level. With the frame, diagnosis becomes precise: identify the actual dependencies, classify them by Thompson's typology, match coordination mechanisms to the level, and invest coordination capacity accordingly.
Manages Complexity¶
Task-interdependence analysis factors work-system complexity into explicit dependency patterns (pooled, sequential, reciprocal, team) and associated coordination requirements. Rather than treating all work as similarly coordinated, this factoring enables targeted intervention: pooled tasks need mainly standardization; sequential tasks need scheduling and planning; reciprocal tasks need intensive mutual adjustment and integrating roles. This matching of coordination mode to interdependence level is more efficient than applying uniform coordination overhead to all work.
Abstract Reasoning¶
Task-interdependence reasoning proceeds by asking[6]:
Lawrence, P. R., & Lorsch, J. W. (1967). Organization and Environment: Managing Differentiation and Integration. Harvard Business School Press. [4]: Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28–31. Origin of "Conway's Law": establishes a homomorphism between an organization's communication structure and the structure of the systems it designs, explaining why organizational and software hierarchies tend to mirror one another.
Structural–Framed Character¶
Task Interdependence sits on the structural half of the structural–framed spectrum, graded mixed-structural with an aggregate of 0.3. The skeleton that travels is a coupling structure: dependencies running through inputs, outputs, resources, information, or decisions; a direction, unidirectional in the sequential case and bidirectional iterative exchange in the reciprocal one; a tightness of coupling deciding whether delays propagate immediately or buffers absorb them; and a level in the pooled/sequential/reciprocal typology that sets how much coordination the coupling demands.
Three criteria read half, and the one doing most of the work is human-practice-bound. The prime is defined over work systems with multiple tasks or actors, and its central claim — that coordination mode must be matched to interdependence level — presupposes someone coordinating. That is what lifts it off the structural pole even though a dependency graph is neutral in itself. Institutional origin is half for a related reason, the typology having been crystallized in organization theory, and vocabulary travels at half: pooled, reciprocal, mutual adjustment, and the gap between documented and emergent dependencies carry a management tint wherever they go.
Evaluative weight is zero — interdependence is a structural property, not a defect, and the entry is explicit that coordination is the response rather than the thing itself. Import-vs-recognize is zero: build-system DAGs, API coupling, and critical-path networks are the same structure recognized, not a framing borrowed.
So read direction, tightness, and level anywhere tasks depend on each other, but expect the coordination prescriptions attached to the prime to travel less cleanly than the coupling does.
Relationships to Other Abstractions¶
Current abstraction Task Interdependence Prime
Parents (2) — more general patterns this builds on
-
Task Interdependence is a kind of Dependency Prime
Task interdependence is a specialization of dependency in which the directed reliance is between coupled tasks in a work system.Task interdependence is a kind of dependency specialized to work-system tasks: the directed reliance is between activities whose completion, quality, or timing requires inputs, outputs, resources, or decisions from other tasks. It inherits dependency's general commitment that one element relies on another being present, prior, compatible, or supplied, and supplies the specific case where the elements are tasks and the typology of reliance — pooled, sequential, reciprocal — sets coordination requirements proportional to the coupling intensity that the underlying dependency relation creates.
-
Task Interdependence is a decomposition of Network Prime
Task interdependence is the specific shape network takes when the nodes are tasks and the edges are workflow couplings of inputs, outputs, and resources.Task interdependence is the workflow-particularized form network takes: the entities are tasks and the connections are the dependencies through which one task's outputs, resources, or decisions feed another. Where network names a set of entities with pairwise connections studied at the level of connection pattern generally, task interdependence fixes the node type (tasks), the edge type (input-output, resource, information dependencies), and the analytic focus (Thompson's pooled-sequential-reciprocal typology) — a particular shape of network structure in work systems.
Children (3) — more specific cases that build on this
-
Activity-centered design Domain-specific is a kind of Task Interdependence
The proposed strict upward parent is
prime:task_interdependence.prime:task_interdependence is the nearest broader Prime; the source domain and invariant supply the residual. This is a proposal-only workspace relationship: the accepted Prime supplies a genuinely instantiated structural prerequisite or superclass, while Activity-centered design adds domain-specific constraints. The entry does not collapse into that parent because the domain-specific identity determined by the target activity and goal, actors, actions, context, tools, dependencies, and success conditions are explicit and design decisions trace to them It also declines a nearby thematic catalog node: the neighbor does not literally subsume the constitutive identity of Activity-centered design. This explicit assert-and-decline pattern keeps the proposed DAG narrow and prevents a merely thematic edge. The prospective workspace queue contains one strict upward edge toprime:task_interdependence. No live DAG mutation is authorized. -
Concurrent, Cross-Functional Collaboration Prime presupposes Task Interdependence
Concurrent cross-functional collaboration presupposes task interdependence because its simultaneous engagement is justified only when functional tasks have reciprocal couplings.Concurrent cross-functional collaboration is justified only when the tasks being performed are reciprocally interdependent — when design, manufacturing, and operations decisions iteratively shape one another rather than feeding forward in a fixed sequence. Without task interdependence's machinery of workflow coupling, the simultaneous engagement of multiple specialists would be wasteful: tasks that are merely pooled or sequential need only sequential handoff. The reciprocal interdependence supplies the structural condition that makes concurrent engagement the efficient coordination form.
-
Coordination Prime presupposes Task Interdependence
Coordination presupposes task interdependence because the active alignment of actors is only required when their tasks are coupled through inputs, outputs, or shared resources.Coordination's whole rationale is to align actors whose tasks depend on one another — to manage the couplings through which one task's output is another's input, or both compete for shared resources. Without task interdependence's machinery of workflow coupling, the actors would be performing independent tasks with no need for active alignment, and the coordination infrastructure would have nothing to coordinate. Interdependence supplies the structural condition — coupling between tasks — that creates the requirement coordination addresses.
Hierarchy paths (2) — routes to 2 parentless roots
- Task Interdependence → Dependency
- Task Interdependence → Network → Reservoir-Flux Network → Conservation Laws → Invariance
Solution Archetypes¶
Solution archetypes in the catalog that build on this prime — directly (this prime is a source ingredient) or as a related prime.
Built directly on this prime (8)
- Concurrent Cross-Functional Integration: Integrate specialized perspectives in parallel through shared artifacts, live interfaces, synchronized decisions, and continuous recombination so conflicts appear while they are still cheap to resolve.▸ Mechanisms (10)
- Big-Room Planning or Concurrent Set-Based Workshop — A periodic all-hands planning event where every function aligns dependencies, reserves shared capacity, and commits to an integration cadence — carrying several options forward where interfaces are still unstable.
- Concurrent Engineering Workcell — A working arrangement where the specialists developing tightly coupled elements design them together in real time, so constraints and interfaces are negotiated as the design takes shape rather than discovered at assembly.
- Cross-Functional Design Review — Convenes the affected functions to resolve one bounded cross-functional tradeoff on shared evidence — with a named decider and a recorded rationale — before the commitment hardens.
- Cross-Functional Swarm on Integration Constraint — Temporarily redirects the minimal set of specialists onto the single issue throttling integration — under a timebox and a stop-rule — then returns ownership.
- Dependency and Change Notification Board — A live shared surface that shows current cross-team dependencies, interface versions, and changes — and pushes each change to the owners it affects until they acknowledge and act.
- Integrated Product or Service Team — Stands up one small, complete team that owns an end-to-end outcome — with the specialist authority and protected capacity to integrate continuously instead of handing off.
- Integrated Readiness and Release Review — A whole-system readiness gate that checks the release unit operates end to end and that a named owner accepts the transition — not that each function is locally green.
- Integration Build or End-to-End Increment — Frequently recombines the teams' partial outputs into a running end-to-end increment and runs cross-functional cases, so interface and workflow failures surface now instead of at final assembly.
- Interface Control Document and Contract Test — Makes each interface between functions explicit, versioned, and executable — a written contract plus automated tests that fail the moment a provider or consumer breaks compatibility.
- Shared System Model or Digital Thread — Connects every function's requirements, designs, decisions, interfaces, tests, and changes into one authoritative, traceable model, so everyone works from the same current state and a change's impact is visible along the links.
- Contribution Visibility Design: Make individual contributions visible enough that group work does not hide effort, free-riding, or overload.▸ Mechanisms (9)
- Contribution Review Meeting — Creates a regular review of contribution patterns, blocked contributors, invisible work, uneven load, and recognition gaps.
- Contribution Tracking Board — Displays work units, owners, status, blockers, and handoffs so individual and shared contributions are visible during collaborative work.
- Credit Taxonomy or Authorship Matrix — Names different contribution categories, such as design, execution, coordination, review, mentoring, analysis, maintenance, and communication, so recognition is not limited to the most visible output.
- Individual Deliverable Contract — Breaks a group output into named deliverables or responsibility slices while preserving coordination across interdependent work.
- Peer Evaluation Process — Collects structured peer observations of contribution quality, reliability, collaboration, and support work, especially where supervisors cannot observe the work directly.
- Shared Task Ownership Protocol — Clarifies how jointly owned work is split, coordinated, reviewed, and credited so shared ownership does not erase individual responsibilities.
- Team Work Board — Uses a shared kanban-style, sprint, project, or operations board to show who is doing what, where work is blocked, and where support is needed.
- Work Log or Activity Trace — Records contribution activity over time, including preparation, review, coordination, support, maintenance, and handoff work that final outputs may hide.
- Workload Heatmap — Visualizes concentration of work, overload risk, support needs, or repeated under-contribution across roles, time periods, or work types.
- Distributed Coordination Architecture: Design the outcome, authority, dependencies, interfaces, shared state, timing, commitments, exceptions, and feedback that let independently controlled actors produce a coherent collective result.▸ Mechanisms (13)
- After-Action Coordination Review — Closes a coordination episode by extracting transferable lessons and transferring residual obligations, so the architecture improves and no commitment vanishes when the coalition disbands.
- Commitment and Dependency Register — Turns promises and the dependencies they create into stateful, addressable objects with owners, dependents, status, and closure evidence — durable coordination memory rather than scattered recollection.
- Coordination Decision Rights and Autonomy Matrix — Maps, for each class of coordinated decision, who may commit, decide, execute, veto, stop, and review — drawing the line between legitimate local autonomy and choices that require joint control.
- Coordination Health Review — A standing review that watches interface- and outcome-level health signals and re-tunes the coordination architecture before degradation hardens into failure.
- Dependency and Interaction Map — Charts the actual interdependencies and handoffs between actors — where one party's state changes another's feasible action — so coordination targets real coupling, not org-chart lines.
- Distributed Planning and Reconciliation Session — A working session where independently-planning actors reconcile competing claims on scarce shared resources into a jointly feasible set of commitments.
- Event-Driven Coordination Channel — Routes meaningful changes and exceptions to exactly the actors whose decisions depend on them, so coordination rides targeted signals instead of broadcast noise or constant shared-state polling.
- Exception and Escalation Protocol — The pre-agreed path for when normal coordination fails — declare the exception, contain harm, hand time-limited interim authority to a named role, route the decision, then review and close.
- Interface Control Document or Service Contract — Freezes one recurring exchange between two parties into an explicit contract — objects, semantics, guarantees, acknowledgment, and versioned change rules — so neither side has to renegotiate it.
- Joint Operating Agreement — Ratifies the shared outcome, the chosen coordination mode, and the incentive and cost-sharing terms into one versioned, authority-bearing agreement every party signs.
- Liaison and Integrator Role — A standing human role that spans a boundary — translating between parties, brokering competing claims on shared resources, and keeping the working relationship intact enough to keep coordinating.
- Shared Coordination Board — A single shared surface where every actor reads the same live picture — outcome, state, commitments, dependencies, capacity, exceptions — each field owned, dated, and confidence-tagged.
- Synchronization Checkpoint — A dependency-triggered readiness gate: before a coupled, hard-to-reverse transition, every required party confirms it is ready, and the gate can release, hold, or send everyone back to replan.
- Integrated Work Partitioning: Make a joint activity scalable and learnable by dividing it into specialized work units, assigning them to distinct performers, and deliberately reconnecting their outputs.▸ Mechanisms (10)
- Cross-Functional Workflow Board — Makes cross-functional work-in-progress visible on one shared, columned surface so specialists can see live status, pull the next item, and synchronize on a light standing rhythm instead of chasing each other.
- Dependency Matrix
- Handoff Protocol
- Integration Review — A periodic checkpoint where specialized streams bring their outputs together, are checked for fit, and have cross-stream conflicts and bottlenecks surfaced and reconciled before they compound.
- Job Rotation or Cross-Training Program — Deliberately moves people across specialized stations to build overlapping capability, coverage for absences, and fairer access to learning, so a division of labor doesn't harden into brittle, deskilling silos.
- RACI or Responsibility Matrix — Crosses every task against every role and tags each cell Responsible, Accountable, Consulted, or Informed, so ownership is explicit and exactly one person is answerable for each piece of work.
- Service-Level or Internal Service Agreement — Turns a recurring handoff between an internal provider and its consumers into an explicit contract of inputs, turnaround, and quality targets, so cross-boundary expectations stop being silently assumed.
- Swimlane Workflow Diagram
- Team or Role Charter — Fixes a team or role's purpose, scope boundary, and specialized remit in a short founding document, so a division of labor starts from an agreed mandate rather than drifting from legacy titles.
- Work Breakdown Structure — Decomposes a project's total scope into nested deliverables and work packages so effort can be owned, estimated, and rolled up.
- Responsibility Assignment for Action: Assign clear responsibility when group presence would otherwise diffuse action.▸ Mechanisms (10)
- Emergency Role Assignment — Pre-assigns named people to named emergency roles ahead of time, keyed to a trigger and an urgency tier, so that when an incident hits nobody burns seconds deciding who acts.
- Escalation Protocol — Defines the threshold at which an agent's ordinary discretion runs out and the decision must be routed up to a higher or different authority.
- Explicit Task Assignment — Turns a shared concern or a meeting's agreed outcome into a single named next-action owner with an expected update — the smallest act that keeps responsibility from dissolving into the group.
- Incident Commander Role — Names one person to hold coordinating command for the duration of an active incident — directing responders, keeping the shared status picture, and owning the response until it is resolved or handed off.
- On-Call Ownership — Puts a named responder on the hook for a defined time window — with a backup and a severity ladder — so recurring alerts and requests never depend on who happens to be around.
- Public Commitment Board — A shared, visible surface that shows who owns each active item and what state it is in, so coverage and gaps are legible to the whole group at a glance — without becoming a surveillance tool.
- RACI-Like Ownership Matrix — A grid mapping every task against every party, marking who is Responsible, Accountable, Consulted, and Informed — disambiguating overlapping roles across a whole effort, and kept current so it does not ossify into fiction.
- Runbook With Named Owner — A documented procedure that pairs the step-by-step for a recurring situation with the named role authorized to run it, so the instructions and the person cleared to act arrive together.
- Shift Handoff Check — A structured checkpoint at the boundary between two shifts that transfers unresolved state, active blockers, and pending obligations to the incoming owner, so nothing silently drops when responsibility changes hands.
- Single-Threaded Owner — Assigns one person — not a committee — to carry a cross-functional effort through ambiguity end to end, with the authority to make calls across team boundaries until it is done or escalated.
- Shared-Benefit Contribution Governance: Turn willingness to help into reliable shared-benefit production by governing who contributes what, why, when, how it is seen, and how burden and benefit stay legitimate.
- Specialization Boundary and Reintegration Design: Improve efficiency by narrowing roles or niches only where the gains exceed the coordination, brittleness, learning, and reintegration costs.▸ Mechanisms (11)
- Bus Factor Review — Finds every capability that rides on one irreplaceable person and turns each into a funded plan for redundancy before that person walks.
- Coordination Cost Accounting — Puts a running price on the meetings, handoffs, waiting, and rework that dividing work creates, so the coordination tax can be weighed against the specialization gains.
- Dependency Heatmap — Renders every specialty's dependencies on one colour-graded grid so single-source chokepoints and lock-in glow before they fail.
- Handoff Contract Template — Turns each handoff between specialties into an explicit, testable contract — inputs, acceptance criteria, owners, and what to do when something doesn't fit.
- Integrator Role Assignment — Names one person or team accountable for the whole — with the standing to force the specialized parts to add up to something coherent.
- Over-Specialization Audit — Asks whether roles have been sliced too thin, measuring specialization intensity and the entrenched status it breeds against the flexibility being lost.
- Role & Niche Charter — A short standing charter that equips one specialist niche — the capabilities it needs, the tools it may run, and where out-of-scope work goes — so the role is legible and its edges are handled.
- Role Recomposition Trigger Review — A standing review that watches a small set of pre-committed triggers — demand shift, chronic bottleneck, local metrics drifting from global ones — and fires when a specialization has outlived its fit and should be recomposed.
- Rotation & Cross-Training Schedule — A standing schedule that rotates people through adjacent specialties and cross-trains them, deliberately spending some depth to buy redundancy and keep the workforce mix broad enough to recombine.
- Specialist-Generalist Portfolio Review — A periodic review of the whole workforce as a portfolio — how intensely specialised it has become and how status and power have concentrated across niches — to judge whether the balance still fits demand.
- Specialization Boundary Workshop — A facilitated session where a group maps the whole space of tasks and collectively decides where the specialization lines should fall — before anyone is slotted into a niche.
- Task Interdependence Mapping: Map how tasks depend on one another so coordination, handoffs, and communication match the actual workflow.▸ Mechanisms (10)
- Coordination Meeting Cadence — Establishes a recurring, dependency-justified forum where the parties to a coupling meet to adjust to each other in real time, rather than discovering the mismatch at handoff.
- Critical Path Analysis — Finds the longest chain of dependent tasks that fixes the earliest possible finish, so coordination attention is spent on the dependencies that actually move the end date.
- Cross-Functional Workflow Mapping — Maps a workflow across the professional, departmental, technical, or jurisdictional boundaries where each side sees only its own half, then pins down what must pass across each crossing.
- Dependency Mapping Session — Brings the people who actually do the work together to surface task edges, missing inputs, handoffs, timing constraints, and coordination risks that no single role can see alone.
- Dependency Matrix
- Escalation Review — A defined procedure for moving a dependency conflict that cannot be solved at the local task level up to the authority and information that can resolve it, before local blockage becomes system failure.
- Handoff Protocol
- RACI Matrix
- Shared Workflow Board — An always-on shared surface where every task's state, blocker, and dependency status is visible to all parties at once, so coordination happens by looking rather than by asking.
- Workflow Diagram — A durable, maintained picture of the task sequence, branches, actors, handoff points, and feedback loops that participants can inspect, correct, and keep from going stale.
Also a related prime in 27 archetypes
- Alignment Governance and Dispute Resolution: Stabilize multi-actor systems by giving misalignments a legitimate forum, clear authority boundaries, and escalation/resolution paths before conflicts cascade.
- Cadence Design: Establish a recurring rhythm for action, review, communication, or maintenance so important work happens reliably without constant re-decision.
- Complexity Scaling Assessment: Assess how effort, cost, time, memory, or coordination burden grows as input size or system scale increases.
- Composability Testing and Validation: Test whether components that work alone still work together, and use the results to define safe recombination boundaries.
- Concurrency Control: Coordinate simultaneous processes so they can proceed in parallel without corrupting shared state, over-claiming shared resources, or blocking one another indefinitely.
- Coordination and Synchronization Across Reentry Phases: Bring separated parts back together in the right order, at the right tempo, with shared state visibility and the ability to pause when reentry creates overload or unsafe coupling.
- Coordination Scaffold Load Control: Keep the support machinery for coordination from becoming a second workload larger than the work it exists to coordinate.
- Coupling Latency and Time-Delay Effects: Treat delay in coupled interactions as a design variable, not as background noise.
- Cycle Phase Alignment: Align the phases of interacting cycles so handoffs, resources, and decisions arrive when they are usable.
- Deadlock Prevention: Structure resource acquisition, authority, or sequencing so circular blocking cannot arise.
References¶
[1] Thompson, J. D. (1967). Organizations in Action: Social Science Bases of Administrative Theory. McGraw-Hill. registry ↩a ↩b ↩c ↩d
[2] Galbraith, J. R. (1973). Designing Complex Organizations. Addison-Wesley, Reading, MA. Develops the information-processing view of organizational design: task uncertainty raises the volume of information that must be processed during execution, and the chosen partitioning determines how much coordination load the integration mechanism must carry. Catalogues design moves (slack resources, self-contained tasks, vertical information systems, lateral relations) that adjust the partition–coordination balance as uncertainty rises. registry ↩
[3] Parnas, D. L. (1972). "On the criteria to be used in decomposing systems into modules." Communications of the ACM, 15(12), 1053–1058. registry ↩
[4] Conway, M. E. (1968). "How do committees invent?" Datamation, 14(4), 28–31. registry ↩a ↩b
[5] Mintzberg, H. (1979). The Structuring of Organizations: A Synthesis of the Research. Prentice-Hall, Englewood Cliffs, NJ. Synthesizes organizational-design research into a typology of five configurations (simple structure, machine bureaucracy, professional bureaucracy, divisionalized form, adhocracy), each characterized by a distinct combination of partitioning (horizontal and vertical specialization) and coordination mechanism (mutual adjustment, direct supervision, standardization of work processes, outputs, or skills). registry ↩
[6] Lawrence, P. R., & Lorsch, J. W. (1967). Organization and Environment: Managing Differentiation and Integration. Harvard University Press. registry ↩
[7] Van de Ven, A. H., Delbecq, A. L., & Koenig, R. (1976). "Determinants of coordination modes within organizations." American Sociological Review, 41(2), 322–338. registry
[8] Goldratt, Eliyahu M., and Jeff Cox. The Goal: A Process of Ongoing Improvement. Great Barrington, MA: North River Press, 1984 (4th anniversary ed., 2014). Theory-of-Constraints methodology consolidated in Goldratt, What Is This Thing Called Theory of Constraints and How Should It Be Implemented? (North River Press, 1990). Methodological consolidation: Dettmer, Goldratt's Theory of Constraints (ASQ Quality Press, 1997). registry
[9] Trist, E. L., & Bamforth, K. W. (1951). "Some social and psychological consequences of the longwall method of coal-getting." Human Relations, 4(1), 3–38. registry
[10] Baldwin, C. Y., & Clark, K. B. (2000). Design Rules: The Power of Modularity (Vol. 1). MIT Press. registry
[11] Simon, H. A. (1962). "The architecture of complexity." Proceedings of the American Philosophical Society, 106(6), 467–482. registry
[12] Ulrich, K. T. (1995). "The role of product architecture in the manufacturing firm." Research Policy, 24(3), 419–440. registry
[13] Sánchez, R., & Mahoney, J. T. (1996). "Modularity, flexibility, and knowledge management in product and organization design." Strategic Management Journal, 17(S2), 63–76. registry
[14] MacCormack, A., Baldwin, C., & Rusnak, J. (2012). "Exploring the duality between product and organizational architecture: A test of the 'mirroring hypothesis'." Research Policy, 41(8), 1309–1324. registry
[15] Meyer, B. (2014). "Agile!: The Good, the Hype, and the Ugly." Springer. registry
[16] Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. registry
[17] McIlroy, M. D. (1968). "Mass produced software components." In Software Engineering: Report of a Conference Sponsored by the NATO Science Committee (pp. 138–155). NATO Science Committee. registry
[18] Sommerville, I. (2010). Software Engineering (9th ed.). Addison-Wesley. registry
Neighborhood in Abstraction Space¶
Task Interdependence sits in a moderately populated region (46th percentile for distinctiveness): it has near-neighbors but no dense thicket of synonyms.
Family — Capacity Limits & Attention (20 primes)
Nearest neighbors
- Coupling — 0.73
- Attention — 0.73
- Concurrency — 0.72
- Oversight Capacity — 0.71
- Scaling and Scale Dependence — 0.71
Computed from structural-signature embeddings · 2026-09-10