Monday Myth: The Admiral Who Planned for Missing Signals

On 9 October 1805, Nelson wrote a memorandum describing how he intended to engage the enemy fleet. It contained formations, objectives and instructions covering different circumstances. It also anticipated that signals might become impossible to see or understand. His captains received guidance for acting under those conditions, while his second in command received authority to direct his own line once Nelson’s intentions had been explained. The plan explicitly accommodated decisions its author would not make.

In an accompanying letter to Collingwood, Nelson explained that he wanted to clarify his intentions and give his colleague scope to exercise judgement. He acknowledged how much remained uncertain about the position in which they would find the enemy. Preparation therefore had to support coordinated action under circumstances that nobody could describe completely in advance.

That makes the memorandum an interesting document to read alongside a modern project plan. Nelson could specify a direction while recognising that its application would require interpretation. In many organisations, interpretation becomes suspicious precisely when the plan has acquired enough signatures to become official.

The approved document begins as an account of what people currently understand. Somewhere along its journey through governance, it acquires a different status. Estimates become commitments. Assumptions become requirements. A proposed sequence becomes the sequence against which performance will be assessed. The organisation retains the document, but gradually loses sight of the uncertainty that produced it.

Approval creates the expectation that the important thinking has finished. What remains belongs to execution, and execution should now provide predictability. Unfortunately, the work continues to reveal information without first checking whether the planning phase has closed.

When discovering something becomes a delivery problem

Consider a team integrating a new customer into an existing platform. The approved design assumes that incoming orders carry a stable identifier. During implementation, engineers discover that the customer changes identifiers after certain amendments. Processing the messages as specified could create duplicate orders and, eventually, duplicate financial transactions.

Before implementation began, the team had a plausible design. It now has a better understanding of the problem. That improvement should help the organisation make a better decision.

Instead, the discovery can trigger a familiar conversation. Why did engineering identify this so late? Can the original delivery date still hold? Has anyone assessed whether the customer will accept a change? Who authorised the team to explore an alternative?

Some of those questions deserve answers. The difficulty lies in their order and purpose. When the conversation starts by defending the existing commitment, the new information enters the organisation as an inconvenience. People must first justify having disturbed the plan before they can examine what the disturbance means.

The original assumption may have passed through several competent hands. The customer described the normal case. A business analyst documented the expected behaviour. An architect proposed an approach using the information available. Engineers encountered the exception while making the system work. Nobody needs to have acted negligently for the collective understanding to have been incomplete.

Sometimes the discovery does expose inadequate preparation. Perhaps a known exception went unexamined, or the team postponed a necessary investigation. That deserves attention too. But understanding how the gap arose and deciding what to do about it require separate consideration. Establishing that someone should have known earlier will not make the current design safe.

When discovery routinely attracts blame, teams learn to describe emerging problems as manageable details until those details become impossible to contain. Leadership receives reassurance for longer and useful information later, then demands earlier escalation next time.

How obedience becomes the rational choice

People watch what happens to colleagues who exercise judgement. They notice whether changing direction attracts more scrutiny than continuing with an approved approach. They notice whether someone who follows the plan receives protection when it fails, while someone who departs from it must defend both the decision and the outcome.

Under those conditions, asking permission becomes a sensible response. A decision that could have been made locally travels upwards because the personal consequences travel downwards. The organisation has made escalation valuable to the individual, even when it adds little value to the decision.

After enough repetitions, managers conclude that their teams lack ownership. Engineers appear reluctant to make commitments. Team leads bring problems without recommendations. Everyone seems to need reassurance before proceeding.

Those behaviours may reflect a capability gap. They may also reflect an accurate understanding of how authority and blame operate. Asking people to become more confident will achieve little if the organisation continues to penalise the judgement it claims to want.

The effect extends beyond individual decisions. People who repeatedly receive instructions without access to the reasoning behind them get fewer opportunities to develop judgement. They become familiar with the approved answer while remaining distant from the trade-offs that produced it. Over time, the organisation can create the dependency it then uses to justify continued central control.

Why leaders keep the decisions

From leadership’s position, retaining authority can make considerable sense. The team sees a technical problem. A senior leader may also see contractual obligations, a customer preparing to change its operating model, another team depending on the release, and a financial commitment that cannot move without consequences.

The engineers who identify the duplicate-processing risk may have excellent grounds for changing the implementation. That discovery gives them no automatic authority to renegotiate the customer’s launch or commit another department to additional work. Decisions must account for those consequences, and someone must reconcile competing obligations.

Central involvement can therefore improve outcomes. Experienced leaders connect information that teams cannot yet see, resolve conflicts and prevent costly local choices. The difficulty begins when every decision follows that route, regardless of its consequences or the knowledge required.

