Slow onboarding is a warning sign, not a normal cost

Almost every engineering proposal contains a line like this: weeks one to four, onboarding and discovery. It is written as if it were a law of nature. It is not. It is the cost of never deciding, in advance, what a new team is allowed to touch.

We run 31 teams inside client companies. On average, our first code reaches production seventeen days after the contract is signed. About eleven of those days are spent waiting for access approvals, which has nothing to do with engineering. Once the environment is ready, the engineering part takes about two days.

What onboarding time really measures

Treat the first release as a measuring tool, not a milestone. How long it takes a good outsider to make a small, safe, real change to your system is the most honest measure of your delivery health that exists. It tests everything at once: your documentation, your test environments, your test reliability, how fast code gets reviewed, how hard it is to release, and whether anyone knows who owns what.

• Two days means your platform is healthy, and your problem really is a shortage of people.
• Two weeks means the bottleneck is your environment setup, and hiring more people will make things worse before they get better.
• Two months means you do not have a people problem at all. You have an ownership problem dressed up as a people problem.

How to cut the part that is real

Three changes account for most of the time we save. None of them are clever.

1. Start the access approvals before the contract is signed, on the condition that it will be. The legal work and the IT work do not depend on each other, so running them one after the other is a choice.
2. Pick one engineer on your side to answer questions for the first ten days. Not a manager. Someone who can explain why the staging database is the way it is.
3. Choose the first change together, and make it small and real. Not a practice exercise. Something a user will see, so the whole release process gets used once from end to end.

The third one matters most, and it is the one teams resist. There is an instinct to keep a new team away from production until they have proved themselves. It sounds careful, but it is just a delay. Making that first small change is exactly how they prove themselves.

The uncomfortable part

If onboarding takes six weeks, that is not a fact about new joiners. It is a fact about your system, and your permanent hires pay the same cost. They just pay it quietly, once, and then stop mentioning it. An outside team simply makes the cost visible, because it arrives on an invoice.

Every project is a health check on your delivery process, whether or not anyone asked for one.

We now treat this measurement as something we hand over in its own right. Clients get a written explanation of what slowed the first release down, with the fixes ranked by cost. Several have used it to get funding for platform work they had been asking for over a year.