Author :
Diana Sharma
Somebody has taught you how to write code, or read a dataset, or run a discovery session. Almost nobody has taught you how to be new, which is the actual skill the first three months test.
I have sat on both sides of this. I have been the person walking in on day one with no idea where the kitchen is, and I have been the person deciding whether a new hire is working out. So this is written for the first version of you, with what I know from the second.
Start with the thing that changes everything.
This is the single most useful sentence I can give you, and almost nobody believes it in week one.
Your manager knows what they hired. They know you will be slow at first, that you will need things explained twice, and that the first few weeks cost the team more than you produce. That was priced in before you signed.
What they are watching is not output. It is how you behave while you are not yet producing much.
Do you come back with the same question three times, or do you write the answer down. Do you disappear when you are stuck. Do you notice the team's way of doing things, or do you talk continuously about how it was done at your last place. Do you follow through on the small thing you said you would do by Thursday.
That is the actual assessment. It is much more achievable than the one you think you are being given, and it is entirely within your control on day one.
Your job in the first fortnight is to build a picture of where you have landed.
Who does what. Not the org chart, the real version: who actually knows how the payment system works, who to ask about deployments, who has been there seven years and holds everything in their head.
How work arrives and where it goes. Where tickets come from, what the team does at standup, who decides what gets built, what "done" means here.
Where things live. Repositories, documentation, the shared drive, the four Slack channels that matter and the fifteen that do not.
Keep a running document of everything you learn and everything you do not understand yet. Two lists. Almost everyone who does this in a first role says later that it was the thing that made month two feel manageable.
And one more, which sounds trivial and is not. Note the names of everyone you meet and one thing about them. Week one is the only period where you can ask someone their name twice without it being awkward. Use it.
Most new starters are so worried about looking incapable that they ask too few questions, too late, and then ask them badly.
A good question shows what you already tried. "I am trying to get the test suite running, I have done x and y, I hit this error, I think it is a config problem but I am not sure where to look." Ninety seconds of your colleague's time, and it demonstrates that you are thinking.
A bad question is "this doesn't work, can you help". It hands the whole problem over and gives them nothing to work with.
Set yourself a rule for the timing, because that is what most people get wrong. Try it yourself for thirty minutes. Then ask. Thirty minutes is enough to learn something and not enough to waste a day. Nobody has ever been let go for asking at thirty minutes. Plenty of people have irritated a team by going quiet for three days.
Somewhere in this window you want a first contribution that is genuinely yours. It does not need to be impressive. A bug fix, a documentation update, a small feature nobody else wanted to pick up.
What matters is going through the full cycle once: pick it up, do it, have it reviewed, respond to the feedback, get it merged, watch it go out. Once you have done that loop once, the second one is a normal piece of work rather than an event.
Take the code review well. Your first proper review will come back with more comments than you expected and it will sting slightly. It is not a judgement of you. In a healthy team a heavily commented review usually means someone took your work seriously enough to read it carefully. Read every comment, apply them, ask about the ones you do not understand, and do not apologise five times.
By the back half of the first 90 days, the thing that earns you trust is not brilliance. It is being the person who does what they said they would do.
Give estimates and then tell people early when they are going to slip. Nobody minds an estimate being wrong. Everyone minds finding out on the due date.
Start answering questions as well as asking them. There will be something, however small, you now know better than the person who joined after you or the colleague who has never touched that part of the system. Being useful to other people is what moves you from new person to team member.
And begin to form opinions. Around week eight or ten, you will notice something that seems wrong. A process nobody likes, a piece of documentation that is out of date, a manual step that could be automated. Say it, once, without insisting. That is what an employer means by initiative, and it is remarkable how many people wait a year before offering their first one.
First, there will be a week where nothing makes sense and you privately conclude you are not cut out for this. It very commonly arrives somewhere between week three and week six, usually after the initial adrenaline wears off and before anything has clicked. It is close to universal. It is not information about your ability.
Second, you will be slower than the people around you, and you will notice constantly. You are comparing your first month against their fourth year. Compare yourself to you in week one instead.
If the wobble is persistent rather than passing, talk to someone. Your manager, a mentor, whoever you trust. Being new is temporary. Being new and silent about it is what makes it drag.
It is not a big feature or a clever solution. It is this. You know how work moves through your team. You have shipped a few small things. People know what you are good at and ask you for it. You have asked for help well and given it at least once. And you have an opinion about one thing that could be better.
That is a good first 90 days. Everything after is easier.
If you are getting ready for a first tech role, the Tech Career Launchpad is built for exactly this stage.
Own what's next.