Day 1 — Setup rituals and Slack channel archaeology

Day 1 is 70% tooling setup and 30% pretending you didn’t just spend 45 minutes staring at a Slack window. Priorities: get access, get your local dev environment running, and map the social topology of the company Slack.

  • Run through the checklist your recruiter or hiring manager sent. If they didn’t send one, ask for it in #onboarding. It should include GitHub, Notion, GitHub repo access, packages, and a VPN if needed.
  • Do the tech: clone the repo, run npm install / pip install, and start the app with the command in README (for us it was npm run dev – your command will differ). If tests fail, don’t panic; screenshot the error and add it to your intro notes.
  • Slack archaeology — find these channels first: #announcements, #onboarding, #introductions, #engineering (or #product-engineering), #product, #help, and the team-specific channel like #backend or #growth. If you only join three channels, make them #announcements, #onboarding, and your team channel.

Intro message template — save this and paste into #introductions or #general. Short, human, and useful:

"Hey everyone! I’m Alex, starting today as a Product Engineer on the payments squad. I’m based in PST (UTC-8) and my usual overlap hours are 10am–2pm PST. Excited to dig into the codebase and meet you all. Small ask: where’s the best place to ask infra/setup questions? Thanks!"

Pro tip: add your timezone and overlap hours to your Slack profile and set a status like “New here — learning the payment flow” so folks know where you are in the onboarding timeline.

Day 2 — The first 1:1 with your manager

Your first 1:1 is not “let’s rate your first week.” It’s reconnaissance. Use it to learn expectations, priorities, and where the skeletons live. Be punctual, bring questions, and take action items.

  • Before the 1:1, send a quick agenda in Slack or calendar notes. Something like: “Agenda: 1) priorities for week 1, 2) how to approach code reviews, 3) best ways to ask for help.” This shows you’re organized.
  • Questions to ask (bring these verbatim): “What are the top 2 things you want me to deliver in the next 30 days?”, “Who should I pair with for product context?”, “How do you prefer updates — async notes or daily check-ins?”, “What’s the current biggest headache the team is solving?”
  • How to take notes: use a single Notion page or a Google Doc titled “1:1 — [Manager Name] — Week of [date]”. Timestamp action items, add due dates, and write a 1-line summary of every decision. At the end of the meeting type: “Action items: 1) Read architecture doc (due Tue), 2) Open first PR (due Thu).”

Bring follow-up: after the 1:1, send a quick Slack DM or email summarizing the action items. Example: "Thanks for the 1:1 — recap: I'll deep-dive the payments readme and open a small PR by Thursday. I'll ping Jaime for product context. Do I have that right?" This consensus saves you from wandering in the weeds.

Day 3 — The codebase and product deep dive

Day 3 is where you go spelunking in the code and product docs. The trick: be a strategic idiot. Ask lots of "stupid" questions, but show what you tried first.

  • Start with the docs: README, CONTRIBUTING.md, architecture.md, and the Notion product pages. Spend 2–3 hours reading and making a map: major services, where data lives, and the main flow the team cares about (e.g., signup → payment → onboarding).
  • Run the app locally, then break it (intentionally). Add a console.log or tweak UI text to see the change. This is how you learn the rope without being scary in a PR.
  • The "stupid questions" strategy: always pair your question with evidence of effort. Slack template: "Hey @jamie — I’m looking at payments/processor.js; I ran npm run dev and saw X console error. I tried Y (searched the repo and looked at payments readme). What am I missing?" This is specific, shows effort, and invites help.

I spent a morning running git log --graph and tracing commit messages to see why a feature existed. It felt nerdy and helpful. Keep a note of three people who seemed to touch critical files — these are your go-to experts.

Remote startup first week timeline
Timeline of common wins in week one: setup → 1:1 → deep-dive → first PR → team ritual.

Day 4 — Make a first small contribution

