First Week Playbook for Engineers: Read, Ask, Ship in 7 Days

Your first week as an engineer is the only time you get a free pass to ask anything. Use it. The engineers who ship a pull request by Friday of week one are the ones who are trusted with real work by month two, and the ones who drift through onboarding reading Notion pages for three weeks are the ones who get quietly deprioritized. This playbook is the exact sequence that works across Stripe, Shopify, Anthropic, and every Series B startup I have watched engineers succeed at since 2023.

The goal is not to look smart. The goal is to build a mental model of the system, meet the humans who own the parts you will touch, and produce something merged. Everything below serves those three outcomes.

Day 1 Is For Access, Not Architecture

Do not try to understand the codebase on your first day. You cannot. What you can do is remove every blocker that will stop you from being productive on day two, and most of those blockers are access-related.

Before lunch, you should have:

1. Laptop provisioned, Okta or Google SSO working, VPN connected if required
2. GitHub or GitLab access to every repo your team owns, plus read access to adjacent services
3. AWS, GCP, or Azure console access at whatever level your team gets (usually read-only to start)
4. Slack, Linear or Jira, Notion or Confluence, PagerDuty, Datadog or Sentry, and whatever internal CLI your company uses
5. The repo cloned, dependencies installed, and tests passing locally

If any of these are blocked, escalate to your manager before end of day. Do not sit quietly waiting for IT. A new engineer who cannot log in on day three is a $2,000-per-day loss and your manager would rather be pinged than have that on their quarterly review.

The single highest-leverage thing you can do on day one is get the repo cloned and a test passing. Everything else is downstream of that.

Read The Code, Not The Wiki

Every company has a Notion page called "Engineering Onboarding" that is 60% out of date. Read it once to get the lay of the land, then close it and open the actual source code.

Start with the service your team owns most directly. Find the entry point — main.go, app.py, server.ts, whatever it is — and trace a single request from HTTP handler to database query and back. Do this for the two or three most common endpoints. If you cannot name the top three endpoints by traffic, ask your tech lead or look at the Datadog dashboard.

Then look at the last 50 merged pull requests. This tells you more than any architecture doc:

• What kind of work is actually happening right now (features vs. bug fixes vs. infra)
• Who reviews whose code (the real org chart)
• What the team's definition of "done" looks like (test coverage expectations, PR description norms, how deploys get triggered)
• Which areas of the codebase are changing fast and which are frozen

By Wednesday you should be able to describe your team's service in three sentences: what it does, who calls it, and what it calls. If you cannot, you are not reading enough code.

The Questions That Earn Respect

Bad new-hire questions waste everyone's time: "What does this service do?" is answered in the README. "Who owns X?" is answered in the CODEOWNERS file. Do not ask those.

Good new-hire questions require someone with context to answer, and they signal that you have already done the reading. Examples:

• "I noticed UserService.authenticate has two code paths that look almost identical except for the Redis cache key. Is there a reason, or is that tech debt?"
• "The last three incidents I see in the postmortem channel were all about the payments queue. What is the current plan there?"
• "I see we use Temporal for workflows but the billing service still uses raw cron jobs. Intentional, or migration in progress?"
• "What is the fastest way to get a one-line config change to production? I want to know the full pipeline before I need it."

Batch your questions. Instead of pinging your tech lead eight times a day, keep a running doc and drop five questions in one Slack thread on Tuesday afternoon. This respects their focus time and makes you look senior.

Meet Seven People In Five Days

The engineers who fail at new jobs almost always fail on the human axis, not the technical one. Book 30-minute 1:1s in your first week with:

1. Your manager (probably already scheduled, make it recurring weekly)
2. Your tech lead or staff engineer on the team
3. Two peers on your immediate team
4. One engineer on a team you depend on (whoever owns your upstream API or data source)
5. One engineer on a team that depends on you
6. Your skip-level manager (director or VP), even if just 15 minutes

That is seven people. It is aggressive. Do it anyway. In each meeting, spend 80% of the time listening and 20% asking two questions: "What do you wish the previous person in my seat had done differently?" and "If you were me, what would you ship first?"

