Onboarding a senior contractor: The first week

Key takeaways

• Senior contractor onboarding is not orientation. The contractor already knows the role; what they don't know is your system, your codebase, your team, and your priorities. Week one is about transferring that context, not teaching them what they already know.
• Day-one access (all systems, all tools, all environments) is non-negotiable. A contractor who can't push code on day one is paying for the delay in lost velocity and lost momentum.
• A clear first deliverable, defined before day one, achievable within week one, is the single most important onboarding investment. It anchors the contractor's effort, surfaces context gaps quickly, and produces a real artifact the team can review.
• A written context document, the system overview, the team conventions, the open architectural questions, transfers context faster than ad-hoc conversation. Spend the hour to write it; recover the time tenfold.
• A named technical lead on the client side, not a manager, an engineer the contractor can ask questions of, accelerates the ramp by weeks. Senior contractors are blocked most often by missing context they don't know to ask for.

Why onboarding is the highest-leverage week of the engagement

The first week sets the trajectory for the whole engagement. A contractor who lands at full velocity in week one continues at that velocity. A contractor who lands in slow motion takes weeks to recover, and the engagement loses momentum that's hard to rebuild. This is true for every contractor engagement; the leverage is highest for senior contractors because their hourly cost is highest and the opportunity cost of wasted week-one days is largest.

The pattern that produces full-velocity week-one starts: access ready before day one, context document ready before day one, a clearly defined first deliverable ready before day one, a named technical lead available for questions. None of these is hard to do. The reason engagements start slowly is not that the preparation is difficult; it's that the preparation is often skipped.

Before day one: The preparation checklist

Access provisioning

By the morning of day one, the contractor should have working access to:

• Code repository (GitHub, GitLab, Bitbucket) with read/write on relevant branches
• Ticketing system (Jira, Linear, GitHub Issues) with access to the team's backlog and active sprints
• Communication tools (Slack, Teams) and the relevant channels
• CI/CD platform with permissions to view builds and re-run failing pipelines
• Cloud console (AWS, GCP, Azure) with read access for the relevant accounts; write access if the engagement scope requires it
• Local development environment, the contractor should be able to clone the repo and run the system locally by end of day one
• Staging environment (the deployment target for week-one work)
• Any third-party tools or services the system depends on (monitoring, error tracking, feature flags, analytics, etc.)

Day one is not the day to discover that the contractor doesn't have access to the AWS account that hosts the system they're being hired to fix. Access requests through corporate IT can take days; sometimes weeks. Start the access provisioning a week before the contractor's start date.

The context document

A written context document, one page is fine, that the contractor reads on day one. Suggested contents:

System overview. A two-paragraph description of what the system does, who uses it, what its current state is, and what the recent significant changes have been. Architecture diagram if one exists; if not, name the main services and how they connect.

Team conventions. How does the team work? PR review rituals, deploy cadence, branching strategy, code style conventions, testing expectations. The contractor will adapt faster if they know the norms going in.

Open architectural questions. The decisions the team hasn't yet made or has deferred. The contractor's perspective on these may be useful early; either way, knowing they're open prevents the contractor from accidentally re-litigating them.

Known issues and accepted trade-offs. The bugs the team knows about and isn't prioritizing. The technical debt the team is aware of and has chosen to live with. The contractor will spot these quickly; knowing in advance which ones are intentional saves the back-and-forth.

Key stakeholders. Who on the team or org will the contractor interact with? Names, roles, and a one-line note on what each person owns or cares about.

The first deliverable

One real deliverable, scoped to be achievable within week one. Not a make-work task, not an orientation exercise. Real work that contributes to the engagement's goal and produces an artifact the team can review.

Good first deliverables: a small bug fix that requires understanding a non-trivial part of the system, a refactor that the team has been wanting to do but hasn't had time for, a piece of a larger feature that can be shipped independently.

Bad first deliverables: "explore the codebase and write a doc," "shadow the team for the first week," "read these documents and ask questions." These don't produce artifacts the team can evaluate, don't surface context gaps quickly, and treat senior contractors like junior hires.

The named technical lead

One engineer on the client team should be designated as the contractor's primary technical point of contact. Not a manager, an engineer who has working knowledge of the system the contractor will be working on. This person's job: answer questions, point at relevant context, unblock when the contractor hits something they can't resolve alone. They don't need to be senior; they need to be available.

The single biggest unforced error in contractor onboarding is having no named technical lead, expecting the contractor to figure out who to ask. Senior contractors don't know who knows what on a new team; without a named contact, they either ask the wrong person, ask the right person who's busy and gets no response, or stop asking and slow down.

The week-one schedule

Day one: Land, set up, read the context doc

30-minute kickoff with the engagement sponsor and the named technical lead. Cover: what the engagement is, why the contractor was hired, what the first deliverable is, who to ask for what. End of meeting: contractor knows what they're working on for the first week and who to ask when they need help.

Rest of day one: read the context doc, get the system running locally, get the first deliverable's ticket onto the board.

Day two: Start work on the first deliverable

Contractor opens the first PR or starts the first concrete piece of work. Reading code is the fastest way to learn a system; doing it in the context of a real task is faster than reading in the abstract.

Brief check-in with the technical lead at end of day two: any blockers, any context gaps that have surfaced.

Days three and four: Make and submit the work

Real work, real PR, real review. The first PR is the most important quality signal of the engagement, both for the contractor (seeing how the team reviews work) and for the team (seeing how the contractor produces work). Treat it as such. The team should review carefully and give detailed feedback; the contractor should respond to that feedback substantively.

Day five: Retro and ramp planning

End-of-week-one conversation between contractor, technical lead, and engagement sponsor:

• What landed in week one (the first deliverable, any other contributions)
• What was blocked or slow, and what would prevent it next week
• What gaps in context the contractor surfaced (the questions they had to ask, what's missing from the context doc, what the team assumed was obvious that wasn't)
• What the second-week scope looks like

The week-one retro is a feedback loop: what worked in onboarding, what didn't, and how to apply the lessons to future contractor hires. Treat it as data, not as performance review.

Common onboarding mistakes

Access set up on day one rather than before. The contractor sits idle while IT processes tickets. This wastes the first day at a minimum; sometimes multiple days. Always start access provisioning at least a week ahead of the start date.

No named technical lead. The contractor doesn't know who to ask, so they either don't ask or ask widely and get inconsistent answers. The single highest-ROI fix in contractor onboarding is naming one engineer as the contact.

First-week orientation marathon. Back-to-back meetings to "introduce" the contractor to the org. Useful only in moderation; not what senior contractors are hired for. One kickoff meeting is enough on day one. Subsequent meetings should be only the ones the contractor actually needs to do their work.

No first deliverable scoped. The contractor lands without a clear target. "Explore the codebase" doesn't produce real artifacts or surface real gaps. A scoped first deliverable, picked before day one, produces both.

Treating senior contractors like junior FTEs. Heavy hand-holding, extensive shadowing, slow ramp into real work. Senior contractors are senior; they need context, not training. The faster they're allowed to start contributing, the faster the engagement starts producing value.

When week one falls short

If the first deliverable doesn't land in week one, the question is: was the deliverable too ambitious, or was the onboarding incomplete?

If the deliverable was too ambitious (the contractor couldn't have shipped it in five days even with perfect onboarding), scope smaller next time.

If the onboarding was incomplete (access wasn't ready, context was missing, no one was available to answer questions), the engagement starts behind. Acknowledge it explicitly and tighten the second week.

If the contractor itself is the issue (the work shipped but is significantly below the quality bar), that's a separate problem, not an onboarding problem. The week-one retro should surface this if it's real.