Your first PR should be a feather, not an anvil. Aim for a doc fix, a small bug fix, or a tiny test addition — something that gets merged fast and teaches you the workflow.

  • How to scope it: pick something that touches one file and takes no more than 2 hours. Examples: typo in README, broken link in onboarding doc, failing lint rule fix, or a one-line change that improves error logging.
  • PR checklist: describe the problem, list the steps to reproduce, show screenshots or test logs, and mention the person you’ve asked for a quick review. Use a clear title like "docs: clarify local dev steps for payments (fixes #42)".
  • Sharing your first PR in Slack — template to post in #engineering or #team when you open PR: "Opened PR #14: docs - clarify local dev steps for payments. I updated README and added a step for Docker users. Would love a quick review from @jamie or @lee. Link: [PR URL]"

Expect feedback. Embrace it. When they request changes, treat it like learning, not rejection. My first PR got two rounds of small fixes and then a :rocket: reaction — I still screenshot that reaction months later.

Day 5 — Your first team ritual

By day five you’ll probably be invited to a standup, demo, or retro. Joining rituals is how you stop being a floating specter and become a teammate. Do not try to solve the team’s roadblock in your first retro. Trust me.

  • Standups: if it’s async, post one crisp line: "Yesterday: set up local env; Today: read architecture + open small PR; Blockers: none (need product context on recurring payments)". If it’s live, keep it under 60 seconds.
  • Demos: ask one clarifying question, compliment specifics (e.g., "Love the reduced latency on checkout — curious if we measured before/after?"). Questions that connect to learning show you care about impact, not heroism.
  • Retros: listen more than you speak. If you do talk, offer a small observation or an experiment idea: "Could we try a weekly async notes channel for follow-ups?" Keep it framed as a curiosity, not a manifesto.

How to participate without being annoying: show up prepared, keep your moments short, and follow up in threads. If you don’t know the shorthand a team uses (like "SLA" meaning something slightly different), ask in-thread after the meeting rather than interrupting the flow.

Slack message templates you'll actually use

  • Intro message (short): "Hi all — I’m Alex, Product Engineer on payments. PST (UTC-8), overlap 10am–2pm. New here and eager to learn the payment flow. Where should I start for product context?"
  • Asking for help (when you’ve tried): "Hey @jamie — I’m getting 'TypeError: X is undefined' in /payments/processor.js after running npm run dev. I searched the repo for 'processor' and looked at payments readme. Error log: [paste]. Any hints on where to look next?"
  • Sharing your first PR: "PR #14 opened: docs — clarify local dev steps for payments. I added Docker notes and fixed a broken command. Would appreciate a quick review from @lee or @jamie. Link: [PR URL]"

Remote Startup Survival Kit

  • Tools: Slack, Zoom, Notion (or Confluence), GitHub, Linear (or Jira), VSCode, Docker, Figma (if you touch design). Get them installed and linked on day one.
  • Habits: calendar-block 60–90 minute focus slots, write an EOD (end-of-day) 2–3 line summary in the team channel, and ping for async context rather than dropping into DMs.
  • Boundaries: set a clear availability window in Slack and your calendar. A simple status like "Available 9–5 EST; check DMs for urgent" is better than ghosting and then rage-pinging at midnight.
  • Communication: prefer threaded replies in Slack, include screenshots, and always paste logs when debugging. People respond faster to compact, reproducible requests.
  • Mental tricks: treat every "no response" as a timezone problem, not a human problem. Buffer found that 67% of remote workers say onboarding is the hardest part (Buffer State of Remote Work). You're not alone in feeling awkward.
"Ask early, be boringly specific, and leave breadcrumbs." — My onboarding mantra, stolen from someone nicer.

If you follow this playbook you’ll move from onboarding fog to useful teammate in five days. You’ll still forget names, misread an emoji, and wonder if your camera looks ok. That’s fine — remote startups are chaotic by design.

Want a checklist PDF with the exact commands I ran and the 15 Slack messages I saved? Head to newjob.tech — they’ve got templates, job-first tips, and a community that remembers the pain of week one.