Onboarding a Contract Developer in the First Two Weeks

Bring on a contract developer and the clock starts. Every day they spend guessing at how your team works is a day you are paying for setup, not output. Most of that time is avoidable with a little preparation.

Before day one

Have the accounts ready: repository, issue tracker, chat, CI, staging, any cloud console they will need. Nothing kills momentum like waiting two days for access. Write a single page that says how to get the app running locally, step by step, and have someone follow it from scratch to check it still works. It never does the first time.

Decide who their point of contact is. One named person who answers questions and unblocks them, not a channel where questions go to die.

Day one and two

Do a short walkthrough of the codebase live. Where features live, how the folders map to the product, where the tests are, how a change gets from a branch to production. Twenty minutes of this saves hours of archaeology.

Then pair on a tiny change. Not a demo, a real edit that goes through your actual review and merge process. It teaches the conventions that no document captures: how you name branches, what a good commit message looks like here, which checks have to pass.

The first task

Pick something real but low risk. A small bug with a clear reproduction, or a minor feature in a part of the code that is well tested and often touched. The point is to run the whole loop once, from clone to merged, while the stakes are low. Avoid the gnarly module and the thing nobody understands.

What to write down

You do not need a handbook. You need the handful of things people keep having to explain: the local setup, the deploy process, the review expectations, and a map of the main parts of the system. Keep it in the repo so it stays close to the code and gets updated when the code does.

Check in at the end of week one

A fifteen minute conversation. What is unclear, what is slower than it should be, what is missing from the docs. Fix those things before week two. This is also when you find out early if the fit is wrong, while it is still easy to adjust.

The payoff

Good onboarding is not a nicety. It is the difference between a contractor who is contributing by Friday and one who is still finding their feet a fortnight in, on the same rate.

Common questions

How long before a contractor is productive?

For a reasonably documented codebase, small pull requests in the first few days and full pace inside two weeks. Poor onboarding easily doubles that.

What is the best first task?

Something real but low risk: a small bug fix or a minor feature in a well-trodden part of the code. It exercises the whole path from clone to merged without much can go wrong.

Should they pair with someone at the start?

A short pairing session on day one or two is worth more than a day of reading. It surfaces the unwritten conventions faster than any document.