The first ninety days decide whether a dedicated team becomes part of your engineering organisation or stays a vendor you manage. Neither outcome is luck. Both are the product of what happens — or fails to happen — in three specific months. Here is the playbook we run, and more usefully, what you should be able to observe from the outside at each stage, whoever your team is.
Month one: due diligence, access, and the first diff
Month one starts with technical due diligence, honestly reported — including the unflattering findings. A team that flatters your codebase in week two will flatter your outages in month six. You want the report that says which corners were cut, which dependencies are rotting, and what the team would tackle first, in writing, before anyone commits to a roadmap.
In parallel: environment access, done properly. Your repos, your cloud, from day one. Every artefact that lands in a vendor’s infrastructure instead of yours is exit cost quietly accruing — this is the moment to get it right, not month twelve. And before any of this, you should have interviewed the tech lead yourself; we insist on it, because everything in this playbook depends on who is actually running the team.
Then the part most onboarding plans defer: production code inside the first month. Small, reversible changes first — a dependency upgrade, a bug with a clean repro, a well-scoped endpoint. Not because the team cannot handle more, but because small diffs exercise the entire pipeline — access, review, CI, deploy — while the blast radius is trivial. Trust is built in the diff, not the deck.
Month two: cadence
Month two is where working sessions harden into a delivery system. Trunk-based delivery: short-lived branches, frequent merges to main, no long-running branch for problems to hide on. Review gates that do not care who — or what — wrote the code: static analysis, tests, and a named engineer’s sign-off on every merge.
Just as important, a working definition of done that includes documentation and ADRs. A change is not finished when it works; it is finished when the next engineer can understand why it is the way it is. If “done” is not written down by the end of month two, every future disagreement about quality is an argument nobody can win. Meeting load should be falling by now — the cadence carries the coordination that calls used to.
Month three: ownership
By month three the team should own a surface area — a service, a module, a product area. Ownership means something concrete: they monitor it, they fix it when it breaks, and they propose what happens to it next, rather than waiting for tickets. The relationship shifts from “we send work over” to “they bring work to us”.
And quietly, in the background, exit-readiness is already being built — not as a project for later, but as a property of how the work is done. The repos were yours from day one, the ADRs have been accumulating since month two, and handover drills sit inside the definition of done. We have written up the full argument in exit-ready by design; the short version is that leaving must always be cheap, and teams that make it cheap are, not coincidentally, the ones clients keep.
What you should be able to observe by day 90
None of the above should be taken on faith. All of it is inspectable: read the due diligence report, open the merge history, read an ADR and see if the reasoning holds, ask any engineer on the team to explain a recent decision. If you cannot observe it, ask why — precisely:
- Why is production code not flowing yet? “We’re still onboarding” at day 90 means the pipeline was never exercised.
- Where is the definition of done written down? If the answer is a person’s memory, quality is a matter of opinion.
- Whose infrastructure is the work in? If any of it is not yours, ask what leaving would cost today.
- Can I talk to the engineers directly? If every question routes through an account manager, you hired a broker, not a team.
What good looks like: the short checklist
- Production code merged inside month one — small and reversible before large.
- All work in your repos and your cloud; nothing you would need to migrate out.
- Trunk-based cadence with review gates; an engineer signs every merge.
- A written definition of done that includes docs and ADRs.
- A named surface area the team owns and proposes work on.
- An exit you could describe in a paragraph — and no reason to use it.
If you are planning the first ninety days with a dedicated team — ours or anyone’s — bring your situation to us: a technical call, not a sales call.