Onboarding a seconded engineer

An engineer joining your infrastructure team for a period is useful once they can see the estate and know which parts of it are fragile. Both take longer than expected, and most of the delay is preparation that could have happened before they arrived.

Access, started a week ahead

Infrastructure access usually requires elevated permissions, and elevated permissions require approvals from more than one person. That approval chain, not the technical setup, is normally what delays the first day.

Have these ready:

• Directory account in the right groups, with multi-factor authentication enrolled.
• Read access to the monitoring platform, which is where they will spend their first days.
• Access to network devices, read-only initially, through whatever jump host or privileged access system you use.
• Virtualisation and server management consoles, read access.
• The ticketing and change management systems, with the ability to raise changes.
• The documentation repository, including whatever informal wiki the team actually uses rather than the official one nobody updates.
• VPN or remote access, tested from where they will actually work.

Read everything, change nothing, on day one. Write access to production follows once they know what depends on what. That is not a comment on their competence. It is that infrastructure changes have consequences that are only visible with context.

The context that prevents expensive mistakes

Four things, none of which takes long to write, and all of which are usually in someone's head.

A current network and estate diagram. Sites, links, core devices, address ranges, where the boundaries are. It does not need to be perfect. It needs to be current enough that someone does not assume two things are connected when they are not.

What is fragile. Every estate has systems that must not be restarted casually, services that must start in a particular order, a device that has not survived a reboot in years, an application whose vendor support depends on an exact patch level. This is the document that does not exist anywhere, and it is the one that prevents the expensive first-week mistake.

How change reaches production. Where a change is proposed, who approves it, what the windows are, how it is rolled back, and what the emergency path looks like. Emergency processes are where people most often get it wrong, because they are used rarely and under pressure.

What the business cannot lose. Which systems stop the organisation working, and what the recovery expectations are. Prioritisation during an incident depends entirely on this.

Give them real work immediately

A week of reading documentation teaches very little and wastes time you are paying for.

A good first task is small, genuine, and exercises the whole path: propose a change, get it reviewed, implement it in a window, verify it. The value is not the change itself. It is that they have now used your process end to end and know where it is awkward.

Good candidates: a monitoring threshold that needs correcting, a documentation gap they can fill from what they have just learned, a low-risk configuration standardisation on a non-critical device.

Bad candidates: anything urgent, anything on the critical path, anything where the only person who understands it is on leave.

Name someone to ask

One named person for the first fortnight, who knows the estate and will answer a question without turning it into a meeting.

Without this, a new engineer either interrupts the whole team or, worse, makes a reasonable-looking assumption. In infrastructure, a reasonable-looking assumption about what depends on what is how an unrelated service goes down.

A short check-in at the start and end of the day for the first week is usually enough and can taper quickly.

End of week one

Four honest questions:

• Can they make a low-risk change through your process without help?
• Do they know what they must not touch, and why?
• Do they know who to call, and have they actually called?
• Is any access still outstanding, wrong, or being worked around?

The last one catches the common case where something was requested, granted at the wrong level, and quietly worked around rather than raised.

Agree the handover artefact at the start

The difference between a secondment that helps for three months and one that helps afterwards is whether anything durable is left behind.

Decide on day one what that will be: updated diagrams, documented procedures for whatever they worked on, configuration standardised and recorded, or the fragility document written down properly for the first time.

Asking for this at the start changes how the work is done. Asking for it in the final week produces a rushed document.

There is a specific opportunity here. Someone new notices what a settled team has stopped seeing: the undocumented exception, the monitoring gap, the process step everyone works around. Ask them explicitly, in week two, what has surprised them. The answer is usually a short list of things worth fixing.

Plan the exit at the start

Decide up front: which access is removed, by whom, on what date. What is handed over and to which named person.

Access left active after a secondment ends is a recurring audit finding and an entirely avoidable one. Putting the removal date in the calendar on day one is the whole fix.

For short engagements

If the secondment is weeks rather than months, narrow the scope rather than compressing the onboarding.

Give them one bounded area (a specific migration, a standardisation exercise, a defined backlog) with the context that area needs and no more. Short engagements fail when treated as long ones with less time, and succeed when the scope is drawn tightly enough that partial context is sufficient.