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

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.

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.

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.

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.

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.

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

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.