Write the answers down. The patterns across seven people tell you exactly what to prioritize in month one.

Ship Something By Friday

Your first pull request does not need to be important. It needs to be merged. A typo fix in a README. A flaky test marked as skip with a linked ticket. A deprecation warning silenced. A missing log line added to an error path you found while reading code.

The point is to exercise the full pipeline: branch, commit, PR, CI, review, merge, deploy. You will discover every broken thing in your environment — the pre-commit hook that does not run, the CI step that times out, the deploy command that requires a flag no one documented — and you will fix those things or file tickets to fix them before they block real work.

Good first-week PRs I have seen:

• Fixed a Datadog alert that had been paging on-call for three weeks with a false positive
• Added a --dry-run flag to an internal CLI that had been requested in Slack four times
• Deleted 300 lines of dead code behind a feature flag that shipped in 2023
• Updated the README with the actual local setup steps (the ones the new hire just figured out)

All of those took under four hours and all of them earned the engineer visible goodwill.

Set Up Your Personal System

By end of week one, you should have:

• A running doc of every acronym, internal tool name, and team name you have heard, with a one-line definition
• A ~/work directory with the two or three repos you will touch most, plus shell aliases for the commands you run 20 times a day
• A pinned Slack channel list: your team, your team's incident channel, the company-wide announcements channel, and one channel for the domain you are working in (payments, search, ML, whatever)
• A weekly cadence: 1:1 with manager, team standup schedule, sprint planning day, demo day
• A working local dev loop that rebuilds and tests in under 30 seconds — if it takes longer, fix that in week two

Do not skip the personal system. Engineers who treat onboarding as pure absorption get overwhelmed by month two. Engineers who build their own index stay oriented.

What To Avoid In Week One

A short list of things that look productive but are not:

• Refactoring code you just read for the first time. You do not have the context. Wait a month.
• Proposing architectural changes in your first design review. Listen and take notes. Your opinion is not calibrated yet.
• Joining every optional meeting because you want to seem engaged. Protect three-hour blocks for actual work.
• Trying to be the smartest person in the room. The smartest person in the room on day four is someone who has been there four years.
• Promising delivery timelines before you understand the deploy process.

The new hires who burn out fastest are the ones who try to prove themselves in week one on technical merit. The ones who thrive prove themselves on curiosity, humility, and follow-through.

Next Steps

1. Before end of day Monday, confirm every access listed in the "Day 1" section above. If anything is missing, Slack your manager directly — do not file a ticket and hope.
2. Block two hours on Tuesday morning, close Slack, and trace one HTTP request end-to-end through your team's primary service. Write a one-paragraph summary and share it with your tech lead for correction.
3. By Wednesday, have seven 1:1s booked across days 3-10. Use the same two questions in each.
4. By Thursday afternoon, open your first pull request. It does not matter how small. Get it through CI and into review.
5. On Friday, write a one-page document titled "What I learned in week one" — the top five surprises, the top three questions still unanswered, and what you plan to ship in week two. Send it to your manager before the weekend. This is the single best career move a new engineer can make in month one.

Related guides

• First Week Playbook for Data Scientists: Access, Baselines, Stakeholders — A concrete first-week plan for data scientists in 2026: get data access on day one, establish baselines, and map the stakeholders who will act on your work.
• First Week Playbook for Designers: Design System Audit, Stakeholder Map — The first-week plan for designers joining a new company in 2026: audit the design system, map stakeholders, and ship one visible deliverable.
• First Week Playbook for Product Managers: Listening Tour, Quick Wins — How new PMs should spend their first five days in 2026: structured listening tour, roadmap archaeology, and two credibility-building quick wins.
• New-Manager Onboarding Playbook — First 90 Days as an EM — The first 90 days as an EM at a new company determine the next two years. Here's the week-by-week playbook for listening, shipping, and earning trust.
• First-Day Questions to Ask Your Manager: The Year-One List — The specific questions to ask in your first one-on-one that set up year-one success. No filler, no soft-pedaling — a checklist you can bring into the meeting.