The first 90 days in a new codebase

What can honestly be delivered in week one?

One small change, merged and deployed.

That sounds modest and it is the single most useful thing to insist on, because it exercises the whole path rather than the engineer. Access under a client-issued identity. A build that runs from a clean checkout. Tests that pass locally and in the pipeline. A review process with someone at the other end. A deployment that reaches an environment. Each of those can be broken, and each is cheaper to discover on a trivial change than on a real one.

Teams that skip the deliberately small first ticket usually spend the second week finding the same problems under more pressure.

What the curve actually looks like

By day 30 a senior engineer should be self-sufficient on scoped work: taking a defined piece, asking the right questions early, and finishing without supervision. By day 60 they should own a feature and be inside the team’s ceremonies rather than adjacent to them. By day 90 they should be leading work and improving the people around them.

Underneath that sits a slower curve that nobody can compress much. Full context in an unfamiliar system — knowing which changes are dangerous, which parts are load-bearing, and which oddities are deliberate — takes sixty to ninety days for a strong engineer. Feathers’ definition explains why: where behaviour is not protected by tests, the only reliable source of that knowledge is the people who have already been surprised by it.

A 30-60-90 that can be agreed in writing

Week 1Access, build, tests, review, deploy — proved by one small merged change.

Day 30Self-sufficient on scoped work. Asking questions early rather than late.

Day 60Owns a feature. Inside the ceremonies. Estimating with the team.

Day 90Leading work, reviewing others, and visibly raising the team’s capability.

What makes the ramp faster or slower?

Three things are in the receiving team’s hands. A named onboarding buddy who is allowed to be interrupted. Real work in the first fortnight rather than documentation reading. And a definition of done that the engineer can check their own work against.

Two things are in the codebase. Whether a build runs from a clean checkout, and whether tests exist for the paths the first changes will touch. Where neither is true, the ninety-day curve stretches, and the honest response is to say so at the start rather than to absorb it quietly.

AI-assisted tooling has genuinely shortened the comprehension phase. DORA’s 2025 finding is worth keeping alongside it: the organisations that convert that speed into delivery are the ones whose review and deployment capacity can absorb it. An engineer who ramps faster into a team that cannot review faster produces a queue rather than an outcome.

What we commit to

A written 30-60-90 agreed between the client lead, the engineer and our tech lead before the first day, including the honest part about the sixty-to-ninety-day context curve. A small first change merged in week one. And a monthly three-way conversation that replaces invented reporting.