Replacement Guarantee: Team Changes Never Slow Delivery

The resignation email arrives on a Thursday. Your squad lead forwards it Friday morning. An engineer — the one who owns the payments integration and has been on the project for eight months — has accepted a competing offer. Last day: two weeks from now.

In a standard contractor arrangement, what happens next is your problem. You or your internal lead writes a brief, the agency starts searching, candidates get screened, an offer gets made. Four weeks later, if you're lucky, someone new starts. Then there's the onboarding — the architecture walkthrough, the codebase tour, the "ask the person sitting next to you" approach to filling knowledge gaps. Eight weeks from departure to contribution is optimistic. Two months is common. Sprint delivery slips. Your roadmap moves right. The cost lands on your side of the ledger.

This is the pattern that replacement guarantee team continuity is designed to break. Not by making engineers stay — attrition is a feature of a competitive market, not a bug. By changing who absorbs the risk when they leave.

The Contractor Attrition Trap

Most contractor arrangements are structured around capacity, not continuity. You buy hours. The agency supplies engineers. When an engineer leaves, the agency may feel professionally obligated to find a replacement quickly — but they're not commercially penalised if they don't. The billable clock keeps running. The shortfall in delivery capacity lands on the client's timeline.

The deeper problem is structural. In a time-and-materials model, the vendor's incentives and the client's incentives aren't aligned on continuity. The vendor has no material reason to invest in documentation depth, bench capacity, or onboarding infrastructure — because the commercial model doesn't require those things to generate revenue. The invoice arrives regardless of what happens to sprint velocity when someone leaves.

This isn't a criticism of individual agencies. It's the default architecture of the contractor model. The architecture produces the outcomes it's designed for: capacity on demand, without structural accountability for continuity.

One composite pattern we've seen repeatedly: a contractor team loses an engineer to a competing offer mid-feature build. The replacement cycle takes eight weeks. In that time, two sprint deliveries slip, a launch date moves, and the client spends around 30 hours on hiring activity they didn't budget for. Compare that to a TaaS engagement operating under the Replacement Guarantee — same situation, engineer leaves, replacement is sourced from the bench, onboarded via the Developer Onboarding Guide, and contributing to the sprint two weeks into the next cycle. No sprint slippage. No client-side hiring overhead.

The gap between those two outcomes isn't luck. It's structure.

What the Replacement Guarantee Actually Commits To

The Built to Last™ 2.0 Replacement Guarantee is operational, not promotional. The commitment: when an engineer leaves, we carry the full attrition risk. A replacement is sourced from the bench, fully onboarded using the Developer Onboarding Guide, and contributing to the sprint within two weeks. The client doesn't manage recruitment, doesn't absorb the knowledge transfer overhead, and doesn't pay for the understaffed period.

Three elements of that commitment deserve unpacking.

From the bench. We maintain a reserve of pre-vetted engineers mapped to active TaaS engagements. A replacement isn't sourced by posting a job description and waiting. It's sourced from engineers who are already known quantities — already vetted, already aligned with our quality standards, already familiar with the tooling and processes we run. Bench investment isn't a nice-to-have; it's the operational condition that makes a two-week timeline realistic.

Fully onboarded using the Developer Onboarding Guide. Every TaaS engagement maintains a Developer Onboarding Guide as a living document — architecture overview, codebase structure, local development setup, deployment process, integration quirks, known edge cases. This is built throughout the engagement, not assembled at the end. When a replacement joins, they follow the same structured onboarding process used for any squad addition. Their productivity doesn't depend on the departing engineer's availability to brief them, because the brief already exists.

Contributing to the sprint within two weeks. This is the measurable commitment. Not "onboarded" — a word that's easy to claim and hard to verify. Contributing. As in: sprint board, assigned tickets, working output. That's the observable. Two weeks from departure to sprint contribution is achievable specifically because the two enabling conditions — bench depth and documentation — are maintained as operational commitments, not ad hoc responses.

The commercial structure enforces it. Replacement sourcing, onboarding, and knowledge transfer are absorbed by us. The client continues paying for a functioning squad, not a squad in recovery mode.

