Levels and expectations
Ship something small in week one
A tiny production change teaches the real workflow. A tutorial app on your laptop teaches none of it.
A tiny production change teaches the real workflow: branch norms, CI flakes, reviewers' tastes, feature flags, deploy buttons, dashboards, and who to ping when the pipeline goes red. A tutorial app on your laptop teaches none of that.
That is why a small ship in week one matters more than a perfect architecture diagram in week six.
Concept
A first ship is a real change that goes through the team's pipeline to production — or as close as the team allows — with a small blast radius. The win is exercising the loop, not the size of the diff.
Walking through a good first change
Day four: you add a missing request_id field to an error log line in the payment webhook handler, with a unit test. CI fails on a linter rule you had not seen; you fix it. Your reviewer asks for a dashboard link in the PR body. You deploy behind the usual pipeline and watch logs in staging, then production. The field is small. The loop is the point.
| Good first ships | Bad first ships |
|---|---|
| Copy fix, log line, metric, dead-code removal with tests | "Rewrite the module so I understand it" |
| Bug with a clear repro and small blast radius | Wide refactors with no owner backing |
| Config or flag default the team already agreed | Security-sensitive auth changes on day three |
If the team has no "good first issue" culture, ask your manager: "What is a safe first production change I can own this week?" Make them help you find one.
After you can ship, leave the path better. Keep a running onboarding doc from day one: setup commands that actually worked, gotchas, links to the real dashboards, "ask X about Y." At day 60–90, put it in the team wiki or repo. The next hire ramps faster because you existed. That is ownership, not extra credit.
If official onboarding is wrong, fix the doc. Stale onboarding is a recurring tax on every newcomer and every mentor who answers the same Slack questions.
Cap setup time. Perfect dotfiles with no product change is a rabbit hole.
Common mistakes
- Waiting for a worthy first ticket. The loop matters more than the prestige of the change.
- Big-bang rewrite in week three. Small diffs. Earn context first.
- Tooling rabbit hole. Good-enough env, then ship.
Check yourself
Week one, you want to rewrite a confusing module so you understand it. Do it?
No. Ship a small real change first. Wide rewrites without context create incidents.
The team has no starter tickets. What do you ask?
"What is a safe first production change I can own this week?"
Key takeaways
- Week one: a small real change through the real pipeline.
- Logs, metrics, copy, and agreed config are good first ships. Rewrites and auth are not.
- Ask your manager to help you find one if none is obvious.
- Leave the onboarding doc better for the next hire.
Further learning
Back to the map: ramping up.
Related
Ramping up on a new team and codebase
Your first 90 days: read code by tracing paths, ask well, ship early, and map people as well as systems.
Asking good questions
Show what you tried, time-box being stuck, and batch questions so help is cheap to give.
Ownership
Acting like an owner: close loops, care about outcomes, and be the person things do not fall through with.