Eventually, the volume exceeds the attention available. Decisions wait longer. Explanations become shorter. Important context gets compressed into a slide or a few minutes at the end of a meeting. Leaders retain a wider organisational view while encountering the immediate problem through increasingly simplified accounts.

Teams spend more time preparing questions for escalation. Leaders spend more time answering them. Both have less time to develop the shared understanding that would allow more decisions to happen elsewhere.

A faster communication tool may shorten the journey of each request. It leaves that concentration of authority intact. A decision queue can move from a weekly committee into a permanent chat channel without becoming a better decision process.

What a better response looks like

Return to the integration team. Having found the identifier problem, the engineers reproduce the failure and establish which order amendments cause it. They work with a business expert to understand how amendments should affect fulfilment and financial processing. They then propose an approach that preserves the relationship between the original order and its subsequent changes.

That investigation belongs within their responsibility for producing a reliable integration. It should not require permission to discover whether the approved design can safely handle the customer’s actual behaviour.

The consequences of the proposed change need wider consideration. Suppose the revised approach requires an additional week, while a narrower first release could preserve the date by excluding a particular amendment flow. The team explains both options, their limitations and the remaining uncertainty. The person responsible for the customer commitment can then assess the operational and contractual implications with the relevant people.

Engineering contributes evidence and a recommendation. Business and operational colleagues contribute knowledge of consequences the team cannot assess alone. The decision reaches the level that holds the necessary authority, with enough information to exercise it.

This requires more discipline from everyone involved. The team must investigate beyond the immediate symptom and make the trade-off understandable. Leadership must engage with the evidence and accept responsibility for choosing between feasible alternatives. Nobody gets to hide behind the original plan.

Preparing people to exercise judgement

Such a response depends on preparation that a delivery date cannot provide. People need to understand which outcomes matter, how competing objectives rank, and which consequences extend beyond their authority. They also need access to the expertise required to test their reasoning.

For the integration team, “deliver the customer by the agreed date” leaves important questions unanswered. What takes precedence when the date conflicts with financial integrity? Who can agree changes to the customer interface? Which decisions affect a shared service? What evidence would justify reopening the launch commitment?

The boundaries should reflect both consequences and capability. A contained, reversible implementation choice can usually remain close to the work. A change affecting contractual obligations or several departments requires broader participation. A team entering an unfamiliar business domain may need closer collaboration while it develops understanding.

Those arrangements must also survive pressure. If the organisation grants authority during planning and withdraws it at the first uncomfortable decision, people will learn to wait. Responsibility becomes credible when teams can rely on the boundaries they were given and obtain timely help when a decision exceeds them.

A plan needs conditions for reconsideration

A useful plan identifies the assumptions on which the proposed approach depends. It should also explain what kind of evidence would justify reopening a decision.

Discovering that order identifiers change could trigger a review of the processing model. Finding that a customer needs an unsupported business process could reopen the scope discussion. Learning that an operating procedure cannot handle the expected volume could change the release approach.

Making those conditions explicit helps distinguish learning from uncontrolled expansion. Teams gain a legitimate route for challenging an assumption, while leadership gains a clearer account of why the proposal needs to change. The conversation can examine evidence and consequences instead of competing impressions of whether someone has remained sufficiently committed.

This also creates a more useful form of accountability. Teams should explain what they discovered, which alternatives they considered and what each would cost. Leaders should remain willing to revise commitments whose supporting assumptions no longer hold. Both carry responsibility for improving the decision as understanding develops.

What we choose to reward

The final difficulty appears during review. If assessment focuses mainly on adherence to the original plan, people will protect that plan even when they doubt its usefulness. If assessment focuses only on eventual outcomes, sound decisions made under uncertainty can attract punishment after an unlucky result.

A more demanding review examines the evidence available at the time, the reasoning applied, the boundaries respected and the response to subsequent learning. It can distinguish a careless departure from a justified change, and a fortunate outcome from a well-founded decision. That requires more effort than comparing actual dates with planned dates, but it also develops the judgement future work will need.

Nelson’s memorandum anticipated the moment when his captains would have to act beyond the reach of his instructions. His intentions needed to remain useful when the signals could no longer be understood. That placed a considerable burden on preparation: people had to understand enough of the wider purpose to exercise judgement from their own position.

Our organisations face a quieter version of that test whenever someone discovers something the approved plan could not account for. The response reveals what all our planning, communication and leadership have actually prepared people to do. They may have the understanding and authority to adapt together. They may have learned that the safest course involves reporting the discrepancy and waiting for someone more senior to own the decision.

There comes a point when the quality of leadership can only be seen in the judgement others exercise beyond its immediate reach. Further instructions may still matter, but they cannot compensate for preparation that never happened. That work lives in the reasoning shared, the competence developed and the authority people can trust themselves to use. Eventually, the wind changes, the flags disappear into the smoke, and the fleet reveals what it understood.