---
title: "Your First 90 Days: How to Join a Crew Without Sinking"
author: "Harry"
published: 2026-10-31T04:49:27.267Z
updated: 2026-10-31T05:08:06.868Z
category: "Career & Teams"
tags: []
canonical: "https://fxblog.dev/posts/first-90-days-new-developer-job"
---

# Your First 90 Days: How to Join a Crew Without Sinking

## Key takeaways

- The first 90 days have three jobs: learn how the team works, take on small real work, then own something end to end.
- On a healthy team nobody expects speed in month one; they watch whether you learn the right things and speak up when stuck.
- A 30-60-90 plan written in week one and agreed with your lead turns vague expectations into goals you can both check.
- Checking in every two weeks lets a slipping goal be re-planned in the open instead of discovered at the review.
- Three small pull requests a week show progress that a single giant one, stuck in review, hides.

> **TL;DR** The costly mistake in your first 90 days in a new job is trying to look fast: you rush, hide how lost you are, and get judged against expectations nobody wrote down. Write a one-page 30-60-90 plan in week one, agree it with your lead, and check it together every two weeks.
>
> **Do this:** Draft a one-page 30-60-90 plan this week, three goals a month, and book twenty minutes with your lead to agree it.

Day 1, 09:00. Pip's laptop is still installing updates. The team chat shows 200 unread messages, and someone in standup has just said "ADR" as if everyone knows what it means. Then Kit, the fox who captains the Red Fox, shakes her paw: "Welcome aboard! Biscuit?"

If your first morning felt like that, you are normal.

**Dev Voyage: Calm Sea, in five parts:**

1. **Your First 90 Days: How to Join a Crew Without Sinking** (you are here)
2. **Ask Better Questions: The Skill That Saves Your First Month**: getting unstuck.
3. **Make Friends on the Ship: Working Happily With Colleagues**: trust, on purpose.
4. **When You Break Something: Owning a Mistake Without Losing Trust**: the next hour.
5. **Pass Probation on Purpose**: a review with no surprises.

Pip and the crew are fiction. The methods are real and linked.

## Day 4, and nothing shipped

By Thursday Pip was quietly panicking. Everyone else was merging pull requests. She had merged nothing.

> **Note**
>
> **Pip:** I haven't shipped anything yet.
> **Kit:** It's day four. Is the app running on your machine?
> **Pip:** Yes! And two steps in the setup guide were wrong.
> **Kit:** Then you've already made the ship better. Go fix the guide.

Nobody on a healthy team expects speed in month one. They watch whether you learn the right things and speak up when stuck. The guide fix counts, because the next newcomer gets it for free. So does walking one tiny ticket all the way to production, just to see the path.

## Three months, three different jobs

Michael Watkins wrote _The First 90 Days_ for leaders changing roles, but his core idea fits a first developer job: a transition has phases, and each phase has a different job.

| Days  | The job                              | What good looked like for Pip                      |
| ----- | ------------------------------------ | -------------------------------------------------- |
| 1–30  | Learn the ship: code, tools, people  | App running, guide fixed, one small ticket shipped |
| 31–60 | Take a watch: real work, help nearby | Three tickets shipped, a first review given        |
| 61–90 | Own a job, end to end                | The discount rules, ticket to production           |

Your team's timing may differ. Some want ownership by week six. You only find out by asking.

## Write the plan before Friday

A 30-60-90 plan is one page: three goals a month, written by you, agreed with your lead. Pip wrote hers on day five.

```text
By day 30 (learn)
- Run the app and all tests locally; fix the setup guide
- Ship one small ticket from branch to production
- 15-minute intro call with each person on the crew

By day 60 (contribute)
- Ship 3 tickets on the checkout service
- Review at least 2 pull requests from others
- Explain the deploy process back to Kit without notes

By day 90 (own)
- Own the discount rules: one feature, ticket to production
- Check-in with Kit every two weeks; update this plan after each
```

Then she booked twenty minutes with Kit and asked: "Here's what I think good looks like. What would you change?" Kit moved one goal and added another. Now they were reading the same page.

![The 30-60-90 plan as a loop: write goals in week 1, agree them with your lead, check in every two weeks; a goal that slips is re-planned in the open, and day 90 ends in a review with evidence](https://fxblog.dev/media/01a1904a-46e7-76b2-94d2-d7f661f9e207/1600)

_Pip's plan, and what happens when a goal slips_

> **Warning**
>
> Goals slip. That's fine. A goal that slips silently becomes a surprise at your review, so at each check-in say what moved and re-plan it out loud.

## Small and visible beats big and secret

In week three Pip wanted to vanish for a fortnight and come back with the discount engine rewritten. Kit said no. A giant pull request sits in review for days, and until it lands nobody can see you moving. Three small ones a week can be reviewed over coffee.

> **Tip**
>
> Start a private notes file today: every answer you get, every trap you hit. In part 5 it becomes your probation evidence.

## Try it

This week:

1. Get the project running, fixing the setup guide as you go.
2. Draft your 30-60-90 plan: three goals a month, one page.
3. Ask your lead what they would change, and book a check-in every two weeks.
4. Open your notes file.

Pip has a plan Kit agreed to, and a first real ticket: change the discount rounding in checkout. On day 12 she is still stuck on a build error, and she hasn't told anyone for two days, because everyone looks so busy. Part 2, **Ask Better Questions: The Skill That Saves Your First Month**, is the question she should have sent on day 10, and why it gets answered in one line.

## Read this with your AI

```text
Read the post "Your First 90 Days: How to Join a Crew Without Sinking".
1. Ask me five questions about my new job, then draft my 30-60-90 plan in the same format.
2. Point out any goal in my draft that my lead could not check on day 90.
3. Suggest the one thing I should fix in my team's setup guide this week.
```

> **Success**
>
> You know what each of your first three months is for, and you have a plan your lead can agree to. Next: **Ask Better Questions: The Skill That Saves Your First Month**.

## FAQ

### What should a new developer do in the first week?

Get the project running locally, meet the people you will work with most, read how the team ships code, and write a first draft of your 30-60-90 plan to agree with your lead before the week ends.

### How fast should I be productive in a new job?

Teams expect learning in month one, small real contributions in month two and ownership of something in month three. Ask your lead what good looks like at each point; the answer belongs in your plan.