How an engagement works

An offshore development centre engagement is an engineering team in another country that works only on your product, is directed by you, and is employed by us. It runs in five phases: scoping the work, ramping the team up, handing you day-to-day direction, governing the output where you can see it, and ending without leaving a dependency behind. None of that is unusual. What differs between providers is how much of it is agreed in writing before money changes hands.

The same five phases run whether the engagement is a full ODC or a single engineer under what the market calls staff augmentation. The scoping conversation is shorter for one person and the governing phase is mostly yours, but no phase is skipped — the ending in particular, because an engagement that cannot be ended cleanly was never really inside your systems to begin with.

1. Scoping the shape, not the headcount

Most bad engagements start with a headcount. The useful conversation is about the work: what is being built, what already exists, where the constraints are, and which decisions are still open. The team shape falls out of that.

This usually takes a week or two of real conversation. It is worth more than a fast start, because a team assembled around the wrong roles is expensive in a way that is hard to unwind.

Five questions do most of the work in that conversation:

• What is the system's job? Not the feature list — what goes wrong in the business when it is down or wrong.
• What already exists, and who understands it? An inherited estate needs archaeology before change, and that is a different skill from greenfield build.
• What cannot change? The ERP you do not own, the interface contract another team depends on, the audit obligation, the release window.
• Who decides? A team with no one on your side to answer questions will make the decisions itself, and you will not like all of them.
• What does done look like, and who says so? If the definition of done lives in one person's head, it is not a definition.

We check the answers against the system rather than accepting the inventory. On our own estate we once started auditing five installations because five were on disk; only three were live. Establishing what is actually there, rather than what a document says is there, is the cheapest hour in the whole engagement.

2. Ramp-up with overlap

Engineers join with a deliberate overlap period where they are reading, asking and pairing rather than shipping. Teams that skip this look faster for three weeks and slower for six months.

By the end of ramp-up an engineer should be able to describe the system's failure modes, not just its features. Concretely: where money is decided, which writes are not idempotent, what a retry does, which reports read directly from tables that were never meant to be a public interface, and what breaks if a batch is rerun.

Part of ramp-up is reading the data, not only the code and the documentation. If you ask a business whether a customisation is still used, you will be told yes about everything. Looking at what has actually been written in the last year answers it properly. That habit is also how we avoid the most expensive kind of new-team mistake — removing something that looked dead.

3. You direct the work

The team works to your backlog and your process. We are responsible for the people — hiring, retention, cover during leave, the working environment, and replacing anyone who is not right for the role.

That division matters. Providers who insist on managing the work as well as the people tend to optimise for utilisation rather than for your outcome.

In practice the split is: you own priorities, technical direction, review rules and the definition of done. We own recruitment, appraisal, retention, leave cover, replacement, and a named escalation point who is accountable for the engagement and is not one of the people doing the work — so raising a problem is not a conversation with the person who caused it.

4. Governance you can actually see

• Code in your repositories, under your review rules, from day one
• Infrastructure defined as code so environments are reproducible without us
• Documentation written as work happens, not assembled at handover
• A named point of escalation on our side who is not the person doing the work

Nothing is developed in a private space and handed over later. That rule exists because the alternative hides exactly the information you would want during the engagement rather than after it: how much rework there is, which decisions were contested, and whether the tests are real.

5. Ending well

An engagement should be endable. That means no undocumented deployment steps, no credentials that live only in someone's head, and no architectural decisions that only make sense if we are still here.

A handover that works is boring: the repositories you already own, environment definitions that rebuild without us in the room, a runbook written while the work was happening, credentials rotated into your own store, and a period where your team runs the system while ours is still reachable. If any of that has to be assembled at the end, it was not being done during.

We would rather be re-engaged because the work was good than retained because leaving is painful.

How do you know the work is good, rather than being told it is?

By measuring it, and by treating a success message as a claim rather than as evidence. A deployment script that prints "done" has told you it reached the end of itself, not that the thing it deployed works.

This is how we run our own estate, which is the only fair test of a claim about delivery discipline. The deploy script for our own website asserts that every target URL returns 200 before it writes anything, and rolls the configuration back as a unit if the syntax check fails. Two deploys were stopped by those guards before reaching production — which is the guards working, not the guards being annoying. A rendered-DOM auditor drives the built site in a headless browser and exits non-zero on layout and content regressions, so a broken page fails a check instead of waiting to be noticed in a screenshot.

The same auditor is a good illustration of why a check has to be proved before it is trusted. Its first run audited the wrong website entirely, because the port it assumed was already serving an unrelated project. It now refuses to run until the homepage proves it is the site under test. A test you have not seen fail is not a test.

When is an ODC the wrong fit?

We would rather say so at the scoping call than discover it in month three.

• The work is a few weeks long. Ramp-up cost makes a dedicated team poor value below a quarter. Take it as a fixed-scope project instead.
• There is nobody on your side to direct the team. An ODC is capacity you direct. Without a product owner or an engineering lead who can answer questions and set priorities, you are buying a team that will invent its own brief.
• The requirement is genuinely unknown. If nobody can yet describe what the system has to do, the next step is a discovery conversation, not eight engineers.
• The data cannot leave the jurisdiction. Some regulated work simply cannot be done offshore, whatever the contract says. Establish that first.
• You want the problem to go away entirely. Somebody on your side still has to accept the work. An engagement where nobody reviews anything ends badly in every model.