Friday Fun: Your Outcome Is Out for Delivery

Modern parcel delivery represents one of civilisation’s quieter engineering achievements. A cardboard box can leave a warehouse outside Rotterdam, cross three borders, pass through several sorting centres, survive conveyor belts, scanners, vans and weather, then arrive at a specific doorway in a village whose street name appears differently on three mapping systems. Most of this happens without anyone knowing what the parcel contains, why it matters or how disappointed the recipient will feel when discovering that the supposedly industrial drill bit resembles something designed for assembling dollhouse furniture.

The system works because nobody needs to understand the whole journey. Each facility receives a package, reads a label, performs a tightly defined operation and sends it towards the next facility. Barcodes replace conversations. Routing tables replace judgement. Scanning events create a trail through the network. The parcel remains closed because opening it at every depot to rediscover its purpose would rather undermine the economics of logistics.

This model works remarkably well for objects. It has consequently proved irresistible to organisations attempting to deliver outcomes.

The corporate version begins when somebody identifies a customer problem. Because problems remain dangerously ambiguous, Product places the problem inside a requirements document, seals it carefully and attaches a label marked Ready for Engineering. The original customer context may no longer fit inside the package, especially once the acceptance criteria, quarterly commitments and stakeholder expectations have entered it, but logistics requires standard dimensions.

The parcel now possesses something more valuable than meaning.

It possesses a status.

Shipment information received

The first tracking event creates a reassuring impression of motion. Nothing has physically moved, but the delivery system knows that someone intends to send something somewhere. Corporate planning operates on the same principle. Once an initiative appears in the roadmap, leadership can already observe progress in its natural habitat: a coloured rectangle extending confidently across several months.

The rectangle contains no awkward questions about technical feasibility, operational constraints or whether customers care enough to change their behaviour. Those details belong to later distribution centres. At this stage, the organisation has generated shipment information, and shipment information looks surprisingly similar to delivery when projected onto a sufficiently large screen.

A preliminary estimate may accompany the parcel. This estimate typically comes from people who have not inspected its contents, travelled its route or spoken to the eventual recipient. Logistics companies would hesitate to promise a delivery date for a box before learning its dimensions, weight, destination or whether it contains lithium batteries. Corporations show greater courage.

The date appears first. Reality receives the remaining fields later.

Collected by Architecture

Before Engineering can accept the parcel, Architecture may need to verify that it complies with the organisation’s approved transportation standards. The package receives diagrams, review records and several stamps confirming that it will eventually travel through the correct conceptual warehouses.

This inspection does not necessarily reveal whether the solution will work. It confirms something institutionally safer: if the solution fails, it will fail according to an approved pattern.

The package may now weigh considerably more than when it contained only a customer problem. It carries target-state architecture, governance decisions, security assumptions, platform dependencies and a recommendation to use a strategic technology selected during a previous shipment. Nobody wants to reopen the strategic technology decision because the organisation ordered several years’ worth of boxes with its logo already printed on them.

Engineering receives the parcel and notices that the address does not exist.

The customer needs something slightly different. One dependency remains unavailable. The platform supports the required use case in principle, which means that somebody once mentioned it during a presentation. The data cannot legally travel along the proposed route. The apparently reusable component requires six weeks of modification before it can save two days of work.

None of these discoveries changes the promised delivery date because the tracking system already told the customer that the parcel had entered the network. Changing the date would suggest that the network lacks control. The preferred interpretation therefore concludes that Engineering has encountered an execution issue.

Delayed due to circumstances within our control

Real parcel networks distinguish between weather disruption, customs delays, incorrect addresses and operational failures. Corporate tracking systems possess a more advanced classification scheme. Almost every delay eventually becomes an Engineering delay because Engineering represents the final identifiable location before the promised outcome fails to materialise.

The distinction matters. A problem discovered during implementation appears to have originated during implementation. The months spent converting uncertainty into confident requirements disappear from the tracking history. The architectural assumptions become invisible packaging. The dependency accepted during planning becomes a technical obstacle. The unresolved commercial question becomes an edge case.

The last handler inherits the accumulated uncertainty of every previous depot.

This creates one of the organisation’s most dependable optical illusions. Upstream functions appear predictable because they pass uncertainty downstream. Downstream functions appear unreliable because that uncertainty finally encounters matter, time and causality.

The parcel may have travelled through five departments without anyone testing whether its contents can survive the journey. Engineering opens it and immediately acquires responsibility for the broken glass.

Recipient unavailable

Customers contribute additional inconvenience by refusing to behave like roadmap assumptions. They misunderstand carefully designed interfaces. They continue using spreadsheets. They abandon registration halfway through. They request capabilities that research classified as secondary and ignore features that occupied three executive steering committees.

The organisation responds as a delivery company might respond to an empty house. It records that an attempt took place.

The feature shipped. The release notes exist. The launch meeting happened. Marketing published the announcement. Sales received enablement material. Somewhere, a dashboard counts impressions with the quiet determination of a courier repeatedly ringing the wrong doorbell.

Whether the customer achieved anything now lies beyond delivery. Product delivered requirements to Engineering. Engineering delivered software to Production. Production delivered availability to the internet. The internet presumably delivered value to someone.

