Wednesday Reality: Most Failures Begin Between Two Competent People

The Ship Continues Through the Night

A ship does not stop because the officer on watch has reached the end of a shift. Its engines continue turning, its position continues changing, weather continues developing and nearby vessels continue following courses of their own. The sea offers no pause button while one person explains the situation to another. At the moment responsibility changes hands, the vessel remains fully exposed to reality.

Maritime watchkeeping therefore treats relief as more than a calendar event. The incoming officer must understand the ship’s position, course, speed, traffic, weather, equipment condition, standing orders and any developing situation that has not yet become dangerous. A logbook can record facts, but it cannot carry the outgoing officer’s entire mental model. A bearing that has altered slowly for twenty minutes, a radar return that looks harmless but behaves strangely, or a wind change that has not yet justified a course correction may matter more than the entries easiest to document.

The incoming officer does not assume control merely because the clock has reached the appointed hour. The officer must first establish sufficient understanding to accept responsibility. If the situation remains uncertain, the change of watch waits. The International Maritime Organization places watchkeeping within formal standards of competence because navigation depends not only on what each officer knows, but on whether operational understanding survives the transition between them. The ship cannot afford a period during which one person has stopped thinking and the next has not yet begun. The IMO’s STCW framework makes watchkeeping a distinct discipline rather than an informal exchange between qualified individuals.

This attention to transfer reveals an uncomfortable property of complex systems. Their most vulnerable moments often occur not inside a component, but between two components functioning as designed. Both officers may possess the required competence. Both may follow their instructions. Neither needs to make an obviously foolish decision. The system only needs to lose one piece of context while responsibility moves from one mind to another.

The Permit on the Other Desk

Industrial systems discovered the same problem in less forgiving circumstances. On an offshore platform, a permit-to-work system controls maintenance by recording which equipment has left service, what has been dismantled and what conditions must hold before anyone restarts it. The permit does not merely authorise activity. It preserves the state of a system while different trades, shifts and operating teams intervene in it.

On 6 July 1988, Piper Alpha suffered the disaster that killed 167 people. The initiating sequence involved condensate pump A, which had been taken out of service while work proceeded on its pressure safety valve. A separate maintenance activity on the pump created another permit. When the operating pump later failed, the night shift attempted to return pump A to service. The information available to them did not make the missing safety valve sufficiently visible. Hydrocarbons escaped, ignited and began a sequence of explosions and fires that the platform’s wider design allowed to escalate. The subsequent public inquiry examined not only equipment and individual actions, but the permit-to-work system, shift communication, emergency arrangements and the organisational conditions surrounding them. The UK Health and Safety Executive preserves the Cullen inquiry, while the Institution of Chemical Engineers identifies inadequate work control and poor shift communication among the central causes in its incident summary.

The permit existed. Qualified people had performed the work. Another qualified group operated the platform. The catastrophe did not require incompetence to occupy every part of the system. It required different fragments of competence to remain separated at the moment when the plant demanded a coherent understanding.

After such events, organisations often respond by improving the transfer. They add fields to permits, signatures to checklists, gates to processes and mandatory meetings between shifts. In continuous industrial operations, this response makes sense. Human beings need rest, but the plant must continue operating. The handover cannot disappear, so engineers reduce the amount of reality it can lose.

A curious thing happens when organisations borrow the same logic for work that never required the boundary in the first place.

The Factory Made of Departments

Many companies describe product development as a sequence resembling a production line. Marketing gathers demand. Product converts demand into requirements. Design turns requirements into interactions. Engineering turns interactions into software. Operations deploys the software. Support receives whatever customers experience after deployment.

Each department contributes something valuable, and the sequence appears rational because work seems to acquire greater definition as it moves downstream. Organisations reinforce the model with stage gates, readiness reviews, acceptance criteria and ownership matrices. Every transition receives a name. Discovery hands over to delivery. Development hands over to operations. The project hands over to the product team. The implementation team hands over to maintenance.

The model assumes that knowledge can travel inside artefacts. A product brief carries the customer problem. A design carries the intended behaviour. A ticket carries the design. Code carries the ticket. Documentation carries the code into production. Once the artefact crosses the boundary, the previous actor can withdraw because responsibility has moved with it.

Yet knowledge work does not behave like material on a conveyor. A machined component should preserve its form as it moves between stations. A product idea should not. Engineering discovers constraints that change the possible solution. Design uncovers behaviours that change the understanding of the problem. Production reveals usage patterns that invalidate assumptions made during discovery. Support encounters consequences that no acceptance criterion anticipated. Every stage changes not only the solution, but the meaning of the work that entered it.

The more faithfully each department protects its local definition of completion, the more easily the whole organisation can fail. Product delivered clear requirements. Engineering implemented the agreed scope. Operations deployed it successfully. Support answered every ticket within its service target. The customer still gained nothing, but every function can demonstrate that it completed its part.

The handovers succeeded. The product did not.

A Stream That Returns to Its Source

A value stream has direction because value must eventually reach someone. It does not, however, have a natural sequence in which one form of expertise finishes before another begins. It behaves more like a control loop. Customer behaviour creates signals. Product helps interpret those signals and frames a desired change. Engineering examines feasibility, system constraints and possible failure modes. Operations observes actual behaviour under real conditions. Support detects where the customer’s experience diverges from the organisation’s model. Those observations alter the next interpretation of the problem.

