The biggest source of early-onboarding misalignment is implicit expectations. Both sides assume what “good” looks like, do not articulate it, and find out at performance review that they had different mental models. Strong EMs prevent this with an explicit “expectations contract” in the first month.
What is an expectations contract
A written document, co-authored with the new engineer, that defines:
- What success looks like at 30, 60, 90 days
- What the engineer can expect from you (the manager)
- What you expect from them
- How you will check in and adjust
Not a binding contract. A shared mental model.
The 30-day expectations
For a typical mid-level engineer:
- Has paired with the team’s key contributors
- Has read all relevant onboarding docs
- Has shipped 1–2 small PRs
- Knows the team’s rituals and roles
- Has named blockers in their setup or context
For a junior:
- Has shipped a single small PR
- Is comfortable asking questions
- Has named the unfamiliar parts of the codebase
For a senior:
- Has met with stakeholders and identified key dependencies
- Has reviewed major design docs and surfaced questions
- Has shipped 1–2 PRs
- Is forming a perspective on team strengths and gaps
The 60-day expectations
- Owns a meaningful slice of work
- Has shipped enough to have a feel for the codebase’s rhythm
- Has built relationships with key collaborators
- For senior+: has identified an opinion on improvements they would lead
The 90-day expectations
- Operating at expected productivity for level
- Has shipped a substantial feature or fix
- Receiving and giving thoughtful code reviews
- Visible to adjacent teams
- For senior+: leading a project or a process change
The contract from your side
You also commit to specific things:
- Weekly 1:1 (never canceled)
- Quick response to questions during onboarding
- Pairing or shadowing opportunities
- Introductions to key cross-team partners
- Explicit feedback at the 30, 60, 90 marks
Adjusting per individual
Generic templates undercut the value. Adjust based on:
- Their experience level
- Their starting context (familiar with the domain or new?)
- Team needs (are they joining a fire? a stable team? a brand-new team?)
- Their growth goals
The check-in cadence
At day 30, 60, 90, sit down and:
- Review the expectations
- Discuss what is on track and what is not
- Ask the engineer how they feel about ramp-up
- Adjust expectations if context has changed
Each check-in produces explicit alignment. No surprises at 6 months.
What if expectations are not being met
- At 30 days: probably ramp-up issues. Provide more support.
- At 60 days: address specifically. What is missing? What can you provide?
- At 90 days: serious gap. Honest conversation. What is the path forward? Are expectations realistic?
Most ramp-up problems are pairing problems — the engineer needs more help than they are getting.
Stretch goals vs core expectations
Distinguish:
- Core: what we agree they will deliver. Hitting these is a normal expectation.
- Stretch: what would be exceeded expectations. Achievement here signals fast-track.
Be explicit. Engineers who do not know they are exceeding expectations leave for companies that recognize them.
The interview question
“How do you onboard new engineers?”
Strong answers describe a specific process: pairing, written expectations, scheduled check-ins, named buddy. Generic “I support them and check in regularly” is insufficient.
Frequently Asked Questions
Should the new engineer write the contract or should I?
Co-author. You provide a draft based on the role; they edit and add their own goals. Both sign off.
What if the engineer’s ramp-up is faster or slower than expected?
Adjust the contract. The point is shared understanding, not rigid milestones.
Should I do this for senior engineers too?
Yes — especially for senior engineers, who often have implicit expectations about scope and visibility that need explicit articulation.