Cherns's Design Principles

Core Concepts

From Theory to Practice

Module 01 established that sociotechnical systems require joint optimization — that you cannot independently maximize either the technical or the social subsystem without degrading the other. Cherns's contribution was to take that theoretical commitment and distill it into a set of actionable design principles that a practitioner could actually use during system design, team structuring, or organizational intervention.

The principles are not a recipe. They are a design grammar: a set of constraints and orientations that shape the solution space without determining a single answer.

The Two Versions

In 1976, Cherns published nine principles, intended as a design checklist:

1. Compatibility — the design process must be compatible with its objectives (i.e., participatory design for participatory outcomes)
2. Minimal critical specification — specify only what is essential; leave method open
3. The sociotechnical criterion — variances should be controlled at source
4. Organism versus mechanism — treat the organization as a living system, not a machine
5. Boundary location — draw organizational boundaries to minimize cross-boundary exceptions
6. Information flow — route information to where it will be acted upon
7. Support congruence — support systems (rewards, training, supervision) must reinforce, not undermine, designed behaviors
8. Design and human values — design must account for quality of working life
9. Incompletion — design is never finished

In 1987, Cherns revisited the list and expanded it to ten principles. The revision introduced the multifunctional principle (workers should be capable of performing multiple functions), made variance control an explicit standalone principle (it was previously embedded in the sociotechnical criterion), added power and authority (people need the authority to match their assigned responsibilities), and introduced transitional organization (the design process itself requires deliberate management as a temporary system). Most original principles were retained, but reframed with greater precision.

The Three Types of Principles

Across both versions, the principles fall into three categories:

• Meta-principles address the overall philosophy and assumptions of the design process itself — e.g., compatibility, incompletion.
• Content principles address specific design decisions about work structure — e.g., variance control, whole task, boundary location.
• Process principles address how design decisions are made and implemented — e.g., participatory design, transitional organization.

This categorization matters because different principles engage different stakeholders. Engineers are often most comfortable with content principles, but skipping meta- and process principles tends to produce designs that are technically coherent and socially dysfunctional.

---

Key Principles

1. Minimal Critical Specification

Specify no more than is absolutely necessary. While it may be necessary to be precise about what must be done, it is rarely necessary to specify how.

Minimal critical specification is the most widely cited and most frequently misapplied of the principles. It does not mean "write no documentation" or "don't specify anything." It means: identify what is genuinely essential to accomplish (outcomes, constraints, interfaces), then stop. Leave the implementation — the how — to the people doing the work.

The rationale is not just ergonomic. It reflects the theory that workers contribute most effectively when given clear objectives but maximum freedom in choosing methods. Rigid specification of method destroys the conditions for self-organization and forecloses adaptations that practitioners would naturally make given their local knowledge.

In practice, the principle demands that design teams ask: "Is this specification here because it is necessary, or because specifying things is what designers do?" Most over-specification survives on the second justification.

2. Variance Control

A variance is any deviation from expected performance, output quality, or operating conditions — an error, an exception, an anomaly. The variance control principle states that variances should be controlled as close to their point of origin as possible, rather than being exported across organizational boundaries.

The logic is direct: the closer control is to the source, the faster the response, the more contextual information is available, and the less cascading disruption results. When variances are escalated or routed to centralized exception-handling functions, you introduce latency, context loss, and a dependency that doesn't scale.

Each organizational level should be capable of handling the variances that arise at its level. Variances that cannot be handled at source should be absorbed at the next level, not propagated wholesale up the hierarchy.

3. Whole Task

The whole task principle holds that work should be designed so that a single, small, face-to-face group experiences the entire cycle of operations. Responsibility for the complete task belongs to a single team.

This serves two functions: accountability and feedback. A team that owns the full cycle can observe the consequences of its decisions across the whole work arc. A team that only handles one slice of a larger process cannot close that loop — it has no visibility into downstream effects and no real accountability for outcomes.

Fragmented work, where each group handles only a specialized subset, limits both the feedback available and the meaning that workers derive from their output. Contemporary formulations describe this as assigning teams tasks that "retain their meaning and provide closure."

4. Boundary Management

Boundary management — referred to as "boundary location" in the 1976 version — is the principle that team and system boundaries should be drawn to minimize the number of variances that must be handled across boundaries.

Boundaries are not neutral. Every team boundary is a coordination interface, and every coordination interface creates a class of exception: situations where two teams have to negotiate rather than one team simply deciding. The question "where should this boundary be?" is equivalent to the question "which coordination costs are we choosing to incur?"

Poor boundary placement creates chronic coordination overhead that no amount of process improvement can eliminate, because the overhead is structural. It is baked into the org chart.

5. Information Flow

Information flow is not just a principle about dashboards or communication channels. It is a design constraint: information must reach the people who need it to act on it.

This principle is foundationally coupled to variance control. A team cannot control variances at source if it cannot observe those variances. A team cannot own a whole task if it lacks visibility into outcomes across the full cycle. Poor information flow distribution is not a tooling problem — it is a structural symptom that usually traces back to poor boundary placement or over-centralized control.

