IT Onboarding Documentation: Getting New Technicians Up to Speed

The first 30 days of a new IT hire is the most expensive period of their employment. They're paid at full rate while producing a fraction of full output. Every hour spent finding information they should have been handed is time and money that doesn't come back.

Most of that ramp-up friction is documentation failure. Not the technician's failure -- the organization's failure to provide what they need.

Here's what onboarding documentation should cover and how to structure it.

What a new technician actually needs

There's a difference between "here's everything about our environment" and "here's what you need to be functional." These are not the same document.

A new technician in the first week needs to:

• Know how to get into the systems they'll be working in
• Understand the environment well enough to not break something by fixing something else
• Know who to ask when they're stuck
• Find relevant documentation without knowing where to look

In the first month they need to:

• Handle the most common ticket types without escalating
• Understand the non-obvious things about key systems and clients
• Know the policies and procedures that apply to their work

After 90 days they should be able to operate independently on the vast majority of situations they encounter.

Each phase needs different documentation. Trying to hand someone everything at once is as bad as handing them nothing.

The week-one package

This is what someone needs before they can do anything else.

Access and credentials. Every system they'll need to log into, how to get the credential or request access, and any setup required (MFA, VPN client, etc.). Don't assume they'll figure out the VPN client on their own. Write it down or send a setup guide.

The tools they'll use daily. RMM, PSA, ticketing system, communication platforms. Where to find things in each. This sounds basic but every tool has its own learning curve and most shops onboard to their tools by osmosis.

Who to contact for what. Your name. Other escalation points. Vendor support contacts they may need in their first week.

The one-page environment overview. A brief description of what the environment looks like: how many sites, how many servers, what the network topology is at a high level, what the major systems are. This gives them context before the details.

The environment overview

This document does more for a new technician than any other single thing you can write.

It covers:

• Physical locations and what's at each
• Network structure at a high level
• Server inventory with roles (not full detail, just enough to know what exists and what it does)
• Key applications and what they're for
• Third-party services and vendors in use
• The things that are unusual about this environment

That last section is where the real value is. Every environment has idiosyncrasies. The server that has to be restarted in a specific order. The client who uses a legacy application that has specific requirements. The firewall rule that looks wrong but is actually intentional.

A new technician who doesn't know these things will encounter them at the worst possible moment. Write them down.

Common ticket type runbooks

Look at your last six months of tickets and identify the ten most common issues. For each one, write a brief runbook: what the issue looks like, how to diagnose it, how to resolve it, and any common mistakes or non-obvious steps.

These runbooks do double duty. They reduce onboarding time by giving new technicians a starting point on common issues. And they serve as reference documentation for experienced technicians who do a procedure infrequently enough that they don't remember all the steps.

The documentation map

New technicians need to know where documentation lives, not just that it exists.

A one-page documentation map should cover:

• Where to find the full environment documentation
• Where runbooks are stored
• Where credentials are managed
• Where policies and procedures are documented
• Who maintains what and how to request updates

If your documentation is scattered across a wiki, a shared drive, and the ticketing system, document that. Someone who spends 20 minutes searching for something that was in the other system is losing time and building frustration.

What most onboarding documentation misses

The context behind decisions. New technicians will encounter configurations and policies that seem strange without knowing the history. "This is how we do it" is not an explanation. "This is how we do it because we had a problem in 2021 with X" is.

The social layer. Who actually makes decisions on things that aren't clearly in scope? Which clients are difficult and why? Which vendor contacts are responsive and which are not? This doesn't belong in formal documentation but it does belong in an informal "how things work here" conversation early on.

An explicit feedback loop. After 30 and 90 days, ask the new technician what was missing from their onboarding documentation. They found the gaps firsthand. Use that feedback to improve the documentation for the next hire.

The payoff

An environment with good onboarding documentation is also an environment with good operational documentation. The work overlaps almost entirely.

If your onboarding documentation is good enough that a new technician can be productive in 30 days instead of 90, that's the difference in output over 60 days of salary. Every subsequent hire has the same return on that investment.

Write it once, maintain it continuously, and stop onboarding people by having them shadow someone for three weeks.