Onboard new support engineers in weeks, not months

Every support manager has had this conversation: a new hire starts Monday, they're solo by Friday of week 6, and they're 'fully ramped' sometime around week 12. That's three months of a salary while the team absorbs the training load and the new hire closes 40% of the cases a senior would.

Most of that timeline isn't necessary. It's the cost of an unstructured shadow-and-learn approach where the new hire picks things up by osmosis. With a structured program built around your runbooks, you can cut the timeline in half.

Why shadow-and-learn is slow

Three reasons it takes so long:

1. Random exposure. Shadowing a senior agent exposes the new hire to whatever tickets happen to come in that day. If it's a slow week of login resets, they don't see the escalation path for data corruption.
2. No written artifacts. The senior demonstrates how they think, but the new hire has nothing to re-read. A week later they've forgotten half of it.
3. Unclear 'done' state. Nobody can articulate when the new hire is 'ready.' So the ramp drifts on vibes.

The structured alternative

A ramp program built around runbooks replaces all three failures. Four weeks, four phases.

Week 1: Read the runbooks

No customer contact. The new hire reads every runbook in your knowledge base, in order of most-used first. They take notes on anything unclear.

At the end of the week, they meet with a senior to go through their questions. Runbooks that are confusing get flagged for a rewrite. This is bonus value: new hires frequently catch KB problems that senior engineers have gone blind to.

Week 2: Shadow with purpose

Now they shadow — but with a structure. Every case they observe gets mapped to a runbook. 'Alex used the Login Reset runbook for this one.' 'Sam used the Data Sync runbook plus a custom SQL check.' If a case doesn't match any runbook, that's a flagged gap.

This turns shadowing from passive osmosis into active mapping. By end of week, the new hire has a personal tally of which runbooks they've seen applied and which they haven't.

Week 3: Handle simple cases with supervision

The new hire starts taking cases that match runbooks they've both read and seen applied. Senior reviews every outbound reply before it goes out, but the new hire is doing the work.

Constraint: only assign cases to the new hire when a matching runbook exists. This builds confidence fast and keeps customer-facing output high quality.

Week 4: Handle the queue

Full autonomy on cases matching known runbooks. Escalate anything novel. Senior shifts from pre-send review to periodic audit.

By end of week 4, the new hire is closing 60-70% of the cases a senior would — not because they're as experienced, but because the runbooks are doing most of the heavy lifting.

The tools that make this work

You need three things, all of which you probably already have in some form:

1. Runbooks with structured fields. Symptom lists. Ordered steps. Explicit resolutions. The new hire should be able to read one in 3 minutes and know what it covers.
2. Runbook surfacing on live cases. When the new hire opens a case, the tool shows them candidate runbooks before they start guessing. Reduces cognitive load; builds pattern recognition.
3. Activity timelines. The new hire can re-read a case they shadowed a week ago and see the exact sequence of actions the senior took. Written, searchable, permanent.

The metric that matters

Track one number: time from start date to solo-on-queue. For most support teams this is 8-12 weeks. With a structured program, it's 4-6.

That's not a small win. A support engineer's fully-loaded cost is $100-150k/year. Cutting ramp in half saves $15-25k per hire, and that's just the salary math. The hidden value — senior engineers not spending three months of their time on training — is bigger.

None of this works if your KB is stale. Step zero is making sure the runbooks are actually good. Everything else follows.