The principle also runs in the other direction: information should not be routed to people who cannot act on it. Flooding teams with information they cannot use is not transparency; it is noise.

6. Incompletion

A design is never finished. Continual rethinking of structures and objectives is required as new demands and conditions emerge.

The incompletion principle is often read as "stay open to iteration," which domesticates it into something obvious. The stronger reading is structural: a design that is treated as complete will degrade.

The reason is not that designers are careless. It is that the conditions under which a design was created — the technology, the market, the skills of the people, the org structure — will change. A design that was well-fitted at time T becomes progressively misaligned with its environment as T advances. The only way to prevent that drift is to keep the design open to revision as a matter of principle, not as an admission of earlier failure.

This matters architecturally. It argues against designs that are expensive to change, even when they are technically elegant. It argues for instrumentation, feedback loops, and the deliberate preservation of reversibility.

7. Participatory Design and Support Congruence

Two principles that are often underweighted in technical contexts:

Participatory design holds that workers closest to the technology should have meaningful input into system design. This is not a concession to worker satisfaction — it is an epistemological position. The people doing the work have access to operational knowledge that designers at a remove simply do not have. Excluding them from design produces systems that are locally invalid in ways that cannot be corrected from a distance.

Support congruence holds that the support systems around a designed work structure — incentives, performance review criteria, tooling, training, reporting lines — must reinforce the design's intent, not undermine it. A team designed for autonomy that is reviewed on individual output metrics will not behave as an autonomous team. The surrounding systems are as much a part of the design as the work structure itself.

---

Worked Example

Applying the Principles to an On-Call Ownership Problem

Situation: A platform engineering team owns a shared infrastructure layer. When that infrastructure has an incident, the on-call rotation is drawn from the platform team. The product teams that depend on this infrastructure are not part of on-call. When incidents occur, the platform team diagnoses, fixes, and closes incidents — often without the product teams involved.

Principle-by-principle analysis:

Principle	Assessment
Whole task	Product teams do not experience the full cycle of operating on top of the infrastructure. They ship features but are insulated from operational consequences.
Variance control	Variances (incidents) arising from how product teams use the infrastructure are being exported to and absorbed by the platform team, rather than controlled at source.
Boundary management	The boundary between platform and product teams is drawn around specialization. This forces all infrastructure-related variances across the boundary.
Information flow	Product teams likely lack real-time observability into infrastructure-level metrics that affect them. The platform team is an information bottleneck.
Incompletion	If the model is treated as fixed ("platform team owns infra"), no mechanism exists for renegotiating ownership as product teams mature.

A redesign direction consistent with the principles:

• Draw team boundaries around service ownership, not layer ownership. Each product team co-owns the operational posture of its services end-to-end.
• Route infrastructure observability directly to product team dashboards, not only to platform team consoles.
• Define the platform team's role as variance-reduction (making the infrastructure easier to operate correctly) rather than variance-absorption (handling all incidents themselves).
• Build explicit review checkpoints — consistent with incompletion — where ownership models are revisited as team capabilities change.

This is not the only valid design. The principles constrain the solution space; they do not prescribe a unique answer.

---

Compare & Contrast

Cherns's Principles vs. Team Topologies Patterns

Team Topologies is a contemporary framework for structuring software engineering organizations. It is worth comparing with Cherns's principles directly, since both address team boundary design.

Dimension	Cherns (1976/1987)	Team Topologies
Primary unit of analysis	Work cycle and variance flow	Cognitive load and interaction mode
Boundary placement logic	Minimize cross-boundary variances	Minimize cognitive load per team
Information flow	Explicit design principle	Implied by interaction patterns
Incompletion	Explicit structural principle	Less explicit; team evolution is acknowledged
Participation in design	Workers are co-designers	Teams are objects of organizational design
Support congruence	Explicit principle	Not addressed

The two frameworks are largely compatible — Team Topologies can be read as a contemporary operationalization of the boundary management and variance control principles in software contexts. The key gaps are on the process side: Team Topologies largely treats teams as objects to be arranged, while Cherns's participatory design principle insists that the people being arranged must be part of the arrangement process.

---

Active Exercise

Variance Audit on a Boundary You Own

Pick a team boundary that you interact with regularly — between your team and a downstream consumer, an upstream dependency, or a platform service.

For each of the following questions, write a concrete answer (two to four sentences each):

1. What variances cross this boundary regularly? List the classes of exception, escalation, or coordination event that routinely cross from one side to the other.

2. Which of those variances originate on the far side of the boundary but are absorbed on your side? These are candidates for variance-at-source redesign.

3. Does your team have the information it needs to handle the variances it is responsible for? If not, what is missing and why?

4. Does the support structure around your team — the review criteria, the incentive structures, the tooling — reinforce or contradict the ownership model implied by that boundary?

5. When was this boundary last deliberately examined? What mechanism, if any, exists to revisit it?

You do not need to produce a redesign proposal. The exercise is a diagnostic, not a prescription. The point is to make the variance flows visible and to assess each principle explicitly against a real situation.