The recipient appears unavailable.

A second delivery attempt may follow. The button moves. The copy changes. A notification campaign reminds customers that the parcel they never requested continues waiting for them. If adoption remains weak, leadership may conclude that the organisation needs stronger execution. The next parcel receives priority shipping.

Proof of delivery

Every mature delivery system requires evidence. A courier photographs the parcel resting beside a gate, beneath a hedge or outside a house that shares several architectural features with the intended destination. The image proves that the parcel occupied a surface at a particular moment. Whether the recipient ever found it belongs to another metric.

Corporate proof of delivery follows the same evidential standard.

The deployment succeeded. The epic closed. The sprint velocity recovered after the team divided the remaining work into smaller tickets. The programme dashboard returned to green once the reporting definition excluded the inconvenient dependency. Every local system can demonstrate successful handling.

The outcome, meanwhile, may sit quietly behind the organisational equivalent of a recycling bin.

This explains why large initiatives can accumulate thousands of completed tasks while producing remarkably little change. Completion travels through the coordination system more easily than value travels through the productive system. Tasks possess owners, dates and statuses. Outcomes spread across boundaries, emerge slowly and frequently depend on conditions that no department controls alone.

A tracking system designed around handovers nevertheless requires each object to occupy one location. So the organisation assigns the outcome to Product, then Engineering, then Operations, then Sales, then the customer. Ownership moves precisely because responsibility does not.

When failure finally becomes undeniable, the tracking history offers an immaculate sequence of successful transfers.

Damaged in transit

Handovers do not merely move work. They transform it.

At each boundary, people remove context that the receiving system cannot process. Customer frustration becomes a requirement. A requirement becomes a story. A story becomes a technical task. A technical task becomes a deployment. A deployment becomes a completion percentage. By the time the organisation reports the result, it has compressed a living problem into a collection of administratively convenient events.

Nothing necessarily went wrong at any individual step. Every transformation made local sense. The damage emerged from the journey itself.

Parcel networks compensate for physical handling with protective packaging. Organisations often attempt the same thing through documentation. More detail enters the package. Requirements expand. Templates grow. Approval gates multiply. The organisation tries to preserve meaning by wrapping it in additional representation.

Unfortunately, context does not behave like porcelain. It cannot always survive separation from the people, conversations and observations that created it. A document can record what somebody believed when they wrote it. It cannot preserve the continuous learning that would have occurred if the people solving the problem had remained connected to the people experiencing it.

The thicker packaging also creates a second problem. Once considerable effort has gone into specifying, reviewing and approving a solution, reopening the parcel feels destructive. New information threatens sunk costs, commitments and reputations. Teams continue transporting an obsolete answer because changing the contents would invalidate the paperwork attached to the box.

The package reaches its destination intact.

The world around it has moved.

Please contact the sender

Eventually, someone asks why delivery takes so long. The organisation studies the tracking data and discovers delays between departments. The obvious response involves optimising the handovers.

A new intake process appears. Product must provide more complete acceptance criteria. Engineering must estimate earlier. Architecture must review sooner. Dependencies must enter a central register. Programme managers must monitor the parcels. Dashboards must expose ageing work. Artificial intelligence may summarise the tracking history and predict which boxes have the greatest probability of vanishing inside the network.

The organisation has now installed a more sophisticated parcel service while continuing to treat problem-solving as parcel delivery.

Each improvement increases the apparent manageability of the system. It also strengthens the assumption that work can cross a boundary without the people on both sides continuing to think together. The interface becomes cleaner while the relationship becomes weaker. The organisation gains more precise information about where meaning disappeared.

This produces fertile conditions for contractual behaviour. Product insists that the requirements were clear. Engineering points towards missing decisions. Architecture cites the approved design. Operations notes that nobody consulted them. The programme office produces timestamps proving that every party received the parcel.

Nobody owns the journey, but everyone retains a delivery receipt.

Returned to sender

The most expensive parcels eventually return. Customers reject the feature. Operations cannot support it. Engineering must replace the hurried design. Product discovers that the original problem changed six months earlier. Leadership launches a recovery programme whose first task involves reconstructing the context discarded during the original journey.

The return does not travel as freely as the outbound shipment. Organisational systems handle commitments better than contradiction. Roadmaps have lanes for planned work, not for discovering that completed work should never have started. Budgets recognise development more readily than unlearning. Performance systems reward delivery and struggle to classify intelligent retreat.

The returned parcel therefore acquires a new label.

It becomes technical debt, optimisation, Phase Two, adoption work or transformation.

Nothing has gone backwards. The organisation has created another forward-moving initiative.

Soon the same box re-enters the network, repackaged, reprioritised and accompanied by a steering committee determined to prevent a recurrence. More checkpoints will protect it. More reporting will follow it. More senior people will receive notifications when it stops moving.

Its original contents remain difficult to identify. The label has passed through too many systems, and rain has reached the cardboard. Yet the tracking portal continues to offer reassurance:

Your outcome is out for delivery.

It has been out for delivery for eleven months.

Nobody knows which van contains it, but the dashboard remains green.