Ramping external engineers: The 30-60-90 framework

Key takeaways

• The most common ramp problem is mistaking slow ramp for a capability problem when it's a context problem. A senior engineer who lacks codebase context will produce less than a mid-level engineer who knows the system well.
• Milestones should be specific to the engagement's scope, not generic. "Full productivity" means different things for an engineer fixing a defined bug list versus one building a new service from scratch.
• Day 30 is the calibration checkpoint. If the contractor isn't independently shipping PRs at quality bar by day 30, identify the root cause before it compounds.
• The 60-day mark is where the ramp investment starts paying off: cross-team pattern recognition, proactive flagging of adjacent issues, domain-specific contributions beyond the assigned scope.
• Day 90 is the engagement velocity check: is this contractor making the team faster, or are they adding coordination overhead that costs more than they produce?

The 30-60-90 framework

Days 1-30: Oriented and independently contributing

The target state at day 30: The contractor ships PRs independently, within the team's quality bar, with minimal revision required. They ask questions when blocked and resolve blockers without waiting to be prompted. Their output is reliable enough that the engineering manager can predict their sprint contribution without constant check-ins.

What the engineering manager should see:

• At least three to five merged PRs (or equivalent design deliverables for a PM or designer)
• Questions asked in public channels, not privately or not at all
• Familiarity with the local dev environment, CI, and deployment process
• An understanding of the system's known rough edges, the workarounds, the legacy decisions, the things that are confusing until you know why

What counts as a ramp problem at day 30:

• First PR hasn't shipped yet
• PRs are opening but require substantial redesign. Stylistic revision is the easy case.
• The contractor is asking questions that should have been answered in the context package
• Engineering manager is spending more than four hours per week directing the contractor's work

If there's a ramp problem at day 30: Before diagnosing a fit issue, run through the context and access checklist. Is there a specific system or decision they don't have context on? Has the task scope been appropriate, neither too broad nor too narrow? Is there a communication dynamic making it hard for them to ask questions? Fix these before concluding the contractor isn't a fit.

Days 31-60: Contributing and adding signal beyond the task

The target state at day 60: The contractor is reliably productive on assigned work and starting to contribute beyond the immediate task scope. They flag adjacent issues in PRs, propose improvements to existing code as they encounter it (without scope-creeping), and notice patterns across the codebase that are invisible to someone new.

What the engineering manager should see:

• Velocity increasing week-over-week: each sprint, the contractor ships more than the last
• Proactive PR comments: "while I was here I noticed X, I didn't fix it but filed a ticket"
• Domain pattern recognition: observations about where similar problems exist, or where the approach in their current task differs from the approach in a neighboring service
• Relationships with the team: the contractor knows who to ask about what, and the team knows when to loop them in

What counts as a contribution gap at day 60:

• Velocity has plateaued or is still lower than expected for the seniority level
• The contractor is completing tasks but not adding the senior-level signal, no architectural observations, no proactive flagging, no cross-task pattern recognition
• The engineering manager is still spending significant time directing rather than reviewing

If there's a contribution gap at day 60: This is the right moment for a calibration conversation with the contractor directly: "We're at sixty days. Here's what I'm seeing. Here's what I expected. What's your read?" Senior contractors who are a good fit will engage with this directly and surface their own perspective on what's missing. Those who aren't a good fit will deflect.

Days 61-90: Operating as a full team member with systemic ownership

The target state at day 90: The contractor operates like a senior member of the team, not a visitor. They own a coherent piece of the system, with surface-level responsibility (rather than tasks on a backlog). They can make scoped decisions independently, identify when something is out of their scope, and bring decisions up to the engineering manager with a recommendation rather than a question.

What the engineering manager should see:

• The contractor makes decisions within their scope without asking for permission
• When they encounter something out of scope, they flag it with context and a recommendation. "What should I do about this?" is the junior pattern.
• Other team members loop the contractor in on relevant decisions proactively, in addition to responding to their questions
• The contractor's contribution is accelerating the team's velocity, not consuming management bandwidth

What counts as an engagement fit problem at day 90:

• The contractor hasn't developed clear ownership of any surface
• Engineering manager is still spending more than two hours per week directing (not reviewing) the contractor's work
• The team doesn't naturally loop the contractor in because their contributions are still seen as external rather than integral
• Output volume is high but cross-team integration value is low

If there's an engagement fit problem at day 90: This is the signal to re-evaluate whether the engagement structure is right. A highly capable contractor who isn't integrating into the team may be in the wrong engagement shape, individual contractor when they'd produce more in a managed team structure, or a staff augmentation role when they'd be better suited to a project-scoped deliverable.

Calibration checkpoints

Build four formal checkpoints into every external engineer engagement:

Week 1 end: Access and context check. What do they still need? Is the first deliverable clear?

Day 30: Independent contribution check. Are they shipping? Is the quality bar met? Is there a ramp problem to diagnose?

Day 60: Signal and velocity check. Are they contributing beyond the immediate task? Is velocity increasing?

Day 90: Ownership and integration check. Do they own something? Is the team treating them as a full member?

Each checkpoint is a 30-minute conversation with the contractor, not a status report. The conversation should be two-way: your assessment and their assessment, and what each side needs to make the engagement work better.

Adapting the framework by role type

For engineers (backend, frontend, fullstack): Day 30 is PR velocity. Day 60 is code review participation and pattern recognition. Day 90 is service ownership with independent decision-making.

For product managers: Day 30 is sprint ownership, running standups, writing stories, making prioritization decisions with input from the team. Day 60 is roadmap contribution: adding to the roadmap based on their own product observations, beyond executing on one that already exists. Day 90 is strategic scope, making product strategy recommendations that reflect accumulated domain knowledge.

For designers: Day 30 is design system fluency and first shipped design component. Day 60 is proactive design feedback on adjacent features, design critique participation, and engineering collaboration without prompting. Day 90 is design system contribution and user research integration.