The first week: getting an augmented engineer productive

An augmented engineer’s first fortnight is usually described as ramp-up, as if the time were spent learning. Some of it is. Most of it is spent waiting for a laptop, a VPN certificate, a repository permission or an account that needs a manager’s approval, and that part is entirely avoidable with a week of notice.

Before day one

The access list is the whole game. Every account, every repository, every environment, every tool, with a named approver against each, raised before the start date. Access requests that begin on the Monday morning finish on the Thursday, and that is four days of a paid engagement spent reading documentation they cannot yet act on.

Alongside it, three things worth having ready:

• A named buddyOne person whose job it is to answer questions this week. Not a team, a person.
• A first task already chosen.Small, real, and merged into production by Friday.
• The one page of context.What the system is actually for, which is almost never in the repository.

Day one: environment and orientation

The goal is a running local environment and a successful build. Nothing else.

If the setup instructions do not work, that is the most valuable finding of the week and the new person is the only one who can make it — everyone else’s machine has been working for two years. Have them fix the setup documentation as they go; it is the first contribution and it pays for itself on the next hire.

Day two: read the system, then draw it

Give them the architecture as it is, including the parts nobody is proud of. An augmented engineer who discovers the real deployment path in week three has spent two weeks designing for a system that does not exist.

Have them draw what they understood and show it to the buddy. The gaps in that drawing are a precise map of what the documentation does not say.

Day three: the first change

Small, real, and shipped. The point is not the change — it is exercising the whole path: branch, review, test, merge, deploy. Every friction in that path is a friction they will hit on every future change, and finding them on a trivial task is the cheapest possible time.

Day four: the domain

Whatever the business actually does. A collections platform, a contact center, a hospital system — the vocabulary and the rules are what let someone judge whether a change is sensible rather than merely correct.

An hour with someone from the business side is worth more than a week of reading, and it is the part of onboarding most often skipped because it is not technical.

Day five: a real piece of work, and a check

They pick up something from the actual backlog. Then a short conversation: what is still unclear, what took longer than it should have, what is missing from the documentation.

Ask specifically about access — there is almost always one more system they have not needed yet and will next week.

What slows this down in practice

• Approval chains for access that nobody has mapped.Each request discovers its approver on demand.
• A build that only works on machines configured by hand.Configured over years, and nobody remembers what was done.
• No buddy.Questions queue behind whoever happens to be free.
• A first task that is too large to finish in the first week.The delivery path then goes untested until it matters.
• Security onboarding that arrives last.It should arrive first: it is usually the longest lead time in the list.

It is not really about contractors

Everything here applies to a permanent hire. The difference is only that an augmented engagement makes the cost immediately visible: a week of waiting is an invoiced week. Teams that fix onboarding for contractors generally find their permanent hires get productive faster too.

Our staff augmentation engagements start with the access list rather than the start date, because it is the single item that most reliably determines whether week one is productive. If you are planning to bring someone in, it is worth comparing lists.