Transfer ownership and develop reusable capability

Delivery is incomplete if only the original engineer can deploy, diagnose or recover the service. Ownership must include the authority, assets, knowledge, budget and operational competence to keep the customer outcome working.

Inventory what must transfer

Record repositories, build pipelines, infrastructure definitions, vendor accounts, domain names, certificates, secrets, data stores, model artifacts, prompt/configuration versions, evaluation sets, dashboards, alerts, runbooks and contracts. For each, name the owner, access path, renewal obligation and recovery method. Customer assets should not depend on a departing engineer’s personal account.

Document what is transferred, licensed, retained by the supplier or excluded. Separate confidential customer data from reusable implementation patterns. Publication permission and reuse permission are distinct. A reusable connector must not carry another customer’s credentials, records or business rules.

Perform a customer-independence exercise

The designated operator uses their own account to deploy a known release, inspect an alert, rotate a test credential and recover a failed task. The delivery engineer observes and records where intervention was required. Choose a bounded environment and safe failure injection with agreed authority.

For a worked recovery acceptance plan, set an RTO target of 30 minutes and RPO target of five minutes for the relevant state. The operator restores a snapshot, replays eligible events, reconciles external receipts and validates business invariants. Time starts at the agreed incident declaration; completion includes verification, not just a healthy container. These are targets until a dated drill produces evidence.

A failed drill is useful. It identifies missing instructions, excessive permissions, unrecorded decisions or a brittle dependency. Fix those causes and repeat the affected exercise. Google SRE’s production-readiness approach informs this focus on responsibility and operational readiness.

Make reusable capability earn its place

A shared library is not automatically a product. Begin with a documented boundary and one implementation, then test a second materially different consumer. It should integrate through supported configuration and interfaces, without a private fork or undocumented changes to the core.

Measure integration time, changes to shared code, support tickets, upgrade effort and defects. Reuse is credible when the second team gets useful capability while preserving the first team’s obligations. Domain policy, commercial terms and sensitive data often belong outside the shared component.

Version contracts and declare compatibility. A shared agent platform needs run/operation semantics that survive framework upgrades. An index migration needs a rollback route. A connector needs deletion and schema-change behavior. The team accepting ownership also accepts the cost of maintaining those promises.

This emphasis on durable product ownership is informed by Deloitte’s product operating model work. FIELD makes ownership transfer and a second-consumer test explicit engagement decisions; it does not prescribe a particular organizational restructure.

Plan portability before it becomes urgent

List vendor-dependent interfaces, model assumptions, data formats, export rights, egress cost and replacement effort. An abstraction layer can reduce some migration effort but cannot eliminate differences in semantics, quality or authority. Test one meaningful export/import or substitution path for a critical dependency rather than claiming portability from an interface name.

Maintain an exit runbook: stop intake, drain or cancel pending tasks, reconcile unknown effects, export retained records, revoke access, delete agreed data, settle vendor commitments and communicate the transition. Verify deletion of derived stores and document backup retention where immediate deletion is not possible or appropriate under the agreed rules.

Close with a decision, not a presentation

The closing record states what was accepted, measured outcomes, known limits, unresolved items, the operating owner, support commitments and the next review. If work is paused, record what can safely remain active. If a pilot is stopped, preserve useful permitted learning without turning the forecast into a success claim.

FIELD can support recurring value reviews, extensions and reusable products. It can also lead to a smaller scope or a decision not to continue. Its usefulness is the quality and traceability of those decisions, not the number of engagements it forces through every stage.