The Builder's Exit

The split could protect an existing billing agreement, preserve a way to undo the migration, or simply mark unfinished work. Each explanation calls for a different next step. You can admire the code and still be unable to judge whether removing the split is safe.

Michael Nygard described this predicament in his 2011 proposal for architecture decision records: without the rationale, a successor faces blindly accepting a decision or blindly reversing it. His records preserve the context, decision, and consequences, including the unwelcome ones. He reported positive early feedback from developers joining projects that used them, a limited experience report rather than a measurement of long-term maintenance outcomes.

The record gives the successor something to challenge as well as follow. Knowing a split once protected a billing agreement doesn’t establish that the agreement still applies. It tells the next engineer which constraint to check before changing the code.

A delivery target can leave that work out. If a review credits shipping the migration, while nobody checks whether the next engineer understands it, the builder can receive full credit before the handoff has been tested. Completing a documentation template doesn’t close that gap if the review counts the file rather than the next engineer’s ability to use it.

That’s the builder’s exit: a person makes a consequential decision, then leaves its blast radius before the maintenance cost lands. A resignation can expose it. So can an internal transfer, or a vendor reaching the end of its contract. None of those departures establishes that the builder was careless. A manager who defers the handoff to meet a launch target has helped create the gap.

Keeping the builder longer gives you more chances to revisit the decision. It also leaves the same dependency in place if nobody else learns the reasoning. A careful engineer can leave a usable handoff; a long-serving one can remain the only person who understands the service. Tenure alone tells you little about which situation you have.

Let the next owner test it

Google’s published process for transferring production services to its reliability engineers makes the receiving team’s preparation explicit. It calls for a readiness review and agreed improvements before that team assumes production responsibility. Its training options include hands-on exercises. Responsibility and access rights transfer progressively, with developers available to back up the receiving team during the transition.

Google describes an operating practice here, without measuring how many failures those steps prevent. The part worth borrowing is the opportunity to discover an incomplete transfer while both teams can still work on it. A presentation lets the builder supply missing context as they go. An exercise led by the successor exposes where that person still needs help.

For the billing example, have the engineer taking over use the record to explain why some accounts remain on the old system and how they’d check whether that reason still applies. If an agreement still prevents a move, recognizing that limit is a successful part of the handoff. A successful test move won’t tell you whether the business is entitled to change those billing terms.

Then rehearse moving an eligible account in a test environment and dealing with a failed move. Can the successor identify which system would bill the account now, where reversal is possible, and where recovery would require repairing the data? Keep the documentation available and let the builder observe before supplying missing answers.

That rehearsal tests a particular transfer, not every future billing edge case. It costs time from both engineers, and the depth should follow the cost of getting the change wrong. A routine, easily reversed change may need only a peer review. A migration that permanently changes billing records warrants more evidence before someone accepts responsibility for it.

The successor doesn’t need to match the builder’s fluency or approve every old design choice. Agree a bounded set of tasks and recovery conditions before the handoff, so acceptance doesn’t expand into a demand to fix the entire service. A failed check still needs a diagnosis: missing rationale, missing access, and insufficient training require different repairs.

For an internal transfer, keep failed checks open and allocate time to repair them before moving the builder to another assignment. That makes the successor’s difficulty part of the current project’s cost, where the team can still act on it.

When a departure date is fixed, the manager has to assign the unresolved work and decide what the receiving team can safely change in the meantime. Planning the transfer while staffing the project gives you more options than a documentation request after the builder has gone.

A standing contract can still end

The same acceptance problem applies to a vendor, whatever the billing model. Recurring fees can reward keeping an engagement alive; renewals and referrals can reward making the client successful. A fixed price can reward finishing efficiently or doing the minimum needed for sign-off. Those pressures compete. The invoice schedule alone cannot tell you how a supplier will behave.

A standing engagement can end before a costly decision is tested. An outcome-based label leaves the practical questions unanswered. Look for the named result, who decides it was achieved, and what correction is owed if it wasn’t, including who pays for it. An agreed successor-led rehearsal can be part of acceptance, with failed checks corrected before sign-off. The terms also need to say what support continues after acceptance, what it covers, and when that obligation ends.

Once that support ends, the receiving team needs the access, authority, and capacity to operate the service and change its decisions. Keeping a supplier available can help during the transfer. If the supplier remains the only party able to explain the billing split, extending the relationship preserves that dependency along with the support.

The uncomfortable decision comes when the successor finds the migration unsafe and the roadmap has already assigned its builder to something else. If the manager moves the builder anyway, the company has chosen who will pay for finishing the handoff.