The Locking Organisation
Pessimistic coordination instead of single-writer authority
Invariants are enforced by designated single writers per domain — not by global locks or serialised approval across the whole system.
When invariants span shared state and no single writer owns the domain, the usual response is to lock everything until agreement is reached. In software this is a global mutex, a distributed transaction, a change-advisory board in code. In organisations it is the steering committee, the architecture review gate, the strategy sign-off that must precede any substantive move. The locking organisation is what you get when you reject diffuse write authority but have not yet assigned single writers — so you serialise the world instead.
The principled alternative at scale is not only single writers and reservations (One Authority Per Invariant — At Scale) but platform self-service: encoded guardrails so product teams configure inside the contour and the system enforces — not a central reviewer on every point.
In software systems
Pessimistic locking treats consistency as a scheduling problem: before any writer acts, acquire exclusive access to all state the invariant might touch, perform the check, commit, release. At small scale this works. At distributed scale it produces global contention, deadlock graphs, and failure modes where one slow or crashed lock holder stalls unrelated work across the cluster.
Two-phase commit across services is the architectural expression. Every participant must agree before any commits; one slow node blocks all. Database row locks held across network calls couple latency and availability in ways that resist horizontal scaling. Teams compensate with ever-longer lock timeouts, retry storms, and “temporary” synchronous call chains that become permanent.
The anti-pattern is often chosen as the safe alternative to multiple writers — safer than hoping concurrent updaters stay consistent, but not safer than redesigning so only one writer holds authority over the invariant domain. Locks preserve the illusion of control while converting a local correctness problem into a system-wide scheduling bottleneck.
In human organisations
The organisational form is the locking organisation: any significant decision must pass through a central approval function before local teams may act. Strategy must bless product changes. Architecture must bless every cross-team integration. Legal must review before engineering commits. Each gate is a lock; the queue behind it grows as the organisation scales.
The same pathology often appears at the culture layer as consensus culture — norms that treat unanimous comfort as prerequisite to action, dissent as disloyalty, and named commitment as premature. Process locks and cultural locks reinforce each other.
Coordination overhead rises as O(n—) with the number of teams that must align. Bottlenecks appear not because approvers are incompetent but because the architecture requires them to serialise work that could proceed in parallel under clear domain authority. Decision latency dominates cycle time. Dynamic capability erodes: the organisation senses need to change but cannot reconfigure what no single team owns.
Invariants are not enforced — they are negotiated at lock points. Customer data quality, spending limits, release criteria exist as policies debated in committees rather than as outcomes committed by named authorities with exclusive write access to their domains.
In socio-technical systems
The compounded failure is mutual paralysis. Software cannot ship without organisational sign-off; the organisation cannot adapt its processes without software changes that require the same sign-off. Platform teams hold de facto locks on deployment; business teams hold de facto locks on requirements; neither can move without the other’s release window.
Conway’s Law ensures alignment: an organisation built on global approval produces platforms where every service synchronously calls a central orchestrator, or where production changes freeze during “change windows” that span quarters. Incidents trigger more locks — emergency CABs, deployment moratoriums — rather than clearer ownership. Accountability diffuses into “the process” while throughput collapses.
The locking organisation and diffuse write authority are twin failures. One lets everyone write and hopes; one lets almost no one write until everyone agrees. Both avoid the structural move: one writer per invariant domain, others interact through reservations, requests, and committed L0 outcomes. See also consensus culture for the cultural variant — including when consensus is appropriate in stable environments.
Why it persists
Coordination as architecture. Global locks and standing approval gates feel like mature governance. They are visible, auditable, and familiar from prior employers.
Path dependency. Early systems used 2PC and CABs; unwinding requires domain redesign and Conway-aligned ownership — expensive and politically slow.
Missing principle. Single authority per invariant is not the default teaching. Teams reach for locks when multiple writers already exist.
Short-termism. A new approval gate ships this quarter; single-writer refactor is “next year.”
Principled alternatives
Single writer principle
Assigning exactly one authority per invariant domain removes the scheduling bottleneck locks simulate. Others read, reserve, and request — they do not write governed facts directly. Cross-service coordination uses reservation-then-commit and sagas with one orchestrating writer, not n-way synchronous locks.
Article 19 extends this to platform domains for cross-cutting invariants: product teams proceed through reversible work, hold at the commitment boundary, and consume platform L0 decisions — without global serialisation of all work.
The goal is not zero coordination. It is coordination proportional to genuine cross-domain commitments — not pessimistic serialisation of work that belongs inside a single authority.