Onboarding a cloud engineer

An engineer who joins on Monday and cannot deploy anything until Thursday has lost three days you paid for. This happens routinely, and almost none of it is the engineer's fault. It is preparation that could have happened before they arrived.

Here is what to have ready.

Before day one

Access, requested early

Cloud access usually depends on an identity account, which depends on HR onboarding, which has its own timetable. Start the chain at least a week ahead. The specific things to have provisioned:

• An identity provider account in the right groups.
• Multi-factor authentication enrolled, or a documented process for enrolling on day one.
• Read access to production and write access to a non-production environment. Production write access should come later, deliberately, once they know the estate.
• Source control access, including the repositories that hold infrastructure definitions.
• The ticketing and change management systems.
• Whatever chat or collaboration tool your team actually uses.

The pattern that works is read-everything, write-somewhere-safe on day one. It lets an engineer explore without a ticket for every question, and without the risk of a confident change made without context.

A machine that works

If you are supplying hardware, it should be built, encrypted, enrolled in management and delivered before the start date. If they are using their own, agree what is required (disk encryption, screen lock, endpoint protection, an approved VPN client) and check it rather than assuming.

Either way, confirm they can reach everything they need from wherever they will be working. Remote access that only works from the office is a common and avoidable first-day discovery.

The context that actually matters

Access without context produces cautious, slow work. Three documents do most of the heavy lifting, and none needs to be long.

A diagram of the estate. Accounts or subscriptions, what lives in each, how they connect, where the network boundaries are. It does not have to be current to the day. It has to be current enough to prevent wrong assumptions.

How change reaches production. Where a change is proposed, who approves it, how it deploys, what record it leaves. Include the emergency path, because that is the one people get wrong.

What is unusual here. Every estate has exceptions: the legacy application that cannot be patched, the account nobody may touch, the region that exists for one customer, the naming convention that changed halfway through. This is the document that does not exist anywhere and lives in people's heads. Writing it is worth an hour and saves days.

Give them a real first task

The most common onboarding mistake is a week of reading. It feels safe and it teaches very little.

A good first task is small, real, and touches the whole path: something that requires making a change, getting it reviewed, deploying it through your pipeline, and confirming it worked. The value is not the change. It is that the engineer has now used your process end to end and knows where it is awkward.

Good candidates: a monitoring alert that needs adjusting, a documentation fix in an infrastructure repository, a small tagging or lifecycle correction. Bad candidates: anything urgent, anything on the critical path, anything nobody else understands.

Name the person to ask

Assign one named person for the first fortnight. Not a manager necessarily, just someone who knows the estate and will answer a question without making it a meeting.

Without this, new engineers either interrupt everyone or, worse, guess. Guessing in an unfamiliar cloud estate is how you get a change that looks reasonable and breaks something two hops away.

Fifteen minutes at the start and end of the day for the first week is usually enough, and it can taper quickly.

What to check at the end of week one

A short review, honestly answered:

• Can they deploy a change to non-production without help?
• Do they know who to ask, and have they actually asked?
• Do they know what they are not allowed to touch, and why?
• Is there any access still outstanding?

The last one catches the common failure where something was requested, not granted, and worked around quietly.

For shorter engagements

If someone is joining for a few weeks rather than months, the preparation matters more, not less. There is no time for the estate to be absorbed gradually.

Narrow the scope deliberately. Give access to the part of the estate the work touches and not the rest. Write down the specific outcome expected and the constraints that apply. Assign the named contact from the first hour rather than the first week.

Short engagements fail when they are treated as long ones with less time. They work when the scope is drawn tightly enough that limited context is not a problem.

Offboarding, planned at the same time

Decide at the start what happens at the end: which access is removed and by whom, where the knowledge is written down, and what is handed to which named person.

The handover artefact is worth specifying up front, because it changes how the work is done. An engineer who knows on day one that they must leave a documented, reproducible result builds differently from one who is told in the final week.