Why Knowledge Transfer Is the Hard Part

There's a reason typical contractor transitions take eight weeks rather than two, and it isn't sourcing speed. It's knowledge.

In engagements without structured knowledge transfer, the architecture lives in the heads of the engineers who built it. Edge cases are remembered, not documented. The reason the payments module behaves unexpectedly at month-end? Ask the person who built it — except that person just left. The integration quirk that's been stable for two years because someone knows not to touch a specific config value? It's undocumented because it never seemed urgent enough to write down.

This is the problem the Knowledge Transfer Protocol in the Built to Last 2.0 framework addresses. Built for handover from week one, not compiled at the end. Every significant architectural decision is documented when it's made. Edge cases are logged in context. The onboarding guide reflects the current state of the system because it's updated throughout the engagement, not assembled when someone leaves.

When knowledge lives in the system — in documentation, in the onboarding guide, in the codebase itself — the departure of any individual engineer is disruptive but recoverable. When knowledge lives only in people, every departure is a potential crisis. The Replacement Guarantee only works if the knowledge infrastructure is there. They're not separate commitments. They're the same commitment expressed in two different forms.

Risk Transfer Changes the Engagement, Not Just the Clause

Here's the distinction that matters commercially. The Replacement Guarantee isn't a service level agreement appended to a standard contractor contract. It's a structural reallocation of who bears the cost when attrition occurs.

In a typical contractor arrangement, attrition risk sits with the client. Not because the agency intended it that way. Because the commercial structure doesn't penalise the vendor when continuity breaks. The incentive to invest in bench depth, documentation, and onboarding infrastructure is missing — or at best, present only as professional pride, which is real but not reliably sufficient when competing priorities emerge.

When the vendor absorbs attrition risk — when replacement failure costs them, not the client — the investment calculus changes. Bench depth stops being overhead and becomes protection on a commercial commitment. The onboarding guide stops being a nice-to-have and becomes the infrastructure that makes the guarantee deliverable. Knowledge transfer stops being a project phase and becomes the ongoing condition of the engagement.

The guarantee doesn't just protect you from the cost of attrition. It changes the vendor's structural incentives in a way that makes the engagement more resilient than it would otherwise be. This is what makes TaaS structurally different from managed contractors. The difference isn't in the engineers. It's in who carries the risk when those engineers leave.

Our engagement with Nuvei — now Till Payments — illustrates what this looks like at scale: a long-running, embedded product engineering team delivering continuously across multiple squad changes, without the client absorbing attrition costs or managing replacement cycles.

When This Matters Most, and When It Can Wait

The Replacement Guarantee is most critical at the Scale stage — products generating revenue, dependent on a specific squad's sustained output, where sprint slippage has direct commercial consequence. When the cost of a two-month delay is real, the ability to replace in two weeks is not a differentiator. It's a prerequisite.

At the MVP stage, the calculus is different. A small squad with a tight codebase and disciplined documentation can manage a team change without formal continuity infrastructure. The blast radius of attrition is smaller when the product is younger. You can likely absorb it. The Replacement Guarantee still has value, but it's not the most critical protection at this stage.

At the Enterprise stage, continuity planning is already embedded in broader governance structures — named account leads, structured handover packages, formal knowledge management. The guarantee sits within a larger continuity framework rather than serving as the primary protection.

If you're running a product at the Scale stage on a contractor model with no explicit continuity commitments, and you haven't stress-tested what happens to your timeline if your lead engineer leaves — that's the gap worth addressing before it becomes the emergency you're managing instead.

What to Do Next

The right question to ask of any squad arrangement is: who carries the attrition risk? If the answer is unclear, or if the answer is you, the commercial structure is telling you something important about the operational structure underneath it.

If you're evaluating a TaaS engagement or reconsidering an existing contractor arrangement, the staff augmentation and TaaS delivery model outlines how the structure works in practice — including how we build for continuity from day one. For context on how delivery accountability works across the broader Built to Last 2.0 framework, the project delivery framework overview is the right starting point.

Frequently Asked Questions