Nothing passes through this loop unchanged. Each movement enriches the organisation’s understanding, provided the signal can travel in both directions. Product does not cease participating when engineering begins construction. Engineering does not wait for a finished problem before applying technical judgement. Operations does not join after the design has fixed the system’s failure characteristics. Support does not merely absorb mistakes after release. The actors remain present throughout the stream, although their influence changes as the work changes.

This distinction matters because continuous participation can easily collapse into permanent coordination. Keeping everyone involved does not mean placing everyone in every meeting or requiring collective approval for every decision. That would replace information loss with decision paralysis. Expertise must scale in when it can materially alter the outcome, scale out when another discipline carries the work, and continue communicating while its direct influence recedes.

During problem discovery, product and customer-facing functions may exert the greatest influence, but engineering can expose feasibility constraints before promises harden into commitments. During construction, engineering carries most decisions, but product remains close enough to recognise when technical discovery changes the original value proposition. During release, operations may control deployment and recovery, but engineering retains responsibility for the behaviour it created. Once customers use the system, support and operational signals gain influence, while product and engineering reinterpret what should happen next.

Influence moves. Responsibility does not disappear.

Engineering Before Implementation

The handover model quietly reduces engineering to implementation. Product decides what matters, architecture chooses an approved direction, and engineers select tools and produce code. The engineer’s competence then appears measurable through delivery speed, technical correctness and conformance to the assigned scope.

Actual engineering begins earlier and ends later. It asks whether the problem has been framed in a way that admits a sound solution. It examines constraints that the requested feature may conceal. It considers not only whether a system will work, but how it will fail, how far the failure will propagate, how anyone will detect it and whether recovery will remain possible when several assumptions fail together.

No tool provides these qualities by itself. A database can look ideal for the access pattern while creating operational fragility the organisation cannot manage. A distributed architecture can scale elegantly while multiplying partial failures and recovery paths. A managed service can reduce immediate effort while concentrating dependency on pricing, quotas or a capability nobody internally understands. A simple design can outperform a sophisticated one because the people responsible for it can observe, modify and recover it.

The best tool exists only in relation to the system that must carry it. Reliability concerns performance under expected conditions. Resilience concerns survival when those expectations stop holding. Maintainability concerns the ability to change the system without rediscovering it. Operability concerns whether another person can understand its condition when the original author has gone home. Security concerns what happens when an intelligent adversary explores assumptions that ordinary users respect. Cost concerns not merely the invoice, but the human and organisational capacity consumed over the system’s life.

An engineer who receives a finished specification too late cannot fully exercise this judgement. By the time engineering discovers that the requested behaviour conflicts with reliability, latency or recovery constraints, the organisation has already converted assumptions into expectations. Technical reality then looks like resistance. The engineer becomes the person explaining why delivery will take longer, while the earlier decision that created the difficulty remains outside the delivery system.

Product suffers from the same separation. Once product hands over the requirement, it loses access to the discoveries made while the solution encounters reality. Trade-offs happen inside implementation, often disguised as technical details, although they alter customer behaviour. The specification survives, but its intention erodes through hundreds of locally reasonable decisions.

Faster Fragments

AI can intensify this pattern without causing it. It can produce code, tests, designs, requirements and documentation within each departmental boundary. Every participant can generate a more complete-looking artefact before passing it onward. The organisation experiences acceleration because local queues shrink and visible output increases.

The underlying flow may deteriorate. More solutions enter construction before the problem has matured. More implementation decisions occur without product context. More technical components appear without proportional growth in operational understanding. Documentation becomes abundant while shared comprehension becomes scarce. Each function moves faster, but the feedback loop struggles to return evidence quickly enough to change direction.

A system composed of rapidly produced fragments still needs someone to understand their interaction. When that understanding has no home, the organisation responds with more coordination machinery. It adds programme managers, architectural reviews, dependency boards and status reporting. These mechanisms attempt to reconstruct globally what the development model deliberately fragmented locally.

The result resembles an industrial plant where every instrument reports correctly to a different control room.

The Interval Nobody Owns

Organisations frequently pursue accountability by assigning an owner to every component. The product manager owns the problem. The engineering team owns the service. Operations owns production. Support owns the customer incident. The map looks complete because no box remains empty.

Reality occupies the lines between the boxes.

A customer outcome depends on the problem being understood, the solution remaining feasible, the system behaving reliably, the operation exposing useful signals and those signals changing subsequent decisions. No single transfer contains that chain. No document can preserve every assumption. No ceremony can compensate for actors who mentally leave the stream once their formal contribution ends.

At sea, the change of watch exists because the ship cannot stop and the officer cannot remain awake forever. Maritime practice surrounds that necessary discontinuity with discipline because the danger cannot be designed away.

A product has no such need to change watch at every departmental boundary. The customer never handed the problem exclusively to Product. Product never possessed enough knowledge to finish it before Engineering began. Engineering never completed it when the deployment succeeded. Operations never received a finished system, only the latest version of an unfolding hypothesis.

The ship requires a handover because human attention must occasionally leave the bridge. Organisations manufacture handovers because their diagrams suggest that knowledge should obey the same boundaries as authority. The sea recognises the first constraint. The customer remains exposed to the second.