Home → Leadership
A New Engineer’s First 30 Days: The First Production Change, Not Orientation
On day ten I asked: “What do you remember from what you read?” They thought for a moment. “Honestly, nothing. I never used any of it.” Their laptop had arrived on day three. Access to the test environment had opened on day eight. Their first change reached production on working day 23.
- One number is enough: working days until the first production change. It measures the whole path, from the laptop to the deploy pipeline.
- Most of the delay is waiting. For us, 14 of the 23 days went to waiting for a laptop, access and approvals. These can be solved before day one.
- The first task is written before the person arrives. Small, real, shipped, easy to roll back. Not a practice project, and not a critical path.
- A buddy is a role, not good will. Two short meetings a day, and 20% taken off their sprint capacity.
- Documentation is read while working. A reading list is forgotten; documentation that gets used is remembered and fixed.
From the field: 23 working days
Last September a backend engineer joined the team. They arrived on Monday at 09:30. On the desk there was a chair, a welcome mug and a 140-page reading list. There was no laptop; we had opened the IT request on the Friday before.
The plan was clear in my head: “For the first two weeks they learn the system and read the docs. Then they start working.” At a brokerage, I thought, touching the code before you understand the system is risky. It sounded like a responsible decision.
Here is what happened. The laptop arrived on day three. The VPN worked on day five. Access to the test environment passed security approval and opened on day eight. Setting up the local environment took four days, because the README had been written two years earlier: the database version was old, and the mock service for market data had a new name. Nobody knew this, because everyone on the team had set up their environment years ago.
The first commit came on day eleven. The first production change shipped on working day 23. Later I counted the days one by one: 14 days had been spent waiting for something. A laptop, access, an approval, an answer to a question for me. Most of the other nine days went to reading things that were never used.
That week I understood the problem was not orientation. I had built a program to transfer knowledge. What the new person needed was to walk the path once, from start to end.
Why the first production change?
Even a one-line change that goes to production travels a long path: laptop, repository access, local environment, tests, code review, pipeline, test environment, approval, deploy. If there is a blocker anywhere on that path, the first change gets stuck there. And you can see where it got stuck.
So this is the one number I measure: working days until the first production change. The answer to “is orientation complete?” is always yes. The answer to “on which day did they ship?” is a number, and that number does not lie.
The real value of the number is this: it measures the preparation, not the person. The 23 days did not say the new engineer was slow. They said the laptop request was opened on a Friday, the access approvals were queued one after another, and nobody had tried the README in two years. All of that was my area. None of it was in the new person’s hands.
There is a side effect too. A person who sees their first change in production feels they have joined the team. A person still reading documents on day ten is still a guest. As in the post on engineering metrics, the number here is not a report card; it tells you where to look.
Before day one
Almost all of the 14 days of waiting could have been solved before the person arrived. Now a list opens on the day the offer is accepted:
DAY -10 : Access requests are opened (11 items).
The 4 items REQUIRED for week one are marked:
repository, VPN, test environment, pipeline.
Read access to the production database is NOT on it.
DAY -5 : Laptop ready, standard image installed.
The local setup script is run once on this laptop.
DAY -3 : The first task is written as a ticket; nobody on
the team touches it.
DAY -1 : Buddy chosen, 20% taken off their sprint capacity.
DAY 0 : Laptop on the desk. Local environment up by afternoon.
DAY 1-3 : First task -> review -> test environment -> production.
RULE : If an item is late, day one is not moved.
The delay is added to the first-change number.The most important line on the list is running the local setup script once on the new laptop. The first time, we skipped this step. The script expected a tool that was already installed on every team member’s machine. On a clean machine it failed on the first line. Seeing this before the person arrives saves half of the first day.
We also split the access list. At a brokerage, access approval is slow, and for good reasons. But the access you need for the first change is not the same as the access you will need in the first month. Read access to the production database is not needed in week one. If the other four items wait for it, the slowest approval sets everyone’s speed.
How to choose the first task
If the first task is badly chosen, everything the preparation list saved is lost in the first review. This happened to me as well; I will come to it below.
- Finishes in one day
- Touches a real user and goes to production
- Goes through the whole path: tests, review, pipeline, deploy
- Can be rolled back in one step
- Was written before the person arrived, and kept for them
Example: a commission label that is rounded wrongly on the portfolio screen.
- “Look around the code and find something”
- A practice project that never goes to production
- A critical path such as order routing
- An old bug nobody owns
- Boring work saved up “for the new person”
Each one either skips the path or wears the person out on the first step.
The one-day rule is not random. I explained the logic of breaking work into eight-hour pieces in the post on epics, stories and tasks. For a new person the rule matters even more, because in the first week everything takes twice as long. A one-day task takes three days. A three-day task takes two weeks, and nobody asks why.
A buddy is a role, not good will
The first time, I made the most senior engineer on the team the buddy. It looked sensible: they knew the most. But they were also the busiest. The new person did not ask a question for two days: “They are very busy, I do not want to bother them.” The question was simple: which user do you log in with on the test environment?
Now there are three rules for a buddy:
- It is visible in the calendar. For the first two weeks, 15 minutes twice a day: morning and afternoon. Questions come to these slots instead of piling up.
- It is taken off capacity. 20% comes off the buddy’s sprint capacity. If you do not do this, the buddy tries to do two jobs at once, and the new person notices.
- Not the most senior person, but the one who walked the path most recently. Someone who joined a year ago still remembers which step got stuck.
The first review is the team’s first answer
The new person’s first pull request is the first real information they get about the team. The orientation slides may say “we help each other”. But if the PR sits without an answer for two days, or the first comment is a three-paragraph lesson about a variable name, the person remembers that comment, not the slides.
So we made a separate rule for the first PR: it is reviewed on the same day, within four hours. The buddy does not review it; someone else on the team does. This way the new person talks with at least two people about real work in the first week. Comments are split into two kinds: ones that block the release, and “next time” notes. On the first PR, we collect the second kind in one message and move on.
This is not lowering the quality bar. The first task was chosen small and easy to roll back, so the risk is low. On low-risk work, a pile of standard comments only tells the new person “everything is hard here”. Two months later, when the same person touches a critical service, the review will be strict. On that day they will also know why.
When to read the documentation
I did not throw away the 140-page list. I only changed the order. Now a document is opened from inside a task: the commission calculation page while fixing the commission label, the deploy page when the pipeline fails. What you read and use right away stays with you.
There is also one thing the new person writes in their first week: a fix to the setup guide. Everyone on the team set up their environment years ago, so nobody can see where the README is wrong. The people who cannot see it are not the new ones; they are everyone who already knows. The last person to set up the environment updates the setup guide. Since we made this rule, the README gets fixed once with every new hire.
The first 30 days: weekly goals
| Period | Goal | Evidence |
|---|---|---|
| Day 1 | Local environment up, tests pass | A test running locally |
| Week 1 | First change in production | Their name in the deploy log |
| Week 2 | Second and third small tasks; first code review comment | A comment on someone else’s PR |
| Weeks 3–4 | A share in a whole feature; first shadow on-call day | Work they present themselves in the sprint review |
The fourth row is the real goal of the first 30 days. By day thirty, the person is no longer “the new one”; they take work like any other team member. The first week is a condition for that, not a goal on its own.
What to track
| What | Why |
|---|---|
| Working days until the first production change | One number for the whole path; for us 23 → 9 → 3 |
| How many of those days were waiting | Waiting is produced by preparation, not by the person |
| Time to get the local environment running | If it is more than a day, the script or the README is broken |
| How long the first PR waited for review | A badly chosen first task shows up here |
| Fixes the new person made to the README | If zero, either the document is perfect or nobody read it |
What did not work for me
- A two-week reading list. 140 pages. On day ten almost nothing was remembered. That was my mistake, not theirs: I had tried to make someone memorise information with no context.
- A three-hour welcome presentation. Company history, org chart, product map. The next day they could not remember anyone’s name. Now it is 30 minutes and one slide: the team, the services we own, who to ask about what.
- Choosing the first task from a critical path. For the second hire, I wanted “real work”, so I gave them a small change in the order routing service. The change was small, but the service was critical; review took six days and four people left comments. The first production change was on day 9, and six of those days were review. The preparation list had cut the waiting; the wrong task spent the saved time in review.
- Saying “do not be afraid to ask”. Saying it is not enough. Unless the buddy has a slot visible in the calendar, everyone holds back.
For the third hire we did four things together: the preparation list, a one-day task written before they arrived, a buddy with reduced capacity, and documentation opened while working. The first production change shipped on working day three. The local environment was running on the afternoon of day one. In the first week they made two fixes to the README. I should note that I saw these numbers on a single hire; three people are not statistics. But you do not need statistics to see that 14 of 23 days were waiting.
Checklist
- Were access requests opened at least ten days before, with the week-one items marked?
- Is the laptop ready, and was the local setup script run once on that laptop?
- Is the first task written as a ticket, does it fit in one day, and does it go to production?
- Does the first task touch a critical path? (If it does, change it.)
- Is the buddy chosen, with slots in the calendar and reduced capacity?
- Who will review the first PR on the same day?
- Is there concrete work in the first week’s plan, other than “read the docs”?
- For the last hire, on which day was the first production change, and how many of those days were waiting?
- Who last fixed the README, and when?
Conclusion
I still remember that question on day ten. When I asked “what do you remember?”, I thought I was measuring the person. In fact I was measuring the process I had built, and the process had failed.
What changed was not a program but an order. First the path is prepared, then the person walks it once, then the documentation is read along that path. 23 days became 3. None of that difference came from the new person’s talent; all of it came from what was ready before they arrived.
The test: for your next hire, can you say what their first change will be before they even arrive? If you cannot, you are not ready to welcome them.